2009-06-03 9 views
11

Apple proporciona el NSArchiver y NSUnachriver para la serialización de objetos/deserialización, pero esto no puede manejar cualquier esquema XML personalizado. Por lo tanto, completar una estructura de objetos con los datos de cualquier esquema xml personalizado debe hacerse manualmente. Dado que la comunidad de desarrolladores de iPhone está creciendo rápidamente, muchos programadores novatos están desesperados por lidiar con las posibilidades de análisis XML disponibles.Aplicaciones iPhone

El SDK de iPhone solo proporciona NSXmlParser para el análisis de xml, que es más útil para leer ciertas partes de un archivo xml, que llenar una estructura de objetos completa, lo que realmente es un problema.

La otra posibilidad es la famosa biblioteca libxml, que está escrito en ANSI C - no es fácil de usar para alguien que comienza con la programación Objective-C y C nunca aprendió adecuada antes. Si hay muchos envoltorios disponibles, lidiar con xml puede ser un problema para los novatos.

Y aquí mi idea tiene lugar. Una biblioteca XmlSerializer que llena automáticamente una estructura de objeto podría facilitar mucho más y aumentar la calidad de la aplicación para muchos programadores. Mi idea debería funcionar así:

el archivo XML

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

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

Las clases para llenar

@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 

Cómo el serializador XML debe trabajar

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]; 

para llenar la estructura del objeto sólo necesita una línea de código:

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

Esto sería tan fácil de usar que cualquier programador novato podría utilizarlo. Para un uso más avanzado, el serializador podría ser configurable.

¿Qué le parece, ¿sería una biblioteca útil y popular para el iPhone y OSX aplicaciones?

Editar: Puedes ver el proyecto here, pero está lejos del lanzamiento.

+0

Aquí hay algo similar que llamé: http://kpmattius.wordpress.com/2011/06/07/objective-c-serialization/ Si alguien tiene tiempo, pueden hacerlo más, pero a mí me sirve: D –

+0

Esto ayudará ... http://code.google.com/p/wonderxml/ – hrishib

Respuesta

0

Ésta es una muy buena idea, la aplicación sabia que lo haría mediante la implementación de NSXMLArchiver y NSXMLUnarchiver como subclases de NSCoder. De esta forma, cualquier clase que se ajuste al protocolo NSCoding podría ser serializada fácilmente desde y hacia XML.

un impacto en el rendimiento al serializar a XML serán los valores primitivos como atributos, porque no se puede garantizar el orden un objeto solicitará los datos a codificar. Entonces, si los atributos son lo que quieres, entonces será bastante grande en los búferes de memoria. Pero sería un ejercicio divertido.

¿Qué tan popular sería? No tan popular, creo. El caso de uso es demasiado pequeño.

  • Dispositivo a dispositivo: simplemente usar NSKeyedArchiver es mucho más fácil y MUCHO más compacto.
  • Servidor de dispositivo a nuevo: el nuevo servidor también debería implementar el mismo esquema, serializando a Java, C# o lo que sea.
  • Servidor del dispositivo a servidor existente: el formato XML ya está arreglado, y lo más probable es que no esté cerca de esto.
0

Lo que usted describe es enterrado en el interior de la ObjectiveResourceimplementations, y es compatible tanto con JSON y XML. Debería ser muy fácil bifurcarlo y reducirlo solo al análisis descartando toda la administración de la conexión.

2

NSKeyedArchiver funciona precisamente porque no intenta mapear en un esquema XML. Muchos esquemas XML están mal diseñados (es decir, están traduciendo una estructura de objetos en memoria a un formato de representación externo). El problema clave es que los documentos deben diseñarse para que tengan sentido desde la perspectiva de un documento, y que luego deberían asignarse al diseño de memoria que desee para sus objetos. ¿Alguna vez ha visto documentos XML con muchos atributos 'refid' que hacen referencia a otras partes del documento? Por lo general, se transcriben a partir de una base de datos relacional que simplemente está sobresaliendo entre paréntesis en el conjunto de resultados.

Por lo tanto, comenzar suponiendo que una correspondencia de uno a uno entre un documento XML y su representación de código está condenada al fracaso, salvo en los casos más simples. Solo considere dónde estaríamos hoy con HTML si hubiera sido diseñado alrededor de los objetos de C++ que se usaron para crear una instancia del documento en el primer navegador ... (bueno, más como Objective-C, pero bueno ...)

El punto sobre NSKeyedArchiver es que puede evolucionar la estructura de datos sin romper la capacidad de cargar versiones anteriores. Es increíblemente difícil hacerlo (correctamente) utilizando algún tipo de mapeo automatizado de instancias de var-a-element.

+0

El ejemplo de OP es un modelo de datos con campos simples que tienen sentido para ser serializados. La pregunta que me parece es más acerca de cómo serializar/deserializar XML en un formato distinto al formato plist de Apple. Probablemente, esto se use para comunicar datos a/desde un servicio web que no ejecute OSX (por lo que no se diseñó alrededor de listas). De modo que, idealmente, escribiría un objeto modelo con propiedades para cada elemento en el esquema y lo usaría para serializar los valores de resultados XML del servicio. – George

+0

Además, el ejemplo de OP es un documento XML que tiene sentido "desde la perspectiva de un documento". En este caso, es más probable que haya objetos Objective-C creados para admitir el formato de documento en uso. Lo cual es perfectamente aceptable. Están buscando una forma simple de traducir el documento en una representación en memoria sin escribir código de análisis personalizado para cada objeto. – George

0

He estado luchando con los requisitos en este ámbito y creo que sería una gran idea. Tuve que intimidar a mis servicios dot net para devolver JSON para un fácil consumo en un iPhone. Una biblioteca de serialización decente sería excelente.

1

He comenzado un proyecto similar de código abierto. Lo he llamado SAMIXOS. puedes visitar esta página y probarla. Está en desarrollo inicial. Funciona de manera similar a lo que Enyra ha pedido.

Pronto proporcionaré un código de muestra.

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

Sami

+0

hi sami. . Tengo problemas para agregar tu biblioteca a mi proyecto. ¿tienes un proyecto de muestra que hace eso? – thndrkiss

1

He abierto un proyecto relacionado con el código abierto, XML stream writer for iOS:

  • escrito en Objective-C, una sola .h. y el archivo .m
  • Una @protocol para el soporte de espacio de nombres y otra para sin

Ejemplo:

// 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]; 

Esto produce la siguiente cadena XML:

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

En mi experiencia, Las herramientas rentables para mapear objetos de un modelo (objetos en la memoria) a otro modelo (algún esquema XML) no existen, ya que la lógica aún tiene que ser expresada de alguna manera. Es mejor que haga el trabajo usando herramientas (¡código !?) con las que está familiarizado.

Pero si insiste en usar una herramienta de este tipo, entonces el camino a seguir es hacer que su modelo de objeto sea el mismo que el modelo XML.

Cuestiones relacionadas