Jetpack is “the next generation of components to accelerate app development”. It’s a set of libraries, tools and architectural guidelines to help making building great Android apps quick and easy. It provides common infrastructure code so you can focus on what makes your app unique.
Activity/Fragment - Depend only on a view model.
View model - Provides the data for fragment or activity, and contains data-handling business logic to communicate with the model.
Repository - Depends on a persistent data model and a remote backend data source and handle data operations.
Room - An object-mapping library that provides local data persistence with minimal boilerplate code.
Retrofit library - To access our backend through REST API.
Lifecycle-manageable components such as activities and fragments perform actions in response to a change in another Android component. The lifecycle methods of activities and fragments leads to a poor organization of the code and to the proliferation of errors in most of the cases.
The lifecycle-aware component helps to move the code of dependent components out of the lifecycle methods of activity & fragments and into the components themselves.
Dependencies
AndroidX
dependencies {
def lifecycle_version = "2.0.0"
// Lifecycles only (no ViewModel or LiveData)
implementation "androidx.lifecycle:lifecycle-runtime:$lifecycle_version"
annotationProcessor "androidx.lifecycle:lifecycle-compiler:$lifecycle_version" // use kapt for Kotlin
// alternately - if using Java8, use the following instead of lifecycle-compiler
implementation "androidx.lifecycle:lifecycle-common-java8:$lifecycle_version"
}
Pre-AndroidX
dependencies {
def lifecycle_version = "1.1.1"
// Lifecycles only (no ViewModel or LiveData)
implementation "android.arch.lifecycle:runtime:$lifecycle_version"
annotationProcessor "android.arch.lifecycle:compiler:$lifecycle_version" // use kapt for Kotlin
// alternately - if using Java8, use the following instead of compiler
implementation "android.arch.lifecycle:common-java8:$lifecycle_version"
}
Refer here for updated Dependencies.
The android.arch.lifecycle package can automatically adjust their behavior based on the current lifecycle state of an activity or fragment that has three main classes that we’ll deal with:
Lifecycle class holds the information about the component (like an activity or a fragment) lifecycle state where allows other objects to observe this state.
The lifecycle events (i.e. Lifecycle.Event.ON_CREATE, Lifecycle.Event.ON_RESUME, Lifecycle.Event.ON_PAUSE and etc) & lifecycle states (INITIALIZED, CREATED, RESUMED and etc) are used to track the lifecycle status for its associated component.
A single state can span multiple lifecycle owner events, so for an activity it’s considered in the CREATED state once it’s created and just before it’s paused, and in the same time the duration between the activity’s onStart() and just before onPause() it’s considered also in the STARTED state.
implementation "androidx.lifecycle:lifecycle-runtime:$lifecycle_version"
annotationProcessor "androidx.lifecycle:lifecycle-compiler:$lifecycle_version" // use kapt for Kotlin
// alternately - if using Java8, use the following instead of lifecycle-compiler
implementation "androidx.lifecycle:lifecycle-common-java8:$lifecycle_version"
}
Pre-AndroidX
dependencies {
def lifecycle_version = "1.1.1"
// Lifecycles only (no ViewModel or LiveData)
implementation "android.arch.lifecycle:runtime:$lifecycle_version"
annotationProcessor "android.arch.lifecycle:compiler:$lifecycle_version" // use kapt for Kotlin
// alternately - if using Java8, use the following instead of compiler
implementation "android.arch.lifecycle:common-java8:$lifecycle_version"
}
Refer here for updated Dependencies.
The android.arch.lifecycle package can automatically adjust their behavior based on the current lifecycle state of an activity or fragment that has three main classes that we’ll deal with:
- LifeCycle
- LifeCycleOwner
- LifeCycleObserver
Lifecycle
Lifecycle class holds the information about the component (like an activity or a fragment) lifecycle state where allows other objects to observe this state.
The lifecycle events (i.e. Lifecycle.Event.ON_CREATE, Lifecycle.Event.ON_RESUME, Lifecycle.Event.ON_PAUSE and etc) & lifecycle states (INITIALIZED, CREATED, RESUMED and etc) are used to track the lifecycle status for its associated component.
A single state can span multiple lifecycle owner events, so for an activity it’s considered in the CREATED state once it’s created and just before it’s paused, and in the same time the duration between the activity’s onStart() and just before onPause() it’s considered also in the STARTED state.
Since multiple states can interleave for a given point of time, if we want to check for a specific state, we always use the isAtLeast method:
if (lifeCycle.currentState.isAtLeast(Lifecycle.State.STARTED)) { //...}
If we're trying to manage the lifecycle of activity or Fragment, we must implement LifecycleOwner interface to the activity. The lifecycle of a whole application process is managed by ProcessLifecycleOwner. Fragments and Activities in Support Library 26.1.0 and later already implement the LifecycleOwner interface.
if (lifeCycle.currentState.isAtLeast(Lifecycle.State.STARTED)) { //...}
LifecycleOwner and Lifecycle Observers
If we have a custom class that we would like to make a LifecycleOwner, we can use the LifecycleRegistry class, but we need to forward events into that class.
LifecycleOwners such as Activity & Fragments are objects with lifecycle like Activity and Fragments. LifecycleObserver (e.g. LiveData) observes LifecycleOwners and are notified of lifecycle changes.
class SampleObserver implements LifecycleObserver{
@OnLifecycleEvent(ON_CREATE)
void startUp(LifecycleOwner source) {
}
@OnLifecycleEvent(ON_ANY)
void onAny(LifecycleOwner source, Event event) {
}
@OnLifecycleEvent(ON_STOP)
void cleanUp(LifecycleOwner source) {
}
}
The best way to handle lifecycle-aware components (activities and fragments) as lean as possible. They should not try to acquire their own data; instead, use a ViewModel to do that, and observe a LiveData object to reflect the changes back to the views.
So, Android Lifecycle-aware components are tracked and managed by Room, LiveData and ViewModel in the next episode.
