Persisting view-state when using a custom backstack: Creating a Flow-like custom backstack (Part 4)

We’ve been creating a backstack for 3 parts now, and have solved a few problems:

But we need to be able to persist the view state so that views that are removed still preserve their state, and we must also make sure we can restore this even across process death.

If you check the good ol’ Flow this example is influenced by, it did not use to have a KeyManager class, it did not have any means of persisting view state with the library.

So we’re not gonna add it to the library yet either, we’ll just add it to the example.

— — — — — — — — — — — — — — — — — — — — —

Persisting the viewstate

Actually, I can just show the commit that adds view-state persistence to our Activity, and explain afterwards. Look!

So what can we see here?

Saving the view hierarchy state

In order to save the state of our view hierarchy, there is a convenient method called view.saveVierarchyState(SparseArray<Parcelable>).

We can store this as a Parcelable, along with a few other things; and we need this to be identifiable.

The State class

We added a State class for storing our viewstate, and it stores 3 things:

  • the Key of the given view (to identify this state later when we restore it)
  • the SparseArray<Parcelable> that is the saved view hierarchy state
  • a Bundle in case we want to add additional data to our stored state.

The State is Parcelable so that we can persist it to Bundle in the form of ArrayList<Parcelable>, just like we do with keys (which represent the application state).

Keeping track of the State

In order to keep track of the state, we store it in a Map that binds it to our Key ( so it is Map<Key, State>).

We create a new entry in this map during the state changer callback (to preserve the previous view’s state, the one that we swap out and remove), and in onSaveInstanceState() (to preserve the current view’s state).

Removing States that are no longer needed

When a state change occurs, we clear out the states we no longer need using keySet.retainAll().

Restoring State after process death/config change

And when our Activity is restored, we also restore the keyStateMap as well from the savedInstanceState Bundle.

Conclusion

With that, it actually works!

Now that we have solved the problem of saving our state, we’ve solved our most aching problems.

But we still have some pain points:

  • we don’t have convenient lifecycle callbacks to our views for when they get created, and removed (or destroyed) ~ although maybe we could use square/coordinators for that
  • you need to add a bunch of code in your Activity to integrate the backstack, and the application state/view state persistence. Maybe we could move this code out, into the library?

In the meantime, the current source code is available here.

--

--

--

Android dev. Zhuinden, or EpicPandaForce @ SO. Extension function fan #Kotlin, dislikes multiple Activities/Fragment backstack.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Connect react with redux, redux-saga

Temporary Web-Hosting using XAMPP and ngrok

Basics of React.js I

Revising Front End Basics

My (Un)Usual Font End Stack

ESLint and Prettier setup in typescript with a Husky Pre-commit Git hook

When to quote JavaScript array keys?

Document your React components using docz

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Gabor Varadi

Gabor Varadi

Android dev. Zhuinden, or EpicPandaForce @ SO. Extension function fan #Kotlin, dislikes multiple Activities/Fragment backstack.

More from Medium

How to write and to read files from Kotlin in JetPack Compose

RecycleView Kotlin — Android Studio

Exploring Android 12: BiometricPrompt Localizable Strings

Android 12 for developers — Changes and Improvements in the User Experience and Design