-
Notifications
You must be signed in to change notification settings - Fork 6
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
[ABW-2744] Access factor sources refactoring - create accounts #761
[ABW-2744] Access factor sources refactoring - create accounts #761
Conversation
// if main babylon factor source is not present, it will be created during the public key derivation | ||
val publicKeyAndDerivationPath = accessFactorSourceProxy.getPublicKeyAndDerivationPathForFactorSource( | ||
accessFactorSourceInput = AccessFactorSourceInput.ToCreateAccount( | ||
forNetworkId = onNetworkId, | ||
factorSource = if (isWithLedger && selectedFactorSource != null) { | ||
selectedFactorSource | ||
} else { | ||
null | ||
} | ||
) | ||
) |
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.
actually here is the part that I don't like and we discussed about it in the chapter meeting.
What it should be ideal here is to pass an already created babylon device factor source and not to pass the null.
...va/com/babylon/wallet/android/presentation/accessfactorsource/AccessFactorSourceProxyImpl.kt
Outdated
Show resolved
Hide resolved
import rdx.works.profile.derivation.model.NetworkId | ||
import javax.inject.Inject | ||
|
||
class AccessFactorSourceProvider @Inject constructor( |
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 am a bit confused with the purpose of this class. It does not access any factor sources, it looks like to me a wrapper of methods that will get increasingly bigger in the future like a utils class. Both methods below have no connection together.
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.
my initial idea is to push all the related to access factor sources (either derive public key or signing) logic in the profile module and keep the viewmodel of the bottomsheet with the minimum logic. And then this "provider" would return the result (public key, signers) to the UI.
However, that's not really possible because some factor sources e.g. ledger are off device.
But I still think to proceed with this way and see how this will escalate. Maybe this provider can be a "AccessOnDeviceFactorSourcesWhatever".
This refactoring is definitely not in the final version( in this PR) and it's in my mind that design can change later when implementing the rest of factor sources.
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.
also keep in mind that this class would go away with the shared lib 😄 and this is one more reason to keep the view with the minimum access factor sources logic 😉
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.
Understood, I get your point
isAccessingFactorSourceInProgress: Boolean, | ||
isAccessingFactorSourceCompleted: Boolean, | ||
showContentForFactorSource: AccessFactorSourceUiState.ShowContentFor, |
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.
Currently this content is only for deriving public keys, correct? If so we should separate each case on its own composable or have different dialogs for different cases. Like
Instead of naming this AccessFactorSourceBottomSheet
we could name it like DerivePublicKeysDialog
. Then we can create other dialogs that do other things with factor sources and let the app event decide what dialog to open.
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.
Yeah it seems that one dialog might be too much to handle all the factor sources., and that's also in my mind for a future change. But my answer here is similar to the above. Let's see how it will really escalate and proceed step by step.
Btw I am not gonna merge this PR, it needs testing from us and Umair, and if all looks fine then I will merge.
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.
Agreed
af736ef
to
688feb7
Compare
3eee9f8
to
fe9fcec
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.
Overall looks good and works fine. Nice work. One thing that might be a bug is scenario when you create first time account with ledger. Please see attached video and let me know if doing biometrics twice is expected here:
screen-20240129-124527.mp4
yeah right, I also spotted this last week and am aware of it. Thanks for clarifying it! |
688feb7
to
4825e52
Compare
e3a2419
to
3431b7c
Compare
5376eb4
to
e525b75
Compare
b9c754d
to
2110b4e
Compare
e525b75
to
feed700
Compare
create accounts with an interface
the profile module and update ProfileGenerationTest
not to derive public key from it
the new CreateAccountUseCase
when purpose is to derive public key
AccessFactorSourcesViewModel
ff8318e
to
fb12bc4
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.
Tested works fine 👍
Quality Gate failedFailed conditions |
115fc02
into
feature/ABW-2743-create-basic-ui-for-bottom-sheet
Description
This PR:
CreateAccountUseCase
that accepts only factor sources that are able to create account, seeFactorSource.CreatingEntity
interface. RemovedCreateAccountWithBabylonDeviceFactorSourceUseCase
andCreateAccountWithLedgerFactorSourceUseCase
AccessFactorSourceProvider
in theprofile
module that access theMnemonicRepository
and theProfileRepository
in order to calculate the derivation path and to derive the public keyAccessFactorSourceProxy
that works as a mediator between the UI (bottomsheet), and the "clients" who request access to factor sources, e.g.CreateAccountViewModel
requires a public key of the factor source to create an accountChooseLedgerScreen
to return the selected ledger device and to not derive the public keyThis PR is a chained PR of the #750
How to test
Please test it not only by creating accounts with device and ledger but also by switching networks and creating accounts during the flows that creation is possible (e.g. when login to a dapp)
Video
Screen.Recording.2024-01-23.at.11.38.59.AM.mov
PR submission checklist