Announcing Jetpack & the Navigation Architecture Component

This year’s Google I/O conference was packed with a lot of exciting announcements for Android Developers, who have long been asking for a Google recommended approach to building apps for the Android platorm and the tooling to support it. Google started an initiative to do this last year by launching Architecture Components, a collection of components to simplify Android development, while guiding developers down the path of what Google considers to be best practices. In other words, exactly what the community had been asking for. These included Room, the very popular object-relational mapping tool for SQLite, LiveData a generic, observable container for data, and a few others.

This year they expanded and rebranded the architecture components into a larger umbrella of tools, components, and architectural guidelines, called Jetpack. For me, one of the more exciting additions that Google added to Jetpack this year was a new architecture component called, Navigation.

The Navigation component is comprised of a set of tools, APIs and resources, that allow you to build your app navigation declaratively and visually. It makes certain tasks which used to be fairly tedious, like animating screen transitions and creating deep links into your application, now very easy. In addition, Navigation makes it easy for developers to follow one of Google’s newly announced architectural guidelines, which is that Android applications should be built using a single Activity whenever possible, utilizing Fragments for individual screens within the app.

Overview

So what does this component look like and how does it work?

If you’re using Navigation, you’ll define the layout of your app in terms of a series Destinations and Actions. Destinations represent individual screens or places that the user can go within your application, and Actions represent named routes between those Destinations.

All of these Destinations and Actions are defined in a new resource file type, called a navigation resource. A navigation resource is just an XML file that lives in your apps res directory, alongside the other cast of characters like layout, menu, drawable, etc.

Here’s a very simple example showing what a navigation resource file might look like for a two-screen application.

Navigation Editor

Storing this information in XML makes makes it easy to diff navigation changes over time, but it could become tedious and error prone to manage this by hand as your application grows. So the Android Studio team has built a very simple, yet powerful view to go along with the navigation resource, called the Navigation Editor.

The Navigation Editor provides a visual of each screen, or Destination, that is wired up within this navigation resource. As you can see in the screenshot above, the editor is even able to pull in the design time rendering of each individual Destination. This makes it super easy to keep track of which screen is which and their relationships to each other.

The arrow that you see connecting crimes_fragment to add_new_crime_fragment in this example represents the Action defined in the navigation XML above. This visual is cool, but what is really amazing to me is how easy it is to build these Actions directly through the editor by simply dragging from the right edge of one Destination to the left edge of another.

Invoking the Actions

The navigation resource defines which Destinations and Actions are available, but it doesn’t define how the actions are invoked. Invoking an action still requires some code in most cases, but once again, Google has given us some really nice tooling to simplify the process.

Traditionally you might have done something like the following in your activity to display a new screen based on the click of a button:

// If launching into a new activity
addCrimeButton.setOnClickListener {
    startActivity(Intent(this, NewCrimeActivity::class.java))
}
-- or --

// If just replacing a fragment in the current activity 
addCrimeButton.setOnClickListener {
    supportFragmentManager.beginTransaction()
        .replace(R.id.detail_fragment_container, NewCrimeFragment())
        .commit()
}

With Navigation, you’ll do something more like this, for both cases…

addCrimeButton.setOnClickListener(
   Navigation.createNavigateOnClickListener(
           R.id.action_crimes_fragment_to_add_new_crime_fragment)
)

Though as noted earlier. Google’s new recommendation is that each screen would be represented as a Fragment.

Notice that with Navigation approach, the same navigation code works regardless of whether the destination is a Fragment or an Activity. Furthermore, notice the one key thing missing from the Navigation version… There is no fragment transaction!! 🎩 Well… to be fair, it’s actually still happening. It’s just completely abstracted away by the framework now 🦄

This is just a quick glance at Navigation and how it works, but I haven’t even touched on some of the reasons I’m super excited about it…

Amazing Features

These are the top 3 reasons I’m excited about Navigation, in order of awesomeness. 🤓

Automatic Fragment Transaction Management

You no longer have to write the boilerplate code to manage Fragment Transactions yourself.

Automatic Back and Up Navigation Management

Navigation, uses the Destinations and Actions that you define in your navigation to build and manage the Android back stack for you on your behalf. It can supply up and back navigation within your application automatically and with appropriate behavior based on where the user is within your app and how they got there.

Built in Deep Linking

What used to be a tedious, error prone process of deep linking into your application and providing proper up and back navigation, is now an almost trivial process.

You simply declare a deep link on a Destination in the Navigation Editor and the framework handles the creation of any necessary intent filters in your AndroidManifest.xml, and synthetically builds the proper back stack for you. This is something you are certain to hear more excitement about from the community as developers start using Navigation and something I can’t wait to start exploring further.

Getting Started

Now is the perfect time to jump in and get started with the Navigation Architecture Component as it is currently still in early Alpha. And, while this means that there might be a few kinks along the way, it also means that the APIs aren’t 100% locked down yet. This means that there is still time to provide feedback and help shape the final API. In fact, Lukas Bergstrom, the Product Manager for Architecture components, explicitly said during the Navigation Component talk presented at IO 2018, that Google has released Navigation as an alpha for that exact reason. He also added that once the API is stable, Navigation will be part of the “default experience” when you create an Android app. The IDE will start you in the Navigation Editor.

You can get started today by downloading the latest canary build of Android Studio. I’d encourage you to also check out the Navigation Architecture Talk from Google IO 2018. It’s filled with really good information about the motivations and future directions they see for this exciting new component.

Finally, there have already been some great tutorials posted by GDE’s and other enthusiastic developers in the community. I found this detailed tutorial by Joe Birch to be very helpful in my research for this post.

I hope you’ll check it out!

Cheers 🎉