'Implementing animations in a Flow-driven Android App [closed]
I'm working on a personal project involving an android app which eschews multiple activities and fragments and instead works with custom views and Flow. Generally, I have navigation set up to work as follows:
I have Screen objects which are the key for my Flow navigation. Each screen object is associated with a layout Id and has an inner class presenter to handle presenting the view.
Navigation is then pretty simple; when I want to move to a screen, I give that screen to Flow. We go to the dispatcher and the magic happens; the dispatcher gets the incoming layout from the screen, detaches the old layout from the content ViewGroup, and attaches the newly inflated layout. Boom! Magic!
Clearly, the dispatcher needs to handle animating in and outgoing views - it knows everything we need to know. The incoming screen type, outgoing screen type, and the traversal direction. The bigger question is where to store the animations, and how to choose which animation to use. Here are some solutions as I see them:
Let the presenters do it
Makes sense, yeah? The presenters job is to present, so it makes sense to have it handle the animation. A lot of animations will be the same though, so having it this deep in the scope might not make sense, and hooking up the presenter to the dispatcher requires a few interfaces that add annoying boilerplate. It's also tricky to have the presenter remove the old layout! Overall, this method doesn't seem elegant to me.
Give the Screens type identifiers
Since some animations might be shared, we could choose which animations to use by giving each Screen object a type - detail, list, etc - which determines which to use. I don't love this idea - lose some control for sure.
Just keep it in the dispatcher
Don't overcomplicate things, just keep animations in the dispatcher where the change itself happens. This makes swapping the old and new layouts after the animations easier, but it feels like it's not in the scope of the dispatcher to animate things.
Offload it to a new helper class to handle things
This is probably the best option, but I have no idea how I would structure such a class!
So, fundamentally, the problem is:
Given two screens, how to choose how to animate the transition at the time of them switching. Are there any good design patterns in particular to apply here?
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|
