Replies: 3 comments
-
@ilmotta I have noticed that the AC opening animation does not execute on Android in debug mode (at least on my device), but it does in release mode. So check in release mode if it is showing the same behaviour described above. |
Beta Was this translation helpful? Give feedback.
-
its not only AC, the problem is global, we have more heavy screens, probably we should find some general solution, most of the time it will be screens with flat list or scroll view |
Beta Was this translation helpful? Give feedback.
-
@OmarBasem, yes, unfortunately it does happen in release mode in a real device. As @flexsurfer said, we'll need to find better solutions to optimize lists of heavy components. I felt like raising this issue just for future reference, I don't intend to attack this problem now. |
Beta Was this translation helpful? Give feedback.
-
Problem
When the Activity Center has more than a handful notifications (e.g. 10), opening it can sometimes cause the modal animation to not be displayed to the user. This behavior can be observed in real devices, as well as in emulators, both in iOS and Android.
Solution
The theory goes that we should reduce the weight of rendering notifications when the AC first opens, which would allow re-frame to do the more important work of rendering the AC modal, with all the tabs, etc. So one of the simplest ideas is to just reduce the time to render each individual notification and see if it solves the animation problem.
Another approach or even a complementary approach to point
1)
could be to animate the layout entering state of notifications. I've experimented with this in the past, and we can get interesting results, but keep in mind there's a known bug in layout animations for Reanimated FlatList. See my comment for more details Animate insertion/removal of notifications in the Activity Center #14683 (comment).Yet another complimentary option is to only pay the cost of mounting the AC once, and reuse it when the bell icon is pressed a second time. By itself, this idea won't solve the clumsy animation when first opening an AC full of notifications, but if implemented correctly it can lead to nice improvements. But this solution should probably be avoided because it puts more pressure on Reagent and re-frame to keep the UI in sync with the app state, even if the AC is hidden. There are ways to circumvent this problem of course.
We can or even should consider rendering less notifications when first opening the AC. Due to the way pagination is currently implemented, when the AC is opened, at most 8 notifications are fetched for the first page, and if the FlatList bottom threshold is reached
onEndReachedThreshold
, the second page is fetched and at most 16 (8 + 8) notifications are rendered. Ideally, we should render only the bare minimum when opening the AC. This problem is not exclusive of the AC. In theory, we could come up with a more general solution for paginating a FlatList that doesn't blindly fetch the full second page.Beta Was this translation helpful? Give feedback.
All reactions