persistente Speicherung

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

  • persistente Speicherung

    Abend,

    ich fange gerade an die Dokumentation von Apple für NSArray zu lesen.
    Ich möchte ein NSArray in eine File speichern und anschließend irgendwo wieder lesen.
    Ich bin auf die Methoden "writeToFile" und "arrayWithContentsOfFile" gestoßen.

    Meine Ambition ist es, ein NSarray persistent in eine File abzulegen. Diese sollen auch nach Beendigung der App zur Verfügung stehen.
    Sind diese Methoden dafür geeignet?

    Gruß
    lernen, lernen, lernen :)
  • Funktioniert alles wunderschön.

    Was ist aber an diesen Daten unschön, dass er mir es nicht in die File schreiben will?

    Quellcode

    1. Auszug aus dem erstellten NSArray / NSDictionary
    2. ({
    3. ACTIVE = 1;
    4. CONTENT = test;
    5. "DISPLAY_POSITION" = singlePage;
    6. EMAILS = "<null>";
    7. "END_DATE" = "2012-12-07";
    8. "MESSAGE_ID" = 175;
    9. ResendMails = "<null>";
    10. "START_DATE" = "2011-11-30";
    11. STRUCTURES = "<null>";
    12. TITLE = test;
    13. Type = TextMessage;
    14. "USER_NAME" = "<null>";
    15. },
    16. {
    17. ACTIVE = 1;
    18. "DISPLAY_POSITION" = fullPage;
    19. EMAILS = "<null>";
    20. "END_DATE" = "2012-10-26";
    21. "IMAGE_PATH" = "http://www2.hs-augsburg.de/infoterm-fki-test/Content/174_Tulips.jpg";
    22. "MESSAGE_ID" = 174;
    23. ResendMails = "<null>";
    24. "START_DATE" = "2011-10-19";
    25. STRUCTURES = "<null>";
    26. TITLE = "bildtest v1";
    27. Type = ImageMessage;
    28. "USER_NAME" = "<null>";
    29. }
    30. )
    Alles anzeigen


    0815 Arrays schreibt er mir schön rein. Ich kann darauf auch schön ein Read machen.

    laut Apple

    ...If the array’s contents are all property list objects (NSString, NSData, NSArray, or NSDictionary objects), the file written by this method can be used to initialize a new array with the class method arrayWithContentsOfFile: ...

    Ist das soweit doch ok?!

    Aber ich tippe auf das "End_date", "start_date" und "message_id" ... habe ich Recht? Die will er nicht.
    lernen, lernen, lernen :)
  • Mh. Also ich habe gerade das selbe Problem gehabt.
    Ich habe ein Array mit x Instanzen von meiner Subclass von NSObject.
    Wie du schon in der Doku gelesen hast, kann writeToFile kein NSObject.

    Ich musste in meiner NSObject-Subclass (Welche 5 String-Attribute hat) das NSCOding-Protokoll machen

    Und dann aus dem Array ein NSData machen, denn kann man dann mit writeToFile schreiben.

    PS:

    NSData* newData = [NSKeyedArchiver archiveWithRootObject:arry];
    NSArray* newArray = [NSKeyedUnarchiver unarchiveData:data ]; (Bin mir hier nicht genau sicher, wie der vollständige name ist)

    Und das NSData kannst du entweder mit NSUserDefalults speichern (Was im ende auch nur eine Plist ist) oder mit writeToFile in eine Plist
    Gruß

    Robin
  • Amin Negm-Awad schrieb:

    1. Instanzen beliebiger Klassen (Läuft über NSCoding)
    2. Ganze Objektgraphen
    3. Volle Dokumentenunterstützung
    4. Undoing
    5. …

    Ein fertiges und seit Jahren bestehendes Framework ist garantiert ausgereifter, stabiler, performanter und besser getestet als jede eigene Bastellösung.
    Ach ja, der Oberhammer kommt ja erst noch: das Archiv ist eine Property List. Ja, eine Property List. Meist eine binäre Property List, doch immerhin eine Property List. Man kann diese, wenn man möchte, sogar in eine XML-Property List umwandeln.
    Geil, wa?
    (Ich LIEBE die Keyed(Un)Archiver. Stockholm Syndrom oder sowas.)

    Und das NSCoding Protokoll ist ganz flink implementiert.
    Man darf nur nicht vergessen es anzupassen, wenn man etwas am Modell geändert hat. ;)
    «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
  • moin,
    danke für den hinweis auf archive, die fielen mir bis jetzt noch
    nicht auf. bin immer wieder überrascht, was in cocoa alles vorhanden
    ist :)

    mir fällt auf, dass hier niemand core data ins spiel bringt. also ich
    finde das handling super einfach und gut ..

    vg
    thorsten
  • thorb65 schrieb:

    moin,
    danke für den hinweis auf archive, die fielen mir bis jetzt noch
    nicht auf. bin immer wieder überrascht, was in cocoa alles vorhanden
    ist :)

    mir fällt auf, dass hier niemand core data ins spiel bringt. also ich
    finde das handling super einfach und gut ..

    vg
    thorsten

    Core Data behandelt Dokumente.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?
  • ähm, wieso doukmente?

    mit core data lassen sich beliebige objekte persistent ablegen. und das sehr
    einfach mit guten suchfunktionen zum späteren wieder auffinden. läßt
    man sich core data gleich bei erzeugen des projekts mit anlegen kostet das
    fast keinen aufwand und man hat einen klasse store out of the box.
    lohnt sich aus meiner sicht immer, wenn ich daten über das progende
    hínaus ablegen will. auch für kleine bzw mini projekte.

    vg
    thorsten
  • Weil die Daten geladen und gespeichert werden und nicht wie bei einer Client-Server-Architektur behandelt ewrden. Letztlich ist ein Store nchts anderes als eine Textdatei, eine Datei einer Tabellenkalkulation, eine BIlddatei … und etwas komplett anderes als ein Dienst.

    Ich hatte nicht NSDocument oder NSPersistentDocument, sondern Dokumente gesagt.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?
  • das sind doch zwei paar schuhe. auf der einen seite ist das persistente ablegen von
    objekten, und das andere die bereitstellung von informationen. gerade im mvc
    läßt sich das super abbilden. derjenige der die infos bereitstellt, muss überhaupt
    nicht wissen, wie die informationen gespeichert werden, nur wo er sie herbekommt.
    und das modell muss nix von der weiterverarbeitung wissen, nur wie er die
    objekte auszuliefern hat.

    klar, wenn du so willst ist der store natürlich eine datei. wenn auch in binärformat
    und somit eigentlich nicht als dokument zu betrachten, die teilweise ganz andere
    eigenschaften haben. der store ist nix anderes als die datenbank, standardmäßig sqllite,
    in der die serialisierten objekte, oder genau genommen die entitäten und ihre relationen,
    abgelegt werden.

    ich denke, da kommen wir nicht auf einen nenner.

    vg
    thorsten

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

  • Ist ja eal, ob wir auf einen Nenner kommen.

    Ein Store gehört demjenigen, der ihn öffnet. Er wird als Ganzes geöfnet. An einen Diens sendest du eine partielle Anfrage, ein Dokument lädst du als Ganzes. (Ob das tatsächlich geschieht, ist dabei gleichgültig. Es geht um die Ansprache mittels API.) In einem Dienst musst du Relationen auflösen, in einem Dokument hast du sie …

    Eine Datenbank (rDBMS) funktioniert komplett anders als ein Dokument. Core Data funktioniert wie ein Dokument. Sieht übrigens auch Apple so. Ausdrücklich.

    Mit dem verwendeten Format hat das übrigens nichts zu tun. Die ist für den Nutzer transparent.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?
  • wie gesagt: ich sehe das anders. coredata hat nix mit dokumenten zu tun.
    sollte apple das an irgendeiner stelle schreiben, was ich bezweifel, wäre ich dankbar
    für ein quellenverweis. ich hab gelesen, dass apple die managed objects mit einem
    dictionary vergleicht(einleitung zu core data), dass wars dann aber auch schon.

    auch
    funktioniert wie ein Dokument
    wäre erklärungsbedürftig. und
    sqllite ist eine mini - rdbms(danke für die aufklärung des begriffs, war mit völlig neu).

    core data funktioniert im kern sehr ähnlich zu bisher bekannten objektorientierten
    datenbanken (odbms) wie zum beispiel ObjectStore, mit dem ich schon vor 10
    jahren gewerbl. anwendungen baute. auch objectstore serialisiert die objekte
    und speichert sie dann binär im eigenen format. dass core data zum persistieren
    ne rdbms nutzt, ist gut gelöst.

    vg
    thorsten