10 things I hate about you Android

I mean, it really sucks sometimes. A mild rant from a fellow Android dev.

Year in, year out something really annoying and historic issue is being solved by Android team but new emerge. Mostly this goes like this: You see some cool feature announced at Google I/O, then you go to see codelab which is inadequate, proceed to check out Github samples, for a moment you think you found a way to tackle the fresh, shiny feature. But no, we’ve all been down this road before, it has never ended well. So you end up with the expectations and waiting if others can manage to actually adopt it and write posts, open-source sample projects and then you can pull the thread.

This is just a list to remind some active issues around Android development right now. Maybe some of the listed items are going to be fixed in the upcoming releases but now we are here and have to bear with it.

1. Clap on this story who wants easy-to-use Keyboard handling API in Android. Just a simple keyboard manager with callback functions. After all the years of evolving Android, developers still crave this interface. I guess it will be in 2 years from now, I don’t know.
2. Storage Access Framework (SAF). The name already suggests that Google made some kind of dragon we need to kill before we successfully implement it. It was introduced in API level 19 (Android 4.4) but believe me, it was bad before and is still now and not many developers used it honestly. With the release of Android 10 (API level 29 or Q), Google changed a lot of things in the Android SDK especially security-wise which is a good thing. The Scoped Storage in Android 10 forces developers to use the SAF for almost all operations files in disregard to the java.io.File API for it not being very secure. Now lots of already published apps have to slowly migrate. Problem is that it is not well documented and comprehensive. You may ask what about Google samples repository? yeah, that’s another issue.
3. Navigation Component part of the Android Jetpack project [codelab]. Again, the concept is cool, single source of truth. When you actually dive in, will realize that it does not support `.add()` and what if you need multiple backstack? No, you can't have it out-of-the-box. After some searching on SO and Reddit, this link is going will appear — link to Google samples advanced usage of Navigation Components. Huge Kotlin file with extension functions to patch an issue. really Google? Oh did I already mentioned samples repository?
4. Samples repository — includes Android Architecture Components, Storage samples, User Interface samples and many more. Most of them are useless crap, outdated and to show-off, all their APIs together. It does not make any sense to put so much effort.
5. Gigantic sized APIs instead of concise and intuitive. Poorly documented and insufficient examples.
6. WorkManager is cool! I mean really cool stuff (Ahem, until you try with Dagger multi-bind 😢). Listen to this episode from Android Backstage to hear what’s inside the tool. Complaints? WorkManager support RxJava with the class RxWorker. All good. Remember what is the standard roadmap for Android’s new feature — it’s not finished, something is always missing. In that case, it supports RxJava but the one cant have Reactive observer on the status from the worker. Google please fix this.
7. Data-binding? Don’t get me started. Some developers use for the sake of view binding only, please don’t do that. Increased build times, frequent cache invalidation(mostly it's because of kapt but still) hunting down bugs from overridden click listeners and missing data. What does Google do? Pushes it in all Android samples and in fundamentals codelab.
8. Lots of tech debt. Year-by-year the amount of deprecated technology is getting increased due to new best practices by Google. Everyone seems hyped about it and it’s so annoying seeing thousands of repositories replicating same concepts without any sense. The current state of Android is like this: “there is a new library every day and everything is deprecated.” I wish to see more mature steps toward advertising new technologies.
9. Configuration changes. Google is pushing ViewModels by default in every aspect. Even making configuration change more complicated. Forced ViewModel SavedState module in favour of `onSavedInstanceState(bundle)` (not deprecated, yet 😈). There are plenty of developers who don’t use ViewModel and don’t need it because of app requirements.
10. onActivityResult API. this is going to change soon with the AndroidX fragment release, but I will always remember the ugly design it has from API level 1.

To summarize I don’t really hate Android itself but the state we are in. We have seen worse days than this obviously. The best part of the story happens to be the community is very active and that’s the part I like most and I contribute most of my time to it.

Google tries to fix some old mistakes and I appreciate, definitely on the right way, but feel a bit suspicious, if Camera API required 5+ years to make it easy-to-use, how much time other things are going to take?