Some folks from iOS has been talking for some time...

# android-architecture

[Pablichjenkov]

Some folks from iOS has been talking for some time about the popularity of MVVM-Coordinator or just Coordinators Architecture in iOS.
Has anyone tried a similar approach to tackle navigation logic in Android?

[ruialonso]

I'm working on that, check my project https://github.com/RuiMiguel/themoviesapp/tree/develop/base/src/main/java/com/gigigo/themoviesapp/base/navigation

[ruialonso]

I first tried Architecture component Navigation but I don't like it yet 😞

[ruialonso]

anyway, my BaseNavigator implementation could be changed to use architecture components' one, I have to try it

[rkeazor]

MVVM is the preferred architecture in android. @ruialonso what didnt you like about Nav component. I used it in a prod app before and really liked it

[rkeazor]

I would say , try it agian. There latest iteration has really come along way

[ruialonso]

I had many problems with navcontroller scope , like back navigation

[ruialonso]

I'm waiting for newer versions 😄

[ruialonso]

I could implement my navigation giving architecture components a second chance, but still using coordinator

[rkeazor]

Hmm what in particular about back navigation gave you a issue

[ruialonso]

I had different navgrap for different features, to split them

[ruialonso]

when navigating from one to other, sometimes gave me error due to NavController scope didn't find actions

[rkeazor]

Was there a reason why they were in different nav graphs?

[ruialonso]

the solution was using MainActivity to get scope of actions

[ruialonso]

https://developer.android.com/guide/navigation/navigation-design-graph

Another way to modularize your graph structure is to include one graph within another via an <include> element in the parent navigation graph. This allows the included graph to be defined in a separate module or project altogether, which maximizes reusability

[rkeazor]

Yea I understand that it is possible. I was just wondering if there was a reason why you split of graph per feature. Ie: they were in different modules.. or each feature had a seperate activity. We did the same thing but because some screens had bottom nav and some different. So instead of hiding it manually we decided not to take the single activity approach and just have a seperate activity for the one without the bottom Nav. That was the little bit of complexity

[Pablichjenkov]

The problem MVVM-C tries to resolve is putting away Navigation Logic either from Fragments or from ViewModels. It makes it easy to have a dynamic navigation. What I mean by dynamic is being able to change your app flow without app updates.
In fact that's one of the major caveats I see with the Navigation Components, you need to know your app flow ahead of time.
Using coordinators a json file could be provided from the server with the coordinators tree and the app will dynamically adapt. Making the same code reusable for more than one app. Honestly, I haven't played with all the Navigation Component details, maybe something similar can be achieved.
At Rui Alonso, I don't see an explicit Coordinator class in your code. You decide to change the class name?
I am talking about this Coordinator:

https://benoitpasquier.com/coordinator-pattern-swift/

[ruialonso]

each module has its on Coordinator at navigation package. It's a first attempt, to be more "" with pattern, I would need an AppCoordinator to rule them, and not explicity calling coordinators from viewmodel, instead use events on viewmodel and coordinators implements these ones

[ruialonso]

you're right @Pablichjenkov, I will develop it

[Pablichjenkov]

Oh cool!

[Pablichjenkov]

I did an attempt to try the concept in Android some time ago:
https://github.com/pablichjenkov/Coordinators/blob/master/coordinator/src/main/java/com/ncl/coordinator/Coordinator.kt
In theory the AppCoordiantor will live in the MainActivity scope in a single Activity app. Otherwise it will have to go to the Application scope. In iOS everything is so simple because ViewControllers keep a relationship of type Parent-Child.
In Android Activities are more like orphan siblings, they don’t talk to each other(unless you serialize data), they don’t know who their parent is. Also they are instantiated by the framework which make it harder to keep track the instance.
Hopefully the future moves to SingleActivity and a bunch of Compose Components.