Droidcon App with Kotlin Native Gradle

This is a minor update after last week’s release of the Droidcon NYC app in Kotlin Multiplatform. Its all about the gradle dependencies and how they’re packaged. This will be more/less interesting depending on how in the weeds you are with Kotlin/Native.

The Kotlin/Native gradle plugin, aka konan, has always been kind of a different thing when compared to the what we’re probably used to in the JVM land and, more recently, the multiplatform land. A more recent addition to K/N has been a new plugin that is more in line with the multiplatform config, but is still pretty new, and features are still being added.

Our original plan was to wait until the new plugin was more mature before trying to move to it, but it looks like the new stuff coming out of Jetbrains is all going to be using the new plugin. Coroutines are probably the most anticipated addition, and hopefully soon we’ll have something to try out!

Rather than wait for that, then go through the horrible pain of trying to update, I took a deep dive. Here’s the result.

The Droidcon App has been fully ported over. All the parts should work as expected:

I’ve updated forks of the outside libraries we’re using: SQLDelight and multiplatform-settings. Those and our threading library were pretty straightforward.

KNarch.db is a different story. There were two primary issues here. The simpler one is we need to pass linker args to the compiler, which took a while to sort out, but only because the docs aren’t really “done” yet. After a lot of digging, it was just adding:

extraOpts("-linkerOpts", "-lsqlite3")

Significantly more involved was adding the C++ output. The original K/N plugin lets you do this directly. I may have missed it in the new plugin, but AFAIK, there’s no way to do that. For now, I’m just modifying the klib file after its built but before its published, and inserting the C++ output into the path that the libraries doc states they should go.

This works, but is problematic for two reasons. First, the docs are clear that the klib format might change. This isn’t a huge deal. Everything is changing, so you’re more or less living with that risk, but its something to keep in mind. More difficult, the test build in the new plugin seems to be more automatic, so I don’t know yet if I have a place to step in and push the C++ output into the test build, or if that’s even possible. The upshot is that the CI on the library repo fails. We’ll be experimenting with that soon.

That’s kind of it for this update. Getting ready for the talk next week at Android Summit!