Einstieg Daten (DB) extern/Webserver einlesen/speichern

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

  • Einstieg Daten (DB) extern/Webserver einlesen/speichern

    Guten Abend,

    Ich habe erst mit der iOS Programmierung begonnen, komm eigentlich aus der Webprogrammierungen.

    Meine Frage:
    Wie realisiere ich es, wenn meine Daten von extern kommen sollen z.B. liegen diese in einer MySQL Datenbank, da auch eine Webseite von dieserihre Daten erhält.
    Zwei Varianten, in der App sollen die Daten zum Teil mit sqlLite abgelegt werden, andererseits sollen bestimmte Anfragen immer an den Server gehen und Rückgabe ist meist ein Array bzw. Objekt.

    Soweit ich das gelesen habe, wird empfohlen das ganze mit Jason-Objekten umzusetzen oder?
    Wie stellt man eine Sicherheit her zwischen App und Server, Hash für Verbindung?

    Würde man Anfragen an eine URL also ein PHP Script senden was dann ein Objekt zurückt gibt?

    Wäre Super wenn mir in diesem Gebiet jemand weiterhelfen kann,
    Ich bedanke mich schon mal für die Zeit.

    Edit:
    Nach längeren Surfen hier noch ein paar Themen, allerdings alles etwas älter, daher die Frage ob das noch die gängige Praxis ist oder es schon besser/moderner geht:

    xappsoftware.com/wordpress/201…-a-remote-mysql-database/

    stackoverflow.com/questions/10…ql-records-to-ios-via-php

    stackoverflow.com/questions/50…to-ios-objective-c-sqlite

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von EvilDragon () aus folgendem Grund: Optimierung

  • EvilDragon schrieb:

    Lucas de Vil schrieb:

    Bitte nicht dieselben Fehler machen wie Andere hier. Ein JSON ist noch kein Cocoa Objekt. :)
    Das ist klar, das Jason ist noch in Coca geparst werden oder?

    Offenbar nicht jedem.
    Das Forum ist voll mit Anfragen, wie man denn bitte in dem umgewandelten JSON Array eigene Informationen einbinden kann. -.-

    EvilDragon schrieb:

    Also ist das eine gute Lösung? Gibt es dazu mehr Informationen oder Beispiele?

    Ob das eine gute Lösung ist hängt immer vom Anwendungsfall ab. :)
    Sagen wir einfach, die NSJSONSerialization Klasse ist genau für den von dir beschriebenen Fall gedacht. (ab iOS 5.0)
    Beispiele gibt es viele, beispielsweise direkt von Apple als Sample Code.
    Du solltest aber vorher wirklich wissen, wie du deine Objekte modelliert bekommst.

    Von einer Lösung 'SQLite auf dem Gerät' würde ich absehen bzw. es nicht von Hand machen sondern Core Data nutzen.
    Core Data ist keine Datenbank sondern ein Objektgraph - es wird also ein ganz anderes Handling erwartet als in einer Datenbank.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Lucas de Vil schrieb:

    Von einer Lösung 'SQLite auf dem Gerät' würde ich absehen bzw. es nicht von Hand machen sondern Core Data nutzen.
    Core Data ist keine Datenbank sondern ein Objektgraph - es wird also ein ganz anderes Handling erwartet als in einer Datenbank.


    Das kann ich ganz ehrlich nicht unterstützen. Bei iOS sehe ich keine Vorteile von CoreData gegenüber eine einfachen Sqlite Lösung. Zugegeben ist CoreData mit Bindings in einer dokument based App unter OSX genial und macht richtig Spaß. Aber ohne die Bindings und den ganzen Undo Krempel (Den man in einer App ja so gut wir nie braucht) finde ich verliert er seine Vorteile gegenüber einer einfachn DB komplett.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    Aber ohne die Bindings und den ganzen Undo Krempel (Den man in einer App ja so gut wir nie braucht) finde ich verliert er seine Vorteile gegenüber einer einfachn DB komplett.

    Diese Meinung sei dir gestattet.
    Ich bleibe so naiv zu glauben, dass keine Eigenimplementierung eines SQLite Storage mit der Performance von Core Data mithalten kann.
    Apple hatte mit Release von 10.4 Ende April 2005 bereits erkannt, dass ORM (Object Relational Mapping) die Zukunft ist. Mittlerweile gibt es für jede Programmiersprache Implementierungen eines ORM, weil die Vorteile klar sind.

    Der Hauptvorteil vom ORM gegenüber einer SQLite Datenbank ist schlicht und einfach, dass man fertige Objekte an Stelle von Datenbankeinträgen bekommt.
    Bindings und Undo-Management hin oder her, es gibt nix Geileres, als einfach Methoden zu einem Objekt hinzuzufügen, die dann out-of-the-databox zur Verfügung stehen.

    Statt 'Ich fummel an der Datenbank umher und dann finger ich noch in meinem Objektmodell rum und anschließend spiele ich noch an der Logik des Auslesevorgangs' hast du nur ein 'Ich finger in meinem Objektmodell rum'.

    Wenn du diesen Hauptvorteil, die performanceschonende Implementierung des Lazy Loading sowie die mittlerweile fast siebenjährige Existenz nicht anerkennen möchtest - ich kann, will und werde dich nicht dazu zwingen. :)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Statt 'Ich fummel an der Datenbank umher und dann finger ich noch in meinem Objektmodell rum und anschließend spiele ich noch an der Logik des Auslesevorgangs' hast du nur ein 'Ich finger in meinem Objektmodell rum'.

    das vertehe ich. so mache ich es :)
    es gibt nix Geileres, als einfach Methoden zu einem Objekt hinzuzufügen, die dann out-of-the-databox zur Verfügung stehen.

    Kannst Du dafür ein oder zwei Beispiele aufzeigen?
    Wenn ich ein bool zusätzlich benötige, dann mache ich es wie oben beschrieben. Wie läuft das bei CoreData (noch nicht mit gearbeitet, eigentlich aus genau den Gründen wie von Thallius beschrieben. Wobei die Projekte/Strukturen noch übersichtlich sind und die drei Stellen einmal angefasst werden und fertig. Ist nicht sooo ein Aufwand. )

    Nachtrag: Funktioniert Lazy Loading auch beim Scrollen in einer Tabelle?
  • entwickler schrieb:


    Kannst Du dafür ein oder zwei Beispiele aufzeigen?
    Wenn ich ein bool zusätzlich benötige, dann mache ich es wie oben beschrieben. Wie läuft das bei CoreData (noch nicht mit gearbeitet, eigentlich aus genau den Gründen wie von Thallius beschrieben. Wobei die Projekte/Strukturen noch übersichtlich sind und die drei Stellen einmal angefasst werden und fertig. Ist nicht sooo ein Aufwand. )

    Wenn der BOOL ein zusätzlicher Datentyp/Instanzvariable ist, dann wirst du nicht umhin kommen es im Core Data Modell zu ändern und damit auch die zu Grunde liegende Datenbank zu invalidieren.
    (Zum Glück bietet Core Data die Möglichkeit der automatischen Migration alter Datenbankstände - was je nach Komplexität des Datenmodells auch sehr gut funktioniert.)

    Die Frage ist also, was dein BOOL liefert.
    Beispielsweise könntest du prüfen wollen, ob eine Person Geburtstag hat.
    Statt halt die Daten aus der Datenbank zu holen, auf jedes Geburtsdatum den Check zu machen und das dann zu speichern, baust du einfach eine entsprechende Methode in deine NSManagedObject Subklasse ein.

    C-Quellcode

    1. - (BOOL) hasBirthdayAtDate:(NSDate*)theDate
    2. {
    3. unsigned unitFlags = NSYearCalendarUnit | NSMonthCalendarUnit | NSDayCalendarUnit;
    4. NSDateComponents *differenceDateComps = [[NSCalendar currentCalendar] components:unitFlags fromDate:theDate toDate:[self birthDate] options:0];
    5. return ([differenceDateComps month] == 0 && [differenceDateComps das] == 0);
    6. }


    Egal was die Datenbank hergibt, du fragst einfach nur:

    C-Quellcode

    1. [currentPerson hasBirthdayAtDate:[NSDate date]];

    Auch denkbar wäre die Berechnung des Alters als eine Computed Property im Objektmodell zu machen.

    Gern genommen ist hier auch der Fall der Entfernungsberechnung eines Punktes.

    C-Quellcode

    1. - (CLLocationDistance)distanceFromLocation:(CLLocation*)theLocation
    2. {
    3. return [[self location] distanceFromLocation:theLocation];
    4. }

    C-Quellcode

    1. [myTaxy distanceFromLocation:currentGPSLocation];

    Natürlich ist Core Data mit seinen Managed Objects nur dann wirklich mächtig, wenn man sie vernünftig einzusetzen weiß.
    Mal eben am Datenmodell rumschrauben, weil einem mitten in der Nacht einfällt, dass die Property falsch heißt, ist ne blöde Idee.
    Per valueForKey: auf die als String übergebenen Attribute zugreifen wollen ist ebenfalls nicht im Sinne von Usability und Testability.

    Doch der Aufwand ist sehr gering, um ein stabiles und veränderbares Objektmodell zur Verfügung zu stellen ohne die Datenbankstrukturen ändern zu müssen.
    Mancher mag sagen: "MOMENT! Genau SO mache ich das doch auch!".
    Darauf mag ich dann sagen: "MOMENT! Warum machst du das selbst?".

    Die Eigenimplementierung entspricht dem ORM, Core Data entspricht dem ORM, Core Data ist seit fast 7 Jahren weltweit auf großem und kleinem Gerät im Einsatz.
    Es gibt keinen Grund, ein ORM für Cocoa (touch) selbst zu bauen.

    entwickler schrieb:


    Nachtrag: Funktioniert Lazy Loading auch beim Scrollen in einer Tabelle?

    Lazy Loading funktioniert nur, wenn als Speicheroption SQLite gewählt wurde und Lazy Loading funktioniert in dem Fall immer.
    Deine Frage ist also erst einmal fachlich falsch. ;)

    Lazy Loading bedeutet, dass dein Fetch Request nur die Zeiger auf eine Speicheradresse deines Objektes zurück gibt.
    Erst wenn du eine Methode des Objektes aufrufst, die auf eine Relationship referenziert (-children zum Beispiel), werden diese zur Relationship gehörenden Objekte in den Speicher geladen.
    Beim Aufrufen der Detailansicht wird schließlich der Rest des Objekts entfaltet - allerdings wieder nur der Rest, den du über Nachrichten an das Objekt explizit abfragst.
    (Genau aus diesem Grund halte ich nix von gefühlten 70.000 Fetch Requests: in jeder View 7. Fetch Requests sollen den Grundstock an Objekten bilden [initiale Objekte, ggf. Suchergebnisse], der Rest wird bitte brav weiterhin über Objektzeiger und Properties weitergereicht.)

    Probier doch mal ein bisschen.
    Lad dir den kompletten Bestand deines CoreData Stores rein und gib eine Beschreibung der Objekte darin aus.
    Dann ruf die Relationship des Objektes explizit ab und gib die Beschreibung der Objekte erneut aus.
    Vergleiche dazu auch diesen Artikel der Dokumentation.

    Irgendwann wird Christians Buch zu Core Data erscheinen und dann gehören diese endlosen Monologe hoffentlich der Vergangenheit an. ;)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Auch hier nochmals vielen Dank für deine Ausführungen. Grundsätzlich interessiert mich CoreData schon. Es war für mich immer nur wesentlich komplizierter als über SQLite Daten zu schreiben/lesen. Da ich sehr wenig Zeit habe, blieb ich zunächst immer bei SQLite. Denn ich müßte erst viel Zeit investieren, um dann später Zeit sparen zu können. Aber ich bleibe dran.
    Nachtrag: Funktioniert Lazy Loading auch beim Scrollen in einer Tabelle?
    Da hatte ich naiver Weise folgendes im Kopf: Bei SQLite habe ich meine Abfrage und erhalte die vollständige Liste aller Daten.Der TableviewController kümmert sich um die Anzeige zum richtigen Zeitpunkt. Mein Gedanke war, dass auch hier das „lazy loading“ greifen würde. also immer nur die Daten abrufen, welche gerade/gleich angezeigt werden sollen.
    Per valueForKey: auf die als String übergebenen Attribute zugreifen wollen ist ebenfalls nicht im Sinne von Usability und Testability.
    Diesen Satz verstehe ich nicht.
    Doch der Aufwand ist sehr gering, um ein stabiles und veränderbares Objektmodell zur Verfügung zu stellen ohne die Datenbankstrukturen ändern zu müssen.
    Wie soll das funktionieren? Das geht doch nur, wenn ich kleinere Feldtypen nutzen möchte, als in der Core-Data-Struktur angelegt? Oder verstehe ich Dich da falsch?
    (Genau aus diesem Grund halte ich nix von gefühlten 70.000 Fetch Requests: in jeder View 7. Fetch Requests sollen den Grundstock an Objekten bilden [initiale Objekte, ggf. Suchergebnisse], der Rest wird bitte brav weiterhin über Objektzeiger und Properties weitergereicht.)
    Das verstehe ich ebenfalls nicht. Du meinst (wie Du später schreibst), weil mit CoreData für die Detailansicht nur eine Referenz übergeben wird und erst dann „sich das Objekt entfaltet“? Diese Vorgehensweise mache ich übrigens (und ich hoffe auch alle anderen) mit SQLite. Für die Tabelle nur die ID und alle Daten die für das Anzeigen der Zeile notwendig sind. Für die Detailansicht wird nur eine ID übergeben. und die Detailansicht holt sich dann das vollständige Objekt mit der ID. (wenn am Ende von CoreData eine SQLite liegt, geschieht doch eigentlich nichts anderes.)
    Ebenfalls beim hasBirthdayAtDate Beispiel: Da macht doch CoreData vermutlich nichts anderes, als anhand der ID das Datum zu (lazy loading) holen und zu vergleichen. Was passiert, wenn ich eine Tabelle mit Vorname und dem Bool anzeigen möchte? Wird CoreData sich den Vornamen holen und dann nochmal das Datum über einen zweiten Eingriff? Denn habe ich viele Datensätze, ist es eigentlich unschön, jedesmal nachträglich den Datensatz herauszusuchen und das Datum zu holen. Ahhh. Ok. Lazy Loading. Vermutlich gibt es dann noch ein Zeiger direkt auf den Eintrag, der im Hintergrund gehalten wird um nicht noch einmal den Index zu bemühen. Ok. Habe ich das verstanden?

    Buch: Ich behalte das mal im Auge. Wobei Mai schon hinter dem nächsten Projekt liegt...
    Dazu gleich noch zwei weitere Fragen:

    1. Wenn ich ein SQLite app später auf CoreData umstellen möchte, was habe ich zu beachten, damit es später nicht zu Problemen kommt?

    2. Das muss ich hier aus Unwissenheit fragen: Wenn das Datenmodell komplett mit CoreData umgesetzt wird und CoreData ja auch meine Daten speichert. Was mache ich mit Daten, die sich nur während der Laufzeit innerhalb meines Datenmodels befinden? Also das Auto-Objekt-Beispiel: Klar hat es eine Geschwindigkeit, bzw. der Scheinwerfer kann an oder aus sein. Aber das möchte ich nicht in meinen Datenmodel speichern, also die Information soll schon gespeichert werden, aber nicht physikalisch auf der „Festplatte“. Weil das Auto nur zur Laufzeit existiert (das kann ich ja mit einem NSObjekt und SQLite machen, weil da die Datenmodelle unterschiedlich sein können)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von entwickler ()

  • entwickler schrieb:

    Auch hier nochmals vielen Dank für deine Ausführungen. Grundsätzlich interessiert mich CoreData schon. Es war für mich immer nur wesentlich komplizierter als über SQLite Daten zu schreiben/lesen. Da ich sehr wenig Zeit habe, blieb ich zunächst immer bei SQLite. Denn ich müßte erst viel Zeit investieren, um dann später Zeit sparen zu können. Aber ich bleibe dran.
    Nachtrag: Funktioniert Lazy Loading auch beim Scrollen in einer Tabelle?

    Da hatte ich naiver Weise folgendes im Kopf: Bei SQLite habe ich meine Abfrage und erhalte die vollständige Liste aller Daten.Der TableviewController kümmert sich um die Anzeige zum richtigen Zeitpunkt. Mein Gedanke war, dass auch hier das „lazy loading“ greifen würde. also immer nur die Daten abrufen, welche gerade/gleich angezeigt werden sollen.

    Das ist Aufgabe des TableView Controllers.
    Und glaube mir, bei jeder Abfrage eines Objektes zur Darstellung als Zelle erst mal die Informationen an dem Index aus der Datenbank ziehen und sie dann wieder wegzuwerfen ist nicht performant.
    Allein beim Scrollen fliegt dir dann vermutlich alles um die Ohren.
    Nein, er lädt immer die komplette abgefragte Liste an Objekten - jedoch nicht seine Referenzen.

    entwickler schrieb:

    Per valueForKey: auf die als String übergebenen Attribute zugreifen wollen ist ebenfalls nicht im Sinne von Usability und Testability.
    Diesen Satz verstehe ich nicht.

    Dir wird ziemlich schnell auffallen, dass -valueForKey: schwer zu debuggen ist.
    Ohne eigene Subklasse greift man auf die Inhalte normalerweise per

    C-Quellcode

    1. [managedObject valueForKey:@"name"];
    zu.
    Fehler in Groß- und Kleinschreibung, falsche Buchstaben etc.pp. werden vom Compiler nicht angemahnt sondern führen zu Laufzeitfehlern. Man sollte sich also im Vorfeld überlegen, wie man das Ganze einfach und stabil definiert bekommt.
    Beispielsweise durch eigene Getter.

    C-Quellcode

    1. - (NSString*) name
    2. {
    3. // Hier stumpf 'name' aufzurufen führt zu einem lustigen Absturz dank Endlosschleife. ;)
    4. return [self valueForKey:@"cdName"];
    5. }


    Wenn dir jetzt auffällt 'Oh, das ist gar nicht name sondern title...' änderst du den Getter und lässt das Datenfeld im Storage so wie es ist.

    Hinzu kommt, dass ein durch das Objektmodell zur Verfügung gestelltes 'addChild:' netter (a.k.a. weniger fehleranfällig) ist als den ganzen Kram in deiner App an allen notwendigen Stellen selbst zu coden.

    entwickler schrieb:

    Doch der Aufwand ist sehr gering, um ein stabiles und veränderbares Objektmodell zur Verfügung zu stellen ohne die Datenbankstrukturen ändern zu müssen.
    Wie soll das funktionieren? Das geht doch nur, wenn ich kleinere Feldtypen nutzen möchte, als in der Core-Data-Struktur angelegt? Oder verstehe ich Dich da falsch?

    Ja, du verstehst mich da falsch.
    Siehe Beispiel oben. ;)

    entwickler schrieb:

    (Genau aus diesem Grund halte ich nix von gefühlten 70.000 Fetch Requests: in jeder View 7. Fetch Requests sollen den Grundstock an Objekten bilden [initiale Objekte, ggf. Suchergebnisse], der Rest wird bitte brav weiterhin über Objektzeiger und Properties weitergereicht.)
    Das verstehe ich ebenfalls nicht. Du meinst (wie Du später schreibst), weil mit CoreData für die Detailansicht nur eine Referenz übergeben wird und erst dann „sich das Objekt entfaltet“? Diese Vorgehensweise mache ich übrigens (und ich hoffe auch alle anderen) mit SQLite. Für die Tabelle nur die ID und alle Daten die für das Anzeigen der Zeile notwendig sind. Für die Detailansicht wird nur eine ID übergeben. und die Detailansicht holt sich dann das vollständige Objekt mit der ID. (wenn am Ende von CoreData eine SQLite liegt, geschieht doch eigentlich nichts anderes.)
    Ebenfalls beim hasBirthdayAtDate Beispiel: Da macht doch CoreData vermutlich nichts anderes, als anhand der ID das Datum zu (lazy loading) holen und zu vergleichen. Was passiert, wenn ich eine Tabelle mit Vorname und dem Bool anzeigen möchte? Wird CoreData sich den Vornamen holen und dann nochmal das Datum über einen zweiten Eingriff? Denn habe ich viele Datensätze, ist es eigentlich unschön, jedesmal nachträglich den Datensatz herauszusuchen und das Datum zu holen. Ahhh. Ok. Lazy Loading. Vermutlich gibt es dann noch ein Zeiger direkt auf den Eintrag, der im Hintergrund gehalten wird um nicht noch einmal den Index zu bemühen. Ok. Habe ich das verstanden?

    First things first: DU hast keine ID, DU nutzt keine ID. IDs sind Datenbank, du hast Objekte. Also arbeitest du nur und ausschließlich mit Referenzen, Zeigern.
    Du selbst holst im Idealfall genau ein mal Daten aus dem Core Data Store. (Zumindest nach meinem Dafürhalten.)
    Lazy Loading bezieht sich auf die Relations, du hast das komplette Objekt geladen. Nur seine Relations noch nicht, die liegen im 'Faulted'-Zustand vor.
    Dein Objekt kennt also zum Zeitpunkt nach dem Laden schon seinen Namen und sein Datum. Nur seine children kennt es noch nicht.

    Der subjektiv meiste Workload passiert bei Core Data im SQL Storage nur beim FetchRequest.

    Auch bei dem hasBirthday Vergleich macht Core Data überhaupt nichts. Weder im SQL Storage noch sonstwo.
    Das macht alles das Objekt selbst.
    Sie geschrieben: seine Membervariablen stehen ihm von Anfang an zur Verfügung. Nur seine Referenzen (Collections) werden bei Bedarf geladen.

    entwickler schrieb:

    Buch: Ich behalte das mal im Auge. Wobei Mai schon hinter dem nächsten Projekt liegt...
    Dazu gleich noch zwei weitere Fragen:

    1. Wenn ich ein SQLite app später auf CoreData umstellen möchte, was habe ich zu beachten, damit es später nicht zu Problemen kommt?

    Nur, dass du dich selbst um die Datenmigration kümmern musst. Die Datenbanken sollten natürlich auch nicht den gleichen Namen haben. ;)


    entwickler schrieb:

    2. Das muss ich hier aus Unwissenheit fragen: Wenn das Datenmodell komplett mit CoreData umgesetzt wird und CoreData ja auch meine Daten speichert. Was mache ich mit Daten, die sich nur während der Laufzeit innerhalb meines Datenmodels befinden? Also das Auto-Objekt-Beispiel: Klar hat es eine Geschwindigkeit, bzw. der Scheinwerfer kann an oder aus sein. Aber das möchte ich nicht in meinen Datenmodel speichern, also die Information soll schon gespeichert werden, aber nicht physikalisch auf der „Festplatte“. Weil das Auto nur zur Laufzeit existiert (das kann ich ja mit einem NSObjekt und SQLite machen, weil da die Datenmodelle unterschiedlich sein können)

    Ich verstehe deine Frage nicht. Wozu willst du einem Objekt Instanzvariablen geben, die es nicht speichern soll?
    Wenn du Daten nicht speichern möchtest, dann lege sie halt nicht als Instanzvariablen an.

    Wie dem auch sei, wenn du eine eigene Subklasse hast, dann kannst du der auch zusätzlich zu den Instanzvariablen von Core Data eigene Instanzvariablen zuschustern.
    Persistiert wird nur das, was im CoreData Modell steht, nicht das, was in der Implementierung der Subklasse steht.

    Abschließend:

    entwickler schrieb:

    Diese Vorgehensweise mache ich übrigens (und ich hoffe auch alle anderen) mit SQLite. Für die Tabelle nur die ID und alle Daten die für das Anzeigen der Zeile notwendig sind.

    Warum nicht vorhandene und gut getestete Frameworks nutzen? ;)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Ich verstehe deine Frage nicht. Wozu willst du einem Objekt Instanzvariablen geben, die es nicht speichern soll?
    Ich habe zum Beispiel eine Liste in der Datenbank mit „physikalischen Schaltern“ <- Also Schalter, die in der Realität ihre Zustände ändern. Der Zustand der Schalter (kann sich alle paar Sekunden ändern) wird aber nicht gespeichert, sondern immer nur zur Laufzeit erfasst.
    Ja. Ich könnte ein Feld dafür vorsehen, aber das wäre immer auf false, weil ich die Liste nur beim Starten der app lade und auch beim Beenden werden die Zustände wieder „verworfen“. Denn im Moment des Speicherns könnte die sich schon wieder geändert haben.
    Wenn du Daten nicht speichern möchtest, dann lege sie halt nicht als Instanzvariablen an.
    Aber die gehören ja „trotzdem“ zum Model. Wie würdest Du die denn „verwalten“?
    Ich: Diese Vorgehensweise mache ich übrigens (und ich hoffe auch alle anderen) mit SQLite. Für die Tabelle nur die ID und alle Daten die für das Anzeigen der Zeile notwendig sind.
    sorry. Das in den Klammern ist verrutscht. ich meinte damit, dass alle anderen ja wohl auch hoffentlich nicht ALLE Daten auslesen und dann immer als NSDictionary/NSArray weiterreichen.
    Warum nicht vorhandene und gut getestete Frameworks nutzen? ;)
    Nicht lachen/ärgern. Du meinst jetzt CoreData? Nachtrag: ich gehe davon aus: ja.
    Du selbst holst im Idealfall genau ein mal Daten aus dem Core Data Store. (Zumindest nach meinem Dafürhalten.)
    Das hingegen, habe ich (glaube ich) verstanden. Das einmalige holen im Idealfall bezieht sich auf eine hierarchische Struktur mit einem „Root-Knoten“. Wobei ja auch mehrere Roots nebeneinander ohne Relationen existieren können (nicht Idealfall)
  • entwickler schrieb:

    Ich verstehe deine Frage nicht. Wozu willst du einem Objekt Instanzvariablen geben, die es nicht speichern soll?
    Ich habe zum Beispiel eine Liste in der Datenbank mit „physikalischen Schaltern“ <- Also Schalter, die in der Realität ihre Zustände ändern. Der Zustand der Schalter (kann sich alle paar Sekunden ändern) wird aber nicht gespeichert, sondern immer nur zur Laufzeit erfasst.
    Ja. Ich könnte ein Feld dafür vorsehen, aber das wäre immer auf false, weil ich die Liste nur beim Starten der app lade und auch beim Beenden werden die Zustände wieder „verworfen“. Denn im Moment des Speicherns könnte die sich schon wieder geändert haben.
    Wenn du Daten nicht speichern möchtest, dann lege sie halt nicht als Instanzvariablen an.
    Aber die gehören ja „trotzdem“ zum Model. Wie würdest Du die denn „verwalten“?

    Du kannst den Entities auch transiente Attribute verpassen. Die werden dann nicht im Persistent Store gespeichert.

    Michael
  • Um hier auch noch meinen Senf als CoreData-Verfechter dazuzugeben: Auf jeden Fall benutzen!11einself11!!
    Für so Sachen wie die Darstellung der Daten in tableviews gibt es ja den NSFetchedResultsController, der lädt ebenfalls immer nur das, was gerade dargestellt wird und benachrichtigt bei Änderungen am store.

    Zur Performance: es ist auch mit CoreData möglich, nur bestimmte properties einer Entität zu fetchen. Das schöne ist, dass das fetching abstrahiert ist (mit NSFetchRequest und o.g. NSFetchedResultsController). Es kann also durchaus sein, dass der NSFetchedResultsController intelligent genug ist, wie die Zugriffsmuster auf das Modell sind, die fetches darauf optimiert, die abgefragten Daten cacht etc. etc. Um all dies musst Du Dir aber keine Gedanken machen - Du profitierst von der low-level Arbeit der Experten bei Apple (und die können auf einer viel tieferen Ebene optimieren als der Anwendungsentwickler).

    Es ist sehr unwahrscheinlich, dass man sowas mit einer selbstgestrickten Lösung ähnlich performant, leicht wiederverwendbar und gut getestet hinbekommt. Wenn Apple dann irgendwann zig tolle neue Features dazufügt, profitierst Du ganz automatisch davon. Hat Lucas ja alles schon geschrieben, aber ich finde, man kann das garnicht genug betonen.

    Zum Argument Core Data eigne sich nur für grosse Projekte oder den Mac: kann ich nur widersprechen! Ganz egal ob iOS, Mac, grosses Datenmodell oder nur ein ganz kleines - m.M.n. sparst Du damit immer Zeit und Nerven.
  • Markus Müller schrieb:

    Zum Argument Core Data eigne sich nur für grosse Projekte oder den Mac: kann ich nur widersprechen! Ganz egal ob iOS, Mac, grosses Datenmodell oder nur ein ganz kleines - m.M.n. sparst Du damit immer Zeit und Nerven.


    Naja ich weiß nicht. Wenn ich meine ersten Apps schreibe und ich bekomme die Daten von einer SQL DB und habe (was eben sehr wahrscheinlich ist) schon Erfahrung in SQL, dann ist es wesentlich einfacher und schneller die Lösung auch mit SQLite aufzubauen als sich erst in CoreData einzuarbeiten. Ich habe mich in meinem OSX Projekt jetzt in CoreData reingebissen und nach nunmehr 3 Monaten finde ich immer noch Dinge die ich nicht so richtig verstehe und einfach so hinnehme als "Von Apple gegeben". Das ist eigentlich nicht mein Stil. Ich mag es zu wissen was in meiner Software abgeht.

    Weiterhin sollte man auch nicht vergessen, dass man mit CoreData seine Exchangeability komplett auf den Mac begrenzt. Mit einer SQlite DB bist du wesentlich flexibler was den Austausch und Einsatz auf anderen Plattformen angeht.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

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