A New Kind of Android Fragmentation

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...

Comments

[Jean-Michel 🕵🏻‍♂️ Fayard]

AndroidX or Support Libraries

This sucks a lot.

I will launch a project in the coming week in the hope to make the transition easier.

Architecture components: MVVM, MVI, MVP, MVP or MVC?

Avoid any recommendations from Google and do whatever makes sense in your particular context.

Java Callbacks, Android RX observables and/or Kotlin Coroutines

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

Medium

Java or Kotlin

Kotlin for me, but I am biased since I learned Java with Android, which makes it look extra bad.

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...

I am not surprised, whenever they recommended one way to do things, they choosed the worst option: multiple activities, fragments, loaders, async tasks, ....

[Thierry]

Yeah, will probably do something like this to make it work well for everyone:
github.com/square/retrofit/tree/ma...

[Jean-Michel 🕵🏻‍♂️ Fayard]

I am curious about your thoughts on the AndroidX vs Support libraries mess and how it affects you as a library author.

[Denys M.]

If you look at iOS development though there is much less fragmentation.

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).

If you look at the stats Kotlin still seems much smaller for new apps than Java:

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).