-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Dax dialog with two buttons #713
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
Dax dialog with two buttons #713
Conversation
Removing one layer of ConstraintLayout for one LinearLayout to simplify working with margins between buttons.
… from SecondaryButtonCta
* Introduce new logic to show/hide a secondaryButton on DaxDialogs. * Change DaxDialog creation logic inside Cta. * Adapt BrowserTabFragment listener logic to new chanes.
| </androidx.constraintlayout.widget.ConstraintLayout> | ||
| <com.google.android.material.button.MaterialButton | ||
| android:id="@+id/secondaryCta" | ||
| style="@style/Widget.AppCompat.Button.Borderless.Colored" |
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.
does it make sense to extract this to our own Button style?
|
|
||
| fun onUserClickCtaSecondaryButton(cta: SecondaryButtonCta) { | ||
| cta.secondaryButtonPixel?.let { | ||
| pixel.fire(it, cta.pixelSecondaryButtonParameters()) |
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.
is this ok being launched in the main thread?
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.
ApiBasedPixel:Pixel will excecute it in a background thread. So we are good here.
|
If this is not going to be used for now, does it make sense to merge into develop or to keep a feature branch where you add multiple PRs? Just wondering if something were to change before it's finished, we'd have to change code that is potentially released to Play Store but is not being used yet. |
|
Thanks @malmstein for the review. About target branch on this PR, I'm happy with both approaches, I think both are valid but I will stick to the preferred one for the team. If it feels more natural creating a feature branch and merge everything there, I will move to that one and we can discuss this topic on our next mobile functional meeting. |
|
Assigning to myself to test all the cta scenarios since I know them very well but @malmstein and others, feel free to do your reviews as well, I just want to make sure all the ctas still work as expected :) |
|
@cmonfortep yes, please don't merge items not ready for release into develop. |
marcosholgado
left a comment
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, left a comment in case you want to think about naming :D
| fun setDaxText(daxText: String) | ||
| fun setButtonText(buttonText: String) | ||
| fun setDialogAndStartAnimation() | ||
| fun onAnimationFinishedListener(onAnimationFinished: () -> Unit) |
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 onAnimationFinishedListener is specific to the typing animation and is triggered when it finishes. I would suggest to move it to another interface or make it specific to the TypewriteDaxDialog class but this would make DaxDialogHighlightView a bit messier.
The other option is to assume the DaxDialog always is going to have the typing animation (which it does for now) and maybe rename TypewriteDaxDialog to something more generic? Having TypewriteDaxDialog makes me think there is another version without the typing animation when in reality there isn't.
I don't think is massively important to stop the PR but it feels a very specific name for something that's always used like that.
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, onAnimationFinishedListener can be moved into an interface and DaxDialogHighlightViewwill not be affected. The only part that will be affected is where we create those dialogs. But I liked that you commented on that. I think we can delay that change till we introduce a different Dax dialog, that is also the reason why I didn't segregate that interface into different ones.
As per the name, I'm fine changing the name or using this concrete one (because the interface takes the generic name), so I'm open to suggestions here. Tbh, I could come up with something else.
Task/Issue URL: https://app.asana.com/0/0/1162132608576977/f
Tech Design URL:
CC: https://app.asana.com/0/0/1158941144031452/f
Description:
This PR is some preparation work that will be related (and be used) in a future task, where we will implement new Ctas with two buttons.
For context: To show our CTAs as Dax dialogs we will make use of a Dax dialog with two buttons. Usually, the secondary button will be used to dismiss the dialog.
Design can be found here: https://app.asana.com/0/0/1158941144031452/f
Within the scope of this PR, you will find the following changes:
Steps to test this PR:
Currently, the new Dax dialog with two buttons is not used in any part of the project (but it will be). Testing the new dialog with 2 buttons will be included on a future PR once we have the experiment ready to be reviewed.
Then, do we need to test something? yes, ensure new changes don't affect how normal dialogs are shown. To testing that part:
mvExample:
Internal references:
Software Engineering Expectations
Technical Design Template