-
Notifications
You must be signed in to change notification settings - Fork 741
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FTUE] - Email input and verification #5868
Conversation
onSuccess = { it.toRegistrationResult() }, | ||
onFailure = { | ||
when { | ||
action.threePid is RegisterThreePid.Email && it.is401() -> RegistrationResult.SendEmailSuccess(action.threePid.email) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the 401 == successful pid sent
logic is no longer handled at the UI/fragment layer but instead at our business logic layer
This logic feels like something that should be part of the SDK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree!
) | ||
} | ||
|
||
private tailrec suspend fun handleCheckIfEmailIsValidated(registrationWizard: RegistrationWizard, delayMillis: Long): RegistrationResult { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uses tailrec
to provide recursion with the safety of avoiding stackoverflows, the kotlin compiler will optimise this to an imperative loop
else -> RegistrationResult.Error(it) | ||
} | ||
} | ||
) ?: handleCheckIfEmailIsValidated(registrationWizard, 10_000) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
previously we were providing the verification polling through the entire fragment -> viewmodel -> sdk
stack, now it only happens here, the start/stop api remains the same
985178a
to
4c114e4
Compare
b9ff015
to
1a68211
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor remarks, otherwise good work!
import javax.inject.Inject | ||
import org.matrix.android.sdk.api.auth.registration.RegistrationResult as SdkRegistrationResult |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe rename SdkRegistrationResult
by MatrixRegistrationResult
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
views.emailEntryInput.error = null | ||
views.emailEntrySubmit.isEnabled = it.isEmail() | ||
} | ||
.launchIn(lifecycleScope) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's safer to use viewLifecycleOwner.lifecycleScope
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great catch, will do 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
b2e3dd1 updated other usages as well
viewModel.handle(OnboardingAction.PostRegisterAction(RegisterAction.CheckIfEmailHasBeenValidated(0))) | ||
} | ||
|
||
private fun showLoadingIfReturningToScreen() { | ||
when (inferHasLeftAndReturnedToScreen) { | ||
true -> views.emailVerificationWaiting.isVisible = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we not always showing the loader by the way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the idea was to avoid the impression that app was busy/loading when we're waiting for the user to click the link in the email verification
the middle ground was to show the spinner if we detect the user has left and returned to app as we're inferring that they've clicked the link and the app is now waiting for the homeserver to respond
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, this is a great UX improvement, thanks!
d037dde
to
0c556a2
Compare
6ae54a5
to
e56a459
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work!
Some remarks on the form.
Also, out of interest, how will be managed the case where a homeserver requires either an email or a phone number to let the user create an account?
Not sure if covered by the previous question, but is the optional email case correctly handled?
vector/src/main/res/layout/fragment_ftue_wait_for_email_verification.xml
Outdated
Show resolved
Hide resolved
@Binds | ||
@IntoMap | ||
@FragmentKey(FtueAuthEmailEntryFragment::class) | ||
fun bindFtueAuthEmailEntryFragment(fragment: FtueAuthEmailEntryFragment): Fragment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe one day #5420 will be implemented...
vector/src/main/java/im/vector/app/core/extensions/TextInputLayout.kt
Outdated
Show resolved
Hide resolved
vector/src/main/java/im/vector/app/core/extensions/TextInputLayout.kt
Outdated
Show resolved
Hide resolved
vector/src/main/java/im/vector/app/core/extensions/TextInputLayout.kt
Outdated
Show resolved
Hide resolved
vector/src/main/java/im/vector/app/features/onboarding/ftueauth/FtueAuthWaitForEmailFragment.kt
Outdated
Show resolved
Hide resolved
viewModel.handle(OnboardingAction.PostRegisterAction(RegisterAction.CheckIfEmailHasBeenValidated(0))) | ||
} | ||
|
||
private fun showLoadingIfReturningToScreen() { | ||
when (inferHasLeftAndReturnedToScreen) { | ||
true -> views.emailVerificationWaiting.isVisible = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, this is a great UX improvement, thanks!
super.onError(throwable) | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for moving this out of the View!
app:layout_constraintBottom_toTopOf="@id/emailVerificationSpace5" | ||
app:layout_constraintEnd_toEndOf="@id/ftueAuthGutterEnd" | ||
app:layout_constraintStart_toStartOf="@id/ftueAuthGutterStart" | ||
app:layout_constraintTop_toBottomOf="@id/emailVerificationFooter" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe show this Button and the TextView above with the same strategy than the loader, i.e. when we detect that the user is coming back after checking their email? Or after a delay of, let's say, 30s?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will delegate this to @daniellekirkwood
I would be weary of hiding the button based on them leaving and returning as some users may use a different device to verify the email
vector/src/main/res/layout/fragment_ftue_wait_for_email_verification.xml
Outdated
Show resolved
Hide resolved
I might be missing something, this PR is for the homeserver requiring an email, or is it possible to require email without also verifying it? The phone number input case will be handled by another ticket #6043 Optional email wasn't something we were aware of, will raise with product |
0422b74
to
65832ef
Compare
…lick logic for resending verification emails
…ying to the waiting for verification title
…tching designs - renames drawable which redirects to the attribute colorBackground
…e email entry step - matching legacy flow
- fixes crash where the scheduled callbacks can attempt to trigger after the view has been destroyed
65832ef
to
98a421a
Compare
…it to be cancelled when resetting the auth flow - extracts an auto cancelling job delegate
98a421a
to
c71f9c8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (did not make a full review)
Matrix SDKIntegration Tests Results:
|
Type of change
Content
Introduces new dedicated email entry and waiting for verification fragments to the FTUE onboarding flow.
RegisterActionHandler
, adds tests around the polling.Motivation and context
Fixes #5278
Screenshots / GIFs
Flow
Phones
Small Phone
Tablet
Tests
Tested devices