Allow use of Android-specific startKoin() in other Contexts (mostly ContentProvider)

[CodingDoug]

There's a lengthy discussion that can be had about the requirement to use Application in order to implement startKoin(Application, modules). I'll try to keep the rationale for my request short.

Use of Application has become somewhat of an antipattern, at least from the perspective of the Android platform team. The reasons for this are varied. For apps that don't want to subclass Application, Koin gives no support for initializing with a root Context. A more appropriate approach is to allow a Context to be given instead of an Application. Context has a method getApplicationContext() that will give you the Application object, cast as a Context. This is the norm for Android apps and libraries.

It's starting to become more popular for apps and libraries to initialize using a ContentProvider instead of Application. ContentProvider doesn't seem appropriate, at first glance, but it has properties that make it superior to Application.

Firstly, it's only initialized in the app's main process (whereas Application is actually initialized in all processes of a multiprocess app). This is critical in cases where an app or library needs to ensure that only one init has control of resources, and can ensure that there is no multiprocess contention for those resources (files, databases, etc).

Secondly, libraries can use ContentProvider to automatically initialize themselves by simply providing a ContentProvider in their manifest, to be automatically merged into the app at build time and invoked automatically at launch time, before any other app code. This is the approach that Firebase uses. I've written a blog post about that.

In order for Koin to be useful to apps that refuse to subclass application, or libraries that simply can't subclass Application and would like to use ContentProvider instead, at least one addition is required to Koin: a startKoin function that accepts a Context instead of an Application. This function should use getApplicationContext() to store the root context, for use in DI. Also, it would be great if startKoin was an extension method on Context and ContentProvider, so it can be used more comfortable way. ContentProvider implementations have a getContext() method to use during init.

[arnaudgiuliani]

Hi @CodingDoug ,

In order for Koin to be useful to apps that refuse to subclass application, or libraries that simply can't subclass Application and would like to use ContentProvider instead, at least one addition is required to Koin: a startKoin function that accepts a Context instead of an Application. This function should use getApplicationContext() to store the root context, for use in DI. Also, it would be great if startKoin was an extension method on Context and ContentProvider, so it can be used more comfortable way. ContentProvider implementations have a getContext() method to use during init.

Ok for that 👍 We will integrate that for 1.0.0

[arnaudgiuliani]

We have reworked the startKoin function as follow:

statrKoin(context,listOf(modules))

The function has been also promoted to ComponentCallbacks instead of Application class only, allowing to use it from more location.