Did someone say Navigation to the rescue: Android Jetpack

If you been around the block a few times with Android development you probably already know that there is an issue with Navigation. If you don’t trust me you will soon find out but don’t worry I am going to let you in on a little hint to overcome many of the challenges that arise doing the development process. Note unless the app you are developing isn’t complex avoid this altogether but let get serious if you are developing for the public it is sure to become more convoluted as you go. Complexity can range from any of the following: Fragment transactions, deep linking to different parts within the app, passing values/arguments securely and safely, and much more. This is where our friend JetPack’s nav component steps in because its purpose brings solutions to the above complexity. From this article, you can expect how to solve those issues.

Terms and Definition to keep 

• NavHost
  • a container that has any or all the information it may need to handle the navigation actions
• NavController
  • This component performs the navigation between destinations,
• NavigationalUI
  • This component simply connects the navigation with some material component (for example the BottomNavigationView and DrawerLayout)

Fragment Transactions

With the nav component, there’s no need to manually handle fragment transactions (praise him), and it takes care of everything internally. To successfully go from  FragmentA to FragmentB and now all you need to do is call the corresponding navigation action at runtime.

navController.navigate(R.id.actionId)
//or something like this
navController.navigate(R.id.destinationId)

The Back & Up Navigation

With the nav component and using the single activity model, the Activity’s role becomes more of an entry point to the app that delegates the handling of its content rather than being its owner. A NavHost, it is hooked up to the navigation graph which represents the single source of truth, and this where all the destinations, actions, arguments and deep links are defined

When using fragments as destinations, you can use the NavHostFragment class as a  NavHost. Let’s take a look at how the activity layout may look like it

<FrameLayout>
    <fragment
         android:id="@+id/mainNavHostFragment"
         android:name="androidx.navigation.fragment.NavHostFragment"
         android:layout_width="match_parent"
         android:layout_height="match_parent"
         app:defaultNavHost="true"
         app:navGraph="@navigation/main_navigation_grah"/>
</FrameLayout

Since the navigation graph is the single source of truth for all navigation within the app, the navigation component does the right thing when the user navigates back or up. Not only does it handles this, but it correctly takes care of things such as the back stack, transactions, pop behavior, and transaction animations.

Passing Data Securely & Safely

If you have ever pass data between  Fragments can be tedious as well as error-prone and this is not including the things that can go wrong or at least get confusing while refactoring the code. Ideally, we like to pass and retrieve arguments in an easy manner without having to worry about their keys, and read them safely.

The navigation component brings a solution to this using the Gradle plugin [androidx.navigation.safeargs]. It basically generates some boilerplate code to make any developer’s life easier. As you will see with the example below when a user navigates from FragmentA to FragmentB while passing a mandatory argument and an optional argument. What classes are generated:

•  FragmentADirections.ActionFragmentAToFragmentB 
  
  • Inner class with a constructor that takes in the mandatory arguments and setters for the optional arguments
•  FragmentADirections 
  
  • Has a method [actionFragmentAToFragmentB] that takes in the mandatory arguments and returns an instance of FragmentADirections.ActionFragmentAToFragmentB
•  FragmentBArgs 
  
  • Has getters for the different arguments

So to begin, within the navigation graph, the destinations are defined along with the action (this transition is from FragmentA to FragmentB) and the arguments

<fragment
	android:id="@+id/fragmentA"
	android:name="com.test.FragmentA"
	android:label="Fragment A">
	<action
		android:id="@+id/action_FragmentA_to_FragmentB"
		app:destination="@+id/fragmentB"/>

</fragment>

<fragment
	android:id="@+id/fragmentB"
	android:name="com.test.FragmentB"
	android:label="Fragment B">
	
	<!--Mandatory Argument-->
	<argument
		android:name="id"
		app:argType="integer" <!--Argument Type-->
		/>

	<!--Optional Argument-->
	<argument
		android:name="data"
		android:defaultValue=""
		app:argType="string" <!--Argument Type-->
		/>
</fragment>

In addition, within FragmentA, performs the navigation while passing the arguments.

//creating  a NavDirection instance for the mandatory argument
val directions = FragmentADirections.actionFragmentAToFragementB(10)

// if there is n optional argument you can pass it
directions.setData("")

//Navigate to the new FragmentB
navController.navigate(directions)

Now reading

val id: Int = FragmentBArgs.fromBundle(arguments).id
val data: String = FragmentBArgs.fromBundle(arguments).data

Deep Links

Deep linking inside any application can get complicated as the app get more complex. Issues such as how to structure these deep links, how to pass the required information, and how to build the right back stack arise. In the nav component, deep linking is a first-class citizen, and both types are supported: Explicit () and Implicit ().

• Explicit

  • Used for notifications, app widgets, actions, and slices. Consider these used for pending intent based.

//prepare the arguments to pass to any notification expectation
val arg = Bundle().apply {
    putString("StringKey", "a string value")
    putInt("IntKey", 0)
}

//preparing intent, while selecting the graph & destination
val pendingIndent = NavDeepLinkBuilder(context)
    .setGraph(R.navigation.main_navigation_graph)
    .setDestination(R.id.destinationFragment)
    .setArguments(arg)
    .createPendingIntent()

//prepaing notification
val notification = NotificationCompat.Builder(context, NavigationApplication.NOTIFICATION_CHANNEL_ID)
    .setSmallIcon(R.drawable.notification_icon)
    .setContentTitle("Explicit Deep Link")
    .setContentText("Click on the following notification")
    .setContentIntent(pendingIndent)
    .setAutoCancel(true)
    .build()

//Display notification
NotificationManagerCompat.from(context).notify(10, notification)

• Implicit

  • Used for handling web URLs and custom scheme URIs.

<fragment
    android:id="@+id/destinationFragment"
    android:name="com.example.destinationFragment"
    android:label="@string/title_destination_fragment">
    <action ... />
    <deepLink
        android:id="@+id/custom_scheme_uri_deeplink"
        app:uri="android-app://path/subpath/{data}" />
    <deepLink
        android:id="@+id/web_url_deeplink"
        app:uri="www.husaynhakeem.com/path/subpath" />
</fragment>

Now we need to review the manifest and tweak it a bit. Within the activity tag of the Activity that contains the above destination fragment, the line below needs to be added.

<activity android:name="com.example.Activity">
    <nav-graph android:value="@navigation/main_navigation_graph" />
</activity>

Testing Navigation

The navigation component comes with a dependency just for testing android.arch.navigation:navigation-testing:$nav_version. But unfortunately, there seems to be very little (to say the least) documentation around it online, I wasn’t personally able to find any projects (not even the google sample apps) that use it, and a GoogleIO talk from earlier this year briefly brings up the topic but doesn’t go into any of its details. But the promise is that testing will be developed further in future releases, allowing developers to test their app’s destinations in isolation without worrying about potential issues such as fragment transactions.

All in All

There’s no doubt that the navigation component brings a lot to the table, it has several other great features I didn’t mention in this article such as nesting graphs, methods curated for Kotlin usage -based on extension functions-, and an easy to use navigation graph editor. But despite this, the navigation component seems to leave some open questions unanswered, especially one that’s bugging me: Passing data back to a previous destination (similar to  startActivityForResult and  onActivityResult).

The navigation component is currently still in Alpha, it’ll be interesting to see how it evolves, and I also look forward to playing with its testing component when there are more resources around it. But for the time being, I think it would be fun to test its limits in a real-world application.