Implement App Startup Library in Android

Apps with a shorter startup time have a better user experience. So in this article, we’ll talk to you about why the App Startup Library is necessary. Most importantly, we will understand what difficulties it solves and how it aids us in reducing the time it takes for an app to start up. The time it takes for your app to startup has a big impact on how consumers view it. The major goal of this article is to help you understand why the App Startup library exists, not how to use it. Everything becomes relatively straightforward if we understand the necessity and the challenges it answers.  First and foremost, Google has released the App Startup library, which will undoubtedly aid in improving the App Startup time. Android Jetpack includes the App Startup Library. We need to grasp the issues with the present method taken by app developers or library developers in order to fully comprehend the challenges that the App Startup library solves and make the most of it. Knowing these factors will also aid us in making appropriate use of the App Startup library.

The Problem in Current Approach

You may have observed that many libraries have stopped requesting the Application’s context, despite the fact that the context is essential for the library to function. When libraries used to ask for the application’s context, we used to do something like this:

Kotlin

class GeeksforGeeksApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        SomeLibOne.doSomething(this)
        SomeLibTwo.doSomething(this)
        SomeLibThree.doSomething(this)
        SomeLibFour.doSomething(this)
        SomeLibFive.doSomething(this)
    }
}

And when the libraries ceased inquiring about our background:

Kotlin

class GeeksforGeeksApplication : Application() {
    override fun onCreate() {
        super.onCreate()
    }
}

As a result, there must be a means for libraries to obtain the context of the application without having to ask us. Actually, the ContentProvider was used by all of these libraries, including Firebase, Facebook, and others. Let’s look at how it works using the library we have created before as an example: Android-Debug-Database

Kotlin

class GfGDeubg : ContentProvider() {
    override fun onCreate(): Boolean {
        GfGDebug.initialize(context, DebugDBFactory())
        return true
    }
    // Some other code
}

First, we extend the ContentProvider: you’ll notice that we’re able to access the Application’s context and initialize the library here. Then, in the Android Manifest, we add the following:

<application>
    <provider
        android:name=".GfGDebug"
        android:authorities="${applicationId}.DebugDBInitProvider"
        android:enabled="true"
        android:exported="true" />
</application>

What is the mechanism behind it?

When the application starts, it takes all of the providers that we specified in the Android Manifest, which are effectively ContentProvider in our case, and instantiates all of them, calling their onCreate methods. All of the libraries will be initialized in this manner.

GeekTip: All of this occurs when the app first launches. As a result, it accomplishes the same goal as if we had passed the context when initializing those libraries in our Application class.

When we do it through the ContentProvider, however, the following complications arise:

1. Content providers are costly to create: if there are multiple libraries, each will have its own content provider. The app’s starting will be slowed due to the large number of content providers that will be instantiated.
2. We can make it more efficient by using a single content source for all libraries. The app’s startup time will be greatly reduced as a result of this.
3. Because the Android System has no information about the order in which libraries are initialized, it might pose an issue when one library’s initialization is dependent on another library’s initialization. It could result in unexpected behavior.

Thus, the need comes for a smart library that can cater to all these demands and is robust at the same time!

Using the App Startup Library to Get Started

The App Startup Library overcomes both of the issues we addressed earlier.

It solves the problem by obtaining the following data from us:

• Initializers for all: If necessary, initialize and retrieve the object. It uses a single content provider to call all of the initializers.
• The interdependence of the libraries is as follows:
  • It aids the library in determining the order in which the library should be initialized.
• Before we implement, we need to know who will be responsible for it, as there are two options:
  • Own Libraries/Modules: We may have developed certain modules and used the content provider strategy. In this scenario, we’ll need to follow the App Startup library’s instructions.
  • Other libraries from third parties