IssueTracker

Component used: Startup Version used: 1.0.0

This is a feature request.

Initializer.create() currently passes in a Context instance which is already the Application instance. My request is to facilitate usage of app startup by making that type explicit:

public interface NicerInitializer<T> {

    @NonNull
    T create(@NonNull Application application);

    @NonNull
    List<Class<? extends Initializer<?>>> dependencies();
}

Many libraries that currently use a ContentProvider for init already call Context.getApplicationContext() and then cast it to Application to be able to call Application.registerActivityLifecycleCallbacks(). Including Jetpack lifecycle-process: https://github.com/androidx/androidx/blob/androidx-master-dev/lifecycle/lifecycle-process/src/main/java/androidx/lifecycle/LifecycleDispatcher.java#L43-L44

The Startup library itself relies on a ContentProvider and already calls Context.getApplicationContext() on the context provided by that ContentProvider.

While the Android APIs make no guarantee that Context.getApplicationContext() will return the Application context here, it's 100% the case today and unlikely to ever change as it would break many libraries. So I think it'd be worth exposing the Application instance directly, i.e. take ownership of the hack as is done in other Jetpack libraries.