Category Archives: jetpack

Datenspeicher ist eine Jetpack-Datenspeicherbibliothek, die eine sichere und konsistente Möglichkeit bietet, kleine Datenmengen wie Einstellungen oder Anwendungsstatus zu speichern. Es basiert auf Kotlin Korutine und Flow die eine asynchrone Datenspeicherung ermöglichen. Es zielt darauf ab, zu ersetzen SharedPreferences, weil es sicher ist und nicht blockiert. Es bietet zwei verschiedene Implementierungen: Proto-DataStoredas typisierte Objekte speichert (unterstützt von Protokollpuffer) ich DataStore-Einstellungen, die Schlüssel/Wert-Paare speichert. Machen wir weiter, wenn wir es einfach benutzen DataStoregilt dies für beide Implementierungen, sofern nicht anders angegeben.

Wir werden uns diesen Blogbeitrag genauer ansehen Datenspeicher – wie es funktioniert, welche Implementierungen es bietet und ihre individuellen Anwendungsfälle. Wir werden uns auch ansehen, welche Vorteile und Verbesserungen es bringt SharedPreferences und warum sich der DataStore dadurch lohnt.

Sie haben es wahrscheinlich benutzt SharedPreferences in Ihren Anwendungen. Es ist auch wahrscheinlich, dass Sie Probleme mit hatten SharedPreferences welche sind schwer zu reproduzieren – Erkennen ungewöhnlicher Abstürze in Ihren Analysen aufgrund nicht erfasster Ausnahmen, UI-Blockierung oder beim Tätigen von Anrufen oder inkonsistenten, persistenten Daten in Ihrer Anwendung. Datenspeicher wurde entwickelt, um all diese Probleme zu lösen.

Schauen wir uns einen direkten Vergleich zwischen an SharedPreferences und Datenspeicher:

Asynchrone API

Bei den meisten Speicher-APIs müssen Sie häufig benachrichtigt werden asynchron wenn die Daten geändert werden. SharedPreferences bietet an manche Async-Unterstützung, aber nur um Updates zu geänderten Werten per zu erhalten OnSharedPreferenceChangeListener. Dieser Rückruf wird jedoch weiterhin aufgerufen Haupt-Bedroung. Ebenso können Sie es verwenden, wenn Sie Ihre Dateispeicherarbeit in den Hintergrund stellen möchten SharedPreferences apply()aber denken Sie daran, dass es sein wird UI-Thread blockieren er fsync(), was möglicherweise Ruck und ANRs verursacht. Dies kann jedes Mal passieren, wenn der Dienst gestartet oder beendet wird oder wenn eine Aktivität angehalten oder beendet wird. Im Vergleich dazu bietet der DataStore a vollständig asynchrone API um Daten herunterzuladen und zu speichern, indem Sie die Leistung von Kotlin und Flow nutzen und das Risiko einer Blockierung Ihrer UI-Threads verringern. Für diejenigen, die mit Kotlin Flows nicht vertraut sind, es ist nur ein Wertstrom, der asynchron berechnet werden kann.

Synchronbetrieb

SharedPreferences Die API unterstützt den synchronen Box-Betrieb. Es ist jedoch synchron commit() Um persistente Daten zu ändern, mag es sicher erscheinen, UI-Threads aufzurufen, aber es funktioniert tatsächlich schwieriger I / O-Operationen. Dies ist ein riskantes Szenario, das zu ANRs und UIs führen kann und dies auch oft tut. Um dies zu verhindern, muss DataStore bietet keine gebrauchsfertige synchrone Unterstützung. DataStore speichert die Einstellungen in einer Datei und führt alle Datenoperationen im Hintergrund durch Dispatchers.IO, Sofern nicht anders angegeben, bleibt Ihr UI-Thread entsperrt.

Es ist jedoch möglich, DataStore und synchronen Betrieb mit ein wenig Hilfe des Corutin-Builders zu kombinieren, wie wir später sehen werden.

Fehlerbehandlung

SharedPreferences kann Analysefehler als Laufzeitausnahmen ausgeben, wodurch Ihre Anwendung anfällig für Abstürze wird. Zum Beispiel die ClassCastException ist eine häufige Ausnahme, die von der API ausgelöst wird, wenn falscher Datentyp Wird benötigt. DataStore bietet einen Weg jede Ausnahme abfangen Sie kommen beim Lesen oder Schreiben von Daten und verlassen sich auf den Fehlersignalisierungsmechanismus von Flow.

Sicherheitsstufe

Die Verwendung von Key/Value Map-Paaren zum Speichern und Abrufen von Daten bietet keine Typsicherheit. Mit Proto DataStore können Sie jedoch das Schema für Ihr Datenmodell vordefinieren und den zusätzlichen Vorteil nutzen vollständige Sicherheit.

Datenkonsistenz

SharedPreferences‘ Das Fehlen von Atomaritätsgarantien bedeutet, dass Sie nicht darauf vertrauen können, dass Änderungen in Ihren Daten immer und überall widergespiegelt werden. Dies kann gefährlich sein, zumal der ganze Sinn dieser API dauerhafte Datenspeicherung. Zum Vergleich DataStore vollständig transaktionale API bietet stark SÄURE Garantien, da die Daten in aktualisiert werden Atomares Lesen-Modifizieren-Schreiben Betrieb. Es bietet auch “nach dem Schreiben lesen„Konsistenz, die die Tatsache widerspiegelt, dass sich alle abgeschlossenen Aktualisierungen in den gelesenen Werten widerspiegeln.

Migrationsunterstützung

SharedPreferences Es gibt keinen integrierten Migrationsmechanismus – es liegt an Ihnen, ein mühsames, fehleranfälliges Mapping von Ihrem alten Warehouse auf das neue durchzuführen und dann aufzuräumen. All dies erhöht die Chancen Laufzeitausnahmen, da Sie leicht auf Probleme mit der Nichtübereinstimmung von Datentypen stoßen könnten. Der DataStore bietet jedoch einen Weg einfache Datenmigration darin, zusammen mit der geplanten Umsetzung für SharedPreferences-on-DataStore-Migration.

Jetzt haben wir gesehen, welche Vorteile der DataStore bietet SharedPreferenceslassen Sie uns darüber sprechen, wie Sie zwischen den beiden Implementierungen wählen können – Einstellungen und Proto DataStore.

Einstellungen Datenspeicher liest und schreibt datenbasiert Schlüssel/Wert-Paare, ohne vorherige Definition der Regelung. Auch wenn das vielleicht ähnlich klingt SharedPreferences, denken Sie an alle oben genannten Verbesserungen, die der DataStore mit sich bringt. Lassen Sie sich nicht von ihrem Teilen täuschen.”Einstellungen„Bei der Benennung – sie haben nichts gemeinsam und kommen von zwei völlig getrennten APIs.

Proto Datenspeicher Geschäfte getippte Objektemit Unterstützung Protocol Buffers, bietet Typsicherheit und eliminiert die Notwendigkeit von Schlüsseln. Protobuffs sind schneller, kleiner, einfacher und weniger mehrdeutig als XML und andere ähnliche Datenformate. Wenn Sie sie noch nie benutzt haben, haben Sie keine Angst! Dies ist sehr einfach zu lernen. Obwohl der Proto DataStore erfordert, dass Sie einen neuen Serialisierungsmechanismus erlernen, sind wir von seinen Vorteilen besonders überzeugt Typ Sicherheites ist es wert.

Bei der Wahl zwischen den beiden müssen Sie Folgendes berücksichtigen:

• Wenn Sie mit arbeiten Schlüssel/Wert-Paare zum Lesen und Schreiben von Daten, die Sie möchten schnell migrieren von SharedPreferences mit minimalen Änderungen, während Sie immer noch die Vorteile von DataStore-Verbesserungen nutzen und sich ohne Typsicherheitsprüfungen sicher genug fühlen, können Sie mit gehen DataStore-Einstellungen
• Wenn Sie Protokollpuffer für den zusätzlichen Vorteil einer verbesserten Lesbarkeit lernen möchten, wenn Ihre Daten Arbeit erfordern komplexere Klassenwie Aufzählungen oder Listen, und die Sie haben möchten vollständige Sicherheit unterstützen, während Sie dies tun, können Sie versuchen Proto-DataStore

Du darfst fragen –“Nun, warum nicht einfach nutzen Zimmer um meine Daten zu speichern?“. Und das ist eine berechtigte Frage! Mal sehen, wo Room in all das hineinpasst.

Wenn Sie mit arbeiten müssen komplexe Datensätze größer als ein paar 10 KB ist, ist es sehr wahrscheinlich, dass Sie es brauchen werden Teilaktualisierungen oder Referenzintegrität zwischen verschiedenen Datentabellen. In diesem Fall sollte der Einsatz erwogen werden Zimmer.

Wenn Sie jedoch mit arbeiten kleiner und einfacher Datensätzewie z. B. Anwendungseinstellungen oder Status, und daher keine Teilaktualisierungen oder Referenzintegrität erfordern, sollten Sie auswählen Datenspeicher.

Wir sind näher ins Detail gegangen Datenspeicher – wie es funktioniert, welche Änderungen und Verbesserungen es bringt und wie man sich zwischen den beiden Implementierungen entscheidet. Wir werden in den nächsten beiden Blogbeiträgen weiter darauf eingehen Proto und Preferences DataStore – wie man Daten erstellt, liest und schreibt, alle Fehler behandelt und wie man sie überwindet SharedPreferences. Bleiben Sie dran!