How to become an author
Search
Write a publication
Pull to refresh

Comments 23

Я тут сейчас пишу приложение под mac os x, и столкнулся с тем что мне нужно хранить данные на локальной машине. Я правильно понял что с помощью plist я могу хранить допустим тысячу пар «ключ-значение»? или мне для этого надо использовать что-то другое?
Total votes 2: ↑2 and ↓0+2
В принципе, это возможно, но я предполагаю, что для тысячи полей лучше использовать Core Data с SQLite.
Total votes 2: ↑2 and ↓0+2
Я прочитал уже несколько статей по Core Data но так и не понял что это. Могли бы вы объяснить или вообще написать пост для новичков? Был бы очень признателен или скинуть ссылки на адекватные статьи по этому вопросу?
Total votes 2: ↑2 and ↓0+2
На хабре, к сожалению, мало информации о Core Data, тем более для OS X. Суть этой технологии сводится к предоставлению СУБД-like интерфейса для хранения данных в некоем абстрактном хранилище, обычно — SQLite, но иногда делают и XML.

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

А изучал я эту тему в основном по официальной документации, там достаточно подробно всё расписано.
Total votes 3: ↑3 and ↓0+3
У Markus Zarra есть неплохая книга «Core Data», ну или документация от Apple.

Описываете модель ваших данных (EAV) и работаете с ней, это просто удобная абстракция которая сама умеет заниматься серилизацией данных (sqlite, xml, бинарный или при определенных допусках даже ваш собственный формат), а также управлением жизненным циклом объектов и их графов. Плюс ко всему фрейморк совместим с Cocoa Bindings со всеми вытекающими. Ну и дополнительно имеет разные специфические фичи, например поддержку версий ваших данных с автоматическим или полуавтоматическим обновлением (ну например вы в новой версии программы изменили структуру вашей БД, core data позволит легко сделать переход от старой версии к новой), или ранее была возможность прозрачно обмениваться данными между разными машинами через облака (сейчас там по идее новый подход и отдельные фрейморки для работы сугубо с iCloud, но не суть).
Total votes 1: ↑1 and ↓0+1
Кстати сериализация plist в xml работает быстрее, чем в бинарный формат (на Mac OS).
Total votes 2: ↑2 and ↓0+2
Вот как? Откуда сведения? )
И интересно, с чем это связано?
Total votes 2: ↑2 and ↓0+2
Собственный опыт.

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

Сейчас посмотрел код, чтобы освежить память — на 10.6 все так, как я описал, а на 10.8 устранение дубликатов больше не делается, по-идее должно стать быстрее (релевантная функция называется __CFBinaryPlistWrite).
Total votes 2: ↑2 and ↓0+2
Спасибо за ценное замечание! Внесу дополнение к статье.
Total votes 1: ↑1 and ↓0+1
Хочу еще добавить, что мне кажется неправильным объяснять что-такое PLIST, начиная от фрагментов XML представления.

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

Кстати XML представление PLIST хорошо еще тем, что с ним можно работать «сторонними» средствами, например для Python есть plistlib в стандартной поставке. Причем plistlib работает не только на маке. Уверен, что что-то такое есть и для других языков.
Total votes 3: ↑2 and ↓1+1
Ну, я выбрал объяснение «из XML» потому, что мне XML ближе. =)

В принципе, можно было бы и «из JSON-а» или даже просто «на пальцах» объяснить. Но обычно, всё таки, plist-ы люди видят именно в виде xml, а отличия от «классического» xml я как раз в начале и постарался раскрыть.
This comment wasn’t rated yet0
Ну вам виднее:) Все таки XML это всего-лишь одно из возможных представлений PLIST.

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

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

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

Вот DTD.
Total votes 1: ↑1 and ↓0+1
Это да, корневым элементом может быть что угодно.
This comment wasn’t rated yet0
А почему бы не использовать вместо

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

По-моему, получится то же самое.
Сейчас конечно, попробую сравнить с вашим вариантом…
Total votes 1: ↑1 and ↓0+1
В моём случае мы можем выбрать конкретную форму представления плиста, конкретно — XML. Могу предположить, что по умолчанию NSDictionary пишет себя в бинарном формате.
This comment wasn’t rated yet0
Нет, по умолчанию в тот же чистый xml plist. С NSArray то же самое.
Total votes 1: ↑1 and ↓0+1
Собственно, даже если так, преимущество возможности выбора формата остаётся в силе.
Кроме того, NSData можно передавать в другие места программы, зиповать для отправки по сети и т.п…
Total votes 1: ↑1 and ↓0+1
Согласен. Но если нужно что-то быстро сохранить — можно использовать сокращенный метод. Правда, в этом случае лишаешься еще и обработки ошибок. Например, если в NSDictionary запихнуть например NSDate, то в iOS 6 файл вообще не сохранится, а в iOS 4-5 сохранится до поля с NSDate. И можно довольно много времени потратить на поиск ошибки…
Total votes 1: ↑1 and ↓0+1
Действительно, я ведь не зря проверки ставил на ошибки =)
Total votes 1: ↑1 and ↓0+1
Ещё один важный момент: при загрузке словаря/массива из файла «простым» способом нельзя задать mutability.
Total votes 1: ↑1 and ↓0+1
Таки да.

    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
Total votes 1: ↑1 and ↓0+1
Прошу прощения, в NSData конечно же можем, но это не plist
Total votes 1: ↑1 and ↓0+1
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr