The Past

So if you like me, an Android Developer who uses Jetpack Compose daily, you probably have the same issue as me when using the navigation library.

I’m personally not so fond of the String route basis for the navigation. There’s so much to declare and remember for basic things, like the String route to associate with your Composable function, keys for each argument, and NavType for each argument.

In addition, because your route is a plain String, you need to implement a way to connect your String route to your arguments like storing it in the same class or the same package or encapsulating it in a sealed class.

Furthermore, parameters are now will be parsed as String because, in a String-based route, all navigation arguments are treated as query parameters or paths like in a URI.

So when the new Type Safety was introduced in Compose Navigation, I was so thrilled to try it out.

Everything is all and well in the world, or is it?

If all of your arguments are primitive types like String, int, Boolean, etc… then you can relax and use the latest compose navigation version. But if not, perhaps you put third-party classes as your navigation argument like BigDecimal or UUID then we need to talk.

It is considered bad practice to include complex data as an argument, as mentioned here:

But sometimes we can’t help it, either the application flow forces us to pass some data (or even a list of objects) or we are just lazy, so sometimes we want to pass the “unsupported parameter” type as arguments. But how to do that in the latest navigation compose library?

Let’s say we have a code like this:

In addition to adding annotation @contextual annotation to the BigDecimal, we need to add @Serializable annotation too to the Account class. What happened when we built this code?

Serializer still can’t parse the Account class as an argument, because we still have to add Custom NavType when declaring it from the composable function. So it will look something like this:

You can look on the internet what the CustomNavType will be for your code, or use generic to handle it dynamically. You’ll need to add custom this NavType for the custom class.

In addition, it still can’t provide mapping for classes that we can’t add the @serializer annotation to, like BigDecimal. Here’s the link to the issueTracker:

https://issuetracker.google.com/issues/348468840?source=post_page—–4c5b565f660f——————————–

I don’t think there’s a workaround for that right now, so you will have to wait until the library supports it natively.

The other thing is collecting the navigation arguments can be done in two ways:

• From NavBackStackEntry from calling the composable function in NavGraphBuilder
• From SavedStateHandle from ViewModel

These TypeMaps will be used to parse your argument from String to intended type when called from NavBackStackEntry. On the other hand, when using SavedStateHandle, you need to pass the TypeMap again somehow.

And adding it to the build.gradle.kts file like this:

Now we’re all set, let’s get cooking.

For dong this, we’re going to use the old plain String-based route because there’s not much we can do with the latest implementation that uses Type-Safety and Serializer.

First, let’s make the extension function to declare our route:

From the generic type, we call :class to get the KClass that will be used for creating the route name and getting all the parameters of the KClass and registering it as the navigation arguments.

I usedprimaryConstructor.parameters to access all the parameters for the constructor in the type of KParameter. From the KParameter instance, we will use the parameter name that is registered in the KClass as the navigation argument key. Another thing we’re going to do is define the NavType from KParameter.type to know which NavType is compatible with the parameter type, and for the nullability, we can easily call Kparameter.type.isMarkedNullable to know if the parameter is nullable and the navigation argument will reflect that.

After getting all the navigation argument types, It’s time to define the route for the composable. Using buildString, we will add:

• The qualified name of the KClass, and shorten it to only contain three words using the asRouteName function
• Add all the arguments from earlier as URI parameter type

It will look something like this:

package.name.ClassName?param1={param1}&param2={param2}

Next, we define code for navigating to another Screen:

From the generic type, we call :class to get the KClass type of route parameter.

I used URI builder to help add more parameters for the URI that will be passed to the navigation function. For the URI, I added the qualified name from KClass like before using the asRouteName function.

declaredMemberProperties will give us the parameters that we will add to the URI. Looping the parameters and accessing the parameter name and its value before adding it to the URI builder earlier.

The result URI will look like this:

android-app://androidx.navigation/package.name.ClassName?param1=param1Value&param2=param2Value

This is basically the same URI that will be passed when using the String-type route

Lastly, for accessing the navigation argument the code will look like this:

Please don’t give too much attention to the annotation, it doesn’t really do much

Navigating to another screen will look the same as the official compose navigation library.

Whether you’re accessing your navigation arguments from NavBackStackEntry or SavedStateHandle, you’ll only need to call the getArg function and define which route you want to access.