Blog Infos
Author
Published
Topics
,
Published

Kotlin Multiplatform Mobile (or simply Multiplatform Mobile) is a new SDK from JetBrains that allows iOS and Android developers to share code between the two platforms. The shared code is written in Kotlin. Typical use cases include: sharing networking, data storage, internal libraries, and algorithms, but the choice is yours!

As your Multiplatform Mobile application starts growing, it becomes necessary to refactor your code to improve its scalability. One possible such refactoring is to separate application components’ configuration from their use, and in so doing, make application components more maintainable, reusable, and testable. This is typically enabled using libraries following either the dependency injection or service locator patterns.

Our running example will be that of a search box on a company intranet page where a particular staff member can be located based on a search criteria. Figure 1 illustrates a naive way this could be implemented. The SearchBox class could use the StaffLister interface to get all the staff members of the company, and then try to locate all the staff members matching certain criteria. However, SearchBox is also configuring itself with the StaffListerImpl implementation of StaffLister. Perhaps the current StaffListerImpl looks up all staff members in a spreadsheet, but one day this could be replaced by StaffListerImpl2 where all staff members are listed by a web service connected to a database. Therefore, we will have to refactor the codebase to separate the configuration of the SearchBox class with StaffListerImpl from its use of the StaffLister interface to do its work.

Figure 1

This article series will discuss the dependency injection and service locator patterns, explain how they differ, and detail the most prominent Multiplatform Mobile libraries and approaches implementing these patterns. This article introduces these important dependency management patterns.

The Dependency Injection Pattern

The Dependency Injection (or DI) pattern is where an object (called the assembler) populates a field in a client class with an implementation of a specific interface. Figure 2 illustrates how this will look for our search box example.

Figure 2

A term that is often closely associated with DI is that of Inversion of Control. Here, SearchBox is no longer in control of the configuration and creation of the StaffListerImpl, it only needs to know that it will be provided with the correct instance as a field.

The Service Locator Pattern

The Service Locator (or SL) pattern is an alternative to the DI pattern. In this pattern, an object (called the service locator) knows how to get the implementations of dependencies, and a client class knows about the service locator and gets the appropriate dependency instances from it. Figure 3 illustrates how this will look for our search box example.

Figure 3

Job Offers

Job Offers


    Kotlin Multiplatform Mobile Developer

    Touchlab
    Remote
    • Full Time
    apply now

    Sr. Software Development Engineer, Last Mile Driver Assistance Technology

    Amazon
    Berlin
    • Full Time
    apply now

OUR VIDEO RECOMMENDATION

,

Sharing code among multiple projects: the case of internal libraries

As tech companies grow, they often find the need to develop multiple projects or applications in order to better address their challenges. Along with its main app, Deezer has also released Deezer for Creators, Audiobooks…
Watch Video

Sharing code among multiple projects: the case of internal libraries

Jean-Baptiste Vincey
Android developer & tech expert
Deezer

Sharing code among multiple projects: the case of internal libraries

Jean-Baptiste Vinc ...
Android developer & ...
Deezer

Sharing code among multiple projects: the case of internal libraries

Jean-Baptiste Vi ...
Android developer & tech ...
Deezer

Jobs

A note on service locator implementation: the service locator object can be implemented using the Singleton pattern for easy lookup, but this is not mandatory.

Comparing the Patterns

While these two patterns have the same purpose- to separate configuration from use- it’s important to understand the difference between them as there are certain pros and cons that need to be considered when choosing a DI/SL library. The SL pattern requires that the client knows about the locator object for it to make a request for the dependency to the locator. The DI pattern requires no such request, as the dependency is injected via an assembler object into the client.

The nature of the DI pattern makes it inherently difficult to understand and debug, as the injector might be difficult to trace via conventional methods. However, the SL pattern requires an explicit dependency on the service locator object. This complicates testing as the service locator object will need to be somehow mocked to provide testing dependencies. However, the primary concern has to do with creating code where the use is outside the control of the writer, where even the minimal assumption of knowledge of a service locator object is problematic.

The remainder of this series will focus on the actual libraries and approaches for dependency management in Multiplatform Mobile, and will feature articles on:

  • Koin
  • Kodein
  • Kotlin-Inject
  • Manual injection

Stay tuned!

Photo by Fahim mohammed on Unsplash

This article was originally published on proandroiddev.com on August 30, 2022

YOU MAY BE INTERESTED IN

YOU MAY BE INTERESTED IN

blog
Modern mobile applications are already quite serious enterprise projects that are developed by hundreds…
READ MORE
blog
Ask yourself a fairly standard question for any interview to fill an Android position:…
READ MORE
blog
Kotlin Multiplatform despite all of its benefits sometimes has its own challenges. One of…
READ MORE
blog
I develop a small multi-platform(android, desktop) project for finding cars at an auction using…
READ MORE

Leave a Reply

Your email address will not be published.

Fill out this field
Fill out this field
Please enter a valid email address.

Menu