I haven’t had a chance to use the Navigation Library in a project but what you’re saying sound close to what I’d do. I’d probably create a Router interface and the concrete implementation would take the NavigationController as a dependency that you could route the calls to.
As far as the API getting more complicated I think that might be justified considering the current methods for navigating in Android feel bolted on in some cases. So in this case I’d expect the API to grow a bit more from what we currently have as it’d be gluing certain pieces together. If we looked at all of the different APIs used for navigating in Android I’d be curious how much larger the actual API becomes. For example: I can get away with just startActivity for a basic app, but once I get into managing fragments and those stacks is the Navigation Component still larger? Once I account for entering the app through push notifications or other means, will my home grown solution be any less complex?
None the less, I still really enjoyed reading this article I think I pointed out a number of good points. As someone working on a still fairly new app that is considering moving to using the Navigation Component it gave some good counter arguments to keep in mind.
