Core Data Daten anzeigen und updaten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Core Data Daten anzeigen und updaten

    Hi,

    ich bin gerade etwas am verzweifeln. Mir fällt einfach keine Lösung ein. Es geht eher um eine konzeptionelle Frage. Ich habe eine Core-Data Datenbank, da sollen Marker welche auf einer Map angezeigt werden sollen gespeichert sein. Mit Bildern, näheren Informationen, Kommentaren etc. Nun zu meiner Frage: Da sich die Marker ständig ändern müssen die ja auch neu geladen werden. Nun wollte ich es so machen, dass man einmal Marker lädt und dann einfach im Hintergrund aktualisiert wird. Nun stelle ich mir folgende Fragen:
    1. Wann soll man immer reloaden? Ich dachte im ViewDidLoad. Denn wenn die App im Hintergrund ist und dann wegen Speicher beendet wird wird ja ViewDidLoad wieder aufgerufen. ViewWillAppear scheint mir zu viel. Das wäre ja andauernd, da es eine TabBar Application ist. Wie würdet Ihr das machen?
    2. Wie mache ich am besten das neu einfügen in die DB? Denn normalerweise würde ich ja alles löschen in der DB und dann einfach neu hinzufügen. Nun kann es aber sein, dass während ich das mache der User auf die Idee kommt sich die Karte anzuschauen. Da sieht er ja entweder gar nichts oder total unvollständig. Schlimmsten falls kommt es zu einem Crash. Jemand da eine Idee zur Lösung? Das Problem habe ich bei einigen Apps aber nie eine Lösung auch nicht nach googlen gefunden. Ich suche wahrscheinlich falsch.

    Viele Grüße und Danke!
    Nils

  • Du solltest die Marker laden wenn sie von der Karte gefordert werden . Nicht früher und nicht später. Und eben auch nur die die gefordert werden. Sonst läuft ja irgendwann dein Speicher auf jeden Fall voll.

    Wieso du alle Einträge löscht und neu schreibst erschließt sich mir nicht.
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Du solltest die Marker laden wenn sie von der Karte gefordert werden . Nicht früher und nicht später. Und eben auch nur die die gefordert werden. Sonst läuft ja irgendwann dein Speicher auf jeden Fall voll.

    Wieso du alle Einträge löscht und neu schreibst erschließt sich mir nicht.
    Das habe ich auch schon überlegt. Aber dann wenn man mal 2cm scrollt dann muss er schon wieder Marker laden und bei einer langsamen Internetverbindung ist es besser alle auf einmal zu haben damit man die App dann auch flüssig benutzten kann. Denn die Marker enthalten ja immer noch Text, Bilder, Kommentare etc. Das ist dann glaube ich sehr nervig, wenn mal alle paar cm. warten muss.

    So viele Marker sind das auch nicht. Es sind in etwa 100-200 Stück. Und da nervt das doch immer die zu laden.

    Mit den Löschen meinte ich, dass ich alle Marker mittels CoreData in die DB speichere. Dann immer im Hintergrund neue Marker lade und gleichzeitig im Vordergrund die Marker für einen bestimmten Bereich aus der DB abfrage und Anzeige.

    Weil sonst ist man ja nur mit Laden beschäftigt. Ob dann die App Spaß macht und sinnvoll ist, ist dann einen andere Frage. Vor allem bei so und so schön langsamen E-Netz. Oder auch langsamen Internet über WLAN (wie bei mir mit 150kb/s maximal)

  • Thallius schrieb:

    Man läd die MArker ja auch nicht synchron. Dann ruckelt auch nichts. Ausserdem kann man ja auch wunderbar einen Cache für sowas einbauen.
    Wir reden irgendwie aneinander vorbei. Klar man lädt die nicht synchron. Wenn der User jetzt aber die Karte offen hat und dann irgendwo hin scrollt müssen ja die Marker neu geladen werden. Während das passiert sieht der User ja keine Marker und wenn er noch einen lahme Verbindung hat dann sieht er lange keine Marker. Da er ja nichts sieht scrollt er weiter. Da sieht er aber auch keine und so weiter und so fort. Vom Kunden bekomme ich dann die tolle Rückmeldung "Geht nicht denn ich sehe keine Marker", weil die meisten leider nicht warten. Sie wissen ja auch gar nicht das es lädt. Deswegen wollte ich die Speichern. Das kommt ja an dein Cachen ran. Aber da ist dann immer noch mein oben beschriebenes Problem mit Updaten der Marker

  • Du solltest die Marker laden wenn sie von der Karte gefordert werden . Nicht früher und nicht später. Und eben auch nur die die gefordert werden. Sonst läuft ja irgendwann dein Speicher auf jeden Fall voll.

    Wieso du alle Einträge löscht und neu schreibst erschließt sich mir nicht.

    für wo etwas hat man einen default Marker der gesetzt wird und der richtige wird dann nachgeladen. Im Normalfall reicht ja die standard-Nadel von Apple solange zu zeigen und dafür must du nur die koordinaten aus der DB laden und eventuell noch einen Titel und das sollte nur millisekunden dauern
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Du solltest die Marker laden wenn sie von der Karte gefordert werden . Nicht früher und nicht später. Und eben auch nur die die gefordert werden. Sonst läuft ja irgendwann dein Speicher auf jeden Fall voll.

    Wieso du alle Einträge löscht und neu schreibst erschließt sich mir nicht.

    für wo etwas hat man einen default Marker der gesetzt wird und der richtige wird dann nachgeladen. Im Normalfall reicht ja die standard-Nadel von Apple solange zu zeigen und dafür must du nur die koordinaten aus der DB laden und eventuell noch einen Titel und das sollte nur millisekunden dauern
    Du redest immer noch von was anderen als ich: Ich habe maximal 200 Marker. Die liegen auf einen WebService online. Damit ich das ganze anzeigen kann muss ich die Maker ja vom WebService herunterladen. Sonst habe ich ja weder Koordinaten, noch die Bilder und Kommentare dazu, die bei einen Klick auf den Marker erscheinen sollen. Diese Marker ändern sich jedoch ständig im WebService online. Dementsprechend muss ich die wieder neu herunterladen. Darauf beziehen sich meine Fragen. Klar zeige ich nur die Marker an die nötig sind aber dafür muss ich die ja erstmal von dem WebService Online in die App bekommen. Deswegen auch Datenbank löschen weil die "alten" Marker in der App müssen ja durch die neuen aus dem WebService ersetzt werden, weil sich Bilder geändert haben, die Beschreibung, Kommentare etc. Oder ganz neue hinzugekommen sind.

    Ich hoffe das ist jetzt mehr verständlich.

  • Sollte eigentlich keine Probleme geben:
    200 Marker sind nicht viel - bei der Menge bist vielleicht nicht mal darauf angewiesen, Cluster zu bilden.
    Wenn ich jetzt davon ausgehe, dass du nicht die Geokoordinaten der jeweils letzen 200 Tweets in Deutschland anzeigst, sondern die Positionen schon eine Lebensdauer von ein paar Stunden haben, ist das Nachladen auch nicht das Problem.
    Was mir nur nicht ganz klar wird:
    Lädst du immer einen Satz von 200 Bildern und anderen Daten? Das geht natürlich schon in die Bandbreite... wird aber wahrscheinlich nicht gebraucht, denn erst einmal sind ja die Koordinaten wichtig, und der Rest wird nur angezeigt, wenn sich der Nutzer für die jeweilige Koordinate interessiert.

    Für den Refresh hast du zwei Möglichkeiten: Entweder baust du jedes Mal eine neue Liste auf und ersetzt die alte in einem Rutsch, oder du holst einfach die neuen Daten dazu und löscht die alten weg.
    Je nachdem, welche Möglichkeiten du im Backend hast, kannst du da gezielt Deltas anfordern ("gib mir eine Liste mit allen gelöschten Einträgen, und alle neuen") oder erst mal alle Einträge als veraltet markieren, und dann diejenigen behalten, die in der neuen Liste noch drin sind.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von t-no ()

  • Wenn der Webserver auch nur ein klein wenig intelligent ist, dann hat er zu jedem Marker auch ein lastchanged datetime eintrag. Damit kannst du dann einfach nur die abfragen die seit dem letzten Download sich geändert haben und diese in deiner lokalten Datenbank ersetzen.
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • AppleDeveloper schrieb:

    sollte man dann schon Kommentare lade oder auch erst wenn aufgerufen?
    Auf jeden Fall zuerst das holen, was man sofort sieht - wären in dem Fall wohl nur die Koordinaten.
    Ob man danach anfängt, auf gut Glück weitere Daten zu laden und zu cachen, hängt vom Szenario ab:
    Bemerkt man die Verzögerung überhaupt, wenn man "on demand" lädt?
    Geht man davon aus, dass die Daten überhaupt jemals gebraucht werden, oder wird meist nur die Übersicht gebraucht, und dann nur noch eine Handvoll Details?

    Am Ende geht es meist ja darum, dass der Nutzer wenig von der Verzögerung merkt (und möglichst wenig Datenvolumen verbraucht... im WLAN ist das zwar egal, aber da hat man meist auch keine Probleme mit der Download-Geschwindigkeit):
    Wenn es Kommentare gibt, könnte man jeweils den ersten cachen und den Rest erst bei Bedarf holen; dann ist der User erst einmal beschäftigt.

    Zu Beginn würde ich wirklich nur die Koordinaten selbst speichern - wenn das nicht reicht, kann man den Rest später immer noch selbst cachen (das URL Loading System kann das ja auch)

  • t-no schrieb:

    AppleDeveloper schrieb:

    sollte man dann schon Kommentare lade oder auch erst wenn aufgerufen?
    Auf jeden Fall zuerst das holen, was man sofort sieht - wären in dem Fall wohl nur die Koordinaten.Ob man danach anfängt, auf gut Glück weitere Daten zu laden und zu cachen, hängt vom Szenario ab:
    Bemerkt man die Verzögerung überhaupt, wenn man "on demand" lädt?
    Geht man davon aus, dass die Daten überhaupt jemals gebraucht werden, oder wird meist nur die Übersicht gebraucht, und dann nur noch eine Handvoll Details?

    Am Ende geht es meist ja darum, dass der Nutzer wenig von der Verzögerung merkt (und möglichst wenig Datenvolumen verbraucht... im WLAN ist das zwar egal, aber da hat man meist auch keine Probleme mit der Download-Geschwindigkeit):
    Wenn es Kommentare gibt, könnte man jeweils den ersten cachen und den Rest erst bei Bedarf holen; dann ist der User erst einmal beschäftigt.

    Zu Beginn würde ich wirklich nur die Koordinaten selbst speichern - wenn das nicht reicht, kann man den Rest später immer noch selbst cachen (das URL Loading System kann das ja auch)
    Also die Daten dienen als zusätzliche Informationen. Da werde ich es so machen, wie du vorgeschlagen hast. Ein paar Kommentare laden und dann den Rest cachen. Danke! Ich mache mich mal an die Arbeit und melde mich bei fragen.