Androidx App Startup Jetpack library
Users expect app to be responsive and fast to use and as a results, app developers mostly make sure that their apps are responsive as such. When the application is responsive and fast, it gives the user a nice feeling and they might not dump your app for a different one and also, they might give good ratings on your app on play store.
Understanding App-Start Internal
Before we can talk about androidx jetpack app startup library, let’s try to understand what happens when app is started. We have three states that app can pass through before they can be fully visible.
The three states are cold start, warm start and hot start and these states affect the how long the app is launched or become visible to the screen. In the cold states, the app is started from scratch and the other two states brings the app from the background to the foreground. When we need to optimize our app, we should do so on the assumption of cold start and when this is done, it cascade to the performances of the other two starts.
Androidx Jetpack App Startup Library
This is a new addition to the jetpack suite of libraries. Most of the libraries run some initialization logic on app startup; libraries like WorkManager and android lifecycle provide some pieces of initialization through the use of content provider which allows initialization once the app goes through a cold start. So when we have more libraries that do initialization in application startup and uses content providers, the application can take some time to finish loading and this affect the user experience of the application.
Below diagram is from this site and gives diagrammatic overview of the App Startup library.
Androidx App Startup library has come to help with this situation. Now instead of using separate content provider to initialize the library components, App Startup uses a single content provider to do this initialization of all the dependencies and as a result, reducing the setup cost.
This is because opening a content provider is very expensive so this library is good and has really come to help since it offers a single content provider to be shared by all the component dependencies for their initialization.
Setup and How it is used
To use Jetpack Startup in your library or app, add this to the android build.gradle file. This version is the latest as at the time this blog was written.
Initialize Components at App startup.
To make use of how App Startup library works, let’s say you want to initialize a Library A but the Library A depends on a Library B. You can do this in App Startup way by creating a class that implements Initializer<T> interface. Below is how it is done.
When you implements the App Startup library, you need to implement some methods.
a. create(Context): This gives you the application context and this is where you return the object of initialization for the library component.
b. dependencies(): This returns the list of dependencies your current library component depends on. This is set to run in an order depending on the order of their dependencies. If LibraryA -> LibraryB -> LibraryC is the order, then the LibraryC runs first, followed by LibraryB and finally LibraryA.
Setting up Manifest Entries
After creating your library component initializers, you need to setup the App Startup library in the androidManifest file. When this is done, it means, your initializers would be called automatically. The App Startup is initialized by using InitializationProvider but it is called with a <provider> with the provider name pointing to InitializationProvider class.
The library uses <meta-data> tag to declare all the initializers but we do not declare the initializers called in the dependencies() as it will be called automatically. For our above example, we do not need to declare LibraryBInitializers.class in the <meta-data> tag.
The tools:node="merge" is used in the <provider> tag to ensure that the manifest merger tool properly resolves any conflicting entries.
The tools:node="remove" in entries remove a particular initializer depending on where you are calling this attribute. You can call this attribute in <provider> tag to disable all initialization when app is starting up. You can also call this attribute in <meta-data> to disable only that Initializer and its corresponding dependencies.
Checking that All Initializers are correctly declared
We can run lint check to see if any of our initializers are not throwing errors or not correctly declared well. You can run this ./gradlew :app:lintDebug from the command line.
Lazy Initialization
You can manually do initialization and this is useful when you don’t need some of the library to be initialized when the app is starting up. To do this, you can make use of tools:node="remove" on the initializers we intend to do manual initialization for and run this piece of code at a point we intend to do the initialization.
After placing this configuration in manifest file, then you can run this piece of code in your java class but we need to use AppInitializer class
In conclusion, App Startup is really good and you might need to try it in your application. Thanks again for your time, Folks.
