Ribs: [android] RIBs tree management & recreation

[almozavr]

Context

One of the main problems in view-based android architecture is screens tree/stack management in terms of Activity recreation. E.g. imagine Activity is killed in background and user returns to the app and expects to see the same (some child) screen he left from – for the RIBs my concerns are:

How to recreate the whole tree of RIBs?

I could think of couple solutions:

1. retain some kind of map of active child ribs for each rib to maintain it's children re-creation?
2. use ScreenStack to keep track of children ribs;

Is there common strategy for this case at the uber? Unfortunately I can see no way to implement ribs in real-world apps with more or less complex screen hierarchy without screen tree retention. E.g. square's Flow recovers *screen objects stack which is popped up on activity rotation/recreation, same thing for Conductor, but I'm afraid I can see no such mechanism for the RIBs.

[AttwellBrian]

Talk about this briefly in https://github.com/uber/RIBs/wiki/Android-Specific-Questions

Both of the ideas you mention could work. Although they will be tricky if you are building RIBs with "dynamic dependencies" that get passed into RIBs.

Looking at the common patterns in our apps, we usually do the following: ignore the lifecycle completely. We persist network state with a repository pattern. When re-opening the app, we decide which RIBs to recreate using the same code paths that created these RIBs the first time. Or in some cases we don't worry about recreating the tree at all.

Ray Ryan and I have chatted about the differences between Flows approach and RIBs approach. Both have upsides and downsides for different apps.

[dron247]

May be it's too late, i just have simple state machine(thinking on something automatic/generic) in each RIB interactor which decides what are we going to attach to parent. Since we have an access to save/restore of instance state we can write something, which will be enough to decide later, and we can restore from it later, since the bundle is basically going back and forth through our component graph everything will be stored there(if we nicely handling instance state in our views, having unique ids and so on). During restoration process we are reading needed keys in root->ribTier2->ribTier3 and because of that we have incremental state restore process since each level decides how to construct its children after reading what it previously saved to that bundle. @almozavr

[almozavr]

thanks for all the replies, and sorry for such a late response.
So, we've end up building something very similar to RIBs but with the help of conductor & kodein: it turned out conductor has *everything in place to be the perfect android-to-mvp glue code and scoping / routing framework, also the kodein helps a lot with dealing with scopes dependency tree in a much more simple (but, yes, non-compile-time-errors-aware) way.
I'd like to share the sample within couple weeks, so will put a link here to compare the things.

[artman]

Closing thread as stale.