Skip to content

Issue/6851 add epilogue social#7048

Merged
hypest merged 39 commits intofeature/new-signupfrom
issue/6851-add-epilogue-social
Jan 19, 2018
Merged

Issue/6851 add epilogue social#7048
hypest merged 39 commits intofeature/new-signupfrom
issue/6851-add-epilogue-social

Conversation

@theck13
Copy link
Copy Markdown
Contributor

@theck13 theck13 commented Dec 28, 2017

Fix

Add an epilogue screen for social signup as described in #6851.

Test

  1. Clear app data.
  2. Tap Sign Up button.
  3. Tap Sign Up with Google button.
  4. Choose Google account.
  5. Notice Epilogue for Social screen.
  6. Edit Display Name field.
  7. Notice display name in header updates while editing.
  8. Tap Continue button.
    a. If display name was changed, notice progress dialog.
    b. If display name was not changed, notice no progress dialog.

Note

To test this code with a wasabiDebug or wasabiRelease build, you must go through the steps to add your development environment configuration to the google-services.json file. Alternatively, you can download a vanillaDebug, vanillaRelease, zaplhaDebug, or zalphaRelease APK from Buddybuild.

@aerych aerych mentioned this pull request Dec 28, 2017
10 tasks
Copy link
Copy Markdown
Contributor

@hypest hypest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made a first pass @theck13 and left a few comments; let me know if anything's not clear. I will do some more testing but wanted to give the chance to address feedback earlier than later. Thanks!

import javax.inject.Inject;

public class SignupEpilogueSocialFragment extends LoginBaseFormFragment<SignupEpilogueListener> {
private String mEmailAddress;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super minor: it seems that there's a convention in the rest of wpandroid's codebase to have the constants defined at the top of the module file and have the instance data definitions after. What do you think about shuffling this around to match the convention?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doing a quick search of the code shows examples of constant variables both before and after instance variables. Let's leave it as is for now and address things like this when implement code style rules (e.g. Checkstyle) that way we can enforce a single convention.


public static final String TAG = "signup_epilogue_fragment_tag";

@Inject
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another super minor: thanks to FluxC conventions, we seem to put the @Inject annotation on the same line as the field definition itself. What do you think about matching that? Thanks!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the annotation in f37ba70.


@Override
protected @LayoutRes int getContentLayout() {
return 0;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add some comment here to explain the 0 (perhaps similar to this comment), thanks!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I add the comment in 0ab9db4.


@Override
protected void setupLabel(@NonNull TextView label) {
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to above, let's add some comment on the reason why the method is empty, thanks!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a comment in c3f9ca2.

</org.wordpress.android.widgets.WPTextView>

<org.wordpress.android.widgets.WPTextView
android:id="@+id/signup_epilogue_header_username"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Judging from the code, we seem to only put email addresses here so, let's rename this accordingly to avoid confusion. WDYT?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the identification in be4851b.


</android.support.v7.widget.CardView>

<org.wordpress.android.widgets.WPLoginInputRow
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With WPLoginInputRow moved to the loginlib, this now needs to be updated to org.wordpress.android.login.widgets.WPLoginInputRow. Same for the second input box below.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the views in ce7429a.

mInputUsername.getEditText().setOnKeyListener(new View.OnKeyListener() {
@Override
public boolean onKey(View view, int keyCode, KeyEvent event) {
// Consume keyboard events except for Enter (i.e. click/tap) and Tab (i.e. focus/navigation).
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was reading the comment (and understood the code) but wasn't aware why we need to do that. Then I figured it out: it's because we basically hack the input box. We want it to look but not behave like one and instead launch the dedicated username changer UI. What do you think about adding that reasoning to the comment here? Thanks!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a comment in 6caef61.

DialogInterface.OnClickListener dialogListener = new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
switch (which) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about adding the DialogInterface.BUTTON_NEUTRAL case too, with a comment that "nothing special, just let the dialog dimiss" since we are using that third option anyway with setNeutralButton?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems subjective since it doesn't make the switch statement more readable. If the case is excluded, it is ignored. If the case is added with only a comment, it is ignored. It's effectively the same. Looking at the statement now, it can be seen which cases produce actions simplifying readability. Adding a case just for a comment seems too verbose.

Copy link
Copy Markdown
Contributor

@hypest hypest Jan 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, let's just add the comment, quickly explaining that the neutral case is ignored as the dialog is being let to simply dismiss. This makes it clear that it's a deliberate functionality, instead of overlooked case. Thanks!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a comment in 41a48a7.

}
}

private class DownloadAvatarAndUploadGravatarTask extends AsyncTask<String, Void, Void> {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since there is no feedback returned to the UI, can we demote the AsyncTask to a simple Thread perhaps?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the class to a Thread in 12ccfd1.

@hypest
Copy link
Copy Markdown
Contributor

hypest commented Jan 19, 2018

Tested out the feature and works nicely @theck13 !

The only pending comment is this one.

One thing I want to run by you is: the Gravatar uploader works in parallel with the epilogue screen and I wonder what would happen if its completion happens after the user has continued/dismissed the epilogue or it fails altogether. There will be a "broken window" there but, we don't need to cover that here in this PR. What do you think about adding tracks to the error cases so we could have an idea how often the errors happen?

Come to think of it, let's hold off adding tracks to this path until we have some indication that we need the data/statistics there.

@hypest
Copy link
Copy Markdown
Contributor

hypest commented Jan 19, 2018

🚢 it!

@hypest hypest merged commit 6b8e4e5 into feature/new-signup Jan 19, 2018
@hypest hypest deleted the issue/6851-add-epilogue-social branch January 19, 2018 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants