Daten für Service - wo halten?

  • Antworten:4
Ultimate Software
  • Forum-Beiträge: 110

24.09.2012, 14:13:39 via Website

Hi,

ich würde mal eure Meinungen zu meinem Problem hören. Ich schreibe eine App die einen Service verwendet. Dieser lädt beim 1. Aufruf relativ viele Daten von einem Server, gegen den die weiteren Dienste des Service gehen.

Wo würdet ihr diese Daten nun lassen?
- Im Service halten macht ja keinen Sinn, da dieser ggf. beendet wird (Service wird von App und durch Broadcast-Intents angesteuert).
- Immer in den SharedPreferences abspeichern wären die Daten etwas groß und zu komplex (Neuaufbau müsste wieder verschiedene Objekte in einem Baum erstellen, da sie ja in der Form nicht gespeichert werden können).
- in einer mySQL-DB ist ähnlich SharedPreferences, zu langsam, zu häufig und die Struktur
- ein Singleton das die Daten hält und falls es leer ist muss halt doch nochmal nachgelesen werden?

habt ihr noch andere bessere Ideen?

<td class="alt1"> <!-- google_ad_section_start -->Mehrere WLANs?? Versuch doch mal den <a href="http://goo.gl/7ojEp&quot; target="_blank">SSID Selector</a>: <img src="images/smilies/extra/thumbsup.gif" border="0" alt="" title="Thumbsup" class="inlineimg" /><!-- google_ad_section_end --> </td>

Antworten
Ultimate Software
  • Forum-Beiträge: 110

24.09.2012, 16:56:40 via Website

ja.... aber die Daten sind nicht "irgendwelche" Daten, sondern ein Tree von Objekten mit Verknüpfungen untereinander. Wenn ich diese nun in der sql-DB ablege muss ich das gesamte Objekt-geflecht ja wieder aufbauen und die aktuellen Verknüpfungen neu erstellen... kostet das nicht riesig Zeit?

Wobei, Tree ist auch nicht ganz richtig, da einträge im Tree wieder Links auf andere Objekte irgendwo im Baum sein können wäre es eher ein Netz....

Ich bekomme die Daten von meinem Server als JSON-Object... dafür hab ich ja ne Logik das Netz aufzubauen, vielleicht sollte ich exact DAS Object (ist ja serialisierbar) abspeichern?

Im Moment bin ich bei meinen Überlegungen bei folgendem: Beim laden der Daten das JSON-Object abspeichern (z.B. SharedPreferences) und die Daten "ausgepackt" in einem Singleton speichern. Wenn das Singelton dann mal leer ist (weil Android es abgeräumt hat) könnte ich aus den SharesPreferences das geflecht neu aufbauen, tue dies aber dadurch so selten wie möglich.....

Was hälst du davon?

<td class="alt1"> <!-- google_ad_section_start -->Mehrere WLANs?? Versuch doch mal den <a href="http://goo.gl/7ojEp&quot; target="_blank">SSID Selector</a>: <img src="images/smilies/extra/thumbsup.gif" border="0" alt="" title="Thumbsup" class="inlineimg" /><!-- google_ad_section_end --> </td>

Antworten
Gelöschter Account
  • Forum-Beiträge: 694

24.09.2012, 17:59:30 via Website

JSON Daten haben m.E. immer eine Struktur.

Ich bin nun mal Datenbank-Mensch - ich klappe immer alle Daten komplett auf. An Preferences denke ich nur im Zusammenhang mit Settings und persistenten Einstellungen. Bei Anwendungsdaten kommen die bei mir nie ins Spiel. Die Datenbank ist halt so gnadenlos schnell - wenn die Daten einmal drin sind. Aber auch das Befüllen ist unvergleichlich schnell. Ich habe vor einigen Jahren viele, viele Tests mit der SQLite auf Android gemacht weil meine GaCoMo App heftige Daten zu speichern hat (die übrigens auch in diesen Austauschformaten daherkommen). Da werden schon mal mehrere MB Daten mit Herzfrequenzen, Geschwindigkeiten, Höhenprofile, etc. von einer 180km Rennradtour geparst, strukturiert und in bis zu 10 Tabellen verteilt. Das alles in 1-3 Sekunden (ohne den Download).

Wenn Du über "auspacken" nachdenkst und es in Preferences speicherst dann kannst Du auch nach dem Auspacken in die Datenbank schreiben.

Nur meine 0.02 Cent. Meine DBA Vergangenheit kann ich halt nicht mehr abschütteln.

Antworten
Ultimate Software
  • Forum-Beiträge: 110

24.09.2012, 23:16:28 via Website

Naja, JSON ist ja gerade dafür da eine Struktur wie ein Object-Geflecht zur Datenübertragung flach zu kopfen.

Das Problem ist, das ich die Daten nicht wirklich dauerhaft speichere, es soll sozusagen Temporär für den Service abgelegt werden. Wenn ich dauerhaft persistieren wollen würde wäre wohl auch die DB meine Wahl, aber diese Daten können quasi alle paar "Zugriffe" neu vom Server geladen werden... je nachdem was gerade passiert. 1-3 Sekunden jedesmal wenn die App eine Aktion auslöst wäre deutlich zu viel overhead. Ich werde es mit dem Singleton probieren, was der absolut schnellste Weg ist (klar, ausgepackt im Hauptspeicher, schneller geht es nicht) und werde mal sehen wie oft der Service bzw. das Singleton wirklich gelöscht wird.

<td class="alt1"> <!-- google_ad_section_start -->Mehrere WLANs?? Versuch doch mal den <a href="http://goo.gl/7ojEp&quot; target="_blank">SSID Selector</a>: <img src="images/smilies/extra/thumbsup.gif" border="0" alt="" title="Thumbsup" class="inlineimg" /><!-- google_ad_section_end --> </td>

Antworten