Skip to content
Gabor Varadi edited this page May 2, 2017 · 15 revisions

Why would I need Simple-Stack?

As Dianne Hackborn from the Android development team once said:

Once we have gotten in to this entry-point (Activity) to your UI, we really don't care how you organize the flow inside. Make it all one activity with manual changes to its views, use fragments (a convenience framework we provide) or some other framework, or split it into additional internal activities. Or do all three as needed.

You don't need multiple Activities to manage your "flow" inside your application.

In my experience, using one Activity instead of orchestrating multiple of them is much easier to work with. But the alternatives had too much baggage to work around.

This is why Simple-Stack was created.

Overview

Simple-Stack provides an easy way to keep track of your state in a persistent manner - across configuration change and process death alike.

But surviving in Android is not easy, and providing a general-purpose solution for tracking your state also isn't either.

The following tasks need to be done:

  • on configuration change, a backstack must be restored as a non-configuration instance, or preserved using a retained fragment

  • on process death, the state must be reloadable from the saved instance state bundle

  • after onPause(), you shouldn't be able to send new navigation operations, but they should be queued up

  • if onPause() froze navigation, then onResume() or onPostResume() should unfreeze it

  • animations (state transition) aren't immediate, so a state change can be an asynchronous operation


With that in mind, Simple-Stack provides means to easily hide all that bogus and concentrate on your backstack and your active state.

Simple-Stack also provides some sensible defaults to start out with for a Single-Activity view-based architecture.

Clone this wiki locally