Xml-Serialisierungsbibliothek für iPhone-Apps

Question

Apple stellt NSArchiver und NSUnachriver für die Serialisierung/Deserialisierung von Objekten zur Verfügung, kann jedoch kein benutzerdefiniertes XML-Schema verarbeiten. Daher muss eine Objektstruktur manuell mit den Daten eines benutzerdefinierten XML-Schemas gefüllt werden. Da die iPhone-Entwicklergemeinde schnell wächst, sind viele Neuling-Programmierer verzweifelt, mit den verfügbaren XML-Parsing-Möglichkeiten umzugehen.

Das iPhone SDK bietet nur NSXmlParser für XML-Parsing, was nützlicher ist, bestimmte Teile einer XML-Datei zu lesen, als eine ganze Objektstruktur zu füllen, was wirklich ein Schmerz ist. Die andere Möglichkeit ist die berühmte libxml-Bibliothek, die in ANSI C geschrieben ist - nicht einfach für jemanden zu benutzen, der mit objective-c programmiert und niemals richtiges C gelernt hat. Event gibt es viele Wrapper verfügbar, Umgang mit XML kann ein Schmerz für Anfänger sein.

Und hier findet meine Idee statt. Eine XmlSerializer-Bibliothek, die automatisch eine Objektstruktur ausfüllt, könnte es für viele Programmierer viel einfacher machen und die App-Qualität erhöhen. Meine Idee soll wie folgt funktionieren:

Die XML-Datei

<Test name="Michael" uid="28"> 
    <Adress street="AlphaBetaGammastrasse 1" city="Zürich" postCode="8000" /> 

    <Hobbies> 
    <Hobby describtion="blabla"/> 
    <Hobby describtion="blupblup"/> 
    </Hobbies> 
</Test> 

Die Klassen

@interface Test : NSObject { 
    NSString *name; 
    Adress *adress; 
    NSArray *hobbies; 
    int uid; 
} 
@property (nonatomic, copy) NSString *name; 
@property (nonatomic, retain) Adress *adress; 
@property (nonatomic, retain) NSArray *hobbies; 
@property (nonatomic, readwrite) int uid; 
@end 

@interface Adress : NSObject { 
    NSString *street; 
    NSString *city; 
    int postCode; 
} 
@property (nonatomic, copy) NSString *street; 
@property (nonatomic, copy) NSString *city; 
@property (nonatomic, readwrite) int postCode; 
@end 

wie der XML-Serializer funktionieren soll

NSError *error = nil; 
XMLSerializer *serializer = [[XMLSerializer alloc] init]; 
NSData *data = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"TestFile" ofType:@"xml"]]; 
Test *test = [serializer deserializeWithData:data error:&error]; 

füllen

Um die Objektstruktur muss nur eine Zeile Code zu füllen:

Test *test = [serializer deserializeWithData:data error:&error]; 

Dies wäre so einfach zu bedienen, dass jeder Neuling Programmierer könnte es benutzen. Für eine erweiterte Nutzung könnte der Serializer konfigurierbar sein.

Was denken Sie, wäre dies eine hilfreiche und beliebte Bibliothek für iPhone und OSX-Anwendungen?

Bearbeiten: Sie können das Projekt here sehen, aber es ist fern von Release.

Answer 1

Das ist eine ziemlich gute Idee, ich würde es implementieren, indem ich NSXMLArchiver und NSXMLUnarchiver als Unterklassen von NSCoder implementiere. Auf diese Weise könnte jede Klasse, die dem NSCoding-Protokoll entspricht, leicht zu und von XML serialisiert werden.

Ein Performance-Hit bei der Serialisierung nach XML sind die primitiven Werte als Attribute, da Sie nicht garantieren können, dass ein Objekt Daten anfordert, die codiert werden sollen. Also, wenn Attribute das sind, was Sie wollen, dann wird es ziemlich groß in Speicherpuffern sein. Aber es wäre eine lustige Übung.

Wie für wie beliebt wäre es? Nicht so beliebt, denke ich. Der Anwendungsfall ist einfach zu klein.

Gerät-zu-Gerät - Die einfache Verwendung von NSKeyedArchiver ist viel einfacher und viel kompakter.

Device-to-new-Server - Der neue Server müsste das gleiche Schema implementieren, serialisieren zu Java, C# oder was auch immer.

Device-to-Existing-Server - Das XML-Format ist bereits festgelegt und wahrscheinlich nicht in der Nähe.

Answer 2

Was Sie beschreiben, ist innerhalb der ObjectiveResourceimplementations begraben, und es unterstützt sowohl JSON und XML. Es sollte ziemlich einfach sein, das zu forchen und es auf das Parsing zu reduzieren, indem man das gesamte Verbindungsmanagement wegwirft.

Answer 3

Der NSKeyedArchiver funktioniert genau, weil er nicht versucht, ein XML-Schema zuzuordnen. Viele, viele XML-Schemas sind schlecht entworfen (d. H. Sie übersetzen eine speicherinterne Objektstruktur in ein externes Darstellungsformat). Das Hauptproblem besteht darin, dass die Dokumente so entworfen werden sollten, dass sie aus der Perspektive eines Dokuments sinnvoll sind und dass diese dann auf jedes für Ihre Objekte gewünschte Speicherlayout abgebildet werden müssen. Schon gesehene XML-Dokumente mit vielen "refid" -Attributen, die sich auf andere Teile des Dokuments beziehen? Diese werden normalerweise aus einer relationalen Datenbank transkribiert, die gerade spitze Klammern auf dem Resultset hält.

Die Annahme einer Eins-zu-Eins-Zuordnung zwischen einem XML-Dokument und seiner Codedarstellung ist also in allen Fällen bis auf die einfachsten Fälle ziemlich verloren. Überlegen Sie nur, wo wir heute mit HTML wären, wenn es um die C++ - Objekte entworfen wurde, die das Dokument im ersten Browser instanziiert haben ... (naja, eher wie Objective-C, aber hey ...)

Der Punkt über NSKeyedArchiver ist, dass Sie die Datenstruktur entwickeln können, ohne die Fähigkeit zum Laden älterer Versionen zu brechen. Es ist unglaublich schwierig, dies (richtig) mit einer Art automatisierter Instanz-Var-zu-Element-Zuordnung zu tun.

Answer 4

Ich habe mit Anforderungen in diesem Bereich gekämpft und denke, es wäre eine gute Idee. Ich musste meine dot net Dienste schikanieren, um JSON für die einfache Nutzung auf einem iPhone zurückzugeben. Eine anständige Serialisierungsbibliothek wäre hervorragend.

Answer 5

Ich habe ein ähnliches Open-Source-Projekt gestartet. Ich habe es SAMIXOS genannt. Sie können diese Seite besuchen und ausprobieren. Seine erste Entwicklung. Es funktioniert ähnlich wie Enyra gefragt hat.

Bald werde ich einen Beispielcode bereitstellen.

http://sourceforge.net/projects/samixos/

Sami

Answer 6

ich einen Zusammenhang mit Open-Source-Projekt geöffnet haben, XML stream writer for iOS:

• Geschrieben in Objective-C, einem einzigen .h. und .m-Datei
• One @protocol für Namespace-Unterstützung und ein für ohne

Beispiel:

// allocate serializer 
XMLWriter* xmlWriter = [[XMLWriter alloc]init]; 

// start writing XML elements 
[xmlWriter writeStartElement:@"Root"]; 
[xmlWriter writeCharacters:@"Text content for root element"]; 
[xmlWriter writeEndElement]; 

// get the resulting XML string 
NSString* xml = [xmlWriter toString]; 

Dies erzeugt den folgenden XML-String:

<Root>Text content for root element</Root> 

In meiner Erfahrung, Es gibt keine kostengünstigen Werkzeuge, um Objekte von einem Modell (Objekte im Speicher) auf ein anderes Modell (irgendein XML-Schema) abzubilden, da die Logik irgendwie noch ausgedrückt werden muss. Sie arbeiten besser mit den Werkzeugen, mit denen Sie vertraut sind (Code !?).

Aber wenn Sie darauf bestehen, ein solches Werkzeug zu verwenden, dann ist der Weg zu gehen, Ihr Objektmodell das gleiche wie das XML-Modell zu machen.