Where is the way forward? Analysis of the current status of Android native development

[[313474]]

Preface

The Android native development ecosystem has been constantly evolving, and my experience in Android development over the past five years has made me realize this. Every two to three years, Google releases new development guidelines, libraries, and frameworks, and I spend a lot of time carefully reviewing these changes and identifying possible problems. I believe many Android developers have similar experiences.

However, 2019 is definitely a year of dramatic changes in the Android native development ecosystem. In this year, the Android SDK has added a lot of new content, rewritten and removed some old content, and the official developer guide has also been significantly updated. It is really difficult to have a complete and detailed understanding of Android development.

So I wrote this article, I tried to summarize what happened in the Android ecosystem and make some predictions about the future of native development. Next, I will divide my views into different chapters for specific explanation, and at the end of the article, I will share some controversial views.

I hope you find this article helpful, but please keep in mind that there are certainly many important things missing from the article and many of the opinions here are my own personal biases.

AndroidX

The preview version of AndroidX was released a year and a half ago. It became stable about a year ago, and at the same time Google stopped further development of the old Support Library. The moment I wrote this sentence, I remembered a question I asked on StackOverflow before: Why does AOSP add new APIs to support libraries without adding them to SDK? ( https://stackoverflow.com/questions/29197821/why-does-aosp-add-new-apis-to-support-libraries-without-adding-them-to-sdk ), I was a novice in android development at that time, I wanted to know the motivation behind the Support Library, why didn't Google put the Support Library directly into the android sdk?

Using the word "stable" to describe AndroidX seems a bit ironic, since nothing about AndroidX seems stable. Google is constantly adding new libraries and frameworks to AndroidX. The namespace and many old APIs (currently less than a year old) are evolving at a very fast pace.

[[313475]]

So far, I have migrated two of my apps to AndroidX. Everything went smoothly, but I didn’t find it amazing. Jetifier is a tool that redirects dependencies on the Support Library to their AndroidX counterparts, and the conversion is surprisingly good. But even if the app is not big, it is not a "one-click migration".

I've also worked on a project that has not yet been migrated to AndroidX with no issues. In some cases it seems like I don't need AndroidX at all.

All in all, I would say that if you are starting a new Android project, you should definitely use AndroidX; for existing projects, I also recommend that you make plans to migrate to AndroidX, even if you don't see obvious benefits now. You will most likely need to migrate anyway, so it's better to migrate according to your own plan rather than make an emergency migration later when you need some new AndroidX libraries.

Jetpack

After discussing AndroidX, I have to mention Jetpack. As far as I know, Jetpack was originally a tool collection of "architecture components", but later expanded to include most (or even all) APIs of AndroidX. Therefore, so far, I have not seen any meaningful difference between AndroidX and Jetpack, except for marketing and PR publicity.

When you visit the official website of Jetpack ( https://developer.android.com/jetpack ), it looks less like technical documentation and more like the homepage of an early-stage SaaS startup.

Check out these testimonials:

Take a look at the following apps:

I wouldn't be surprised if Jetpack files for a standalone IPO in 2020 since they are so focused on marketing and PR.

Seriously though, there are some deep issues with this approach of "selling" APIs to developers in your own ecosystem. For example, why would anyone really want to advertise ViewModel in Search?

In summary, since most of Jetpack's content is derived from AndroidX, what I wrote about AndroidX before is also applicable to Jetpack to a large extent.

Below, I will discuss some of these specific APIs separately.

Background Work

One of the most common scenarios in Android development is to allow your app to perform actions when it is not in the foreground. Before the introduction of doze mode, SyncAdapter, GCMNetworkManager, FirebaseJobDispatcher, JobScheduler, and most recently WorkManager, you could do this by starting a service (rather than binding it). These are Google's own APIs, but there are also many third-party solutions, such as Android-Job.

However, Google recently announced that they will unify the scheduling of background tasks through the WorkManager API ( https://android-developers.googleblog.com/2019/11/unifying-background-task-scheduling-on.html ). It sounds great, but for some reason, when I hear something like this, I always feel a sense of déjà vu...

Regardless of whether it is unified or not, WorkManager does not solve the single most serious problem with background tasks: reliability. I won’t explain it here, but remember, if you need to run background tasks in your app, please read all the information on dontkillmyapp.com first. Also, please read and star the issue in Google’s issue tracker.

Android's background task execution and scheduling is a mess, and fragmentation makes it very subtle and unreliable.

In the past, I have always advocated for putting data synchronization and similar work in the background whenever possible, and I may be the last fan of SyncAdapter. But today, given the reliability issues, I advocate the opposite approach: avoid performing operations in the background as much as possible. If your PM insists on using this feature, please show them the link above and explain to them that background tasks take hundreds of hours to implement and bring more trouble than benefits.

There are times when running background tasks is unavoidable, but in most cases, you can avoid doing so, and it may be the best option, even at the cost of some inconvenience to the user.

Databases

There is no doubt that Room dominates among the many ORM frameworks for SQLite. Since 2.2.0, Room supports incremental annotation processing. But remember, your application architecture should not be too concerned about which ORM framework is used. Therefore, as a member of architecture components, Room is just a marketing term, not a technical role.

The main contender for ORM frameworks in Android development is SQLDelight. This library is older than Room, but from what I understand, it has been rewritten quite a bit in the past year or so. Unfortunately, it only targets Kotlin right now. On the other hand, SQLDelight supports Kotlin cross-platform. So as Kotlin usage increases, I expect SQLDelight usage to increase as well.

By the way, there are instructions for using native SQLite in AndroidX, but I don’t know how to use it yet. But if you want to use native SQLite in your app, you may need to study this topic seriously.

[[313476]]

There are also many non-relational databases for Android, such as Realm, Parse, Firebase, ObjectBox, etc. (some of them still use SQLite). If I remember correctly, most (or even all) of them had automatic data synchronization features. For a while, these solutions were popular, but as far as I know, they are no longer. But I would not immediately assume that non-relational databases are no longer important.

Last year, I wrote a very complex Android app that integrated Parse Server. I used the Android version of the Parse SDK and had a very good experience. If your company has already hired many backend developers or you need to implement a lot of server-side logic, this may not be the best solution, but for startups and individuals who only perform CRUD operations on the backend, this may be a good choice.

But I must warn you: if you are going to adopt a database-as-a-service solution (such as Firebase), make sure you understand its long-term costs and impacts.

External Storage

There are many interesting things going on when it comes to external storage development.

If your app's target sdk version is equal to or greater than 29, then your app will no longer be able to access files on the phone's external storage, except in a few obvious cases. Instead, you need to use the SAF framework (supposedly), which allows users to do more fine-grained access management. Unfortunately, SAF works completely differently than before, so some apps may need major refactoring.

Google wanted to implement this requirement for all apps starting with Android 10, but it caused strong protests from the developer community, so they decided to postpone this feature. Therefore, even if your app sets the target sdk version to 29, it can still work in "legacy" mode. However, regardless of the target API level, the next version of the Android system will impose stricter restrictions on the storage access range of all apps.

I haven't used the SAF framework so far, but from many discussions I read on the internet it seems like this could be a daunting task. So if your application is still using external storage in "legacy" mode, it's best to start refactoring and testing now.

Shared Preferences

A few weeks ago, a new framework was added to the AndroidX series ( https://www.techyourchance.com/the-state-of-native-android-development-november-2019 ). Its commit message says this:

New library meant to replace SharedPreferences. The name is not final, this is just for implementation review and to support the design doc (feel free to request the design doc privately)[…]

For now we don't have to worry about this, but in the long run it seems that SharedPreferences will be rewritten and we will need to use this new approach.

The main difference between SharedPreferences and this new framework is that the latter is asynchronous by default. In other words, you need to implement a callback to get the value of a specific key, and the callback will be notified at a later time.

If you are curious about the mechanics of this asynchronous notification, you can read this answer on StackOverflow ( https://stackoverflow.com/questions/37549578/how-to-get-something-useful-from-this-anr-log/37551254#37551254 ). Reddit user Tolriq shared their experience with this bug here. In their app, this bug affects 1/10,000/SESSIONS_PER_USER_PER_MONTH of users. For general applications, this may be insignificant. But in situations where high reliability is required, this may cause serious consequences. For example, in a car with Android Auto, the app hang and subsequent crash distracts the driver, which may lead to very unfortunate consequences.

Dependency Injection

The biggest change in terms of dependency injection is the deprecation of Dagger-Android. I want to explain two things here: first, when I say deprecated, I don’t mean “officially” deprecated, because it has not been officially deprecated yet. Second, Dagger-Android is not the entire Dagger2 framework, but only relatively new features. I wrote a very detailed article on this topic ( https://www.techyourchance.com/dagger-android-dead/ ), so I won’t repeat it here.

As for other dependency injection frameworks, I don’t think they are real competitors to Dagger. For example, Koin might be good, but I don’t think it will attract many people. In fact, I believe it has only seen initial adoption for two main reasons. The first is the terrible documentation of Dagger, Koin is light years ahead of Dagger in this regard. The second reason is that Koin is written in Kotlin and it started to rise on the wave of kotlin development. So far, this wave has almost died down.

I think what might happen is that pure dependency injection frameworks (aka manual dependency injection) will emerge.

Now, Google claims that "the cost of manual dependency injection grows exponentially as your application grows". I think this just shows that they neither understand what "exponential" means nor have they done any actual "measurements". This statement is completely wrong, and I hope Google will stop misleading the developer community in this way.

In fact, pure dependency injection is very common in backend development (especially when developing microservices, where you don't want to add a dependency on the framework for each service), and reflection is also a valid option in backend development. Therefore, if you want to use a dependency injection framework, they usually don't need to parse compile-time code.

However, the situation is different for Android development. Since we can't use reflective DI frameworks, we use Dagger. In fact, we can use reflective DI frameworks, and it's OK for most projects, but there are performance issues. I'm not saying that using reflective DI frameworks is safe, but it's definitely not a black-and-white solution. In any case, Dagger is already the de facto standard for using dependency injection in Android development, and we all use it. But the cost of using Dagger is also obvious:

• 1) The more code your application has, the more time it takes to run annotation processing during the build process.

• 2) The more developers involved in the application, the more builds they need to perform.

• 3) All developers need to learn Dagger, which takes a lot of time.

In other words, while Dagger does allow you to write less code, it will cost you more time on larger projects because it affects build times and the training time required.

In large projects, slow build times are a real problem and become a major productivity bottleneck. So while Dagger does provide very nice features to simplify DI (once you know how to use it, of course), I believe we will see more and more interest in pure Dependency Injection.

DataBinding

One of the main reasons developers adopt DataBidning is to no longer have to call findViewById. To be honest, findViewById is really redundant and I don’t mind getting rid of them. However, in my opinion, the small annoyance caused by calling findViewById does not justify the use of DataBinding. The good news is that soon we will be able to remove these findViewById calls using another new feature ViewBinding.

Actually, I never believed in DataBinding. I felt it was too complex for the problem it (supposedly) solves. Moreover, DataBinding allows developers to put logic into XML layouts. Experienced developers don’t use this approach because it makes the project maintenance more difficult. This is another disadvantage of the DataBinding framework.

Back in November 2016, when DataBinding was at the peak of its hype, I made the following prediction in an answer on StackOverflow:

However, there is one prediction I can make with a high degree of confidence: Usage of the Data Binding library will not become an industry standard. I'm confident to say that because the Data Binding library (in its current implementation) provides short-term productivity gains and some kind of architectural guideline, but it will make the code non-maintainable in the long run. Once long-term effects of this library will surface – it will be abandoned.

Now, I don't have any statistics on the usage of DataBinding, but it's clear that it hasn't become an industry standard. I myself have never seen a professional project using DataBinding, and I rarely see developers using DataBinding in their applications. In my estimation, once ViewBinding matures and becomes widely adopted, DataBinding will become more popular and become a "legacy" framework.

Preserving State on Configuration Changes

Since the introduction of ViewModels, handling configuration changes in Android apps has become a mess. I know that's a bit harsh, but it's really the mildest way I can describe it.

Luckily for me, Gabor Varadi (aka Zhuinden) has already summarized this issue in this post on Reddit, so I don’t have to do it myself. His conclusion is: onRetainCustomNonConfigurationInstance is deprecated in favor of ViewModel. Interestingly, at the end of the post, Gabor makes some rather cynical predictions:

Did you notice anything? Retained Fragments are now deprecated! .

I think that deprecating retained fragments is actually a good idea. The only reason the fragment lifecycle has onAttach and onDetach methods is to support the use of retained fragments. By deprecating retained fragments, these methods can also be deprecated and the fragment lifecycle can be simplified. If you use my approach ( https://www.techyourchance.com/android-fragment-lifecycle-for-professional-developers ) to handle the fragment lifecycle, then this deprecation will not bother you because I have long recommended that you avoid retained fragments and ignore the onAttach and onDetach methods.

While there are good reasons to deprecate retained fragments, deprecating onRetainCustomNonConfigurationInstance is bullshit. This is not what I said, but what Jake Wharton said (you can read his original words under the aforementioned Gabor post on Reddit).

Why are these changes being made? I can only see one explanation: Google decided to force all Android projects to migrate to ViewModel regardless of other technical advantages. They are willing to deprecate all existing alternatives to achieve their goals, even if these alternatives are actually better than ViewModel itself.

Sounds a bit conspiratorial, right? I agree. But, luckily, we can do a simple test of this theory.

While I don't like Preserving State on Configuration Changes, it doesn't affect me in any way because I don't use it. In fact, the vast majority of applications don't need it. They don't need ViewModel either. The correct way to handle Configuration Changes is to add processing logic in the onSaveInstanceState(Bundle) callback method. This is a simpler and better approach because it also handles the save and restore flow (also known as process termination). So as long as I can save the state this way, it's fine. Despite Google's heavy marketing and PR efforts, many experienced developers realize that ViewModel is too complicated and there are better ways to preserve the state of configuration changes.

So if Google really has ulterior motives and wants to force all projects to use ViewModel, then they also need to deprecate onSaveInstanceState(Bundle). I know this sounds crazy, but it's actually a good thing because if this crazy prediction comes true, you'll know the underlying theory is correct.

However, given Android's memory management mechanism, Google can't just deprecate onSaveInstanceState(Bundle) without providing a reliable alternative. "Luckily", these changes have already been applied to the ViewModel's save state module.

I think in a year or two we will know whether there is any merit to this approach.'

In summary, as I said at the beginning of this section, Configuration Changes in Android have been shit since the release of ViewModel. More than two years ago, when I wrote the article titled "Android ViewModel Architecture Component Considered Harmful" ( https://www.techyourchance.com/android-viewmodel-architecture-component-harmful ), I predicted that ViewModels would be a waste. All of my predictions were true, but unfortunately, the truth turned out to be worse than that.

Concurrency

The biggest change in terms of concurrency is the deprecation of AsyncTask. I’ve written a very detailed article on this topic ( https://www.techyourchance.com/asynctask-deprecated ) with specific recommendations, so I won’t go into detail here.

What I am about to say may offend some of you. Please don't take it too seriously.

RxJava, another popular multithreaded framework in Android development, will soon become a thing of the past. This is clearly seen from the following StackOverflow trend chart:

Many developers will challenge my opinion, saying that the data is not representative and that there are other ways to explain this graph. They may be right, as I am not a data scientist myself. However, I do not see any other explanation for the spike in this graph, and the curve for RxJava has the same slope as the curve for AsyncTask.

So if you haven’t taken the time to learn RxJava and your project isn’t using it, I recommend that you avoid it. In fact, this has always been my advice, and today it’s backed up by data.

If your project already uses Rx, don't panic, you don't need to refactor anything right away. However, keep in mind that it will be increasingly difficult to find developers with Rx experience in the future. Therefore, using Rx extensively in a project may require more time from new developers. Eventually, projects that use Rx extensively will be considered "not cool" (such as projects that use AsyncTask and Loaders today).

I know that these opinions of mine are not very friendly to many developers. They have spent weeks learning RxJava and even convinced their colleagues to use it in their projects, and now I say that it will become a thing of the past. I just want to say that I am only analyzing the actual situation and making predictions based on what I see. I may be wrong or I may be right.

In Kotlin, we can use coroutines. I recently implemented some complex use cases using coroutines ( https://www.techyourchance.com/kotlin-coroutines-in-complex-scenarios ) and found that this framework is very subtle and complex, and relatively immature. I even found a bug.

There is a popular saying that coroutines make concurrency easier. I never thought so because I knew concurrency is very complicated, but after some practical experience, I can confidently say that coroutines are not as beautiful as imagined. In my opinion, coroutines actually increase program complexity, so I suggest you use them with caution.

On the other hand, coroutines seem to be the default way to handle concurrency in the Kotlin language, so I think if you write Kotlin code, you need to invest the time and learn to use them.

As far as I know, there is also a stream framework which adds stream processing operators on top of coroutines. It was only stabilized a few months ago, so I can't say anything about it yet.

Kotlin

Now let's talk about Kotlin. From past experience, I know that this is a very sensitive topic, and no matter how objectively I describe it, I will eventually be attacked by some developers. However, I think it would be extremely dishonest to skip Kotlin when summarizing the current state of native Android development. Therefore, I once again ask you not to take my words seriously.

One important fact you need to know is that using Kotlin in Android development will seriously increase your build time.

In this article, you’ll find the results of statistical tests I performed on build times when developing with Kotlin. Clean builds increased build time by 18%, and incremental builds increased build time by 8%.

Uber and JetBrains have also published their own research results, and their results are even more negative. If you are not using annotation processors in your application, then introducing Kotlin may increase your build time by four times! If you are using annotation processors, then introducing Kotlin will increase your build time by 50%-100%.

Uber’s findings are consistent with the finding that build times increased 4x after migrating OkHttp to Kotlin.

If you are surprised by these numbers, don’t worry - it’s not your fault, and you are not alone. Despite the importance of this fact, it is not widely discussed, and I feel like Google tries to avoid it. I had a very interesting discussion with a developer at Google who was familiar with this, and I asked him if we could discuss this topic, and he said, “I don’t like it; I don’t like it; I don’t like it. It’s a very delicate thing.”

[[313477]]

Besides increasing build times, Kotlin does not support incremental annotation processing, which was added to Java about 10 months ago.

Two years ago, I wrote an article ( https://www.techyourchance.com/kotlin-vs-java-whole-story ) to warn developers about the potential risks they might encounter when using Kotlin in the early stages. For a long time, I was called a "Kotlin hater".

However, if you read this post today, you’ll see that I actually underestimated the severity of these issues. Build times are one of the worst productivity killers on large Android projects, and even today, more than two years after Kotlin was officially “adopted,” Kotlin is still inferior to Java. Whatever other benefits Kotlin brings, all of them are likely negated by longer build times.

In other words, we should not ignore the fact that it was Google that forced the Android development ecosystem to Kotlin, causing its usage rate to steadily increase.

Personally, I haven't chosen Kotlin for the new projects I've started so far, I don't want to waste my own time on Kotlin. However, from now on, I will seriously consider using Kotlin to develop new projects, I have tried it on several demos. But I don't agree with developers saying that you must use Kotlin in new projects, it's still a trade-off.

As for whether you should migrate your existing projects to Kotlin, I can't offer any general advice, you need to carefully analyze your specific situation. However, if you do decide to start (or have already started) the migration, this post may be useful to you.

Summary

In the past two years, I've built three new apps. I've taken a hard look at existing projects and analyzed the long-term impact of early technology decisions. I've written a few blogs that offer advanced courses on Android development. I've spent a lot of time discussing Android development topics on the Internet.

Despite this, I still feel like I can't keep up with the changes in the Android ecosystem.

If that's the case, I'm deeply sorry to the inexperienced Android developers out there who need guidance, and I still can't imagine what it's like to learn Android development from scratch. By the time you get comfortable with the frameworks and tools, many of them will be obsolete or will soon be. This is probably the worst possible time to join this otherwise great community. Google is very proud of their "inclusiveness", but it looks like it doesn't apply to inexperienced developers.

I personally think that the changes Google makes to the Android framework result in a huge waste of human potential. It would take hours to read all of these changes, let alone actually implement them. I would rather spend more time creating value than chasing my tail.

In this post, I tried to summarize some important things about the current state of native Android development, and I also made some predictions about the future. This post is not perfect: it may contain some errors, and it may miss some other important things. Please feel free to correct me in the comments below. But please remember that this article is nothing personal. I know I made some very controversial points, but I believe they are right.

I have also referenced some of the articles I wrote previously in several places in this article. I do this not to show off and say “see, I was right!”, but to give you the ability to see my past predictions and compare them to what actually happened. When I wrote those articles, they read as crazy as if you were reading this article today. But the predictions I made were incredibly accurate.

Of course, I also want to say, “See, I was right!” I publish these controversial predictions at great professional risk, and I feel great relief knowing that I didn’t mislead my readers. Even though sometimes I’d rather be wrong and Google be a true partner. But so far, that hasn’t been the case.

Finally, attached are some of the author’s views on cross-platform development for reference only.

• Learn it even if you can't! Learn more about ViewPager2

• Effective Java in Kotlin: 2. Consider using builders when you have multiple constructor parameters

• Who is born to be a programmer?

Which trend do you think will become popular first?