CoreData in-Memory iOS

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

  • CoreData in-Memory iOS

    Guten Tag,

    nach einiger Google recherche aus der ich nicht schlau geworden bin, wende ich mich mal an diese Stelle.

    Ich habe ein kleines iOS Projekt in welchem ich ein geparstes JSON File von einem WebService in, so hab ich mir das zumindest gedacht, CoreData verwurschteln will. Diese Daten sollen nicht Persistent gespeichert werden, da Sie von einem Login abhängen, ich will CoreData quasi nur als DatenModell für eine Sitzung benutzen.

    Nun meine Fragen:

    - Ist eine in-Memory variante eines CoreData Modells für mich sinnvoll ? bekomm ich da evtl. Probleme mit dem Memory Management ?

    - Wird diese in-Memory Variante auch auf dem Dateisystem gespeichert welche nach beenden des Programms verschwindet, oder wie kann ich mir das Vorstellen?

    - Wie setzt man so eine in-Memory Variante um ?

    - Anregungen wie man es besser machen könnte ? good-ol-NSArray als Rückgabe aus meiner Parsing Methode ?


    Vielen Dank!
  • Danke Claus! klar, is am einfachsten.

    Ich dachte daran CoreData zu benutzen da die daten aus dem JSON je nach Benutzer recht komplexe und verworrene strukturen annehmen können und diese Struktur sich auch je nach Rolle verändert.

    Um sich hinterher das Leben leichter zu machen auch nicht ? Bin ich mit CoreData in ner Sackgasse ?

    Gruß Kai
  • Danke für die Antworten.

    gekauft! Ich denk ich werd den Ansatz mit den Wrapper Klassen nehmen.

    Jetzt aber noch Verständnisfragen zu CoreData, dann bin ich ruhig:

    - Ist CoreData überhaupt sinnvoll wenn man nicht persistent speichert ?
    - Wo wird die inMemory Variante denn jetzt gespeichert ? nur im Arbeitsspeicher oder im Dateisystem?
  • 1) Nope. Du könntest zwar jedes Attribut als 'nicht speichern' kennzeichnen, aber das ist Humbug. Hat aber nichts mit dem Memory Management zu tun.
    Das ist ungefähr wie 'Ich pack mir einen fetten 560PS 12l V10 Motor in meine Viper, fahre aber mit nem 25PS 0.5l Erdgasmotor wegen der Umwelt.'

    2) Nope. Core Data würde immer speichern und nie was wegwerfen. Weil es von Core Data keine 'In-Memory' Variante gibt.

    3) Mit Core Data gar nicht. Weil wegen siehe unten.

    4) Klar. Siehe auch unten.

    Erst einmal Glückwunsch, du hast offenbar verstanden, dass Core Data keine Datenbank ist.
    Schade, dass du noch nicht verstanden hast, was Core Data ist.

    Eigentlich sind Core Data Objekte ganz normale Objekte, so wie jedes andere Objekt auch.
    Core Data kümmert sich nur darum, dass diese Objekte persistiert, also gespeichert und geladen werden können.
    Core Data ohne Persistenz = stinknormale Objekte. Stinknormale Objekte mit Persistenz = Core Data. Core Data mit Persistenz = Core Data. Stinknormale Objekte ohne Persistenz = stinknormale Objekte.
    NSManagedObject ohne Managed = NSObject. NSObject mit Managed = NSManagedObject. NSManagedObject mit Managed = NSManagedObject. NSObject ohne Managed = NSObject.
    Roter Onyx = Karneol. Schwarzer Karneol = Onyx. Schwarzer Onyx = Onyx. Roter Karneol = Karneol.
    Und so weiter.

    Ich wette, du möchtest einfach die simpel zusammengestrickten Modelle aus dem Modelleditor übernehmen.
    Mach doch. Ändere einfach in den Headerdateien 'NSManagedObject' in 'NSObject'. Dann tippst du noch schnell die @synthesize anstelle der @dynamic und fertig.

    Ergo: Bau die erwarteten Strukturen deines JSON einfach mit stinknormalen Objekten zusammen.
    Ob du das jetzt im Editor machst und es dann änderst oder direkt 'from scratch' selbst tippst macht erst einmal keinen Unterschied.
    Doch braucht ein Programm, dass kein Core Data nutzt, auch nicht das Core Data Framework linken. Das wäre ja übertrieben.

    // Nachtrag:
    NSObject und Derivate bleiben nur im Speicher und fliegen nach Beendigung der App wieder raus, sofern du sie nicht anderweitig selbst persistiert hast.
    Ohne dein Zutun landet nix im Dateisystem.
    «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:

    1) Nope. Du könntest zwar jedes Attribut als 'nicht speichern' kennzeichnen, aber das ist Humbug.

    Solchen Humbug muss man auch gar nicht machen, um eine in-Memory Variante von Core Data zu erhalten.

    Lucas de Vil schrieb:

    2) Nope. Core Data würde immer speichern und nie was wegwerfen. Weil es von Core Data keine 'In-Memory' Variante gibt.

    Doch die gibt es!

    Lucas de Vil schrieb:

    3) Mit Core Data gar nicht.

    Doch, geht auch mit Core Data. Einfach für den Core Data Stack einen NSPersistentStore vom Typ NSInMemoryStoreType verwenden.

    Lucas de Vil schrieb:

    Core Data kümmert sich nur darum, dass diese Objekte persistiert, also gespeichert und geladen werden können.

    Och, Core Data kann schon ein wenig mehr, wie zum Beispiel Validation und Undo Management.

    Lucas de Vil schrieb:

    // Nachtrag:
    NSObject und Derivate bleiben nur im Speicher und fliegen nach Beendigung der App wieder raus, sofern du sie nicht anderweitig selbst persistiert hast.
    Ohne dein Zutun landet nix im Dateisystem.

    Das gilt für einen NSPersistentStore vom Typ NSInMemoryStoreType genauso.

    Michael