Kotlin Multiplatform Mobile: Store Key-Value Approach

Photo of Krzysztof Kansy

Krzysztof Kansy

Updated Mar 14, 2024 • 3 min read
Programmers_kotlin_multiplatform

SharedPreferences and UserDefaults are mechanisms for persistently storing small amounts of data in key-value pairs. They frequently serve as storage for user preferences, settings, and other minuscule quantities of information particular to a program.

SharedPreferences, which is a component of the Android SDK, offers a straightforward interface for saving and retrieving data on Android. It can be shared across components and is accessible from anywhere within the application in question.

Similar interfaces for storing and retrieving data are provided by UserDefaults, which is a component of Apple’s iOS SDK. It can be used throughout an entire application and is typically accessed through a singleton instance.

Basic data types including Int, Float, String, Boolean, and Date are supported by both mechanisms. Even though these mechanisms are efficient for storing small amounts of data, it's important to keep in mind that they are not designed to handle complex data structures or large quantities thereof. Other storage solutions, like databases or file systems, may be more effective in those circumstances.

Assumptions

The main goal is to compare using a third-party library that provides a ready-made solution and uses the expected-actual mechanism with relying on our own solution, as well as to consider the advantages and disadvantages of each.

multiplatform-settings

platform-specific

Description

Allows storage of key-value data in common code modules without any additional boilerplate code.

The shared part delivers only interfaces for common actions (set, get, clear, etc.), with everything else done in the platform-specific part.

Pros









Cons

Easily understandable documentation

Simple API

The library is actively supported and has 934

No need to maintain the code

Support for Coroutines and Flow

We are dependent on the author of the library –what if support stops?

Long waiting time for bug fixes

Flexibility and ease to adapt the solution to our needs

Errors can be fixed quickly





The need to maintain code on two platforms

A large amount of boilerplate

Entry threshold into the code is higher

Every additional solution requires adding implementation to each platform

Estimated cost

Low

Hight

Conclusion

We chose to use a pre-built solution library for our Kotlin Multiplatform project after carefully weighing our options. This choice was made primarily so that our developers could concentrate on core functions without worrying about maintenance costs. The library's ease of use assures a low barrier to entry, making it simple to adopt and incorporate into our project.

Photo of Krzysztof Kansy

More posts by this author

Krzysztof Kansy

Former Android Developer at Netguru
Kotlin Multiplatform App Development  Reduce development cost and increase team efficiency Check how

We're Netguru!

At Netguru we specialize in designing, building, shipping and scaling beautiful, usable products with blazing-fast efficiency

Let's talk business!

Trusted by: