Why deplay 600ms when click success?

[Mystery00]

https://github.com/maxkeppeler/sheets-compose-dialogs/blob/5b0d0bbf4b9e12451bb0f4a72f33e1645e6d1e11/core/src/main/java/com/maxkeppeker/sheets/core/utils/BaseConstants.kt#L31

https://github.com/maxkeppeler/sheets-compose-dialogs/blob/5b0d0bbf4b9e12451bb0f4a72f33e1645e6d1e11/core/src/main/java/com/maxkeppeker/sheets/core/models/base/BaseBehaviors.kt#L47-L51

After a successful operation, I noticed a delay of approximately 600 milliseconds before the completion callback for the subsequent operation is triggered. I'm curious about the reason behind this design. What is the intended purpose of this delay? I would appreciate an explanation. Thank you!

[Mystery00]

Maybe provide a setting to adjust the delay time?

[maxkeppeler]

The 600ms delay happens when hiding the button view. This delay ensures the completion of the item animation for selection, preventing the dialog or view from disappearing abruptly. However, this delay is not applied if the dialog or view includes buttons.

The delay occurs before any listeners are triggered and before the dialog closes. A shorter delay might lead to issues, but using the buttons view could be more suitable for your use case. Once the user clicks the positive button, the dialog closes immediately.

[Mystery00]

I still think that when there is no button displayed, a shorter delay should be provided for a better user experience. But I respect your existing logic. Perhaps a delay of 600 ms provides a better experience on some low-spec devices, ensuring smooth animations without sudden disappearance of dialog boxes. Nonetheless, on high-spec devices, a 600 ms delay after clicking might give the impression that the app is unresponsive. I will attempt to replace certain scenarios with a dialog format to avoid this delay. I also want to express my gratitude to you for your contributions to this project and for taking the time to address my issues.

[maxkeppeler]

Can you show me a recording of this scenario? I remember that the duration of selection animations was up to 600 ms, which is why it's set to 600 ms. However, if I'm wrong and it's less, we can reduce it. A minimum would be around 300 ms.

[Mystery00]

https://github.com/maxkeppeler/sheets-compose-dialogs/assets/19162205/685b1f28-3dc5-4820-984e-97869e868955

And this is my code https://github.com/Mystery00/XhuTimetable/blob/master/app/src/main/java/vip/mystery0/xhu/timetable/ui/activity/PagerWeekCourse.kt#L257-L274

[Mystery00]

https://github.com/maxkeppeler/sheets-compose-dialogs/assets/19162205/02c0e381-fc5f-4f02-af7b-6c385edd6458

Another scenario with code https://github.com/Mystery00/XhuTimetable/blob/master/app/src/main/java/vip/mystery0/xhu/timetable/ui/activity/PagerTodayCourse.kt#L643-L669

[Nek-12]

I agree, this delay is too much. The screencasts above clearly show that the app hangs for 600ms

[maxkeppeler]

Will be fixed when I find the time, promised!

[maxkeppeler]

I will go for a 300ms delay. Looks fine to me with the OptionDialog and CalendarDialog. If you see any issues due to this change, let me know.