Lifecycle – (5) Integrate Lifecycle in several ways with the source code differences
It’s been a long time since I wrote this article, but I recently decided to write about another basic piece of Android: the official Android architecture component series. Lifecycle is going to be written down, so this series will be about Lifecycle.
The body of the
In fact, we know that in the final analysis, source code mainly on: basic class introduction, registered source code, send source code, response source code
In Lifecyele – (1) Fundamentals we have talked about three ways to integrate Lifecycle. We have talked about three ways to integrate Lifecycle.
In this article we will introduce Lifecycle as a basic class and focus on State and Event because many people will forget the exact relationship between Lifecycle and events and why. (I have also been asked by others, who said they could not understand), so this article focuses on this content.
1.1 Lifecycle State and Event analysis
1. Lifecycle class
We know that the landlord needs to tell the relevant information to the intermediary, and the intermediary will relay the information uniformly. Therefore, some relevant so-called information values are also defined by the landlord, such as price value.
public abstract class Lifecycle {
//'This is pretty straightforward, just add an Observer, and we'll see what happens later.'
@MainThread
public abstract void addObserver(@NonNull LifecycleObserver observer);
//'Literally, remove Observer'
@MainThread
public abstract void removeObserver(@NonNull LifecycleObserver observer);
//'Get current State value'
@MainThread
@NonNull
public abstract State getCurrentState();
//'Event value'
public enum Event {
ON_CREATE,
ON_START,
ON_RESUME,
ON_PAUSE,
ON_STOP,
ON_DESTROY,
ON_ANY
}
//'the State value'
public enum State {
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
public boolean isAtLeast(@NonNull State state) {
returncompareTo(state) >= 0; }}}Copy the code
We can see that there are two main types of values: Event and State, which literally means that State will be the value of the current Lifecycle and Event will be the value of the action that will follow Lifecycle
(PS: It can be simply understood that the landlord has two state values. One is the specific housing price, for example, the house is set to sell 10,000 yuan per square meter, and the other is the action value, for example, the price increases of 1,000 yuan per square meter. Such a simple analogy is easier to understand.)
Have you ever wondered why there are 7 events (ON_ANY I won’t cover in a minute, so I’ll explain 6 events later) and only 5 states? A lot of people will say that Lifecycle will have this value, if you were to write source code will you design it like this, will you design it like this??
Let’s look at this problem in detail:
If you draw a normal picture, I guess you would draw it as:
I’m sure you can understand the above diagram, there’s no problem, because it’s a horizontal chain structure, we can bend it so that the picture is not too long, let’s draw the second diagram:
For example, ON_RESUME is aligned with ON_PAUSE and ON_CREATE is aligned with ON_DESTORY. However, we have too many State values. Is there any way to change them? The answer, of course, is yes:
We changed the name of our onPause to onStart2, which is different from onStart, but it’s actually onPause, so we changed the name. The answer is yes, why? Because there are events, we can know.
Maybe some people here are a little confused, let me take an example: for example, the original house price is 13000 per square meter, increased by 1000, became 14000, and then increased by 1000, became 15000, then decreased by 1000, and changed back to 14000, can I distinguish the two 14000 at this time?? Of course, with the action value can be, because one is called up by 1000 14000, one is called down by 1000 14000.
Of course, in order to look better, we can write the above changes in housing prices as:
In the same way, we changed the name of onPause to onStart, but because of the ON_PAUSE action, we know that onStart is actually onPuase, and we changed the name of onStop to onCreate
So the picture becomes:
Finally, in order to have a good symmetry, we used red ones to complete the relevant missing places:
Let’s take our image and compare it to the official Android image to see if it’s the same:
So in the future, when the interviewer asks you about the value of State and Event, you can just play it off.
PS: At the same time, I would like to add a small knowledge point about enumeration, which is conducive to the understanding of some source code value judgment:
For example, let’s take the enumeration State:
public enum State {
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
}
Copy the code
For example, at present, when comparing the size of enumerations: DESTROYED.compareTo(CREATED), how much will this value be? Let’s look at it step by step:
public final int compareTo(E o) { Enum<? > other = (Enum<? >)o; Enum<E> self = this;if(self.getClass() ! = other.getClass() && // optimization self.getDeclaringClass() ! = other.getDeclaringClass()) throw new ClassCastException(); //'We can see that the last comparison is the ordinal value of Enum, which is the order value'.return self.ordinal - other.ordinal;
}
Copy the code
So it actually looks like this:
Public enum State {// DESTROYED, 1 INITIALIZED, 2 CREATED, 3 STARTED, // 4 RESUMED; }Copy the code
DESTROYED.compareTo(CREATED) results in 0-2 = -2;
CREATED.compareTo(DESTROYED) : 2-0 = 2
conclusion
This article will make it easier to remember events & State.
