Need for the App Startup Library

In this blog, we are going to discuss why there is a need for the App Startup Library. Most importantly, we will learn what are the problems it solves and how it helps us in improving the App Startup time.

The App Startup time plays an important role in how your app is perceived by the users.

Lesser the App Startup Time, Better the App Experience

Aim of this blog

The main aim of this blog is to understand why there is a need for the App Startup library, not how to use it. If we understand the need, what problems it solves, then everything becomes very simple.

First I would like to thank Google for releasing the App Startup library which is going to help us in improving the App Startup time for sure. This App Startup Library is a part of Android Jetpack.

We must understand the problems with the current approach followed by the app developer or the library developer so that we can actually understand what are the problems solved by the App Startup library and get the most of it. Also knowing these things will help us in using the App Startup library effectively.

Problem with the Current Approach

You must have noticed that many libraries have stopped asking us for the context of the Application, even though the context is required by the library to work.

Earlier when the libraries used to ask us for the context of the Application, we had to do like below:

class MyApplication : Application() {

    override fun onCreate() {
        super.onCreate()
        LibraryOne.initialize(this)
        LibraryTwo.initialize(this)
        LibraryThree.initialize(this)
        LibraryFour.initialize(this)
        LibraryFive.initialize(this)
    }

}

And when the libraries stopped asking us the context:

class MyApplication : Application() {

    override fun onCreate() {
        super.onCreate()
    }

}

So, there must be a way through which the libraries started getting the context of the Application without even asking us.

Actually, all these libraries like Firebase, Facebook, and etc started doing it through the ContentProvider.

Let's see how it works by taking the example of the library which I had created earlier: Android-Debug-Database

First, we extend the ContentProvider:

class DebugDBInitProvider : ContentProvider() {

    override fun onCreate(): Boolean {
        DebugDB.initialize(context, DebugDBFactory())
        return true
    }

    // code removed for brevity
}

Here, if you notice, we are able to access the context of the Application and initialize the library.

Then, we add the following in the Android Manifest:

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

How does it work?

Whenever the Application starts, it takes all the providers that we have provided in the Android Manifest which are essentially ContentProvider in our case, all those content providers get instantiated, and the onCreate of those providers get called. In this way, all the libraries will get initialized.

Note: All these things happen when the app starts. So, it serves the same purpose as if we would have initialized those libraries in our Application class by passing the context.

But the following issues arise when we do it through the ContentProvider:

  • Instantiation of Content Providers are expensive: If there are many libraries, all will have their own content providers. So many content providers will be instantiated, it will slow down the app startup. We can optimize it by having a single content provider for all the libraries. This will significantly improve the app startup time.
  • Order of library initialization: It can create a problem when one library's initialization is dependent on another library's initialization because the Android System does not have any information about the order of library initialization. It may lead to unexpected behavior.

So, here comes the App Startup library to the rescue, all these problems are solved by this library.

Getting Started with App Startup Library

App Startup Library solves both the problems which we discussed above.

It solves by taking the following information from us:

  • All the Initializers: To initialize and get the object if required. It calls all the initializers from the single content provider.
  • How the libraries are dependent on each other: It helps the library in deciding the order of library initialization.

Before we implement, we should know who has to implement it, as there are two possibilities here as follows:

  • Own Libraries/Modules: We might have created some modules and we have implemented the content provider approach. In this case, we will have to do the steps required for the App Startup library.
  • 3rd party other libraries: We might be using some 3rd party libraries that have implemented the content provider approach. In this case, the library creator will have to do the steps required for the App Startup library.

Now, we know why we need this library and what problems it solves, who has to use this library.

For the implementation part, I will highly recommend going through the Official Android Developer Website Documentation. In fact, they have made it very easy for all of us to implement.

Link to App Startup Documentation.

That's it for now.

Show your love by sharing this blog with your fellow developers.

Also, Let’s become friends on Twitter, Linkedin, Github, Quora, and Facebook.