Androidx App Startup Jetpack library

Photo by Jonathan Kemper on Unsplash

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

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

Below diagram is from this site and gives diagrammatic overview of the App Startup library.

LibraryA, LibraryB, and LibraryC initialized by AndroidX Startup

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

Initialize Components at App startup.

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

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

Lazy 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.

References

Senior Android Developer at ECOM Trading