Skip to content
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

OnActionClickListener is not safe #33

Closed
0x7e57 opened this issue Jun 10, 2020 · 3 comments
Closed

OnActionClickListener is not safe #33

0x7e57 opened this issue Jun 10, 2020 · 3 comments

Comments

@0x7e57
Copy link

0x7e57 commented Jun 10, 2020

Click on the ActionButton will execute the onActionClick() method and automatically close the SnackProgressBar, however, there is an opportunity (accidentally or intentionally) to click on it several times before the SnackProgressBar closes. The onActionClick() will execute twice, leading to unpredictable results.
Please lock the ActionButton after the first click.

@tingyik90
Copy link
Owner

tingyik90 commented Jun 12, 2020

Seems to be a valid concern, although this has been an issue in Android for a long time.
I have made the commit 6f54f36 to prevent double click. Please try implementation 'com.github.tingyik90:snackprogressbar:master-SNAPSHOT' and let me know if this solves the issue.

@0x7e57
Copy link
Author

0x7e57 commented Jun 12, 2020

This problem occurs everywhere: when you click on View, when navigating through Fragments and Activitys and other actions in the UI.
Activity.finish()
Activity.startActivity()
navController.navigate()
...
We can not guarantee that the user does not have time to perform any other action on the still available MyViews, before one of these commands is executed. What all this can lead you can imagine. It is a pain.
Even your parentView.addView(overlayLayout) does not add overlayLayout to the screen instantly. MyViews will be available for a while.

As for the commit 6f54f36, I checked it in work, everything is fine. Thanks!

@tingyik90
Copy link
Owner

tingyik90 commented Jun 12, 2020

You are right and that was what led to the development of this library in the first place.

In the early days, as I recalled, Material Design stated that user input should never be blocked even if something is in progress, which is just impossible sometimes. As we cannot predict what user will be doing over the few seconds of the process in background, the simplest method is just to block the whole screen and show a progress bar to notify user that something is happening.

Anyway, thanks for the confirmation. Releasing as v6.4.2.

If you can offer better, faster way to add the overlayLayout, feel free to submit a pull request. Currently, when show() is being called, the overlayLayout is the first to be shown or hidden, before showing the snackProgressBar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants