• Lifecycle (I) origins of Android Jetpack architectural components
  • Lifecycle (ii) for Android Jetpack architecture components
  • Lifecycle (iii) of Android Jetpack architectural components

The meaning of Lifecycle

I’ll start with a business case

This is an App for learning English. Part of the page supports delimiting words

How can this real business scenario be gracefully implemented?

First we need to define a global singleton player that has a method play(Val Content: String)

object ContentPlayer {
    
    fun play(content: String) {
        // Call system player to play
    }
    
    fun prepare(context: Context) {
        // The player is ready}}Copy the code

After implementing ContentPlayer, you can write something like this in the delimit event callback of an Activity that supports delimit playback:

class ContentActivity : AppCompatActivity(), UnderLineWordCallBack {
    
    override fun onCreate(savedInstanceState: Bundle?).{... ContentPlayer.prepare(this)}// The current Activity is called back after the dashes play
    override fun callback(content: String) {
    	// Start playing
        ContentPlayer.play(content)
    }

}
Copy the code

So we’re done with this. Do we really have to finish? If your Leader sees this code, he’s not going to let you go the next day.

Code like this can leak memory: If the client draws up a long English text and hits Play, halfway through the text the client doesn’t want to listen to it, and hits the back button, the player still holds a reference to the ContentActivity. While the player continues to play, the ContentActivity cannot be gc, and there will be a problem

So we also need to prepare an unAttach() method. The final plan is as follows:

object ContentPlayer{

    fun play(content: String) {
        // Call system player to play
    }

    fun prepare(context: Context) {
        // The player is ready
    }
    
    fun unAttach(a) {
        // Release the currently held Activity resource}}Copy the code
class ContentActivity : AppCompatActivity(), UnderLineWordCallBack {
    
    override fun onCreate(savedInstanceState: Bundle?).{...// Prepare player resources
        ContentPlayer.prepare(this)}// The current Activity is called back after the dashes play
    override fun callback(content: String) {
    	// Start playing
        ContentPlayer.play(content)
    }
    
    override fun onDestory(a){...// Release resources
        ContentPlayer.unAttach()
    }

}
Copy the code

Of course, there is no problem with the above code, it can be used normally. We also scrupulously protect the App from memory leakage, which is worthy of praise!

But there’s a problem:

  • Call consistency cannot be guaranteed, and there are great hidden dangers in multi-party collaborative development
  • Call not elegant enough
  • Code is too intrusive

If there are many activities in the App that need to use the function of underline play, then we need to repeat the above code in each Activity. When the amount of code is up, it will be easy to forget to call the unAttach method. Moreover, a project cannot be completed by one person later, it is usually collaborative development. If someone else’s interface wants to call your ContentPlayer, you’ll have to dig into the source code to release resources in the Activity’s onDestory unless you’ve written a detailed comment.

A more elegant and secure way to write this is to use the Lifecycle component

How does the presence of Lifecycle solve the problem

Before further optimizing the code with Lifecycle, take a look at the official definition of Lifecycle:

Life-cycle-aware components perform operations in response to changes in the life-cycle state of another component, such as an Activity or Fragment. These components help you write more organized and often leaner code that is easier to maintain.

That is, when we write code that develops a component that needs to be aware of the Lifecycle, we first think about using Lifecycle.

Let’s listen for the lifecycle inside the component, like this:

object ContentPlayer : LifecycleObserver{

    @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
    fun prepare(context: Context) {
        // The player is ready
    }
    
    @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    fun unAttach(a) {
        // Release the currently held Activity resource}}Copy the code

Method annotations determine when the current method will be called. Then register the observer in the Activity that needs to use the ContentPlayer

override fun onCreate(savedInstanceState: Bundle?). {
        super.onCreate(savedInstanceState)
        // One line of code
        lifecycle.addObserver(ContentPlayer)
    }
Copy the code

Lifecycle. AddObserver (ContentPlayer) will register the Lifecycle observer with a single line of code. Perfect solution to call consistency and code is too intrusive problems.

Lifecycle paves the way for other JectPack-related components

Lifecycle is a component that is fundamental to the Google Jectpack architecture in addition to being available to us developers. Databing, viewmodel, and so on all rely on lifecycle’s perception of the lifecycle, so I think it’s important to understand the use of lifecycle and the basic implementation principles before learning about jectpack and MVVM