Too many steps to invoke Navigator method, isnt it?

[fabius-bile]

Could someone explain me why Navigator's methods are calling from activity, not from fragment directly? Why first we invoke presenter's method which in turn invoke fragment's method which invoke activity's method?

[Trikke]

I don't know the entire implementation by heart. But the Navigator is injected into the Activity so it resides there. The point of the Presenter is to separate the View logic. So the only thing a View does is let the Presenter know something happened, the View doesn't care what happens. It's only job is to render stuff and notify the Presenter. The Presenter wants to issue a navigation event, so it calls the Activity to make this happen, via the Navigator. So now everyone's responsibilities are nicely divided.

[fabius-bile]

But is it so necessary to inject Navigator to activity, we can make all its methods static?

[Trikke]

I'm not the author, so i'll leave it up to @android10 to comment on that. I'm guessing it's implemented like this so you have a concrete implementation of Navigator. Navigation is a complex subject, and is quite simple in this demo project, but in "actual apps" it can be a complex task. The author might have chosen this approach because in the near future, his Navigator might hold some navigation logic that is dependant on more variables. Or he can go the polymorphism route and have different navigators for different scenario's. Also, Unit Testing plays a big part in this. So it's good to have a concrete class.

You shouldn't look at it like "this is how it is done". Your code and architecture is dependant on your scope and needs. But be sure to spend time thinking about how you want to handle it and not just throw a bunch of static methods in there and be done with it.

[android10]

@Trikke completely agree :+1: . It is about encapsulating navigation logic in one place (with one responsibility). As it is pointed out, we can either inject different implementations or even include collaborator to the navigator class. It is up to the consumer :). Also we can easily test navigation flow. Static methods are hard to test.

[MightySeal]

Actually, i think it might be ok to merge Navigator and BaseActivity. Separate Navigator is ok while there is no need to implement complicated animations using transitions, shared elements, etc, since these animations usually require not only Context, but view ids.