Skip to content

Issue/6852 add username changer#7151

Merged
hypest merged 26 commits intofeature/new-signupfrom
issue/6852-add-username-changer
Jan 26, 2018
Merged

Issue/6852 add username changer#7151
hypest merged 26 commits intofeature/new-signupfrom
issue/6852-add-username-changer

Conversation

@theck13
Copy link
Copy Markdown
Contributor

@theck13 theck13 commented Jan 23, 2018

Fix

Add a username changer for social signup as described in #6852.

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. Tap Username input field.
  7. Notice Change Username screen with username suggestions.
  8. Tap X action in toolbar.
  9. Notice Username input field is unchanged.
  10. Tap Username input field.
  11. Tap any username from suggestions.
  12. Notice username changes in header text.
  13. Tap X action in toolbar.
  14. Tap Discard action in dialog.
  15. Notice Username input field is unchanged.
  16. Tap Username input field.
  17. Tap any username from suggestions.
  18. Tap X action in toolbar.
  19. Tap Cancel action in dialog.
  20. Tap Save action in toolbar.
  21. Notice Username input field has changed.
  22. Tap Username input field.
  23. Tap any username from suggestions except first suggestion.
  24. Enter text to get new username suggestions.
  25. Notice new username suggestions are displayed.
  26. Notice selected username is first in suggestions.

@hypest hypest self-requested a review January 23, 2018 10:23
@hypest
Copy link
Copy Markdown
Contributor

hypest commented Jan 23, 2018

Works nicely @theck13 , good job!

I'm a bit confused with the FullScreenDialogFragment class. Can you elaborate on what needs does it address? What functionality is it abstracting away from UsernameChangerFullScreenDialogFragment for example? Thanks!

@theck13
Copy link
Copy Markdown
Contributor Author

theck13 commented Jan 24, 2018

I'm a bit confused with the FullScreenDialogFragment class. Can you elaborate on what needs does it address?

I created the FullScreenDialogFragment class with the idea of reusability across the app for the fullscreen dialog pattern since it isn't included in the design or support libraries.

What functionality is it abstracting away from UsernameChangerFullScreenDialogFragment for example?

The biggest advantage of wrapping FullScreenDialogFragment around UsernameChangerFullScreenDialogFragment is that it allows us to use any Fragment as a fullscreen dialog rather than only DialogFragments.

If we would like to go with a different implementation, we can create an optimization issue and an associated pull request once we find a better solution.

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.

Thanks for the explanation @theck13 !

I think that at present, FullScreenDialogFragment doesn't seem to engulf key functionality that UsernameChangerFullScreenDialogFragment would be too verbose/bloated to implement itself if we subclass a DialogFragment directly.

That said, this PR works as designed and I don't see a good reason to block it on this. So, yeah, let's open an optimization ticket to implement the full-screen-dialog directly in UsernameChangerFullScreenDialogFragment, thanks!

In the meantime I finished my review pass and left some fairly minor comments. Please have a look! Thanks!

protected boolean mShouldWatchText; // Flag handling text watcher to avoid network call on device rotation.
protected int mUsernameSelectedIndex;

public static final String EXTRA_DISPLAY = "EXTRA_DISPLAY";
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.

I guess this one was meant to be named EXTRA_DISPLAY_NAME instead, right?

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 constant name in 7b63b43.


protected void launchDialog() {
final Bundle extras = new Bundle();
extras.putString(UsernameChangerFullScreenDialogFragment.EXTRA_DISPLAY, mEditTextDisplayName.getText().toString());
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 introducing a "newInstance" type of method to hide away the setup of the input bundle? For example, a UsernameChangerFullScreenDialogFragment.newInputBundle() static method could accept the displayName and the username as parameters and return a properly populated bundle ready to be passed to .setContent() 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 added the newBundle method in 1537644.

}
}

mUsernamesAdapter = new UsernameChangerRecyclerViewAdapter(getActivity(), suggestionList);
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.

Perhaps here's an opportunity to reuse setUsernameSuggestions() after setting mUsernameSelectedIndex = 0?

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 method in 71818d2.


private void setUsernameSuggestions(List<String> suggestions) {
mUsernamesAdapter = new UsernameChangerRecyclerViewAdapter(getActivity(), suggestions);
mUsernamesAdapter.setOnUsernameSelectedListener(UsernameChangerFullScreenDialogFragment.this);
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.

Qualifying the this with UsernameChangerFullScreenDialogFragment is probably redundant here, right?

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.

It's a little verbose, but it doesn't hurt anything and it makes things absolutely clear.

}

protected void showDismissDialog() {
new AlertDialog.Builder(getContext())
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.

This alert dialog seems to not survive rotation. It's not super important to survive it so I'll leave it up to you to assess if this needs to be addressed. 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 dialog to survive device rotation in 1f25851.

public static final String KEY_USERNAME_SELECTED_INDEX = "KEY_USERNAME_SELECTED_INDEX";
public static final String KEY_USERNAME_SUGGESTIONS = "KEY_USERNAME_SUGGESTIONS";
public static final String RESULT_USERNAME = "RESULT_USERNAME";
public static final int GET_SUGGESTIONS_INTERVAL_MS = 2000;
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.

Highly subjective: 2secs feel a bit much for my taste. Wdyt about making it 1s or around 1s?

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.

This is subjective and fairly arbitrary. I chose a value that would try to ensure the user has stopped typing in order to avoid premature and frequent network calls. It would be better if we had data to support that decision though. @folletto, do you have any idea what a good time would be for this interaction? This value is the amount of time in milliseconds to wait after the user has stopped typing to fetch the username suggestions from the API.

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.

The delay should be sub-1s. I think we use 250-300ms in search in Calypso, with debounce and sequencing the calls to avoid an old call to reset a newer call.

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.

I'm debounching the calls based on an (arbitrarily chosen) 400ms delay for the relevant constant in site-creation domain selection screen. I can adjust it to 250-300 if we decide to.

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 think we use 250-300ms in search in Calypso

I would argue that we should not follow the desktop pattern for mobile in this case and avoid making multiple network calls in quick succession for a few reasons.

  1. Metered data
  2. Network speed
  3. Network reliability
  4. Typing speed
  5. Typing reliabiliy

Waiting 2000ms might be too slow, but 300ms feels way too fast. @hypest's suggestion of 1000ms or more might be a good compromise.

Copy link
Copy Markdown
Contributor

@folletto folletto Jan 25, 2018

Choose a reason for hiding this comment

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

I disagree here. Calypso has all the same considerations for mobile web. That timing is also a timing based on human expectation of a response, and bounce+sort take care of the networking aspect regardless of the connection.

Native here has also the advantage of having faster response times than a web app in both typing and network stack, compared to Calypso on mobile on point 2+3+4+5.

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 value in ec00d88.

@hypest
Copy link
Copy Markdown
Contributor

hypest commented Jan 25, 2018

Thanks for the changes @theck13 ! Let me know if another pass will be needed or this is ready for merge. It's 👍 from my side. Thanks!

@hypest
Copy link
Copy Markdown
Contributor

hypest commented Jan 26, 2018

The discussion in #7151 (comment) got worked on over chat so, let's get this merged @theck13 !

@hypest hypest merged commit 5b388bd into feature/new-signup Jan 26, 2018
@hypest hypest deleted the issue/6852-add-username-changer branch January 26, 2018 22:08
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.

3 participants