Ribs: RIB state clarification for a specific use case

[Axelsyrex]

Hey!
My team is in a state of picking an architecture for a big application, both android and iOS. I read in details all your documentation and watched probably every video regarding this matter, but still some questions wander in my head.
I am doing a simple PoC of an application that has two screens, one for showing a list of names(Strings), and another for adding a new name. There are two approaches that come to my head, but I am having trouble to identify which is the right one. The both approaches consist of 3 RIBs: Root, Names, AddName. The difference between the two approaches is that the first one has a linear-like flow which means the order of RIBs is Root->Names->AddName, while the latter has a tree-like flow Root->Names, Root->AddName. The second approach leaves the decision of which RIB to be shown in the hands of the Root. My question is which one seems more appropriate to you in a matter of following the state principle of RIBs correctly? IMHO I think the first approach seems more logical, but I have doubts.

[igordeoliveirasa]

@Axelsyrex
You can do first option, second options or both. There is no rule on this case.

But I think Root->Names->AddName is a common scenario.

[stoimen01]

Hello!
I have a little problem with the Root->Names->AddName approach on Android.
The problem comes from the fact that Names and AddName RIB's should fulfill the whole screen space.
So at the moment when i try to route from Names to AddName RIB I have no space to attach the
AddName View. Thus I'm forced to remove all the stuff from the Names View and then to attach the AddName View. I hope there is better way to accomplish this. I've come up with passing the root view to the children RIB's and attach/detach with it but I'm not sure if this is the best way to do it. If you have any suggestions please tell us.
Thanks i advance.

[kovpas]

@Axelsyrex this depends on the application actually. If the Names RIB is not supposed to know which RIB comes next, then the Root RIB should decide that. For instance, Names RIB might actually not show the AddName RIB unless the user is logged in. Which means that Root RIB should be informed about the intention of the user and decide which screen to show.

On the other hand, this approach has drawbacks: if you leave every single decision up to the Root RIB, its router and interactor would become big pretty quickly.

There's really no wrong or right approach in this situation, look at your application needs and decide which way to go.

[Axelsyrex]

@kovpas thank you for the answer, I think I get what you mean now. Basically RIB A should not decide to attach another RIB B that depends on a state outside the scope of RIB A. Please correct me if I am wrong.

[kovpas]

@Axelsyrex yes, that sounds correct. Although, you can propagate the decision to the RIB A, by propagating dependencies that are needed for the decision. So it really depends on the architecture and the responsibilities of each RIB.