Welcome devs 👋
You are reading the first installment of this new series dedicated to exploring the latest tools, tips and trends in the world of Android development; helping you stay up to date and to grow in your career.
Each issue will aim to highlight new libraries, tools, tutorials and discussions around the world of Android development. I hope each issue will also bring with it interesting discussion, and a place for Android developers to connect with one another and find mentorship and community.
What did you think of KotlinConf?
It’s been a couple of weeks since KotlinConf, and, if you’re like me, there’s still quite a bit of interesting Kotlin news and content to digest.
One of the themes that stood out to me was Kotlin Multiplatform. For the past 12-18 months, Kotlin Multiplatform support has been quickly evolving. Building a mobile applications that utilize shared Kotlin code has not only been possible, but something that was being done in production; if only in small amounts.
Just this past week, I came across another publicly available example of a Kotlin Multiplatform project. Press is a cross-platform markdown editor built with Kotlin Multiplatform, and is currently open for contributions if you’re interesting in contributing to a real Kotlin Multiplatform application.
This year, it seems the Kotlin Multiplatform story is taking some big steps forward. An important feature, multi-threaded coroutines, is reaching maturity and will soon big publicly available, and the number of sample projects, and talks about the subject seems to be increasing rapidly. This year’s KotlinConf had quite a few sessions dedicated to Kotlin Multiplatform which, to me, shows they are really invested in building out support for that feature. And beyond that, JetBrains announced a new product, Space, which is build using Kotlin Multiplatform; further highlighting that they have a very personal interest in the Kotlin Multiplatform story being a viable long term play.
Below, are just a few of the Kotlin Multiplatform sessions to check out:
- Sharing Is Caring – Kotlin Multiplatform for Android Developers by Britt Barak
- MPP in 1.3.X and Beyond by Dmitry Savvinov & Liliia Abdulina
- Shipping a Mobile Multiplatform Project on iOS & Android by Ben Asher & Alec Strong
What KotlinConf announcements stood out to you?
What sessions did you find most interesting?
The future of Navigation
Are you using the Navigation Android Architecture Component? I posed that question to the Android community over the past week interested to see what type of adoption this new method of navigation was seeing.
I’ve been working with the Navigation component for the last week or so, and have been pleasantly surprised at how easy it’s been to get up and running, both in an isolated project, and in a real application filled with existing code.
Are you using the Navigation Architecture Component in your app?
If you aren’t familiar with the Navigation Android Architecture Component, it’s an Android Jetpack library aimed at simplifying the implementation of application navigation. It provides a new visual editor for designing and managing an app’s navigation graph, and integrates nicely with common UI elements such as an AppBar and a BottomNavigation view.
Anyone really love it, or run into odd issues in production?
From the discussions I’ve seen on social media this past week, it seems that roughly 50% of Android developers are using the Navigation component in an app. Now, a social media poll is hardly scientific proof of usefulness and adoption, but I was a bit surprised to see the number that high.
Using the Navigation component is a non-trivial departure from traditional solutions for navigating around an Android app. Additionally, a full migration towards using the Navigation component might constitute a significant refactoring effort in an existing app. For these reasons, I thought there might be been less adoption of the new component.
However, after working with it myself for the past two weeks, and talking with other developers, it does seem that getting started with the Navigation component can be quite painless in many cases. I’m currently in the process of integrating Navigation into a single portion of an existing app, and so far, this has been quite easy thanks to clear separation of concerns in our existing code, and thanks to clear patterns and documentation on the part of the Navigation component.
I’m happy to see Google continue listening to the developer community and providing updated tools and solutions for common challenges such as app navigation.
To get some hands on experience with the new Navigation component, you can find the Jetpack Navigation codelab here:
Some would likely argue that the Navigation component is unnecessary, or requires just as much boilerplate as traditional approaches; and they very well could be right. However, in many respects, I don’t think the Android Architecture Components are necessarily aimed at those experienced enough to feel highly comfortable with their own approaches.
I think the benefit of Google’s increased investment into Android Jetpack, the Architecture Components, and developer training is in the benefit of first time Android developers. Guidance is more helpful when you have less experience, and once you are experienced enough to know how a particularly library doesn’t meet your needs, I think you’re experienced enough to not worry about always using the latest and greatest from Google.
What do you think?
Should Android developer guidance from Google be taken with a grain of salt and set aside when you feel strongly about an alternative approach?
What in the world of Android development are you interested in right now? Join in the conversation in the comments below.
See you next time devs 👋