Работа с файлами .plist в Cocoa/CocoaTouch

[mixailflash]

Я тут сейчас пишу приложение под mac os x, и столкнулся с тем что мне нужно хранить данные на локальной машине. Я правильно понял что с помощью plist я могу хранить допустим тысячу пар «ключ-значение»? или мне для этого надо использовать что-то другое?

[silvansky]

В принципе, это возможно, но я предполагаю, что для тысячи полей лучше использовать Core Data с SQLite.

[mixailflash]

Я прочитал уже несколько статей по Core Data но так и не понял что это. Могли бы вы объяснить или вообще написать пост для новичков? Был бы очень признателен или скинуть ссылки на адекватные статьи по этому вопросу?

[silvansky]

На хабре, к сожалению, мало информации о Core Data, тем более для OS X. Суть этой технологии сводится к предоставлению СУБД-like интерфейса для хранения данных в некоем абстрактном хранилище, обычно — SQLite, но иногда делают и XML.

Лично я его использовал пока только для проектов под iOS, но могу действительно попробовать написать статью типа «Введение в Core Data для Mac OS X».

А изучал я эту тему в основном по официальной документации, там достаточно подробно всё расписано.

[int80h]

У Markus Zarra есть неплохая книга «Core Data», ну или документация от Apple.

Описываете модель ваших данных (EAV) и работаете с ней, это просто удобная абстракция которая сама умеет заниматься серилизацией данных (sqlite, xml, бинарный или при определенных допусках даже ваш собственный формат), а также управлением жизненным циклом объектов и их графов. Плюс ко всему фрейморк совместим с Cocoa Bindings со всеми вытекающими. Ну и дополнительно имеет разные специфические фичи, например поддержку версий ваших данных с автоматическим или полуавтоматическим обновлением (ну например вы в новой версии программы изменили структуру вашей БД, core data позволит легко сделать переход от старой версии к новой), или ранее была возможность прозрачно обмениваться данными между разными машинами через облака (сейчас там по идее новый подход и отдельные фрейморки для работы сугубо с iCloud, но не суть).

[mejedi]

Кстати сериализация plist в xml работает быстрее, чем в бинарный формат (на Mac OS).

[silvansky]

Вот как? Откуда сведения? )
И интересно, с чем это связано?

[mejedi]

Собственный опыт.

XML пишется «в лоб», а при сохранении в бинарный формат происходит поиск и устранение дублирующих элементов (формат по сути представляет собой поток сущностей с взаимными ссылками, например если у нас два раза строка «hello world» встречается, хранить две копии не обязательно).

Сейчас посмотрел код, чтобы освежить память — на 10.6 все так, как я описал, а на 10.8 устранение дубликатов больше не делается, по-идее должно стать быстрее (релевантная функция называется __CFBinaryPlistWrite).

[silvansky]

Спасибо за ценное замечание! Внесу дополнение к статье.

[mejedi]

Хочу еще добавить, что мне кажется неправильным объяснять что-такое PLIST, начиная от фрагментов XML представления.

Я обычно объясняю PLIST как такой аналог JSON от Apple — композиция словарей, массивов и простых типов данных вроде строк и чисел. Что такое JSON и его преимущества и недостатки по сравнению с XML знают все:)

Кстати XML представление PLIST хорошо еще тем, что с ним можно работать «сторонними» средствами, например для Python есть plistlib в стандартной поставке. Причем plistlib работает не только на маке. Уверен, что что-то такое есть и для других языков.

[silvansky]

Ну, я выбрал объяснение «из XML» потому, что мне XML ближе. =)

В принципе, можно было бы и «из JSON-а» или даже просто «на пальцах» объяснить. Но обычно, всё таки, plist-ы люди видят именно в виде xml, а отличия от «классического» xml я как раз в начале и постарался раскрыть.

[mejedi]

Ну вам виднее:) Все таки XML это всего-лишь одно из возможных представлений PLIST.

Это как объяснять что XML это такие текстовые файлы, в которых угловые скобочки являются спец-символами и формируют тэги, при этом про семантику ничего не сказать или упомянуть вскользь.

Собственно, plist состоит из тегов <key>, за которыми следуют перечисленные теги со значением.

Кстати у вас фактическая ошибка — пара ключ/значение всего-лишь фрагмент сериализованного представления словаря. А корневой объект не оязательно словарь.

Вот DTD.

[silvansky]

Это да, корневым элементом может быть что угодно.

[lim]

А почему бы не использовать вместо

NSData *representation = [NSPropertyListSerialization dataWithPropertyList:root format:NSPropertyListXMLFormat_v1_0 options:0 error:&error];
BOOL ok = [representation writeToFile:self.plistFileName atomically:YES];

вот такой вариант:

BOOL ok = [root writeToFile:self.plistFileName atomically:YES];

По-моему, получится то же самое.
Сейчас конечно, попробую сравнить с вашим вариантом…

[silvansky]

В моём случае мы можем выбрать конкретную форму представления плиста, конкретно — XML. Могу предположить, что по умолчанию NSDictionary пишет себя в бинарном формате.

[lim]

Нет, по умолчанию в тот же чистый xml plist. С NSArray то же самое.

[silvansky]

Собственно, даже если так, преимущество возможности выбора формата остаётся в силе.
Кроме того, NSData можно передавать в другие места программы, зиповать для отправки по сети и т.п…

[lim]

Согласен. Но если нужно что-то быстро сохранить — можно использовать сокращенный метод. Правда, в этом случае лишаешься еще и обработки ошибок. Например, если в NSDictionary запихнуть например NSDate, то в iOS 6 файл вообще не сохранится, а в iOS 4-5 сохранится до поля с NSDate. И можно довольно много времени потратить на поиск ошибки…

[silvansky]

Действительно, я ведь не зря проверки ставил на ошибки =)

[silvansky]

Ещё один важный момент: при загрузке словаря/массива из файла «простым» способом нельзя задать mutability.

[lim]

Таки да.

    NSDictionary *d = @{
        @"asd" : @"ert",
        @"dfsdf": @{
            @"dsfs" : @"fsdf",
            @"fgdfg" : @"dsfsdf"},
        @"sdfs":@[@"asdasd", @"asdgv", @"fdgdfg"]};

    [d writeToFile:[self getPersistPathFilename:@"file1.plist"] atomically:YES];

    NSData *representation = [NSPropertyListSerialization dataWithPropertyList:d format:NSPropertyListXMLFormat_v1_0 options:0 error:nil];
    BOOL ok = [representation writeToFile:[self getPersistPathFilename:@"file2.plist"] atomically:YES];

file1.plist абсолютно эквивалентен file2.plist

[garnett]

То есть, массив вьюшек Вы таким способом не сериализуете, даже не пытайтесь.

Эм, а почему мы не можем сериализовать UIView (поддерживает NSCoding)? stackoverflow.com/questions/1169061/how-to-serialize-a-uiview

[garnett]

Прошу прощения, в NSData конечно же можем, но это не plist