Future because the native impl in Navigation 2.8

[hrach]

First, there is a resolution conflict, as the NavController has its own navigate method accepting an object. Therefore ours is ignored and this crashes in runtime. (but that is probably better instead of failing silently).

So after the next alpha, there should be finally some more usable API, I plan to take a look and decide how much better/worse is this library and if there is a future for it. If there is a future, we should rename the navigate method not to conflict.

Even though I do not expect the official API to be super "easy" as this one, I don't plan to transform this library to make it "better", that should be ideally a new project. So the most probable solution will be a sunset/deprecation.

[StylianosGakis]

Yup, when those APIs land and the path to migration is clear it would be perfect for this library to provide just a little documentation on how to do it.

The API conflict is unfortunate, what I did in my testing was typealias the import like

import com.kiwi.navigationcompose.typed.composable as typedComposable

just to quickly unblock myself when I was testing some things out.

I also wonder if the official solution will be as "easy" as this one. From me trying the snapshots right now the first thing which I already did not manage to get working was navigating to destinations which have a List<Foo> in their parameters, as I mention here https://issuetracker.google.com/issues/188693139#comment69

If there are such problems still there in the official implementation, and the workaround is not as simple as one might hope for then I see a place for this library. At least for people who had big projects already built with it.

[hrach]

The preliminary evaluation:

• all navigation functionality is there, including pops, etc.
• complex types have to be defined manually
• it is not compile type safe - missing types in type map are reported in runtime, but at least immediately after the graph creation
• even enums are not supported by default (:()
• the good part is that we may build some abstraction that will "bring" back this, but probably in another library.

Not tested yet:

• safety on empty strings
• adaptability for result sharing

[hrach]

My migration is currently blocked by a crash: https://issuetracker.google.com/issues/341319151

[hrach]

Maybe I should have tested more before migrating. https://issuetracker.google.com/issues/341319159 Hm :/

[cj1098]

Have you looked at the official library's bottom sheets? They don't have the ability to declare the route as a serializable class yet. This library does :)

[hrach]

For integration of M3 bottom sheets into the navhost (with the official serializable API), you can use my new library: https://github.com/hrach/navigation-compose/

[hrach]

https://issuetracker.google.com/issues/344943214 :/

[StylianosGakis]

So so far you need to:

• Wrap types you do not own in your own type even if you have made a serializer for that external class
• Need to make sure to implement serializeAsValue yourself for all NavTypes
• And must ensure that the serializeAsValue implementation properly URI encodes everything.

This migration is gonna be a "fun" one I am sure 😅

I know they have made implementing custom NavTypes have at least some friction, according to this https://medium.com/androiddevelopers/navigation-compose-meet-type-safety-e081fb3cf2f8 it's a hint towards pausing and thinking if you want a custom type here or not. But it certainly makes the migration a bit tricky.
I think the most sensible thing to make this migration easier is to still just use kotlinx.serialization to put it into the bundle that way instead of also mixing in Parcelable in this.
Maybe there's even room for a generic NavType implementation which assumes non-null and always works with Strings to put in the bundle, uses kotlinx serialization for all transformations? Have you migrated any project so far to test this out?

[hrach]

I am thinking about using the official solution but introducing custom helpers that will do the work for you:

• a generic JSON Nav Type serializer (I am using it already)
• composableSomething that will define missing nav types

[StylianosGakis]

a generic JSON Nav Type serializer (I am using it already)

Yeah that's exactly what I was thinking of when I said "Maybe there's even room for a generic NavType implementation which assumes non-null and always works with Strings to put in the bundle, uses kotlinx serialization for all transformations?"
If you have one impl already for this, do you mind sharing it? I haven't had the time to do our migration yet, but I want to very soon and it would really help!

composableSomething that will define missing nav types

What do you mean by this one? I don't think I understand it

[hrach]

import android.net.Uri
import android.os.Bundle
import androidx.navigation.NavType
import kotlinx.serialization.KSerializer
import kotlinx.serialization.json.Json
import kotlinx.serialization.serializer

@Suppress("FunctionName")
inline fun <reified T : Any?> JsonSerializableNavType(): NavType<T?> =
	JsonSerializableNavType(serializer())

class JsonSerializableNavType<T : Any?>(
	private val serializer: KSerializer<T?>,
) : NavType<T?>(isNullableAllowed = true) {
	override fun get(bundle: Bundle, key: String): T? {
		val data = bundle.getString(key) ?: return null
		return parseValue(data)
	}

	override fun parseValue(value: String): T? {
		if (value == "null") return null
		return Json.decodeFromString(serializer, value)
	}

	override fun put(bundle: Bundle, key: String, value: T?) {
		bundle.putString(key, Json.encodeToString(serializer, value))
	}

	override fun serializeAsValue(value: T?): String {
		if (value == null) return "null"
		return Uri.encode(Json.encodeToString(serializer, value))
	}
}

and then

private val typeMap: Map<KType, @JvmSuppressWildcards NavType<*>> = mapOf(
	typeOf<FilmReview?>() to JsonSerializableNavType<FilmReview?>(),
)

[hrach]

(the sad thing is it is serialized twice: string -> object -> Bundle string -> object)

[StylianosGakis]

Did you also find that you needed one for nullable and one for non-null nav types? Most of ours are non-null and I wonder if I should just do this for them.

class JsonSerializableNavType<T : Any>(
  private val serializer: KSerializer<T>,
) : NavType<T>(isNullableAllowed = false) {
  override fun put(bundle: Bundle, key: String, value: T) {
    bundle.putString(key, value.encodedAsString())
  }

  override fun get(bundle: Bundle, key: String): T {
    return parseValue(bundle.getString(key)!!)
  }

  override fun serializeAsValue(value: T): String {
    return Uri.encode(value.encodedAsString())
  }

  override fun parseValue(value: String): T {
    return value.decodedFromString()
  }

  private fun T.encodedAsString(): String = Json.encodeToString(serializer, this)
  private fun String.decodedFromString(): T = Json.decodeFromString(serializer, this)
}