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

fix: activity center closing animation #15222

Merged
merged 1 commit into from
Mar 1, 2023
Merged

Conversation

OmarBasem
Copy link
Member

fixes: #15221

@OmarBasem OmarBasem self-assigned this Mar 1, 2023
@status-github-bot status-github-bot bot added this to REVIEW in Pipeline for QA Mar 1, 2023
fix: activity center closing animation

lint

lint
@status-im-auto
Copy link
Member

status-im-auto commented Mar 1, 2023

Jenkins Builds

Commit #️⃣ Finished (UTC) Duration Platform Result
e29d5de #2 2023-03-01 08:55:01 ~2 min ios 📄log
✔️ e29d5de #2 2023-03-01 08:57:04 ~4 min tests 📄log
✔️ e29d5de #2 2023-03-01 09:01:16 ~8 min android 🤖apk 📲
✔️ e29d5de #2 2023-03-01 09:11:04 ~18 min android-e2e 🤖apk 📲

Copy link
Contributor

@ilmotta ilmotta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You did remember to fix the springy animation! Thank you 🎆

I still find the bottom sheet opening animations too slow when using the mobile app, but it's not something we should worry in this PR. I usually grab a cup of coffee between bottom sheet opening and closing animations ☕ 😉

Gone with the spring!

@OmarBasem OmarBasem merged commit 4a6e42c into develop Mar 1, 2023
@OmarBasem OmarBasem deleted the fix-popover-animation branch March 1, 2023 11:12
Pipeline for QA automation moved this from REVIEW to DONE Mar 1, 2023
@OmarBasem
Copy link
Member Author

I usually grab a cup of coffee between bottom sheet opening and closing animations

@ilmotta HAHAHA! 😃

I still find the bottom sheet opening animations too slow when using the mobile app

This PR improves it a bit, but still far from perfect. As we discussed before, it would have been better if we used a screen, but of course due to the design constraints a screen may not give the intended look.

It looks okay on iOS, but on Android, for some reason, there is some delay between the initial screen overlay appearing and the activity center view animating. We can investigate further in another issue.

@ilmotta
Copy link
Contributor

ilmotta commented Mar 1, 2023

It looks okay on iOS, but on Android, for some reason, there is some delay between the initial screen overlay appearing and the activity center view animating. We can investigate further in another issue.

@OmarBasem, this is a very important topic you're touching. Just today I explained to Andrey why this delay exists and how it could be eliminated.

I'm gonna quote myself:

The button delay I've solved in a branch that's not ready to become a PR yet. The only way to eliminate the delay was to force re-frame to render the notifications outside the batch that renders the AC bottom sheet. This delay always existed. I hope to get this improvement merged in the next 1 month hopefully.

-- #15216 (comment)

@ilmotta
Copy link
Contributor

ilmotta commented Mar 1, 2023

@Parveshdhull

Do you know why we have a fixed delay of 250ms to render popovers? https://github.com/status-im/status-mobile/blob/develop/src/status_im/popover/core.cljs#L9

This delay is far too long as Omar and Andrey recently reported. Delays above 100ms are easily perceived as lag by humans. I'm pretty sure there's a reason for this, but if I lower it to say 30ms, opening the AC feels snappy, way better. I'm assuming the dispatch-later is to force re-frame to start opening the popover in a separate rendering batch, which is a fine approach I used many times as well. I'm just wondering why the huge 250ms delay?

@Parveshdhull, if you think the 250ms is necessary, I'll change the popover event to accept a delay-ms parameter to at least solve the problem for the AC without impacting other popovers.

Edit: cc'ing @flexsurfer who might have context as well

@flexsurfer
Copy link
Member

i don't remember :( probably not needed anymore, but I'm more wondering why is it used for AC

@ilmotta
Copy link
Contributor

ilmotta commented Mar 1, 2023

i don't remember :( probably not needed anymore, but I'm more wondering why is it used for AC

You mean the popover? The popover is needed due to the requirement to display the blurred (live) background behind. I was even in a meeting with John discussing about this.

It seems we can't use a screen, and if performance becomes an issue in the future an external RN expert will be considered to implement/optimize screens so that we can blur the screen behind without resorting to popovers (this external contributor could be the same one working on the optimized flatlist).

This "blur problem" will exist for the new Settings "screens". The designs require live & blurred backgrounds, but I talked to designers and John and the requirement to keep the blur is non-negotiable 🤷‍♂️

@OmarBasem
Copy link
Member Author

OmarBasem commented Mar 1, 2023

Btw, why do we have both popovers and bottom-sheets? I think both can achieve the same effect. Doesn't this create a bit of confusion?

@ilmotta
Copy link
Contributor

ilmotta commented Mar 1, 2023

Answering a little bit my own question. Without at least a 1ms delay to dispatch the popover event the popover is never displayed. I honestly don't want to fix this problem properly now because it's lower priority, but I'll open a PR to at least allow the delay to be configured by the caller.

It seems that the popover is only properly displayed with a bit higher delays, like 10+ ms. So I guess someone decided to use 250ms to play on the safe side.

@ilmotta
Copy link
Contributor

ilmotta commented Mar 1, 2023

Btw, why do we have popovers and bottom-sheets? I think both can achieve the same effect. Doesn't this create a bit of confusion?

Confusion might be very personal. But I can speak for myself, yes, I'm confused by the terminology.

@flexsurfer
Copy link
Member

Answering a little bit my own question. Without at least a 1ms delay to dispatch the popover event the popover is never displayed. I honestly don't want to fix this problem properly now because it's lower priority, but I'll open a PR to at least allow the delay to be configured by the caller.

It seems that the popover is only properly displayed with a bit higher delays, like 10+ ms. So I guess someone decided to use 250ms to play on the safe side.

most likely it was me , popover was a really rare case, so i decided to play safe

@ilmotta
Copy link
Contributor

ilmotta commented Mar 1, 2023

Answering a little bit my own question. Without at least a 1ms delay to dispatch the popover event the popover is never displayed. I honestly don't want to fix this problem properly now because it's lower priority, but I'll open a PR to at least allow the delay to be configured by the caller.
It seems that the popover is only properly displayed with a bit higher delays, like 10+ ms. So I guess someone decided to use 250ms to play on the safe side.

most likely it was me , popover was a really rare case, so i decided to play safe

Did the right call ;) I'll open a PR, but I'll keep the default 250ms @flexsurfer. I'm not in the mood of introducing weird regressions in other places and in some devices if I lower it too much.

@flexsurfer
Copy link
Member

i think i remember why, because popover react view has an animation itself, we use RNN popover only as a container and it doesn't have an animation, yeah right i even left a comment ;TODO refactor popover just start animation on mount :)

@ilmotta
Copy link
Contributor

ilmotta commented Mar 1, 2023

i think i remember why, because popover react view has an animation itself, we use RNN popover only as a container and it doesn't have an animation, yeah right i even left a comment ;TODO refactor popover just start animation on mount :)

I saw the comment before, but I was still left wondering why the hardcoded high delay. Now we know, thanks.

ilmotta added a commit that referenced this pull request Mar 2, 2023
Make the popover delay in milliseconds configurable.

To open the Activity Center, 30ms delay seems to be more than enough. It's a quick fix because the current 250ms to open the AC gives the wrong impression to users (and confuses even us developers) who think the AC has a performance issue to open.

See issue #15222 for the full discussion.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Add closing animation to activity center
4 participants