I’ve worked quite a bit on a library named , specifically to make it easy to use custom viewgroups as the building blocks of applications. simple-stack Android However, the proved to be a bit difficult to work with — delegating numerous lifecycle callbacks just to make it work. Using a retained fragment, this is much easier. Enter , a new additional to . BackstackDelegate Navigator Simple-Stack 1.5.0 Navigator uses ‘s internally, just like — while also providing some sensible defaults. [**Navigator**](https://github.com/Zhuinden/simple-stack/blob/master/simple-stack/src/main/java/com/zhuinden/simplestack/navigator/Navigator.java) simple-stack BackstackManager BackstackDelegate Previously, you had to set up like this (with the benefit of working from API 1 and above): simple-stack opts to use the “retained fragment as lifecycle listener” approach employed by both (MinSDK 16+) and (MinSDK 14+), while also provides a default implementation, reducing installation to: Navigator Conductor Flow DefaultStateChanger I’d say that reduces quite a strain from the library user, right? :) Instead of relying on manual callbacks and having to persist view state, the retained fragment gets callbacks from the Activity. And as retained fragments survive as long as the activity does, we can even ditch ! onRetainCustomNonConfigurationInstance() In case you’re curious, this is essentially what the fragment does: This is all technically code that the library user no longer needs to write. Woo! Default State Changer But with Min SDK 11 comes , therefore allowing default animations — therefore making it reasonable to create default state changers and default animators. ObjectAnimator If the user chooses to use , then their state keys must implement an interface called . This is what specifies the layout which has the custom viewgroup as the root, and the view change handler that handles the animations. DefaultStateChanger StateKey As you can see, our specifies a , which will handle left-right and right-left animation (depending on direction). StateKey SegueViewChangeHandler But it’s just as easy to provide one for fading over, or even with transitions: And in the end, creating a more complex version of the looks like this: DefaultStateChanger After that, you can use your custom viewgroups just as you would, any other time. Conclusion Hopefully you like what you saw in , (check out the sample, maybe even the sample), and consider dropping intents and fragment transactions for the sake of simplicity. :) Navigator mvp nestedstack If not, just the other day I saw a library: , that functions as a “command buffer” for navigation operators — exactly what is achieved internally by simple-stack’s and methods — but as it’s just the command buffer/processor, it can be integrated against any already existing solution — for example, activities and fragments. If custom viewgroups really aren’t your cup of tea, that is worth checking out. Cicerone detachStateChanger() reattachStateChanger() backstack In my opinion, viewgroups are more predictable, so I’m sticking with them. No need to manually destroy and recreate them just to place them into a container with a different ID; this is something that in contrast, . fragments could learn from
