Laden...

Windows UWP: Wo Einstellungen permanent sichern?

Erstellt von Bumbum vor 7 Jahren Letzter Beitrag vor 7 Jahren 4.826 Views
B
Bumbum Themenstarter:in
8 Beiträge seit 2016
vor 7 Jahren
Windows UWP: Wo Einstellungen permanent sichern?

Hallo,

ich habe mir für mein Raspberry Pi mit Windows 10 IoT eine kleine App geschrieben, in der ich nun Einstellungen dauerhaft ablegen möchte. Nach einigem Googeln habe ich folgenden Ort dafür benutzt:

Windows.Storage.ApplicationData.Current.LocalSettings

Das war alledings nicht permanent. Wenn ich ein Update ans Pi gesendet habe waren die Einstellungen weg. Also habe ich das ganze auf:

Windows.Storage.ApplicationData.Current.RoamingSettings

umgestellt, bin aber immer noch nicht zufrieden. Es ist an diesem Ort auch schon vorgekommen, dass die Einstellungen einfach weg waren. Den genauen Grund konnte ich allerdings nicht feststellen.

Aktuell handelt es sich um ca. 70kb Daten, könnte in Zukunft aber minimal mehr werden.

Wie würdet ihr vorgehen? Mein nächster Gedanke ist einfach eine Datei anlegen. (wo in W10 IoT?) Das könnte aber auch der falsche sein bei den ganzen Möglichkeiten in .net
Ein Problem scheint, dass unter UWP nicht alle .net Lösungen verfügbar sind.

Viele Grüße
Andreas

16.806 Beiträge seit 2008
vor 7 Jahren

Siehe auch:

Speichern und Abrufen von Einstellungen und anderen App-Daten
Da ist der Unterschied von Local und Roaming beschrieben und wann was eingesetzt werden soll.

Einfach so ne Datei anlegen ist bei isolierten Apps nicht.

Dazu der sehr deutliche Hinweis:

Die Lebensdauer der App-Daten ist an die Lebensdauer der App gebunden. Wenn die App entfernt wird, gehen auch alle App-Daten verloren. Verwenden Sie App-Daten nicht zum Speichern von Benutzerdaten oder anderen Daten, die Benutzer als wertvoll und unersetzlich betrachten. Solche Informationen sollten in den Bibliotheken des Benutzers und auf Microsoft OneDrive gespeichert werden. App-Daten eignen sich perfekt zum Speichern von App-spezifischen (Benutzer-)Einstellungen und Favoriten.

B
Bumbum Themenstarter:in
8 Beiträge seit 2016
vor 7 Jahren

Hallo Abt,

vielen Dank. Diesen Link und Text habe ich bereits gelesen. Ich habe die App noch nie entfernt, immer nur über Visual Studio aktualisiert. Trotzdem kommt es vor, dass die Daten einfach weg sind. Ich habe hier eine App, bei der passiert das fast bei jedem Update. Bei einer anderen wesentlich seltener. Das ist sehr frustrierend, da die Backup-Möglichkeiten auch quasi nicht vorhanden sind.

Es muss doch eine Möglichkeit geben Benutzerdaten dauerhaft für eine App zu speichern, auch wenn diese aktualisiert wird.
Wenn Dateien nicht möglich sind bleibt ja nur eine Art Cloud-Lösung. Das kann ich irgendwie nicht glauben...

Viele Grüße,
Andreas

16.806 Beiträge seit 2008
vor 7 Jahren

Haste Dir denn auch mal Guidelines for roaming app data durchgelesen, wie man es tun sollte?
Wir einem sehr deutlich nahegelegt, wenn man sich als Store Developer registriert.
Ich vermute, dass Du das hier nicht beachtest und daher mit Seiteneffekten zutun hast, zB. weil die Quota überschreitest. 70kB sind hier schon viel (kein Witz!).

Dafür ist das einfach nicht gedacht; hast Du mehr, dann musst Du das auslagern, zB. OneDrive oder ne eigene Datei in Deinem Isolated Storage.
Der wird aber nicht synchronisiert und gekillt, wenn die App deinstalliert wird.

Microsoft ist für das Sichern Deiner Appeinstellungen auch nicht verantwortlich.

B
Bumbum Themenstarter:in
8 Beiträge seit 2016
vor 7 Jahren

Hallo Abt,

vielen Dank für die Hinweise. Ich bin noch am Einsteigen und die zwei Projekte sind meine ersten mit der neuen Sprache C# und Windows UWP. Da kämpft man so manchen Kampf um passende Links, bei denen das nötige Wissen vermittelt wird.
Ich habe mich tatsächlich noch nicht als Shop Developer registriert, da das Ganze (derzeit) für privat als Einzelprojekt genutzt werden soll.

Ich denke wir reden bis jetzt auch ein bischen anneinander vorbei. Vielleicht habe ich mich mit "permanent" etwas unglücklich ausgedrückt. Mir geht es darum die Daten zu behalten, auch wenn die App abstürzt, ein Update kommt oder sonstwas undefiniertes passiert.
Eine einfache Ini-Datei, von der ich auch noch eine Backup-Kopie anlegen könnte wäre praktisch.

Ich habe gerade mal nach "isolation storage" gegoogelt, könnte gehen. Der Namespace ist auch verfügbar. Auf die schnelle habe ich allerdings nichts über den Lebenszyklus der Dateien dort gefunden. Hast du da was für mich?

Viele Grüße
Andreas

16.806 Beiträge seit 2008
vor 7 Jahren

Technisch gesehen sind ini-Dateien bereits jahrzente überholt. Das solltest Du also schon direkt wegwerfen und auf Json oder XML setzen.
Ini geht gar nicht mehr heute.

Der Isolated Storage lebt solange die App installiert ist.
Du kannst hier auch einfach eine lokale Datenbank (Sqlite) nehmen.

D
985 Beiträge seit 2014
vor 7 Jahren

Und wenn man dieses konkrete INI-Datei mal ersetzt durch "hierachischer Key-Value-Store" (das ist es, was man eigentlich benötigt, egal wie das konkret dann umgesetzt ist), dann findet man das unter dem von Abt geposteten Link.

Einfach mal durchstöbern, bis du zu LocalSettings oder RoamingSettings (je nach Belieben) kommst, das ist das, was du suchst, wenn du eine INI-Datei im Kopf hast.

16.806 Beiträge seit 2008
vor 7 Jahren

Naja, das stimmt so nicht ganz.

Vermutlich ist weder Roaming noch Local das, was er will:

  • LocalSettings sind nur für innerhalb einer Session. Wenn die App geschlossen wird, dann wird das Zeug entfernt. Größe ist hier unbegrenzt; Beispiel: Twitter-Feed Caching.
  • Roaming ist aber wiederum kein Platz, bei dem man etwas ablegt, was als Cache gedacht ist oder für größe Datenmengen. Das ist wirklich Minimal, eher im 1-stelligen KB-Bereich.

Für alles andre, was an eines dieser K.O.-Kriterien kommt - und das scheint hier der Fall zu sein - muss sich der Entwickler zB. eine Sqlite-DB in den LocalStorage legen und ein eigenes Settings-System bauen.
Nicht unbedingt so dolle; aber das ist de facto überall so.

PS: nicht anders stehts in den beiden von mir verlinkten Seiten.

D
985 Beiträge seit 2014
vor 7 Jahren

Naja, das stimmt so nicht ganz.

Vermutlich ist weder Roaming noch Local das, was er will:

  • LocalSettings sind nur für innerhalb einer Session. Wenn die App geschlossen wird, dann wird das Zeug entfernt. Größe ist hier unbegrenzt; Beispiel: Twitter-Feed Caching.

PS: nicht anders stehts in den beiden von mir verlinkten Seiten.

Hast du da mal einen Link, wo das dokumentiert ist, denn unter deinen Links finde ich leider nur diese Information

Lokale App-Daten

Lokale App-Daten sollten für alle Informationen verwendet werden, die zwischen App-Sitzungen beibehalten werden müssen und die nicht als App-Roamingdaten geeignet sind. Daten, die auf anderen Geräten nicht verwendet werden können, sollten ebenfalls dort gespeichert werden. Es gibt keine allgemeinen Größenbeschränkungen für lokal gespeicherte Daten. Verwenden Sie den lokalen App-Datenspeicher für Daten, für die ein Roaming nicht sinnvoll ist, sowie für große Datasets.

Eventuell deute ich auch die Aussage "die zwischen App-Sitzungen beibehalten werden müssen" völlig falsch (soll ja vorkommen).

16.806 Beiträge seit 2008
vor 7 Jahren

Da hab ich den Text selbst 10 Sekunden vorher gelesen und doch falsch wieder gegeben 😉
Dann ist LocalSetting das, was er will. Das Verhalten, was er im Eingangsthread beschreibt, ist dann aber nicht nachvollziehbar.
Vermutlich macht Bumbum also irgendwas, was diese Settings zurück setzt.

B
Bumbum Themenstarter:in
8 Beiträge seit 2016
vor 7 Jahren

Hallo,

vielen Dank für die rege Diskussion. Ob ich etwas falsch mache mit LocalSettings kann ich nicht sagen. Ich lese den Container 1x bei Programmstart und schreibe nur, wenn sich was ändert. Das muss der Benutzer aber vorher auslösen. Die Daten verliere ich (bei Local) bei jedem Update, wenn ich eine neue Version via Visual Studio auf das Pi übertrage. Die Daten waren auch schon mal weg, wenn ich eine andere Anwendung auf dem Pi gestartet habe. (Es kann immer nur eine gleichzeitig laufen; beim beenden wird NICHT gespeichert) Mit dem Roaming-Container klappt das zwar besser, aber auch nicht in jedem Fall.
Die Frage wäre, ob das mit einer Datei im isolierten storage auch passiert, da diese scheinbar den gleichen Lebenszyklus hat wie LocalSettings...

Die Ini-Datei war nur symbolisch gemeint. Ich weiß, dass sowas modern anders gelöst wird, bzw. löse das in meinen anderen Projekten auch so. Nur hier bin ich am Einsteigen in UWP und C#. Da hat man noch nicht für alles eine perfekte Lösung am Start und hangelt sich erst mal zu einer testfähigen Anwendung um Erfahrung zu sammeln, bis man sich einen Bibliotheken-Stamm aufgebaut hat, wie man ihn eigentlich gewohnt ist.
Für welches Speicherformat (Ini, XML, SQL, etc.) ich mich dann entscheide hängt ja auch davon ab, welche Möglichkeiten ich zum Speichern habe.
Ich fühle mich beim aktuellen Projekt nur so, dass ich mit Kanonen auf Spatzen schieße, nur um mal eben 70kb Anwendungsdaten (Es handet sich um einen simplen Kalender) zu speichern, die dann auch ein Update überleben...

Meine Gedanken gehen inzwischen so weit, dass ich einen externen Kalender bemühe (am besten Exchange) und dort meine Daten ablege. Aber wie gesagt: Kanonen auf Spatzen... Noch dazu gibt es bis jetzt scheinbar keine EWS Umsetzung für UWP... Die Lösung hat außerdem den Nachteil, dass ich bei meiner nächsten Anwendung eventuell immer noch nicht weiß, wie ich es richtig löse.

Viele Grüße,
Andreas

D
985 Beiträge seit 2014
vor 7 Jahren

Hast du mal eine Test-Anwendung mit den LocalSettings geschrieben und unter einem normalen Windows 10 laufen lassen und getestet? Das funktioniert bei mir ganz wunderbar.

Dann die gleiche Anwendung auf dem PI testen ...