This fixes the issue, but you’d need to remember to do this (I for one have forgotten).Īnother thing you could try, to avoid inadvertent use of kotlin.toString() on a nullable type, is to use an import alias for it, e. That paired with a ?.let statement means we could write something like this: URLResolver().navIdToURL(navId)?.toString()?.let ?: handleUnrecognizedUrl(navId) on the very first link in a chain that returns null. One way to fix this would be to make sure you use the Kotlin safe operator ?. This is something for which to be very careful with the toString() function, because it is very easy to just use that extension function on a nullable object and not realize that you’re not properly handling a null value. That’s why our code compiles and runs.īut it crashes if navIdToURL returns null because we pass in the malformed URL string “null” to navigateToUrl(). What’s happening is toString() is intercepting the nullable object and always returning a non-null object. Instead, we’re using the Kotlin extension function kotlin.toString() which allows for a null receiver. We’re not actually using the toString() member function as overridden by the URL class (not directly, that is). It has to do with the toString() function that we’re using. You can mark a generic type parameter as definitely non-nullable at the use site with the new syntax T & Any. They provide better interoperability when extending generic Java classes and interfaces. And yet, we’re passing the value returned from navIdToURL, which allows nulls, right into this non-null parameter. In Kotlin 1.7.0, definitely non-nullable types have been promoted to Stable. One of the nice things about Kotlin is that it forces you to deal with nullable types when you try to use them in non-nullable places. But we’re totally ignoring the fact that it can return null. This works fine if navIdToURL() returns a non-null value. So we write our code to get the URL and pass it to navigateToUrl(): navigateToUrl(URLResolver().navIdToUrl(navId).toString()) And there’s one more catch: the navIdToURL() function can return null if it can’t find a matching URL for the given navigation ID. We can do that with the venerable toString() function. We then need to pass that URL to a navigation function navigateToUrl(urlString: String), but that navigation function needs a string version of it (odd, yes, but let’s say it’s an API we don’t control ). Let’s imagine we have a function navIdToURL(navId: Int): URL?that takes a “navigation ID” and converts it into a URL. To enable this feature, you specify the following build.Wanted to share something that has bitten me with Kotlin’s toString(): be careful of using it on nullable types! With version 1.6.20 the Kotlin compiler is able to create proper standard executables for Android Native targets, whereas it previously could only generate a shared library to be used as a NativeActivity.
Kotlin 1.6.20 brings many new features, including standalone Android executables, extended context receivers, native parallel compilation, definitely non-nullable types, and much more.
0 kommentar(er)
