aumentada - Biblioteca de serialización Xml para aplicaciones de iPhone

ios 12

Question

Apple proporciona NSArchiver y NSUnachriver para la serialización / deserialización de objetos, pero esto no puede manejar ningún 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.

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

La otra posibilidad es la famosa biblioteca libxml, que está escrita en ANSI C: no es fácil de usar para alguien que comienza a programar con objetivo-c y nunca antes había aprendido la C propiamente dicha. 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 debería funcionar el serializador xml

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 solo 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 usarlo. Para un uso más avanzado, el serializador podría ser configurable.

¿Qué crees que sería una biblioteca útil y popular para aplicaciones de iPhone y OSX?

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

Answer 1

Esta es una idea bastante buena, en lo que respecta a la implementación, lo haría implementando 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 rendimiento alcanzado al serializar a XML serán los valores primitivos como atributos, porque no se puede garantizar el orden en que un objeto solicitará que se codifiquen los datos. Entonces, si los atributos son lo que quieres, entonces será bastante grande en los búferes de memoria. Pero sería un ejercicio divertido.

En cuanto a lo popular que 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.
• Dispositivo a servidor nuevo: el nuevo servidor también debería implementar el mismo esquema, serializando a Java, C # o lo que sea.
• Servidor de dispositivo a servidor existente: el formato XML ya está arreglado, y lo más probable es que no esté cerca de esto.

Answer 2

Lo que está describiendo está oculto dentro de las implementaciones de ObjectiveResource , y es compatible 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.

Answer 3

NSKeyedArchiver funciona precisamente porque no intenta mapear en un esquema XML. Muchos, muchos esquemas XML están mal diseñados (es decir, están traduciendo una estructura de objeto 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 asignación de uno a uno entre un documento XML y su representación de código está prácticamente condenada en todos los casos, excepto en los 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 oye ...)

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.

Answer 4

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.

Answer 5

He comenzado un proyecto de código abierto similar. 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

Answer 6

He abierto un proyecto relacionado de código abierto, XML Stream writer para iOS :

• Escrito en Objective-C, un solo .h. y archivo .m
• Un @protocol para soporte de espacio de nombres y otro 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 (algunos esquemas XML) no existen, ya que la lógica todavía 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 tal herramienta, entonces el camino a seguir es hacer que su modelo de objeto sea el mismo que el modelo XML.