I most recently gave a talk about this on Thursday (8/15/2018) at Android Summit. I did my first experiment with recording my own talk, which went OK I think…
I’ll be doing a few more talks through the remainder of 2018. I’m most excited about KotlinConf, but will be doing a few other events as well.
We still need to release the Android app. Sometime in the next couple days.
The underlying libraries are being updated to Kotlin 1.3 eap as well as the latest Kotlin/Native builds. That should also be early this week.
That will probably be it till after Droidcon NYC. Speaking of, today is the last day for standard price tickets (use code ‘kotlinmp’ for a discount)!
Just a quick note about app size. We’ll write more about this later, but the summary is Kotlin/Native does really well with regards to download and install size vs other frameworks. The download size is under 10m. Our last version with J2objc was just under 30m. It had more images in it, but still. By comparison, we did the flutter sample a few months back, which came out to 20m. React Native kind of beat everybody, but anyway. Will need to make some bare-bones apps and do some comparisons.
As always, Touchlab is looking for orgs that want to get started with this tech. Reach out.
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.
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!
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.
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
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.
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.
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.
None. Looking for hands, if anybody wants to play!
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.
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.
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.
It’s a little hard to believe, but this will be year #5 for Droidcon NYC. I’m super biased, but as great as every year has been, the year after seems to be a huge leveling up in terms of event and content quality.
That means this year needs to be ridiculous. It’s the 5 year, right?
This is a community conference, which means the content comes from the community. We’ve had a lot of great submissions so far, but it’s time to get the word out and make a big push to the end of CFP.
CFP Ends June 10th
That means we’ve got a couple weeks to get those submissions in. If you’ve submitted in the past, you’ve had the pleasure of experiencing my hand-rolled web system. No more! We’re using sessionize this year, which should be better for everybody:
Every year we get requests for topics of interest and some guidance for how to submit. The real answer is “whatever the committee votes on”, and what *I* think is interesting is not always what *they* think is interesting, but I’ll make some guesses for 2018.
The good part about timing for Droidcon NYC is we get the fresh topics right after I/O. You can submit anything you want, but there are always a few big themes.
There have always been a few talks about React Native (or whatever), but this year “multiplatform” has hit the mainstream (or at least people’s desire to talk about it at a native developer conference). We expect several talks, possibly a 1 day track on the topic. Most likely to be of interest are Flutter, Kotlin Multiplatform, or React Native. General topics may also be of interest.
A huge pile of things were released and/or rebranded under Jetpack. Clearly lots of stuff in there to talk about.
There’s also a whole new Android release to talk about.
This thing. TBH, I need to learn about this more. May attend talk.
Kotlin was the big news last year, but we’ve had a year to absorb it and release a bunch of new libraries. In that year, Kotlin has been embraced to the point that it’s weird to see a Java slide at an Android event. Probably lots of talks around actually implementing it.
All the other stuff…
Implemented an instant app in production? Using voice assistant stuff? VR/AR? There’s a lot of stuff going on.
If you have ideas for topics you’d like to hear about, please leave a comment (or tweet)
Droidcon NYC has generally leaned toward more advanced or “deep dive” types of talks, but there will be content for a range of experience levels. If you are interested in a specific topic, I’d personally suggest creating multiple submissions, with different levels experience and specificity.
For any topic that is very popular, there will likely be several similar submissions. Last year, for example, had several “Intro to Kotlin” submissions. We’re only likely to pick one, so again, multiple submissions is the best bet.
As for how to write a submission, there are a lot of great resources online about this. My only real advice is that there are generally hundreds of submissions, so a catchy title and shorter description will probably work better. The voting process is a lot of work (and much thanks to the selection committee for their efforts).
A Note on Keynotes
Every year roughly 0 to 2 people submit talks specifically designated as “keynote”. If this is something you’d like to submit for, I highly encourage that you do. Just please put that in your title. As in “Keynote: Android in 2028” or “Keynote: Android S should be Stroopwafel!” We will likely go back to keynotes on both mornings, and possibly something end of day as well, so we will have multiple slots to fill.
This year will be in Brooklyn. Greenpoint, specifically, which might sound odd if you’re somewhat familiar with NYC, but if you’ve been in Greenpoint in the last few years, it’s not weird at all. Brooklyn in general and Greenpoint in particular has changed dramatically over the last few years. It is a major part of the NYC tech ecosystem. Plus there’s a big parking lot for food trucks.
The talk selection committee details will be solidified in the near future. We expect to have 8–10 folks voting on submissions, with notifications going out 2 weeks after CFP ends.
I don’t want to lead you on too much about the status of coding Kotlin on iOS. I’m very excited about where that’s going, but it’ll be a little while.
The Kotlin team is making tons of progress, though. It’s coming and it’ll be pretty great.
One of the things that will be needed are Kotlin libraries that don’t need access to the JRE. A lot of stuff is in the JRE, so many libraries will have some issues.
I’m not sure running Doppl/J2objc under Kotlin native will be how a lot of apps are built, but I was curious to see if it would work. After all, J2objc is basically a JRE running on iOS. With some smoothing, I think the two will go together quite well.
The Doppl Droidcon app runs RxJava 2, Retrofit 2, Dagger, Android Architecture components (RC1), with room, all on iOS, with Swift as a front end.
Here’s a Kotlin native version, calling into the same Doppl code underneath (RxJava 2, etc). It’s only the main schedule page. There are technical hurdles on the Kotlin side that I won’t go into, and I think they’re a mix of things the Kotlin team is fixing and/or me not fully understanding how to interact with the framework (and not wanting to spend more than a few hours on a proof of concept).
We’re gearing up to have our 4th year of Droidcon NYC! The talk selection committee just started voting, and we have an excellent lineup. Should be a great event.
Because we’re a mobile dev shop, and mostly an Android shop, we’ve launched an Android app for the Android conference each year. Last year we used Dopplto create an iOS version of the app as well (Apple is pretty serious about not having Android in the app store, though).
It’s his birthday, btw.
The current version of the Droidcon app started back in 2014. We used some early Kotlin, way way before that was a “thing”. However, in 2017, it’s some pretty old looking Kotlin. We also used some libraries and architectures that aren’t exactly current “best practice” by Android standards.
There were also zero tests. So, you know.
We want to have a nice, public example of a well designed Android app, the very modern architecture of which can then be used directly in iOS. We also want to train some more of our team on Doppl, and figured we’d do it publicly.
I wrote a threading task queue a couple years ago. It was designed to be simple, and also implement a persisted queue for offline support. Everybody has kind of moved away from the “event bus” model over the past few years, so the non-persisted tasks will be implemented in RxJava 2. The persisted stuff will be backed by the Android Priority Job queue. Fun fact, Yigit did that and the Room DB stuff. Thanks, Yigit!
The current app uses Retrofit v1. Doppl doesn’t have Retrofit v2 yet because we need Okhttp to support ssl, or we need a different call client. We’re going to move the Droidcon app to Retrofit v2 to sort of force the issue and prioritize sorting out the Retrofit v2 situation.
We’ll be moving to the new architecture components, but probably using Rx instead of LiveData. I’m not sure right now how much of that will make sense in an iOS context. Obviously, we’ll need some implementation of the lifecycle stuff, but it won’t mean as much. That’s all still TBD. The general idea of Doppl is to move as much code as possible into the shared space, though, so hopefully, the architecture code makes sense.
This year’s app will be simpler than previous years. We’re removing the “login” requirement. It doesn’t make all that much sense. The only feature loss to the user will be a lack of sharing RSVP’s between devices, which seems ridiculously unnecessary. This will simplify the code considerably, but should still deliver similar functionality and UX.
Here at touchlab we could not agree more with Huyen and the many people on Twitter saying great things about this community. Droidcon NYC 2016 ended a few weeks ago, but it feels like yesterday and we already can’t wait for the next big community event.
Thank you to everyone. To the attendees who were kind enough to trust that we would do our best to make it valuable to you. To the speakers who are generous enough to come and share their knowledge and experience. To the sponsors who are forward thinking enough to invest in the community and earn their gratitude. We appreciate you all, thank for coming.
We were really grateful to hear all of your feedback afterward. You told us that Convene was the best venue yet, that the talks were stellar, and most importantly for us, you all had a great time. For many, it was a reunion of Android developers and designers scattered across the US and abroad, and we’re blessed to be able to bring you guys together every year.
Pictures of you doing things
Head to our Facebook page. Below are links to each of the albums to make your life super easy. Please tag yourself and people you know!
So, first things first. All the livestream videos are live right now on at droidcon.nyc for anyone with a ticket to the event. Just click through to the speakers page.
But of course, what you really want is the final, edited, free version that’s going to be up on Youtube. Well good news, those will be live by the middle of November!! Even better news, we’ve got a bunch live right now. Check them out here.
The final edited videos will be published in a few weeks on our touchlab YouTube channel, so subscribe if you want to get notified.
Let’s show some love for our amazing sponsors
These folks are the reason we could make this Android community conference happen. When it comes time to test out new tools or look for a new position or refer someone somewhere, please remember these great organizations and support them.
mParticle is the the data platform for the world’s leading mobile apps. The top app businesses in retail, travel, social networking, gaming, streaming media, and more use mParticle to collect customer data once and send it to any analytics, marketing, and data warehouse platform. With its turnkey data connections and enrichment capabilities, enterprise-grade privacy and security safeguards, and business end-user friendly audience creation and management tool set, mParticle enables mobile-first companies to harness and act upon their data with greater agility, more control, and higher ROI. Learn more at mparticle.com or follow @mparticles on Twitter. Zendesk builds software for better customer relationships. It empowers organizations to improve customer engagement and better understand their customers. Zendesk products are easy to use and implement. They give organizations the flexibility to move quickly, focus on innovation, and scale with their growth. JW Player is a full-stack video solution that prioritizes speed, control, and reach across all viewing platforms. JW Player’s Android and iOS SDKs include native software classes and methods that enable you to build adaptive live and on-demand video playback, player UI customization, VAST3 and VPAID2 advertising, and other video features directly into any native mobile application.