Google I/O 2018: Android Navigation Architecture Component

Last year, Google released Android Architecture Components: “A collection of libraries that help build robust, testable, and maintainable apps.” These libraries have included things like “LifecycleObserver,” which helps separate the lifecycle of a view controller from the view logic, and “ViewModel,” which helps store and manage user-interface-related data in a way that eases view updates. This year at the Google I/O conference, Google introduced a new library called Navigation Architecture Component. With this addition, you can remove “FragmentTransactions” from your code, and instead use the new Navigation Editor to manage fragment navigation, back stack management, and deep linking. In this blog post, I will explain the basic structure of an app that is using the new navigation component, how to navigate between fragments, the benefits of this component to deep linking, and how it compares to iOS storyboards.

Setting up for Success

Before you get started with the new Navigation Architecture Component, it is important that you are on the same page as Google on the job of an activity and the job of a fragment. According to Google, the role of the activity is to be the entry point of your app. It should control some global elements of your app, such as your “Toolbar” and “BottomNav” components, but it should leave the content of your app to the new “NavHost” component, which uses fragments. An example activity XML file for a standard app could look like this:

This will allow your navigation component to control the content of the app by navigating through fragments. You can still have multiple activities, but each activity will have a different “NavGraph,” and you will have to do some programmatic navigation to go between activities.

The Navigation Editor

The Navigation Editor is a visual tool built on top of XML that enables the setup and visualization of the navigation graph of your app. Through it, you can configure your fragments and set their arguments and actions (e.g., fragment ID, targets for “back” and “up” navigation, or custom arguments).

This is more intuitive than the current method, which involves building a “FragmentTransaction” whenever you want to navigate to a different fragment. Not only are fragment transactions more complex, but they can easily crash your app if you mistype a few strings. This new method will ease development and take away a few common scenarios that can cause crashes in Android apps.

Navigating to a Fragment

In order to navigate from one fragment to another, you just need to get an instance of the navigation controller, and call navigate on it with the id of the fragment that you are navigating to:

There are also some convenient methods to set up simple on click listeners with less code:

This code is far simpler and safer than the fragment transactions you have to use in the current Android app framework.

Deep Linking

The Navigation Architecture Component also changes the way deep linking is done in your Android app. Previously, if you had a deep link into your app, you would have to spin up all of the view controllers that normally show up before the view controller you are linking to. You would then have to put all of these view controllers on the back stack so the back behavior of your app worked correctly. Now with the navigation graph, this “back stack” management is taken care of automatically. On top of this, there is a new feature that will automatically manage deep link intents in your AndroidManifest.xml file. All in all, deep linking into your app has just gotten a lot easier.

Compared to iOS Storyboards

This new component is different from iOS storyboards in that it is only focused on navigation, rather than being focused on the layout and navigation. Just like in storyboards, you can define all of the transitions and relationships between views in a convenient, easy to understand view. The “back stack” management of the Android navigation component, and deep linking support is better than the iOS counterpart, but other than that, they essentially accomplish the same thing. One major advantage of the Android Studio Navigation Editor is the XML it generates behind the scenes is cleaner, has less metadata, and is easier to understand, since it is just defining the navigation. The major advantage of this is that using these graphs in source control with multiple developers shouldn’t generate quite as many merge conflicts as iOS storyboards, and it should be easier to resolve any conflicts that do happen. If you are an iOS developer dabbling in Android development, this component will make the transition much easier.

Conclusion

The new navigation architecture component is a great addition to the Android arsenal. It will be easier to develop complex navigation interactions while keeping a clean, maintainable app. Even though it is still in alpha, now is the time to consider how you will migrate your current app to this methodology, and if you are starting a new app after the full release, then without question, you should be starting with this navigation component. To find out more, check out the documentation or watch the Google I/O session.

Are you an app developer excited by the new Google I/O announcements? Apply to Credera today!

• Android
• Apps
• Google I/O
• Customer Engagement & Commerce