Datenpersistenz in der mobilen Entwicklung — was es ist, Methoden und wie es funktioniert

Was ist Datenpersistenz

Data Persistence ist die Fähigkeit einer Anwendung, Daten im nichtflüchtigen Speicher des Geräts zu speichern. In der mobilen Entwicklung umfasst Persistenz Datenbanken, Dateisystem, Einstellungen und Cache. Jeder Mechanismus hat seine eigenen Merkmale in Bezug auf Leistung, Sicherheit und Speicherkapazität.

Flüchtige und persistente Daten

Flüchtige Daten existieren nur im RAM und gehen bei Beendigung des Prozesses verloren. Dazu gehören Bildschirmzustand, temporäre Berechnungen und Bildercache. Persistente Daten werden in ein Dateisystem oder eine Datenbank geschrieben und bleiben nach einem Neustart der App verfügbar. Dazu gehören Benutzereinstellungen, Autorisierungstokens, Operationsverlauf und heruntergeladene Inhalte.

Kriterien für die Wahl eines Speichermechanismus

Bei der Auswahl einer Speichermethode bewerten Entwickler mehrere Faktoren. Der Datentyp bestimmt die Speicherstruktur: einfache Einstellungen — SharedPreferences oder DataStore, strukturierte Datensätze — SQLite oder Room, Dateien — File Storage. Das Datenvolumen beeinflusst die Leistung: Datenbanken sind für tausende Datensätze optimiert, während Dateien für große Binärobjekte geeignet sind. Die Sicherheit erfordert die Verschlüsselung sensibler Informationen über EncryptedSharedPreferences oder SQLCipher.

data class StorageOption(
    name: String,
    dataType: StorageType,
    capacity: Long,
    secure: Boolean
)

enum class StorageType {
    KEY_VALUE,
    RELATIONAL,
    FILE
}

SharedPreferences und DataStore

SharedPreferences ist die klassische Methode zur Speicherung von Schlüssel-Wert-Paaren unter Android. Diese API ist seit den ersten Versionen der Plattform verfügbar und unterstützt primitive Typen: Zeichenketten, Zahlen, boolesche Werte. Die Daten werden in einer XML-Datei im privaten Verzeichnis der App gespeichert und sind nur für ihren Prozess zugänglich.

DataStore als Alternative

Jetpack DataStore ist ein moderner Ersatz für SharedPreferences, der auf Kotlin Coroutines und Flow basiert. DataStore bietet zwei Varianten: Preferences DataStore für einfache Werte und Proto DataStore für typisierte Objekte. Im Gegensatz zu SharedPreferences garantiert DataStore Datenkonsistenz bei gleichzeitigem Zugriff und unterstützt asynchrone Operationen ohne Blockierung des Hauptthreads.

// SharedPreferences — der traditionelle Ansatz
val prefs = context
    .getSharedPreferences("settings", Context.MODE_PRIVATE)
with (prefs.edit()) {
    putString("username", "john_doe")
    putInt("score", 1500)
    apply()
}

// DataStore — asynchroner Ansatz
val settingsDataStore = context
    .createDataStore("settings.pb")

val usernameFlow: Flow<String> = settingsDataStore
    .data
    .map { it[USERNAME_KEY] ?: "" }

Unter iOS ist das Äquivalent zu SharedPreferences UserDefaults — ein Speichersystem für einfache Werte im Property-List-Format. UserDefaults verwendet synchronen Zugriff und eignet sich für kleine Mengen an Konfigurationsdaten, wird aber nicht für die Speicherung sensibler Informationen empfohlen.

SQLite in mobilen Apps

SQLite ist eine eingebettete relationale Datenbank, die innerhalb des App-Prozesses ohne separaten Server läuft. Es ist das am weitesten verbreitete DBMS in der mobilen Entwicklung: Es wird standardmäßig auf beiden Plattformen verwendet. Android enthält SQLite im SDK, iOS in der libsqlite3-Bibliothek. SQLite unterstützt Standard-SQL, Transaktionen, Indizes und Trigger.

Tabellenerstellung und CRUD-Operationen

Die Arbeit mit SQLite beginnt mit der Definition des Datenbankschemas. Der Entwickler definiert Tabellen, ihre Felder und Typen und führt dann Einfüge-, Lese-, Aktualisierungs- und Löschoperationen durch. SQLiteOpenHelper unter Android verwaltet die Erstellung und Migration der Datenbank, während iOS die C-Schnittstelle oder den FMDB-Wrapper verwendet.

// SQLiteOpenHelper unter Android
class DBHelper(context: Context) :
    SQLiteOpenHelper(context, "app.db", null, 1) {

    override fun onCreate(db: SQLiteDatabase) {
        db.execSQL("""
            CREATE TABLE users (
                id INTEGER PRIMARY KEY,
                name TEXT NOT NULL,
                email TEXT UNIQUE
            )
        """)
    }

    fun insertUser(name: String, email: String) {
        val db = writableDatabase
        val values = ContentValues().apply {
            put("name", name)
            put("email", email)
        }
        db.insert("users", null, values)
    }
}

Room — ORM für Android

Room ist eine Bibliothek aus Jetpack, die eine ORM-Schicht über SQLite bereitstellt. Room beseitigt die sich wiederholende Arbeit beim Schreiben von SQL-Abfragen und ContentValues und ersetzt sie durch Annotationen und Kotlin-Funktionen. Der Room-Compiler generiert DAO-Implementierungen (Data Access Object) zur Build-Zeit und eliminiert damit SQL-Syntaxfehler.

Room in einem Projekt einrichten

Um Room zu integrieren, müssen Sie die kapt-Abhängigkeit hinzufügen und die Entitätsklasse, das DAO-Interface und die Datenbankklasse annotieren. RoomDatabase dient als Einstiegspunkt: über sie erhalten Sie ein DAO und führen Datenbankoperationen aus. Room unterstützt Flow für reaktive Abfragen, Schema-Migrationen und die Abfrageüberprüfung zur Compile-Zeit.

@Entity(tableName = "users")
data class User(
    @PrimaryKey val id: Int,
    @ColumnInfo(name = "full_name") val name: String,
    @ColumnInfo val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM users")
    fun getAll(): Flow<List<User>>

    @Insert
    suspend fun insert(user: User)

    @Delete
    suspend fun delete(user: User)
}

@Database(
    entities = [User::class],
    version = 1
)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Core Data — iOS-Framework

Core Data ist Apples Framework zur Verwaltung eines Objektgraphen und dessen Persistierung auf der Festplatte. Im Gegensatz zu Room arbeitet Core Data nicht mit Tabellen, sondern mit verwalteten Objekten (NSManagedObject), die eine Hierarchie von Beziehungen bilden. Core Data unterstützt verzögertes Laden, Rückgängigmachen von Änderungen und komplexe Abfragen über NSFetchRequest.

Core Data Stack

Der Kern von Core Data besteht aus drei Komponenten: einem verwalteten Objektkontext (NSManagedObjectContext), einem persistenten Store-Koordinator (NSPersistentStoreCoordinator) und einem Datenmodell (NSManagedObjectModel). NSPersistentContainer vereint alle Komponenten in einem einzigen Einstiegspunkt und vereinfacht so die Einrichtung für moderne Swift-Anwendungen.

import CoreData

class PersistenceController {
    static let shared = PersistenceController()
    let container: NSPersistentContainer

    init() {
        container = NSPersistentContainer(name: "AppModel")
        container.loadPersistentStores { _, error in
            if let error = error {
                fatalError("Failed: \(error)")
            }
        }
    }

    func saveUser(name: String, email: String) {
        let context = container.viewContext
        let user = User(context: context)
        user.name = name
        user.email = email

        do {
            try context.save()
        } catch let error {
            print("Save error: \(error)")
        }
    }
}

Dateispeicherung (File Storage) wird zum Speichern von Bildern, Videos und Dokumenten verwendet. Android bietet internen Speicher (context.filesDir) — privat für die App, und externen Speicher (Environment.getExternalStorageDirectory) — für andere Apps zugänglich. Unter iOS werden Dateien in den Verzeichnissen Documents und Library gespeichert, wobei Library/Caches für den Cache vorgesehen ist, der nicht in iCloud gesichert wird. Für Dateioperationen stellen beide Plattformen File-API und Streaming-Lese-/Schreiboperationen bereit. Moderne Bibliotheken wie Coil und SDWebImage fügen eine Caching-Schicht hinzu, die Dateispeicherung mit RAM für optimale Leistung kombiniert.

Unter Android ist Realm ein alternatives Gegenstück zu Core Data in Bezug auf Komplexität und Funktionalität — eine objektorientierte Datenbank, die direkt mit Modellen ohne SQL-Schicht arbeitet. Realm ist bei Leseoperationen schneller als SQLite und unterstützt Live-Objekte, die die UI bei Datenänderungen automatisch aktualisieren.