Author at Infinum

Koin vs. Kotlin-inject – Which to Choose and Why?

Marin Šimić — Thu, 14 Sep 2023 10:47:00 +0000

In the fast-evolving world of cross-platform development with Kotlin Multiplatform, choosing the right dependency-injection library can have a great impact on your project. We reveal the strengths and weaknesses of Koin and Kotlin-inject, so you can find the best match for your KMP needs.

As Kotlin Multiplatform is becoming an increasingly popular choice for cross-platform development, developers face the task of selecting a suitable dependency-injection library for their KMP projects. We’re here to introduce Koin and Kotlin-inject, two libraries that take different approaches to solving this problem.

In this article we will present both libraries, exploring their features and implementation. We’ll do a head-to-head comparison, shedding light on their strengths and weaknesses. So let’s dive in and help you find the best fit for your KMP needs.

If you want to explore more Kotlin-based libraries, you can also check our blog post on JsonApiX.

Our example project

In order to better compare Koin and Kotlin-inject, we’ve come up with a simple example project. It includes a WeatherApiService responsible for providing WeatherData, along with domain components like Interactor, Repository, and UseCase, used for propagating and mapping data:

// WeatherApiService.kt
interface WeatherApiService {
  @GET("weather")
  suspend fun getWeatherData(@Query("city") city: String): WeatherData
}

// GetWeatherDataInteractor.kt
class GetWeatherDataInteractor(private val weatherApiService: WeatherApiService) : Interactors.GetWeatherData {
  override suspend operator fun invoke(city: String): WeatherData {
    return weatherApiService.getWeatherData(city)
  }
}

// WeatherRepository.kt
class WeatherRepository(private val getWeatherInteractor: Interactors.GetWeatherData) : Repositories.Weather {
  override suspend fun fetch(city: String): Weather {
    return getWeatherInteractor(city).mapToLocal()
  }
}

// GetWeatherUseCase.kt
class GetWeatherUseCase(private val weatherRepository: Repositories.Weather) : UseCases.GetWeather {
  override suspend operator fun invoke(city: String): Weather {
    return weatherRepository.fetch(city)
  }
}

We want our example to cover the differences in implementation, so let’s say WeatherApiService and WeatherRepository are intended to be singletons. This is what our final dependency structure looks like:

Koin

Let’s start by diving into the Koin library. Here are some of its key features:

Kotlin-based dependency injection library that offers a user-friendly experience through its easy-to-read Kotlin DSL
Suitable for any Kotlin application, including Android, Multiplatform, or Backend development
Easily integrates with the ViewModel, Ktor, and Compose, which adds to Koin’s appeal across diverse developer domains

But let’s shift from theory to practice and test this library in action on our example project:

// ServicesModule.kt
val servicesModule = module {
  single { 
     WeatherServiceProvider.provide()
  }
}

// InteractorsModule.kt
val interactorsModule = module {
  includes(servicesModule)
  factory<Interactors.GetWeatherData> { 
     GetWeatherDataInteractor(get()) 
  }
}

// RepositoriesModule.kt
val repositoriesModule = module {
  includes(interactorsModule)
  single<Repositories.Weather> { 
     WeatherRepository(get()) 
  }
}

// UseCasesModule.kt
val useCasesModule = module {
  includes(repositoriesModule)
  factory<UseCases.GetWeather> { 
     GetWeatherUseCase(get()) 
  }
}

Koin’s DSL, while remarkably straightforward, presents significant distinctions from Dagger or Hilt API. It primarily consists of module functions, which can be linked together using includes function:

val repositoriesModule = module {
  includes(interactorsModule)
  ...
}

val useCasesModule = module {
  includes(repositoriesModule)
  ...
}

This way, useCasesModule includes all of the dependencies provided inside the repositoriesModule, which includes all of the dependencies provided by interactorsModule and so on.

The factory function binds implementations to interfaces and the function get() helps Koin retrieve injected dependencies during runtime. In the code snippet below, we’re instructing Koin on how to build a UseCases.GetWeather instance. It uses the get() function to obtain the necessary Repositories.Weather dependency that GetWeatherUseCase requires:

factory<UseCases.GetWeather> { 
  GetWeatherUseCase(get()) 
}

For WeatherApiService and WeatherRepository instances intended to be singletons, the single function is used:

single<Repositories.Weather> { 
  WeatherRepository(get()) 
}

To use Koin, we first need to initialize it by calling the startKoin function and providing a parent module, in this case, the useCasesModule:

val exampleKoin = startKoin { modules(useCasesModule) }.koin
val weather = exampleKoin.get<UseCases.GetWeather>().invoke(cityName)

That’s it; Koin is initialized and ready for use.

Kotlin-inject

Now that we have a clearer understanding of how Koin works, let’s see how Kotlin-inject compares. Some of its key features are:

Relatively new and simple Kotlin-based dependency-injection library
Powered by Kotlin’s robust features like KSP and lazy initialization, which simplify the process of providing dependencies
With the use of Kotlin typealias, it allows injecting multiple instances of the same type and even supports lambda injection

Let’s roll up our sleeves again and put this library to work on our example project:

// ServicesComponent.kt
interface ServicesComponent {
  @ExampleScope
  @Provides
  protected fun provideWeatherApiService(): WeatherApiService = 
    WeatherServiceProvider.provide()
}

// InteractorsComponent.kt
interface InteractorsComponent : ServicesComponent {
  @Provides
  protected fun GetWeatherDataInteractor.bind(): Interactors.GetWeatherData = this
}

// RepositoriesComponent.kt
interface RepositoriesComponent : InteractorsComponent {
  @ExampleScope
  @Provides
  protected fun WeatherRepository.bind(): Repositories.Weather = this
}

// UseCasesComponent.kt
interface UseCasesComponent : RepositoriesComponent {
  @Provides
  protected fun GetWeatherUseCase.bind(): UseCases.GetWeather = this
}

// ExampleComponent.kt
@ExampleScope
@Component
abstract class ExampleComponent : UseCasesComponent {

  abstract val getWeatherUseCase: UseCases.GetWeather

}

Kotlin-inject relies on annotations to define scopes and functions that contribute to the dependency graph. In the example above, we can notice a more Dagger-like API, unlike Koin DSL, which bears less resemblance.

Additionally, we can notice one major difference – there are no modules. Kotlin-inject operates using components, with the parent component ExampleComponent being an abstract class with @Component annotation and its own @ExampleScope:

@Scope
@Target(CLASS, FUNCTION, PROPERTY_GETTER)
annotation class ExampleScope

The components rely on the interfaces they inherit to provide the necessary dependencies, which is called component inheritance:

interface RepositoriesComponent : InteractorsComponent {
  // provide repository dependencies
}

interface UseCasesComponent : RepositoriesComponent {
  // provide usecase dependencies
}

@ExampleScope
@Component
abstract class ExampleComponent : UseCasesComponent {
  ...
}

ExampleComponent implements UseCasesComponent, which provides the necessary dependencies while also relying on RepositoriesComponent for its dependencies and so on.

To bind implementations, a familiar @Provides annotation is used combined with the extension function bind:

@ExampleScope
@Provides
fun WeatherRepository.bind(): Repositories.Weather = this

WeatherRepository and WeatherApiService are scoped as singletons using the already mentioned @ExampleScope annotation. The instance of these components will live as long as the ExampleComponent does.

Finally, ExampleComponent is crafted using the create extension function and is ready for use:

val exampleComponent = ExampleComponent::class.create()
val weather = exampleComponent.getWeatherUseCase(cityName)

With the differences in implementation covered, we can now compare the two libraries based on some common criteria.

Koin vs. Kotlin-inject – a head-to-head comparison

Let’s size up these two libraries in some key categories that affect your development as well as the user experience. This will allow you to get a clearer picture of where each library shines and where its weaker points are.

Build time

First, we’re going to take a look at how these two libraries stack up against each other when it comes to build time. A key difference between Koin and Kotlin-inject lies in their mechanics:

The Koin approach:

Koin functions similarly to a service locator pattern, creating and providing the dependencies we want in runtime when they are needed. This translates to less boilerplate code generated during compile-time.

The Kotlin-inject approach:

Kotlin-inject acts as a code generator, creating the necessary boilerplate for effective dependency injection based on the setup and annotations you provide. Similarly to Dagger and Hilt, this results in a significant amount of code generated during compile-time.

Due to reduced compile-time code generation, using Koin typically leads to quicker builds. Notably, the difference in build time becomes more significant on larger projects, amplifying Koin’s advantage.

Runtime performance

Moving on with our agenda, we’ll compare the startup and injection performance of the two libraries. The results presented are based on the median of 100 iterations in our example project setup:

// Koin
// Startup time: 0.2475 ms
val exampleKoin = startKoin { modules(useCasesModule) }.koin
// Injection time: 0.0137 ms
val weatherUseCase = exampleKoin.get<UseCases.GetWeather>()

// Kotlin-inject
// Startup time: 0.0005 ms
val exampleComponent = ExampleComponent::class.create()
// Injection time: 0.0043 ms
val weatherUseCase = exampleComponent.getWeatherUseCase

In summary, while Koin offers quicker build times, it does come with a trade-off. The runtime dependency resolution impacts the overall performance, causing Koin to lag significantly behind Kotlin-inject in this regard. The difference is most noticeable during startup. Resolving the Koin dependency graph requires significantly more time compared to creating a Kotlin-inject component, which benefits from pre-generated boilerplate code.

Debugging

Now, let’s delve into the libraries’ debugging capabilities. Both libraries excel in providing clear and informative error descriptions. However, Kotlin-inject has the advantage of showing them at compile-time, which allows you to correct your mistakes without ever running the application. This is not only a more convenient but also a much safer approach. On the other hand, Koin addresses this with somewhat of a workaround – writing tests to validate your Koin setup:

class CheckKoinModulesTest {

    @Test
    fun checkUseCasesModule() {
        checkKoinModules(listOf(useCasesModule))
    }
}

Writing these tests does provide you with the verification of DI structure, but still requires you to run them quite often, which is less practical compared to Kotlin-inject compile-time error detection.

Community

To wrap things up, we should mention the communities behind these two libraries, since they are the ones responsible for their respective future development.

Koin has an active community of contributors ensuring regular updates and enhancements. After all, they’ve paved the way for smooth integrations with Ktor, Compose, ViewModel, and KMP and will continue to provide support for future technologies. Alongside regular updates and initiatives, Koin’s engaged user community helps spot and resolve issues quickly.
On the other hand, Kotlin-inject is still establishing its presence with a smaller contributor base. However, it’s gaining traction within the Kotlin development scene, hinting at a bright future for the community.

Koin or Kotlin-inject? You choose.

As would be expected, both Koin and Kotlin-inject come with their own set of strengths and weaknesses.

If you prefer a simpler DSL, want to benefit from faster build times, seek integration with various technologies like Ktor, Compose, Android, KMP, and value a strong community support, Koin is a solid choice.

On the other hand, if you prefer a Dagger-like API, prioritize compile-time safety and runtime performance, want to use Kotlin’s powerful features, and are comfortable with fewer integrations by a smaller, but growing community, Kotlin-inject is the library for you.

Clearly, there’s no universal answer when it comes to choosing between these two libraries. However, if you take a close look at the needs of your project and take into consideration your own skills and preferences, you’ll be able to decide which of the two is the best fit.

The post Koin vs. Kotlin-inject – Which to Choose and Why? appeared first on Infinum.

Enabling Philips Coffee+ Users to Brew Drinks Remotely

Marin Šimić — Mon, 07 Nov 2022 13:23:39 +0000

Coffee+ is the accompanying application for Philips coffee machines that allows users to control certain functions of their machines remotely. The app provides a seamless user experience and offers various ways of interacting with the machine over WiFi. Users can turn their machine on and off, set a timer to turn it on at a specific time, adjust water hardness and standby time.

As part of the 2.0.0 release, we finally launched the most requested and most challenging feature so far – remote brewing.

This feature allows coffee machine users to choose a specific drink, customize it to their liking, start and track the brewing process without having to physically interact with the machine.

However, implementing the feature was no simple task. This blog post will discuss a problem we encountered on the way and how we solved it.

From strategy to deployment, we cover all aspects of IoT development lifecycle. Download our Guide to Successful IoT Implementation.

The elusive brewing status

The remote brewing flow is far from simple. It required adding new activities as well as updating some old ones. Apart from the standard happy flow, we had to implement an error-handling flow as well as various checks and handles throughout the brewing process.

The biggest challenge we encountered during implementation was keeping track of the brewing status in different activities and navigation graphs. Also, during the brewing process the machine couldn’t be a single source of truth for the current state of brewing due to the lack of emitted properties. This means that simply renewing the subscription and reading the properties wouldn’t suffice if we wanted to determine the latest state. If we wanted to show a snackbar at the bottom of DashboardActivity immediately after remote brewing is canceled, reading machine properties wouldn’t provide enough information for us to do it.

As you can see in the example above, once brewing is canceled by calling CancelBrewingUseCase and we close BrewingActivity, the machine state remains at BREWING for some time until the whole process is completed. So there is no real way of determining if the brewing process was canceled just by observing machine properties.

On top of that, we wanted our logic to be handled in one component for easier logging and testing, as well as reducing the amount of repetitive code. Since there is always a chance we will expand upon this feature sometime in the future, we also wanted our code to be clean and scalable.

Envisioning a solution

We’ve defined the problem, and now we can start looking into potential solutions. There are several aspects we’ll need to consider.

Scope

Because the brewing process spans multiple activities, we cannot use a shared ViewModel, meaning we need a separate component independent of any activity lifecycle. We can conclude that we need a component with a scope that lasts throughout the entire remote brewing flow.

States

How do we present the state of the brewing process? The machine can go through various states during the process. For example, before brewing is started, the machine is considered to be in an IdleState. When it starts brewing, the machine switches to ProgressState and the updated progress value should be shown in the app UI.

If an error occurs during brewing, for example, someone pulls the drip tray out, the machine switches to ErrorHandlingState, and user action is expected. Some of the states can be observed directly from the values emitted by the machine, but some are more dependent on the user’s interaction with the app.

As mentioned, when a user decides to cancel brewing, we should switch to CancelledState, which cannot be determined from the machine properties. We can conclude that brewing should be reflected in various states. These states can change depending on the properties observed from the machine or from the user’s interaction with the application.

State machine

All of these requirements point towards the finite-state machine or FSM. FSM is a mathematical model of computation, an abstract machine that can be in exactly one of a finite number of states at once. FSM can then change states depending on the current state and input. These are called transitions and in our case, inputs that will trigger transitions can either come from the machine side (a change of value observed) or from a user’s interaction with the application.

Therefore, to determine where the input came from, we want to make a lifecycle-independent state machine component with a single current state that will always reflect the state of remote brewing.

Implementation

Now that we’ve defined what our solution requires, we can dive into the implementation in more detail.

State

First let’s see how a state is defined through the BaseState interface:

interface BaseState, Output, Action> {

    suspend fun onAction(action: Action): State

    fun toOutput(): Output
}

If we look at the definition of BaseState, we can notice two generic types, Output and Action.

Output is a model that holds state properties. By emitting an Output rather than the whole State we protect state values and functions from other components.
Action represents inputs that lead to transitions. Each state can handle a certain Action through the call of onAction function and return a new State (or itself). That way states perform transitions by handling actions.

Now let’s take a look at a simplified example of ProgressState:

class ProgressState(
    private val progress: Int = 0
) : BaseBrewingState {

    override fun toOutput(): BrewingOutput =
        BrewingOutput.ProgressState(
            progress = progress
        )

    override suspend fun onAction(action: BrewingAction): BaseBrewingState =
        when (action) {
            is BrewingAction.UpdateProgress -> action.handle()
            is BrewingAction.StartErrorHandling -> action.handle()
            is BrewingAction.CancelBrewing -> action.handle()
            else -> this
        }

    private fun BrewingAction.UpdateProgress.handle(): BaseBrewingState = ProgressState(updatedProgress)
    
    private fun BrewingAction.StartErrorHandling.handle(): BaseBrewingState = ErrorState()

    private fun BrewingAction.CancelBrewing.handle(): BaseBrewingState = CancelledState()
}

Function toOutput is implemented and returns BrewingOutput.ProgressState which holds the latest progress value. The other function onAction handles three types of BrewingAction, otherwise the same state is returned and no transitions are made. In case the UpdateProgress action is received, a new ProgressState is returned with updated progress value. Action StartErrorHandling will return ErrorState and the last handled action CancelBrewing will return CancelledState.

If we wanted to visualize these state transitions with a diagram, they would look something like this:

If our ProgressState receives the CancelBrewing action from a user’s interaction with the UI it will immediately transition to CancelledState. Otherwise, if the brewing progress property changes from the machine side, ProgressState will receive the UpdateProgress action and transition to a new ProgressState with updated progress value. Finally, if any errors are observed from the machine side, the StartErrorHandling action is received and ProgressState transitions to ErrorState where it will wait for the user to resolve the machine error.

State machine

Now that we have a good understanding of how states and transitions work, the only thing left is to implement a state machine. Following is an example of BaseStateMachine:

abstract class BaseStateMachine, Output, Action> {

    protected abstract val scope: CoroutineScope
    
    abstract val stateFlow: StateFlow<Output>

    protected abstract val currentState: State

    abstract suspend fun update(action: Action)
}

The first value to implement is the scope. As mentioned earlier, we want our state machine to have its own independent scope. In this example we are using CoroutineScope:

override val scope = CoroutineScope(dispatcher + SupervisorJob())

When initializing CoroutineScope, we are using an injected dispatcher combined with SupervisorJob. That way we can be sure that failing jobs will not cancel the whole state machine process. Inside the scope the state machine can observe machine properties, perform actions, and make state changes. If we wanted to observe the brewing progress flow and perform actions on each updated value, we would do it inside the mentioned scope:

 private fun observeProgress() =
    observeBrewingProgress().onEach {
        // update state
        // log tracked progress
    }.launchIn(scope)

The second value implemented is the stateFlow, which is the output of the state machine. Other components can subscribe to stateFlow changes and observe the state of brewing. Here is an example of stateFlow used in the implementation with its initial value set to BrewingOutput.IdleState:

 private val mutableStateFlow =
     MutableStateFlow<BrewingOutput>(BrewingOutput.IdleState)

 override val stateFlow: StateFlow<BrewingOutput> = mutableStateFlow

The next value implemented is currentState, which holds the reference to the latest state the state machine was in:

override var currentState: BaseBrewingState = IdleState()
     private set(value) {`
         field = value
         mutableStateFlow.tryEmit(value.toOutput())
         log("New state set: ${value.toOutput()}")
     }

Initially, the currentState is set to IdleState. The value setter is marked as private to ensure encapsulation and prevent other components from altering the state. Once a new state is set, the state output value is emitted to the mutableStateFlow to notify all of the observing components about the latest state change. This state change is also logged.

The last to implement was the update function, which acts as the only input to the state machine:

 override suspend fun update(action: BrewingAction) {
     currentState = currentState.onAction(action)
 }

Certain app components can use this function to interact with the brewing process. Once this function is invoked with a specific action, the result of currentState.onAction(action) is going to be the next currentState. For example, if our currentState is ProgressState from the previous chapter, once update(BrewingAction.CancelBrewing) is called, the resulting CancelledState will be the new currentState and all of the observing components will be notified of the change through stateFlow.

Architecture

By now we should have a deeper understanding of the state machine. Now let’s see how it blends into our app’s architecture. As mentioned before, the state machine has its own scope, meaning it differs from any other domain component (UseCase, Repository, Interactor). On top of that, we would also like to use these components for performing actions inside the StateMachine. For that reason, StateMachine is like a bridge layer between the UI and the domain layers.

Here’s an example of the way state machine interacts with the components from both UI and domain layers:

The example above shows a standard brewing navigation flow. First, when the drink parameters are defined, brewing is started inside AdjustDrinkViewModel by sending BrewingAction.StartBrewing(drink). BrewingStateMachine handles this action by calling StartBrewingUseCase and performs state transition to ProgressState. This state is updated by observing ObserveBrewingProgressUseCase, with each progress change from the machine being emitted as BrewingOutput.ProgressState(progress). The output is observed inside the BrewingProgressViewModel and the UI is updated accordingly. If the user decides to cancel brewing, BrewingAction.CancelBrewing is sent inside CancelBrewingViewModel and BrewingActivity is finished. Upon receiving this action, BrewingStateMachine cancels the brewing process by calling CancelBrewingUseCase and transitions to CancelledState. This new BrewingOutput.CancelledState is observed inside the DashboardViewModel and a snackbar is shown notifying the user that brewing was canceled.

State machine and onwards

We successfully added a much-anticipated feature for Coffee+ users. Enabling remote brewing was not a simple implementation, but we managed to tackle the challenges involved.

Working our way through the implementation, we got a very close look at the state machine. Let’s summarize some of its benefits:

State machine acts as a single point of reference for controlling and observing the brewing process and can be used as such from any ViewModel inside the application.
State machine is a lifecycle-independent component that has its own scope, meaning it will persist regardless of activity changes like in the example above.
State machines are easily scalable by simply adding new states and actions, with states handling transitions without accumulating code inside the state machine.
Most of the logic is stored inside the state machine component, preventing us from writing repetitive code elsewhere and having to test it individually.

The remote brewing feature is now fully functional, and our clean and scalable code will allow us to build upon it even further in the future.

To find out what else we can do in the Internet of Things realm, check out our IoT solutions page.

The post Enabling Philips Coffee+ Users to Brew Drinks Remotely appeared first on Infinum.