question about router deactivation order

[davissuber]

This is a question regarding the reason why Routers first deactivate themselves before dispatching the deactivation to their children and perhaps a proposal to reverse that order.

For Android, the code is in this neighborhood, where dispatchDetach is called before detachChild (which will eventually call dispatchDetach on the child as well).

For iOS similar behavior can be observed here in the deinit block of Routers.

[psteiger]

Did you encounter a specific use case where you would rather have your suggested behavior instead of the current behavior?

With that asked, in principle I agree with you: children must have a lifecycle less than or equal to the parent, so it makes sense for them to be deactivated before the parent.

[davissuber]

When using RIBs with simple-store - it's quite reasonable to use the lifecycle provided by RIBs to manage simple-store (or any other resource that can only be opened once and needs to be closed when done).

In the current ordering where the children outlives the parent RIB, if one opens the simple-store in the parent RIB with the intention that both the parent RIB itself and the child RIB will make use of the store - there's a small window where the parent RIB will be deactivated (and the store cleaned up) while there are still activities coming from the children that make use of the store.

We are seeing some sporadic "the store is already closed" errors that could be caused by the current parent-child-deactivation-ordering - but still collecting evidence of such claim / find other causes and want to do some tentative finger-pointing in the process.

[davissuber]

An update: we are able to repro the issue and it does seem that this ordering of children outliving the parent is creating problem for unsuspecting developers who binds an SimpleStore to the parent RIB's lifecycle, and use the store in the children lifecycle.

Perhaps the sharing of simple store across different scope provider per se is a bad way to use that library and one shouldn't make any strong assumption between parent and child scope deactivation order. 🤷

At any rate, given the potential impact of swapping the deactivation order at RIBs level - we are seeking alternative solutions to our problem at the moment, but it is our belief that the current behavior is creating some surprises in managing resources like simple store.