Kotlin Multiplatform Academy · レッスン

Settings Abstractionが必要な理由

SharedPreferencesとNSUserDefaultsを1つのAPIで扱います

「Settings Abstractionが必要な理由」はCoddyKit上の無料Kotlin Multiplatform Academyレッスンです。これはレッスン1/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはKotlin Multiplatform Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Kotlin Multiplatform Academyコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

The Storage Gap

Android and iOS each ship their own way to save small values. Without a shared layer, you would write that code twice. Let's fix that. 🔑

Two Native Stores

Android stores small key-value data in SharedPreferences, while iOS uses NSUserDefaults. Same idea, two very different APIs.

One API to Rule Them

A Settings abstraction wraps both native stores behind a single Kotlin interface, so your shared code calls one method everywhere.

Meet Multiplatform Settings

The community library multiplatform-settings gives you exactly that: one Settings type backed by the right native store on each platform.

Add the Dependency

You add the multiplatform-settings artifact to your shared module's commonMain so every target can use it.

commonMain.dependencies {
    implementation("com.russhwolf:multiplatform-settings:1.1.1")
}

The Settings Interface

At its core sits the Settings interface. Your shared code depends on this type, never on the platform store directly.

interface Settings {
    fun putString(key: String, value: String)
    fun getString(key: String, defaultValue: String): String
}

Why Abstract at All

Abstraction keeps your shared logic portable. Swap the backing store or add a platform later, and the calling code never changes.

Perfect for Small Data

Settings is built for small values: flags, a username, a theme choice. For big or relational data, reach for SQLDelight instead.

Inject, Don't Create

Each platform builds its own Settings instance and passes it into shared code, so commonMain stays free of platform dependencies.

Call It from Common

Once injected, your shared code just calls Settings methods. The same line runs on Android and iOS without a single change.

fun saveTheme(settings: Settings, theme: String) {
    settings.putString("theme", theme)
}

Test-Friendly by Design

Because it's an interface, you can drop in a fake in-memory Settings during tests, no device or emulator needed. 🧪

Quick Check

Let's make sure the abstraction's purpose is clear.

Recap

You learned why KMP wraps native key-value stores behind one Settings interface: portable, testable, and written once. Next, real reads and writes. 🎉

よくある質問

「Settings Abstractionが必要な理由」レッスンは無料ですか？

はい。「Settings Abstractionが必要な理由」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Kotlin Multiplatform Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Kotlin Multiplatform Academyコースには全4レッスンが含まれています。

「Settings Abstractionが必要な理由」で何を学びますか？

SharedPreferencesとNSUserDefaultsを1つのAPIで扱いますブラウザで直接実行するハンズオンコードでKotlin Multiplatform Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Kotlin Multiplatform Academyを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのKotlin Multiplatform Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン1/4です。

「Settings Abstractionが必要な理由」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このKotlin Multiplatform Academyレッスンでコードを書いて実行できますか？

はい。すべてのKotlin Multiplatform Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Kotlin Multiplatform Academyに戻る