A quick glance on single activity approach with navigation component

Gabriel Samojło
AndroidPub
Published in
3 min readJul 20, 2018

So it’s pretty official. After introducing Navigation Component at Google I/O, Google announced that the recommended app approach is single activity per application.

Today we are introducing the Navigation component as a framework for structuring your in-app UI, with a focus on making a single-Activity app the preferred architecture.

source: https://android-developers.googleblog.com/2018/05/use-android-jetpack-to-accelerate-your.html

This approach wasn’t working for me very well. Handling all of those transitions, passing data, persisting state and managing complex lifecycles across tens of fragments… That’s a bit too much. So when Google started talking about single activity per app I wasn’t very happy. I thought then: “But hey, we have navigation component! Let’s take a look at it!”. And one idea came to my mind.

I imagined a really simple app with only one activity and three fragments. Rules are simple: the First fragment has collapsing toolbar with recycler view. The second one should have a regular toolbar but in a different colour variant, and the last of the fragments shouldn’t have any toolbar at all.

It’s not a big deal even without Navigation but I tried to implement it just to see how it will look like. And I was disappointed. “Built-in” support was only dedicated for ActionBar so managing different toolbars was really painful. Each of the fragments had to set its own action bar which is not so good. Of course, it’s not a big deal with only three fragments, but imagine tens of them! Basically, there were two possible solutions to this problem: implement toolbar logic (like showing up button and delegating its click to navigation controller, colouring, updating title etc) in each fragment or handle it globally in Activity. Both of them looks like really bad choices to me. I started to look for some pieces of information about this “new recommended approach” but I didn’t find anything explaining how Navigation helps to implement this kind of architecture. So I just said to myself: “Okay, I don’t want to follow this, I like the way my apps are written now, maybe that’s a better approach”. I closed Android Studio and forgotten about the whole thing.

And this article could be ended here with all this complaining about how Navigation Component doesn’t support single activity apps very well. But about week ago Google released alpha03 version of it. And it has a really nice feature which finally makes a lot easier to maintain my problem.

The new version has now two new methods:

NavigationUI.setupWithNavController(Toolbar, NavController)NavigationUI.setupWithNavController(CollapsingToolbarLayout, NavController)

What does it mean? It basically solves all of my problems which I considered as the biggest issues of how Navigation makes it easy to implement a single activity approach. Now we can easily set up our Toolbar or CollapsingToolbarLayout with NavController without using ActionBar at all! That gives us the ability to use Navigation across many fragments with various kinds of toolbars without worrying about setting them up by our own. That gives us cleaner code fully integrated with Navigation Component. And it’s working like a charm!

As you see I wasn’t really sure about all of this. Now, with Navigation and other Architecture Components, it all starts to look really promising. I have successfully implemented a bit bigger app with a single activity approach which handles much more complex cases than described before. And I have to say: It makes sense.

If you are not convinced, as I was about week ago, give a try to a Navigation alpha03 and play with it on your own. Maybe a single activity approach is a future.

If you want to check how this really simple app looks like check out this repo:

Thank you for your time and keep coding!

--

--