Android: When does application’s onCreate() method get called?

3.6 Splash Image

1. Understanding the application class

The Application class in Android is the base class for maintaining global application state. You can provide your own implementation by creating a subclass and specifying the fully-qualified name of this subclass as the "android:name" attribute in your AndroidManifest.xml's <application> tag. The Application class, or your subclass of the Application class, is instantiated before any other class when the process for your application/package is created.

There is normally no need to subclass Application. In most situations, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), include Context.getApplicationContext() as a Context argument when invoking your singleton's getInstance() method.

This class is primarily used for initialization of global state before the first Activity is displayed. Note that custom Application objects should be used carefully and are often not needed at all.

2. Custom Application classes

In many apps, there’s no need to work with an application class directly. However, there are a few acceptable uses of a custom application class:

• Specialized tasks that need to run before the creation of your first activity
• Global initialization that needs to be shared across all components (crash reporting, persistence)
• Static methods for easy access to static immutable data such as a shared network client object

Note that you should never store mutable shared data inside the Application object since that data might disappear or become invalid at any time. Instead, store any mutable shared data using persistence strategies such as files, SharedPreferences or SQLite.

3. Application:

You can specify a custom application class in your Android manifest file.

The application object is already the first components started. It is also always the last component of the application, which is terminated.

This object provides the following main life-cycle methods:

• onCreate() - called before the first components of the application starts
• onLowMemory() - called when the Android system requests that the application cleans up memory
• onTrimMemory() - called when the Android system requests that the application cleans up memory. This message includes an indicator in which position the application is. For example the constant TRIM_MEMORY_MODERATE indicates that the process is around the middle of the background LRU list; freeing memory can help the system keep other processes running later in the list for better overall performance.
• onTerminate() - only for testing, not called in production
• onConfigurationChanged() - called whenever the configuration changes

Implementations should be as quick as possible (for example using lazy initialization of state) since the time spent in this function directly impacts the performance of starting the first activity, service, or receiver in a process.

If you override this method, be sure to call super.onCreate().

Be aware that direct boot may also affect callback order on Android Build.VERSION_CODES.N and later devices. Until the user unlocks the device, only direct boot aware components are allowed to run. You should consider that all direct boot unaware components, including such ContentProvider, are disabled until user unlock happens, especially when component callback order matters.

If you override this method you must call through to the superclass implementation.

4. Question

How many times onCreate call?

5. Answer

Only the first time.

Called when the application is starting, before any activity, service, or receiver objects (excluding content providers) have been created. Implementations should be as quick as possible (for example using lazy initialization of state) since the time spent in this function directly impacts the performance of starting the first activity, service, or receiver in a process. If you override this method, be sure to call super.onCreate()

6. Limitations and Warnings

There is always data and information that is needed in many places within your app. This might be a session token, the result of an expensive computation, etc. It might be tempting to use the application instance in order to avoid the overhead of passing objects between activities or keeping those in persistent storage.

However, you should never store mutable instance data inside the Application object because if you assume that your data will stay there, your application will inevitably crash at some point with a NullPointerException. The application object is not guaranteed to stay in memory forever, it will get killed. Contrary to popular belief, the app won’t be restarted from scratch. Android will create a new Application object and start the activity where the user was before to give the illusion that the application was never killed in the first place.

So how should we store shared application data? We should store shared data in one of the following ways:

• Explicitly pass the data to the Activity through the intent.
• Use one of the many ways to persist the data to disk.

Bottom Line: Storing data in the Application object is error-prone and can crash your app. Prefer storing your global data on disk if it is really needed later or explicitly pass to your activity in the intent’s extras.

Thanks for

• https://guides.codepath.com/android/Understanding-the-Android-Application-Class
• https://developer.android.com/reference/android/app/Application.html