Issue/6851 add epilogue social#7048
Conversation
| import javax.inject.Inject; | ||
|
|
||
| public class SignupEpilogueSocialFragment extends LoginBaseFormFragment<SignupEpilogueListener> { | ||
| private String mEmailAddress; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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!
|
|
||
| @Override | ||
| protected @LayoutRes int getContentLayout() { | ||
| return 0; |
There was a problem hiding this comment.
Let's add some comment here to explain the 0 (perhaps similar to this comment), thanks!
|
|
||
| @Override | ||
| protected void setupLabel(@NonNull TextView label) { | ||
| } |
There was a problem hiding this comment.
Similar to above, let's add some comment on the reason why the method is empty, thanks!
| </org.wordpress.android.widgets.WPTextView> | ||
|
|
||
| <org.wordpress.android.widgets.WPTextView | ||
| android:id="@+id/signup_epilogue_header_username" |
|
|
||
| </android.support.v7.widget.CardView> | ||
|
|
||
| <org.wordpress.android.widgets.WPLoginInputRow |
There was a problem hiding this comment.
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.
| 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). |
There was a problem hiding this comment.
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!
| DialogInterface.OnClickListener dialogListener = new DialogInterface.OnClickListener() { | ||
| @Override | ||
| public void onClick(DialogInterface dialog, int which) { | ||
| switch (which) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
| } | ||
| } | ||
|
|
||
| private class DownloadAvatarAndUploadGravatarTask extends AsyncTask<String, Void, Void> { |
There was a problem hiding this comment.
Since there is no feedback returned to the UI, can we demote the AsyncTask to a simple Thread perhaps?
There was a problem hiding this comment.
I updated the class to a Thread in 12ccfd1.
|
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. |
|
🚢 it! |
Fix
Add an epilogue screen for social signup as described in #6851.
Test
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
wasabiDebugorwasabiReleasebuild, you must go through the steps to add your development environment configuration to thegoogle-services.jsonfile. Alternatively, you can download avanillaDebug,vanillaRelease,zaplhaDebug, orzalphaReleaseAPK from Buddybuild.