Das geht mit NSPropertyListSerialization und dem Format NSPropertyListBinaryFormat_v1_0

+öhm+ Das ist doch aber auch dasselbe, was NSKeyedArchiver bastelt.

Da ich fast ausschließlich mit binären PLists arbeite (weil NSKeyedArchiver die eh automatisch bereitstellt), kann ich dir auch nicht genau sagen, warum Apple das empfiehlt.
Ich weiß nur, dass vor dem binären Serialisieren erst einmal alle doppelt bis xfach vorhandenen Objekte zu einer Referenz umgebaut und entsprechend referenziert werden.

Apple hatte irgendwo in den Tiefen seiner Core Foundation Lite eine plist.c, die aus einer PList im XML-Format eine binäre PList erstellt hat und vice versa.
Stelle gerade fest: seit 10.4 gibt es plutil - das macht ungefähr dasselbe, unterstützt zusätzlich aber noch JSON.

Du kannst ja mal ein und dasselbe Objekt (idealerweise mit vielen unterschiedlichen und vielen identischen Unterobjekten) einmal als XML-Plist und einmal als binäre PList abspeichern.
Dann jeweils hin- und her konvertieren und vergleichen.

Gern darfst du uns die Vergleichsergebnisse mitteilen, ich für meinen Teil bin jedenfalls neugierig.

Die Frage ist doch nicht wie man die plist speichert sondern viel mehr wie man sie ausließt.

Wenn ich für jeden Wert die plist neu lade und parse mache ich wohl irgendwas falsch. Wenn ich sie nur einmal lade ist es wurscht ob das 1ms oder 10ms dauert

Gruß

Claus

Und wenn du jetzt noch einen halben Meter weiter denkst fällt dir auf, dass dass Erstellen von 17 Dictionaries mit jeweils drei Keys @"Oans", @"Zwoa", @"Zwuenf" und jeweils drei Objekten [NSNumber numberWithInt:9]; nicht nur wesentlich länger dauert sondern auch wesentlich mehr Speicher verbraucht, als das Erstellen und 17fache Referenzieren eines Dictionarys mit jeweils einer Referenz auf die drei Keys @"Oans", @"Zwoa" und @"Zwuenf" mit jeweils einer Referenz auf [NSNumber numberWithInt:9].

Aber vermutlich mache ich mir viel zu viele Sorgen um den viel zu knappen Speicher auf diesen Mobilgeräten.
(Es ist meine Vermutung, dass die XML-PropertyLists diese Referenzierungen nicht auflösen und entsprechend permanent neue Objekte anlegen - kein fundiertes Hintergrundwissen!)

+öhm+ Das ist doch aber auch dasselbe, was NSKeyedArchiver bastelt.

Das ist so nicht ganz richtig. In eine Plist kann man nur NSData, NSString, NSArray, NSDictionary, NSDate und NSNumber Objekte reinpacken. Ein NSKeyedArchiver hingegen packt alles ein, was NSCoding-konform ist. Zwar erzeugt der Archiver ebenfalls eine binäre Plist, aber die ist vollkommen anders strukturiert als eine Plist von z.B. NSPropertyListSerialization.

Das ist ja wohl relativ logisch

Gruß

Claus

DroneDeveloper
Bitte erstelle doch mal aus der binären PList eine XML und erzähl mal, wie sie sich unterscheiden!

plutil -convert xml1 binary.plist

In einer XML-Datei wird z.B. ein Integer-Wert als "<integer>1</integer>" Zeichenkette abgelegt. Das wird in einer binären Plist wesentlich platzsparender gemacht. Den Unterschied sieht man, wenn man so ein Plist-File mal mit TextEdit öffnet.

Schön, dass der Finder das alles haargenau in XML umbaut, bevor er das anzeigt - das macht einem die Hälfte der Erfolgserlebnisse wieder wett.
Anyways, die von mir erhoffte 'Einsparung' an Ressourcen gibt es offenbar nur mit NSCoding. Dafür ist die Datei (egal welches Format) 5x so groß wie bei der Property List Serialisation.



Wer möchte, kann sich die Unterschiede in den Vorgängen ja mal ansehen.

Es ist jetzt aber nach wie vor wirklich spannend, ob beim Entfrickeln der Serialisationsvariante 42x [NSNumber numberWithInt:42]; erstellt wird oder nicht.
Wer möchte kann ja mal testen. Bitte um Info.

PS: Das (vermutlich NDA) Apple Dokument spricht eindeutig von NSCoding, also NSKeyedArchiver und nicht von NSPropertySerialisation. Vermutlich aus dem von mir vermuteten Grund.