|Android Pie API is Kotlin Friendly|
|Written by Mike James|
|Friday, 10 August 2018|
Although Kotlin is compatible with Java, and there really isn't any need to change the Java APIs that Android runs on, a little annotation can make interworking easier. Android P's SDK is now null- and Kotlin-friendly.
If you have worked in Java or similar languages, you will know the danger of the null pointer.
Tony Hoare invented null pointers as part of the Algol W specification back in 1965, but it is likely that similar ideas had been in use before this. He refers to it as his "billion dollar mistake". I think that's a bit hard. The idea of null, and a null pointer in particular, is just that of a variable that currently has an invalid value.
A null pointer is one that doesn't currently point to an object. It could be because it has been initialized to null, but more likely it is because the object it points at has been removed. Java supports null pointers and if you try and use such a null pointer to access a object or its properties you get a NullPointerException, which is the curse of many Java programmer's lives.
The alternative to the null pointer problem is to hand over responsibility for validity of pointers to the compiler. This is what Kotlin's non-nullable types are all about. By default a Kotlin type is non-nullable. That is, they are built so as to be unable to accept the null value. The compiler checks to make sure that a non-nullable type is initialized and can never be set to the contents of another variable that could be null.
The problem with this is that nulls are like a virus. Once you let a nullable type into your program they tend to spread and you end up having to check for them, just as you would have to if you had done the job properly in Java. The big problem is that Kotlin has to interface to the Android Java API, which is most definitely nullable.
What this means is that in any interaction with a Java API the Kotlin type becomes nullable and therefore a problem. The solution is to add nullable annotations, which tell Kotlin which return types are practically non-nullable, i.e. in practice they cannot be null and a pointer to something is always returned
The latest Android Pie (formerly P) SDK now has nullability annotations for the most frequently used APIs. This makes their use by Kotlin, and in fact Java, much more bug-free.
One little oddity is:
"Normally, nullability contract violations in Kotlin result in compilation errors. But to ensure the newly annotated APIs are compatible with your existing code, we are using an internal mechanism provided by the Kotlin compiler team to mark the APIs as recently annotated. Recently annotated APIs will result only in warnings instead of errors from the Kotlin compiler. You will need to use Kotlin 1.2.60 or later."
I'm not at all sure what the effect of this is. Does it mean I can ignore the assigment of a nullable to a non-nullable because a warning is just a warning and I'm used to ignoring warnings? If so this isn't good.
"To make use of the new annotated SDKs all you have to do is install the Android SDK Platform 28 revision 6 and then set you project to use it along with the latest Kotlin plugin.
Yes it is true that using Kotlin with the Android SDK isn't as easy as if the SDK was written in Kotlin. As the announcement says:
The Android SDK API surface is very large, and we have only annotated a small percentage of the APIs so far - there is still lots of work remaining. Over the next several Android SDK releases, we will continue to add nullability annotations to the existing Android APIs, as well as making sure new APIs are annotated."
A more radical solution would be to write new APIs in Kotlin.
Of course, the reality is that in today's Android programming we are aiming at a moving target. Not only do we have language upheaval, we have Android KTX and AndroidX, plus the constant churn that is Android Studio.
You might think that, after so long, Android would have settled down a bit - after all it's only Linux with a UI stuck in front...
or email your comment to: firstname.lastname@example.org
|Last Updated ( Friday, 10 August 2018 )|