Подтвердить что ты не робот

Библиотека сериализации Xml для приложений iPhone

Apple предоставляет NSArchiver и NSUnachriver для сериализации/десериализации объектов, но это не может обрабатывать какую-либо собственную схему XML. Поэтому заполнение структуры объекта данными любой пользовательской xml-схемы должно выполняться вручную. Поскольку сообщество разработчиков iPhone быстро растет, многие программисты-новички отчаянно пытаются разобраться с доступными возможностями анализа XML.

iPhone SDK предоставляет только NSXmlParser для синтаксического анализа xml, который более полезен для чтения определенных частей XML файла, чем заполнение всей структуры объекта, что на самом деле является болью.

Другая возможность - это известная библиотека libxml, написанная на ANSI C - не простая в использовании для тех, кто начинает программирование с помощью objective-c и никогда не учился надлежащему C раньше. Событие, что доступно множество оберток, дело с xml может быть болью для новичков.

И вот моя идея имеет место. Библиотека XmlSerializer, которая автоматически заполняет структуру объекта, может сделать ее намного проще и повысить качество приложения для многих программистов. Моя идея должна работать следующим образом:

Файл xml

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

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

Классы для заполнения

@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

Как должен работать сериализатор 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];

Для заполнения структуры объекта требуется только одна строка кода:

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

Это было бы так легко использовать, что любой программист-новичок мог его использовать. Для более расширенного использования сериализатор может быть настроен.

Как вы думаете, будет ли это полезной и популярной библиотекой для приложений iPhone и OSX?

Изменить: Вы можете увидеть проект здесь, но он не зависит от выпуска.

4b9b3361

ОТВЕТЫ

Ответ 1

NSKeyedArchiver работает именно потому, что не пытается сопоставить XML-схему. Многие, многие схемы XML плохо разработаны (т.е. Они переводят структуру объектов в памяти в формат внешнего представления). Ключевая проблема заключается в том, что документы должны быть разработаны с учетом перспективы документа, и тогда это необходимо будет отобразить на любой макет памяти, который вы хотите для своих объектов. Когда-либо видели XML-документы с множеством атрибутов refid, относящихся к другим частям документа? Обычно они транслитерируются из реляционной базы данных, которая просто фиксирует скобки на наборе результатов.

Таким образом, начиная с предположения, что взаимно однозначное сопоставление между XML-документом и его представлением кода в значительной степени обречено на все, кроме самых простых случаев. Просто подумайте, где мы будем сегодня с HTML, если бы он был разработан вокруг объектов С++, которые использовались для создания экземпляра документа в первом браузере... (ну, скорее, как Objective-C, но эй...)

Пункт NSKeyedArchiver заключается в том, что вы можете развить структуру данных, не нарушая возможности загрузки более старых версий. Это невероятно сложно сделать (правильно) с помощью какого-либо автоматического сопоставления экземпляров-var-to-element.

Ответ 2

Я начал аналогичный проект с открытым исходным кодом. Я назвал его SAMIXOS. вы можете посетить эту страницу и попробовать ее. Его в начальном развитии. Он работает аналогично тому, что спросила Энира.

Вскоре я предоставлю пример кода.

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

Сами

Ответ 3

Я открыл связанный проект с открытым исходным кодом, писатель потока XML для iOS:

  • Написано в Objective-C, одном .h. и .m файл
  • Один @protocol для поддержки пространства имен и один для без

Пример:

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

В результате создается следующая строка XML:

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

По моему опыту, экономически эффективные инструменты для сопоставления объектов из одной модели (объекты в памяти) в другую модель (некоторые схемы XML) не существуют, поскольку логика все же должна быть как-то выражена. Вам лучше выполнять работу с помощью инструментов (кода!?), с которыми вы знакомы.

Но если вы настаиваете на использовании такого инструмента, то путь к нему - сделать вашу модель объекта такой же, как XML-модель.

Ответ 4

Это неплохая идея, но я бы это сделал, реализовав NSXMLArchiver и NSXMLUnarchiver в качестве подклассов NSCoder. Таким образом, любой класс, соответствующий протоколу NSCoding, может быть легко сериализован в XML и из него.

Одно значение производительности, когда сериализация в XML будет примитивными значениями в качестве атрибутов, потому что вы не можете гарантировать, что объект будет запрашивать данные для кодирования. Поэтому, если атрибуты - это то, что вы хотите, тогда оно будет довольно огромным в буферах памяти. Но это было бы забавным упражнением.

Как популярно это будет? Не так популярно, я думаю. Пример использования слишком мал.

  • Device-to-device - Простое использование NSKeyedArchiver проще, а MUCH более компактно.
  • Сервер от устройства к новому. Новый сервер должен будет реализовать ту же схему, что и сериализация на Java, С# или что-то еще.
  • Существующий сервер - формат XML уже исправлен и, скорее всего, не близок к этому.

Ответ 5

То, что вы описываете, находится внутри ObjectiveResource реализации, и он поддерживает как JSON, так и XML. Это должно быть довольно легко разветкить это и уменьшить его до просто синтаксического анализа, выкинув все управление подключением.

Ответ 6

Я боролся с требованиями в этой области и думаю, что это будет отличная идея. Мне пришлось запугивать мои сетевые сервисы, чтобы вернуть JSON для легкого потребления на iPhone. Хорошая библиотека сериализации будет превосходной.