Droidcon NYC App!

Mobile conference apps are an interesting beast. It’s a place where you can add the “weird” new tech people are talking about, and open source it, but that you’re not *quite* putting into production yet.

Fun fact. Our original Droidcon NYC app was where we first tried Kotlin, way back in 2014. For 2018, we have come full circle and ported the whole thing to Kotlin Multiplatform.

https://github.com/touchlab/DroidconKotlin/

There is an Android version and an iOS version. The UI’s are coded on their native platform, with Kotin on Android and Swift on iOS. The logic and much of the architecture is shared.

Building the app and talking architecture

The live code video from Friday (8/3/18) with Natalie…

Another fun fact. The conference schedule is not up on the site, but it IS in the app. If you absolutely need to see the Droidcon NYC 2018 schedule before next week, build the app.

There’s still some polishing left to be done before putting them in the app stores, but they’re functional now, and we wanted to get a fully functional mobile app out in the world for people to play around with. We might have to repeat the Sad Puppy mod before publishing to the Apple store, but the Android deploy doesn’t always go smoothly either. Cross fingers!

Libraries

The more interesting stack in the app is KNarch.db, Sqldelight, to LiveData. It’s a multiplatform, reactive architecture.

You *can* use the LiveData implementation in your app, but it’s largely for demonstration purposes. Something more useful and robust would need to be built (perhaps something like Reagent). For now, though, you can observe SQLDelight queries and update the UI as data is modified.

We’re also using Multiplatform Settings, which is an elegant multiplatform implementation of a properties store. Not doing a lot with it yet, but the plan is to add more properties.

Both SQLDelight and settings are published from forks we made. SQLDelight had some changes to support Kotlin/Native. For the MP library, it was purely to support Gradle dependencies.

Threads

The first thing you’ll notice, and I’m sure comment on, is the lack of coroutines. Coroutines on native have taken longer to emerge, and while building the app, they weren’t super ready. I’ve seen some progress being made while wrapping up the app, but Kotlin/Native is changing fast and trying to include all the stuff that they add while building is a good way to kill your productivity. High on the list of todos is investigating the state of coroutines and seeing what we can do there.

For now, though, how threading works. There are a couple functions that power the explicit backgrounding in the app. Look at

sessionize/src/main/kotlin/co/touchlab/sessionize/utils/Functions.kt 

expect fun <B> backgroundTask(backJob:()-> B, mainJob:(B) -> Unit)
expect fun backgroundTask(backJob:()->Unit)
expect fun networkBackgroundTask(backJob:()->Unit)

In the JVM these get sent to an ExecutorService. In K/N, these get run on a worker. The interesting trick is how the ‘mainJob’ returns. That should be its own blog post, but if you understand K/N, ‘mainJob’ is kept in a ThreadLocal set in the main thread, so there’s no need to freeze it. If you don’t know what I’m talking about, we should be putting out some followup K/N threading posts.

What’s ‘networkBackgroundTask’? Just a separate queue. The networking stuff generally takes longer.

LiveData

There’s kind of a debate in the Android world between RxJava and LiveData. I won’t comment on that. We picked LiveData because we needed to implement it on iOS, and LiveData is very, very small. RxJava is not. That’s it.

SQLDelight needed some internal mods to support query listeners that could be frozen and exist in multiple threads. LiveData uses them and will push to the main thread when data is updated. You have to explicitly detach from the query because of a frustrating multiplatform issue. Please vote to have that one looked into.

Packaging

There seems to be a lot of movement around the K/N Gradle plugin, to bring it more in line with the others. The dependency mechanism is likely to change, so we’re in kind of an unknown space. In this app and with the libraries, we’re using the older plugin and dependency mechanism. It’ll look strange to Java folks, but it works fine. Our situation is somewhat complicated by the fact that KNarch.db and threads both have some C++ compiled and included. Personally, I’d like to see the K/N tools embrace their C++ underpinnings and make C++ easy to include in your own projects. If you’re going to get serious about K/N development you should at least be familiar with the runtime folder of K/N. Yada yada, dependencies, and packaging will likely change over the next few months.

Testing

None. Looking for hands, if anybody wants to play!

Future

Will try to include http-client-common. I ran into issues out of the gate, and the app is only doing GET calls, so I just hand rolled them.

As mentioned, investigate coroutines.

K/N 8.1 has been released. I think we’d want to re-publish all the libs as well as the project itself, so I’m holding off on that.

Looking for

If you’d like to play with Kotlin multiplatform and push some code back, we’ll be looking for a few things.

The UI on both platforms is partially Material Components. The goal was to have a relatively homogenous style definition so any conference using sessionize could use the app (cough). It’s not quite there. I did much of the app work as the rest of the team is doing actual client work, and my iOS UI understanding is minimal at best. Cleaning and consolidating that would be great.

Testing, as mentioned. This app, as much as anything, is an example of how to build Kotlin Multiplatform on mobile, and testing is going to be critical to selling that idea. By that I mean the tests don’t necessarily have to be super useful. They just need to exist.

Maybe some design adjustment. We largely took what we had in previous years on both platforms.

Status

It’s still a little early to be producing apps, but things are moving fast. I’ve been predicting that we’ll see several libraries emerge over the summer, and by late 2018/early 2019 there will be the full library stack and toolset necessary to be fully productive. I’m betting that’s still true. Hopefully, anyway, because I’ve pitched a lot of talks around it: http://androidsummit.org/, https://www.nyc.droidcon.com/, https://kotlinconf.com/, and at least 2 more that I’m still confirming.

To be clear, it’s a little early if you don’t know what you’re doing, but that’s when you bring in your friends at:

We are seriously looking for orgs that want to get started early on realizing shared architecture between mobile platforms as well as the web. Get in touch.