Android app development is constantly evolving. As the community continues to explore new ways to develop , Google continues to provide new technologies to keep us moving forward.

In this article, 3 technologies that I think will start to be phased out this year. At the very least, use less.

1. Android View

Since day one of Android development, we've defined the view primarily with XML. This is a proxy with Android View code (in Java) behind the scenes.

This allows the Activity and Fragment not to interact directly with the view's code.

Unfortunately, there are a few limitations, e.g.

• When we want to interact between views (such as animations), we'll need code in the Activity to manage everything.
• Binding data to a view is always tricky. There is no perfect way to do this other than manually transferring the data.
• The purpose of an Activity is not clear to everyone. For some it's a controller, for others it's a view. Sometimes we have too much code inside.

Jetpack Compose is the future

In this regard, the Jetpack Compose was introduced. A completely different UI design paradigm than Android View. It is declarative in nature, which is much more in line with today's preferred programming paradigm.

It overcomes the Android View issues mentioned above, for example:

• Views can cross-interact with each other in Jetpack Compose, so animation control can be in Composable functions.
• The Mutable State data is automatically bound to the view component's function. Changes to them recompose the view. Therefore, there is no longer any need for explicit manual data processing.
• The role of Activity/Fragment continues to decrease. The ViewModel can be connected to the corresponding Composable function.

Jetpack Compose was first announced in 2019 at Google I/O, and the first stable version was released in September 2021 . Now many applications have started using Jetpack Compose.

2.Live Data

During Google I/O 2017, the Architecture Component was first announced , in which Google now has a recommended architecture pattern for Android developers, i.e. MVVM using ViewModel and LiveData.

At one point the ViewModel was still a half-baked solution, as it only survived configuration changes, not process deaths. However, in 2019, the SavedStateHandler was introduced in the ViewModel, which made it possible to use this technology in every screen of the application.

Therefore, already in 2020, many applications began to use the Architecture Component, using LiveData as a means of communication between levels.

However, it has many limitations and was never intended to be widely used. As Yigit Boyar said:

LiveData has never been a replacement for RX, we've been very clear about it since day one, but sometimes it's hard to control the agenda. Actually, at the time (over 5 years ago) we were thinking about making RX a core technology, but after seeing how much people suffer from it, we decided to provide a lightweight solution that can deal with common simple cases as well will serve as a starting remedy for reactive programming. For the same reason, we never added multithreading or many transformations. In fact, the original design didn't even have transforms, but we noticed that LiveData was too limited and useless without them (without switchMap, to be honest).

StateFlow is the future

These days, Kotlin coroutines are gaining momentum in Android development, Kotlin Flow as an alternative to RxJava, and Kotlin StateFlow as a communication tool that connects different layers of the Android architecture.

StateFlow has many advantages :

• Kotlin StateFlow is part of Flow, which has many operations available to transform data, etc.
• This can ensure seamless work between different threads, just like we've used RxJava in the past.
• This is a technical stack that is platform independent and can be used in shared code such as KMM.

More importantly, the Google development team is now supporting StateFlow by introducing Kotlin extension features to make it run more smoothly on Android.

Although StateFlow is not perfect yet, I think the Google team will continue to improve it for use in Android development. In addition, already today there are many workarounds for its limitations.

So I foresee we will see more use of StateFlow in the coming months, although LiveData may still be used for some lifecycle specific work, it will be used much less in the future.

3. Activity Lifecycle API

This is a bit of a contentious issue. Maybe not everyone will agree with me, but I see this trend more and more.

From day one of Android development, Activities have dominated the life cycle of an app's screen. They have many lifecycle APIs like onCreate, onStart, onResume, onpause, onStop, onSavedInstanceState, onDestroy…

Their use is both love and hate because, although they allow us to process responses in certain Activity life cycles, it seems like we need to use a lot of pesky code in the Activity to respond to these events.

It also makes the Activity/Fragment the central point of control for a particular screen/view. Because of this, there are many technical obstacles in development. For example, testing becomes more difficult.

Google is starting to advocate for deprecating the Activity Lifecycle API

If we look closely, Google's approach to Android development has been to move away from Activity as much as possible.

1. With the introduction of the Android Architecture Component in 2017, Google introduced a ViewModel that persists when onConfiguraiton changes. Hence, it helps to reduce the call to onSavedStateInstance (though not completely).
2. With the introduction of LiveData, the goal is to be able to reduce the code in an Activity and unsubscribe from the observer. LiveData will no longer send data to an observer in an Activity when it is no longer active, so we no longer need the lifecycle API for this purpose.
3. Google has also introduced the Lifecycle class , with which you can intercept lifecycle events as needed by any class that needs to know about it. This removes the explicit need for code in the Activity Lifecycle API.
4. In 2019, the SavedStateHandler was introduced for the ViewModel, further reducing the need to use onSavedStateInstance in an Activity.

Lifecycle aware coroutines

Recently, with the advent of coroutines, instead of just using a Global Scope for MainScope() or even creating arbitrary CoroutineScope, we now have a Lifecycle Aware Coroutine.

These coroutines will have the ability to either terminate or pause their activity when the Activity goes into the background. They may also resume when the screen comes to the foreground.

Here is what their behavior looks like:

By using them, there is no need to manually work with the Lifecycle API, further reducing the need for Activity Lifecycle API calls.

Still here, just smaller

Today, there are still applications that are written using Java, maybe not completely, but partially. Likewise, the Android View (XML), LifeData, and Activity Lifecycle APIs will continue to exist for some time to come. But I think that this year their use will start to decline.

If you're new to Android, it's good to know what they are and be able to use them as needed, but the focus in the future should be on newer ways of developing.