-
-
Notifications
You must be signed in to change notification settings - Fork 162
-
-
Notifications
You must be signed in to change notification settings - Fork 162
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
What's about reworking MaterialDialogs.ShowAlertAsync to make it really awaitable and return Task<bool> instead? #4
Comments
Hi. You have a point, and I like your suggestion. I still have time until the day after tomorrow to apply this, along with the other feature request. Can you wait until then? I'll update you also if I was not able to apply it. If so, you can just send me a pull request. |
That's fine. I am not in a rush. Just mentioning that. Also, you might know better if there are some other places you can consider having same logic as well. |
And speaking of other things... In the confirm dialog, if you have the title too long to fit it into one line, it will be cut as on wrapping it's still going to have height == 40. Is there any reason why you made it fixed? |
I can also fix that. I set it to 40 since it was the recommended height, but I forgot to consider long titles. BTW, thanks for raising these issues/suggestions. |
I will also add your suggested implementation for |
Version 1.0.6 has been released, adding |
Hi!
I've tried also
MaterialDialogs.ShowAlertAsync
which works fine in general.However, with current implementation I can't see a way of notifying when the alert (confirmation) box is closed with negative (cancelling) result.
Currently the method is (in general) awaitable, which completes on the confirm popup appearing, however, usually, it doesn't have much sense from the app logic functionality perspective. From my experience, it's rather more important to be able further processing of the app logic after the choice been done.
So, I would suggest to rework it to return
Task<bool>
, which would complete after the used made his choice.What do you think? I can also fork and apply that update as well if you have no time for that.
The text was updated successfully, but these errors were encountered: