Issue/6852 add username changer#7151
Conversation
…gment input field
|
Works nicely @theck13 , good job! I'm a bit confused with the |
I created the
The biggest advantage of wrapping 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. |
hypest
left a comment
There was a problem hiding this comment.
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"; |
There was a problem hiding this comment.
I guess this one was meant to be named EXTRA_DISPLAY_NAME instead, right?
|
|
||
| protected void launchDialog() { | ||
| final Bundle extras = new Bundle(); | ||
| extras.putString(UsernameChangerFullScreenDialogFragment.EXTRA_DISPLAY, mEditTextDisplayName.getText().toString()); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I added the newBundle method in 1537644.
| } | ||
| } | ||
|
|
||
| mUsernamesAdapter = new UsernameChangerRecyclerViewAdapter(getActivity(), suggestionList); |
There was a problem hiding this comment.
Perhaps here's an opportunity to reuse setUsernameSuggestions() after setting mUsernameSelectedIndex = 0?
|
|
||
| private void setUsernameSuggestions(List<String> suggestions) { | ||
| mUsernamesAdapter = new UsernameChangerRecyclerViewAdapter(getActivity(), suggestions); | ||
| mUsernamesAdapter.setOnUsernameSelectedListener(UsernameChangerFullScreenDialogFragment.this); |
There was a problem hiding this comment.
Qualifying the this with UsernameChangerFullScreenDialogFragment is probably redundant here, right?
There was a problem hiding this comment.
It's a little verbose, but it doesn't hurt anything and it makes things absolutely clear.
| } | ||
|
|
||
| protected void showDismissDialog() { | ||
| new AlertDialog.Builder(getContext()) |
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
Highly subjective: 2secs feel a bit much for my taste. Wdyt about making it 1s or around 1s?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
- Metered data
- Network speed
- Network reliability
- Typing speed
- 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.
There was a problem hiding this comment.
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.
|
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! |
|
The discussion in #7151 (comment) got worked on over chat so, let's get this merged @theck13 ! |
Fix
Add a username changer for social signup as described in #6852.
Test