Ready with Koin 2.0 ?

It is time! The stable version of Koin 2.0 has officially been released. 6 months of development, rewriting, API analysis and user feedback. And all this with a real challenge: keep the simplicity of Koin!

1.Startup DSL

The old startKoin() function was replaced by a DSL startup . Providing initialization for each platform and hiding all options with default parameters is a good quickstart option, but it will lock a lot of development possibilities. Now we need to expand and add new concepts easily, and also make load definitions more efficient.

How do we start Koin 2.0? Still with func startKoin , but now you need to declare what you will use:

For Android, don’t forget to declare your AndroidContext with the androidContext function:

2.Better Performances ?

One of the main arguments for upgrading to Koin 2.0, is the new engine performance.

Last year, Rafa Vázquez wrote a benchmarking project to help measure some performances for the DI framework. This helps me very clearly internal review. This benchmark runs a project of 400 definitions.

Here are the benchmarks for Koin 1.0:

Now with Koin 2.0:

Koin has achieved great performance improvements. You should not worry about performance right now ? Contrary to code generate, we need to analyze the components at the start. But this is very fast to proceed right now.

3.Definitions & Modules ?

Koin DSL remains the same! It has been simplified by removing unused features and implying useless complexity. After that, there were no more internal module declarations, weird display rules, and scope API declarations that were completely revised.

The first major change you’ll notice is that we no longer use direct strings to name our components. We use qualifiers instead of named() functions. This function can take a string or a type to help qualify the definition or scope. This gives us a logical name for a component.

It should be simpler to understand now about the DSL (bind) binding operator. Consider that this operator adds a type of secondary constraint to your definition. To make it clearer, let another view it as an additional aspect of your definition. The Koin API has a new bind () function to help you retrieve components declared with the bind operator in your module.

A good example can help understand:

4.Loading & unloading modules ♻️

Because it easily loads modules in Koin (via startKoinor loadKoinModules), it is also easy to unload a module. The unloadKoinModules () function eliminates definitions and expressions:

With that, we can handle Koin modules flexibly: load and unload as you like, based on the context of your application. The case of lagging behind works like that, involving single & scrope definitions.

5.Some other new incomings in the Koin APIs ✨

A few small things can help you in special situations, requested by the community. You could try asking for an undefined component or the case might solve the case:

Another interesting feature, is the ability to add a quick instance. Use the declaration function () to provide an object for Koin. It will declare it as a new single definition for you:

6.Koin Isolation ⚙️

The Koin API has been redesigned to allow you to create a local version of Koin. Instead of using the startKoin declaration function to declare your Koin instance into GlobalContext , use the koinApplication function to declare a local Koin instance.

A local / isolated Koin instance is not registered in the Global Context. Obviously, you can directly use the standard KoinComponents extensions. Instead, you must specify the use of your local instance (overriding the getKoin () function from the KoinComponent interface).

7.New Scope API ⚠️

Scope is a context with a fixed period in which an object exists. At the end of the scope, all objects bound within that scope cannot be re-injected. To get a better picture of that, think of a range like a box: a space where you put furniture and throw it when you don iron need it. How do I use the new scoping API? We now declare and use the scope like:

Finally, in any scope case, you can declare an active component:

8. Load / Unload modules vs Scope API?

With these new features, we have some ability to handle components for a limited time. So, is it using scope API or not? It is more dependent on your use case and how you must manage the creation of those instances. If you need better granularity (timing or definition), the Range API is specific to that

9.Stronger Android support ✅

With such a new Scope API, we can provide you with interesting tools for your Android Activity & Debris. You can easily declare a scope attached to your view and easily retrieve everything from it using the currentScope property (the Koin Times extension for LifecyclOwner components):

The currentScope property is created when you access and follow the lifecycle of the Android component. It was canceled when receiving the signal ON_DESTROY.

This Android scope API is included in koin-android-scope and koin-android-viewmodel packages (also for AndroidX).

A lot of fixes have been made to the ViewModel section. The global API remains the same, but has been simplified:

• The name attribute of the definition is used as the ViewModel id
• Getting a ViewModel instance for a given class can be done directly with getViewModel and by viewModel.
• ViewModels can be declared within a scope, to help resolve dependencies from this scope

Working with ViewModel and scope is now easier:

10.Android Experimental Features ✨

Experimental features for Android have been extracted to external packages. You must set it up with the following packages:

These experimental features suggest a DSL version that doesn’t require you to write your constructor function injection: