It has been about 5 years since I have been able to spend a dedicated chunk of time working solely on Android development. One of our competitors shut down their product a few months ago, causing a huge inflow of customers all asking for an Android Chat SDK. Unfortunately, our Android team was behind on schedule. #startuplife Long story short, I had the pleasure of doing some Android development again.
It was cool to see how much the ecosystem improved. The constraint layout is really easy to work with and much more performant than the older layouts. The new livedata system reduces quite a bit of boilerplate code. Room is a nice abstraction over SQLlite and the concept of viewmodels (while simple) is quite elegant.
One type of fragmentation became much worse though. If youβre a library author you now have to think about:
- Java or Kotlin
- Java Callbacks, Android RX observables and/or Kotlin Coroutines
- Architecture components: MVVM, MVI, MVP, MVP or MVC?
- Proguard
- AndroidX
Yes, you can argue that Java and Kotlin are compatible. At the end of the day, you still have 2 sets of docs and halve the people that use your library wonβt be happy with the language you choose. If you look at the stats Kotlin still seems much smaller for new apps than Java: https://www.appbrain.com/stats/libraries/details/kotlin/kotlin.
Itβs cool to see how Room and Retrofit deal with the callback vs observable difference. If you look at iOS development though there is much less fragmentation.
Android development has improved a lot over the last 5 years. For a library author fragmentation became worse though. I wonder why Google has this wait and see attitude instead of just ensuring that there is 1 best way to do all of these things...
Top comments (4)
This sucks a lot.
I will launch a project in the coming week in the hope to make the transition easier.
Avoid any recommendations from Google and do whatever makes sense in your particular context.
Use callbacks, that's the universal idiom and they can be converted to coroutines in a few lines.
Callbacks and Kotlin Flows - Roman Elizarov - Medium
Roman Elizarov γ» 5 min read
Kotlin for me, but I am biased since I learned Java with Android, which makes it look extra bad.
I am not surprised, whenever they recommended one way to do things, they choosed the worst option: multiple activities, fragments, loaders, async tasks, ....
Yeah, will probably do something like this to make it work well for everyone:
github.com/square/retrofit/tree/ma...
I am curious about your thoughts on the AndroidX vs Support libraries mess and how it affects you as a library author.
Well, sure. Because:
a) Apple has closed eco-system and there are only few iOS devices you need to support as a developer.
b) Apple is pushing developers to use new tools all the time (ask your iOS developers about breaking changes in XCode and Swift) :).
I think Google is moving towards making Kotlin main language for Android development (they still support Java developers because it's a reasonable business-decision for now).
Technically, if (when) one's app use OkHttp 4 - it's already have dependency on Kotlin stdlib (luckily it's very tiny, almost invisible if R8/Proguard is your friend).