Gibt es einen Wert bei der Verwendung von Core-Daten für iPhone-Apps?

Question

Können mir Leute Beispiele nennen, warum sie CoreData in einer Anwendung verwenden?

Ich frage dies, weil die meisten Apps nur Clients zu einem zentralen Server sind, wo eine API von einer Art gibt Ihnen die Informationen, die Sie benötigen.

In meinem Fall Ich schreibe eine Zeiterfassungsanwendung für einen Web-App, die eine API hat und ich diskutieren, ob es ein Wert gibt die Datenstruktur auf meinem Server in Kerndaten in der Replikation (SQLite)

zB

Projekt hat viele Zeiterfassungen Mitarbeiter viele Zeiterfassungen haben

Es scheint mir, dass ich bei jedem Aufruf für Listen von Projekten oder bestehende Zeiterfassungen zum Beispiel an die API nur anschließen.

Ich realisiere für eine Art von Offline-Modus können Sie lokal in Core-Daten speichern, aber dies schafft viel mehr Probleme, weil Sie jetzt ein großes Problem mit der Synchronisierung dieser Daten zurück auf den Webserver haben, wenn Sie wieder Verbindung erhalten. Das für eine Arbeitszeittabelle ausgewählte Projekt existiert nicht mehr.

Kann ein erfahrener Entwickler etwas über die Erfahrungen berichten, wann Kerndaten ein Best-Practice-Ansatz sind?

EDIT

Mir ist klar, natürlich Wert gibt es scheint lokale Persistenz bei der Speicherung, aber der Schlüsselwert der Benutzereinstellungen die meisten Anwendungen abdecken ich mir vorstellen kann.

Answer 1

Sie sollten nicht einfach als eine SQLite-Datenbank von Coredata denken. Es ist nicht nur eine SQLite-Datenbank. Sicher, SQLite ist eine Option, aber es gibt auch andere Optionen, wie In-Memory und ab iOS5 eine ganze Reihe von benutzerdefinierten Datenspeichern. Der größte Vorteil von CoreData ist offensichtlich die Persistenz. Aber selbst wenn Sie einen In-Memory-Datenspeicher verwenden, profitieren Sie von einem sehr gut strukturierten Objekt-Graphen, und das gesamte Heavy-Lifting hinsichtlich des Herausziehens von Informationen oder des Einbringens von Informationen in den Datenspeicher wird von CoreData for gehandhabt Sie, ohne dass Sie sich unbedingt damit befassen müssen, was diesen Datenspeicher unterstützt. Sicher, heute interessieren Sie sich nicht so sehr für Persistenz, also könnten Sie einen In-Memory-Datenspeicher verwenden. Was passiert, wenn Sie sich morgen, in einem Monat oder in einem Jahr entscheiden, ein Feature hinzuzufügen, das wirklich von Persistenz profitieren würde? Mit CoreData ändern Sie einfach oder fügen Sie einen persistenten Datenspeicher hinzu, und alle Ihre Methoden, um Informationen zu erhalten oder zu ändern, bleiben unverändert. Der Aufwand für diese Art der Hinzufügung ist minimal im Vergleich zu dem Versuch, direkt auf SQLite oder einen anderen Datenspeicher zuzugreifen. IMHO, das ist der größte Vorteil: Abstraktion. Und im Wesentlichen ist Abstraktion eine der mächtigsten Dinge hinter OOP. Zugegeben, das Erstellen des Datenmodells nur für In-Memory-Speicher kann für Ihre App zu viel Aufwand sein, je nachdem, wie stark die App ist. Aber als Nebenbemerkung möchten Sie vielleicht überlegen, was schneller ist: Informationen von Ihrem Webdienst jedes Mal anfordern, wenn Sie eine Aktion ausführen möchten, oder die Informationen einmal anfordern, im Speicher ablegen und für diesen gespeicherten Wert handeln der Rest der Sitzung. Ein speicherinterner Datenspeicher würde über diese bestimmte Sitzung hinaus nicht bestehen.

Zusätzlich mit Coredata erhalten Sie viele andere tolle Features wie das Speichern, Abrufen und Undo-Redo.

Answer 2

Es ist ideal, wenn Sie Daten lokal auf dem Telefon speichern möchten.

Im Ernst, wenn Sie nicht sehen, dass es für Ihre Zeiterfassung App brauchen, dann machen Sie sich keine Sorgen darüber und verwenden Sie es nicht.

Die Synchronisierungsprobleme, die Sie mit einem "Offline" -Modus haben würden, würden in Ihrem Design Ihrer App ausführlich beschrieben. Zum Beispiel - erlauben Sie nicht, dass Projekte gelöscht werden. Warum würdest du? Möchten Sie nicht in die Vergangenheit zurückgehen und sich frühere Daten für bestimmte Projekte ansehen? Verwenden Sie stattdessen eine Markierung im Projekt, um sie als inaktiv zu markieren, und ein Datum/eine Uhrzeit, zu der sie inaktiviert wurde. Wenn die Daten, die vom Gerät synchronisiert werden, für dieses Projekt bestimmt sind und vor dem Datum/der Uhrzeit liegen, an dem/denen es als inaktiv markiert wurde, können Sie die Synchronisierung durchführen. Andernfalls wird eine Nachricht angezeigt und der Benutzer muss sie sortieren.

Answer 3

Es hängt ausschließlich vom Design Ihrer Anwendung ab, ob Sie Daten lokal speichern müssen oder nicht, ob es sich um ein echtes Problem handelt oder um einen dünnen GUI-Client um Ihren Web-Service. Abgesehen von dem "Offline" -Modus ist der andere Grund, Serverdaten auf der Client-Seite zwischenzuspeichern, die Verkehrslast von Ihrem Server zu nehmen. Denken Sie nur daran, was es für Ihren Server bedeutet, jedes Mal die gesamten Zeiterfassungsdaten an den Client oder nur die Änderungen zu senden. Ja, es bedeutet mehr Umsetzung auf beiden Seiten, aber in einigen Fällen hat es ernsthafte Vorteile.

EDIT: Beispiel hinzugefügt

Sie haben 1000 Datensätze pro Benutzer in Ihrer Zeiterfassungsanwendung und ein Datensatz ist ca. 1 kByte. In diesem Fall muss jedes Mal, wenn ein Benutzer die Anwendung startet, 1 MB Daten von Ihrem Server abgerufen werden. Wenn Sie die Daten lokal zwischenspeichern, kann der Server Ihnen sagen, dass zwei Datensätze seit dem letzten Update aktualisiert wurden. Sie müssen also nur 2 KByte herunterladen. Jetzt sollten Sie dies für mehrere zehntausend Benutzer skalieren und Sie werden sofort den Unterschied der Serverbandbreite und CPU-Auslastung bemerken.

Answer 4

Es gibt grundsätzlich zwei Arten von Apps. Diejenigen, die Ihnen lokale Funktionalität bieten (Spiele, professionelle Anwendungen, Navigationssysteme ...) und solche, die Zugriff auf einen Remote-Service gewähren.

Ihre Anwendung scheint in der zweiten Kategorie zu sein. Wenn Sie auf Remote-Dienste zugreifen, möchten Ihre Benutzer auf neue oder Echtzeitdaten zugreifen (Sie möchten keine 2 Wochen alten Facebook-Posts lesen), aber in manchen Fällen ist lokales Caching sinnvoll (z. B. das Lesen Ihrer Mails) im Zug mit instabilem Netz).

Ich nehme an, dass der Wert für den Zugriff auf zwischengespeicherte Einträge, wenn sie nicht mit einem Netzwerk verbunden sind, für Ihre Kunden (intern oder extern) relativ gering ist, verglichen mit der Wichtigkeit des Zugriffs auf Echtzeitdaten. Daher ist lokaler Speicher möglicherweise gar nicht notwendig.

Wenn Sie in Ihrem Zeitplan Hunderte von Einträgen, „normal“ Serialisierung (NSCoding-Protokoll) möglicherweise nicht genug. Wenn Sie nur auf einige "Dashboard-Daten" zugreifen, können Sie mit einem einfachen Request/Response-Caching (NSURLCache kann viele Dinge tun ...) auskommen.

Core Data macht mehr Sinn machen, wenn Sie komplexe Datenstrukturen aufweisen, die mit einem Server synchronisiert werden sollen. Dies fügt Ihrem Projekt eine Menge Synchronisierungslogik hinzu sowie die Komplexität der Kerndatenintegration (Nebenläufigkeit, Thread-Sicherheit, In-App-Konflikte ...).

Wenn Sie eine "Client" -App mit einer servergesteuerten Benutzererfahrung erstellen möchten, ist lokaler Speicher überhaupt nicht notwendig, daher ist mein Vorschlag: Behalten Sie es so einfach wie möglich, es sei denn, es besteht Bedarf an Offline-Speicher.