Постоянство данных и песочница на iOS

Найдите папку приложения, соответствующую приложению, проверив различные зашифрованные папки в папке « Приложения ». Папка с загадочным именем на самом деле является каталогом песочницы приложения. В каталоге изолированной программной среды приложения откройте папку « Установки », расположенную в папке « Библиотека », и проверьте ее содержимое.

Вы должны увидеть список свойств с именем, идентичным идентификатору пакета приложения. Это хранилище по умолчанию для вашего приложения.

Если вы хотите упростить доступ к песочнице приложения в iOS Simulator, я настоятельно рекомендую вам взглянуть на SimPholder . Это бесплатная утилита, которая значительно облегчает работу с симулятором iOS.

Списки недвижимости

Мы уже рассмотрели списки свойств в этой серии. По сути, резервное хранилище базы данных по умолчанию для пользователя является списком свойств. Использование списков свойств — это удобная стратегия для хранения и извлечения графа объектов. Списки свойств издавна существуют, их легко использовать, и поэтому они являются отличным вариантом для хранения данных в приложении iOS.

Как я упоминал ранее, важно иметь в виду, что список свойств может хранить только данные списка свойств. Означает ли это, что невозможно сохранить объекты пользовательской модели, используя списки свойств? Нет, это возможно. Однако, объекты пользовательской модели должны быть заархивированы — форма сериализации — прежде чем они могут быть сохранены в списке свойств. Архивация объекта просто означает, что объект необходимо преобразовать в тип данных, который можно сохранить в списке свойств, например в экземпляре NSData .

Архивирование объектов

Вы помните протокол NSCoding , определенный в платформе Foundation? Протокол NSCoding определяет два метода, initWithCoder: и encodeWithCoder: которые должен реализовать класс, чтобы обеспечить возможность кодирования и декодирования экземпляров класса.

Кодирование и декодирование являются основными механизмами архивирования и распространения объектов. Как объекты архивных работ станут понятны чуть позже в этой серии. В этом уроке я только покажу вам, как записывать массивы и словари на диск, используя списки свойств.

Запись в файл

Следующий фрагмент кода должен дать вам представление о том, как легко записать массив или словарь на диск. Теоретически, граф объектов, хранящийся в списке свойств, может быть настолько сложным или настолько большим, насколько вы захотите. Однако имейте в виду, что списки свойств не предназначены для хранения десятков или сотен мегабайт данных, поэтому попытка использовать их таким образом, вероятно, приведет к снижению производительности.

Давайте посмотрим на приведенный выше фрагмент кода. Мы начнем с сохранения ссылки на литерал массива в переменной с именем fruits . Мы создаем путь к файлу для хранения списка свойств, который мы собираемся сделать. Путь к файлу создается путем добавления строки к пути к файлу каталога Documents , который мы получили ранее в этом уроке. Добавляемая строка будет именем списка свойств, включая его расширение, .plist , которое мы создадим за секунду.

writeToFile:atomically: массив на диск так же просто, как вызвать writeToFile:atomically: для массива. Вы можете пока игнорировать atomically флаг.

Как показывает пример, запись словаря на диск происходит по аналогичной схеме. В примере также показано, как создавать массивы и словари из списка свойств, но это то, что мы уже рассмотрели ранее в этой серии.

Запустите приложение в iOS Simulator и перейдите в каталог документов приложения, как мы видели ранее. В этом каталоге вы должны увидеть два списка свойств, которые мы только что создали.

SQLite

Если ваше приложение управляется данными и работает с большими объемами данных, вы можете захотеть изучить SQLite. Что такое SQLite? Слоган на веб-сайте SQLite гласит: «Маленький. Быстрый. Надежный. Выберите любые три». Это прекрасно подводит итог.

SQLite — это библиотека, которая реализует облегченную встроенную реляционную базу данных. Как следует из его названия, он основан на стандарте SQL (язык структурированных запросов ), как и MySQL и PostgreSQL.

Основное отличие от других баз данных SQL состоит в том, что SQLite является переносимым, очень легковесным и что он не требует сервера, а не является отдельным процессом, доступным из клиентского приложения. Другими словами, это встроено в приложение и, следовательно, очень быстро.

Веб-сайт SQLite утверждает, что это самая распространенная база данных SQL. Я не знаю, так ли это до сих пор, но это, безусловно, популярный выбор для хранения данных на стороне клиента. Aperture и iPhoto, например, полагаются на SQLite для хранения некоторых своих данных.

Преимущество SQLite перед работой непосредственно с объектами состоит в том, что SQLite работает на несколько порядков быстрее, что в значительной степени связано с тем, насколько существенно отличаются реляционные базы данных и языки объектно-ориентированного программирования.

Чтобы преодолеть разрыв между SQLite и Objective-C, с течением времени было создано несколько решений Object Relational Mapping (ORM). ORM, созданный Apple для iOS и OS X, называется Core Data , и мы рассмотрим его позже в этом уроке.

Летающее мясо FMDB

Использование SQLite на iOS означает работу с библиотекой на Си. Если вы предпочитаете объектно-ориентированное решение, я настоятельно рекомендую оболочку Objective-C Гуса Мюллера ( Flying Meat, Inc. ) для SQLite, FMDB .

Это делает работу с SQLite намного проще, если вы предпочитаете объектно-ориентированный интерфейс. Библиотека поддерживает ARC ( автоматический подсчет ссылок ) из коробки и очень эффективна. Я использовал FMDB в прошлом и был очень доволен его API, надежностью и надежностью библиотеки.

Основные данные

Разработчики, плохо знакомые с Core Data, часто ошибочно принимают Core Data за базу данных, хотя это действительно решение для реляционного отображения объектов, созданное и поддерживаемое Apple. Мэтт Галлахер написал отличный пост о различиях между Core Data и базой данных. Базовые данные предоставляют реляционную объектно-ориентированную модель, которую можно сериализовать в хранилище XML, двоичное или SQLite. Базовые данные даже поддерживают хранилище в памяти.

Почему вы должны использовать Core Data вместо SQLite? Задавая этот вопрос, вы ошибочно полагаете, что Core Data — это база данных. Преимущество использования Core Data заключается в том, что вы работаете с объектами, а не с необработанными данными, такими как строки в базе данных SQLite или данные, хранящиеся в файле XML. Несмотря на то, что у Core Data было несколько трудных лет, когда она была впервые выпущена, она превратилась в надежную среду с множеством функций, таких как автоматические миграции, отслеживание изменений, сбои и встроенная проверка.

Еще одна замечательная особенность, которую многие разработчики ценят, — это редактор модели Core Data, встроенный в Xcode, который позволяет разработчикам моделировать свою модель данных через графический интерфейс.

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

ICloud

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

Платформа iCloud включает в себя несколько сервисов или компонентов. Интересующий нас компонент — iCloud Storage , который включает в себя три типа хранилищ:

• хранилище ключей
• хранение документов
• Базовое хранение данных.

Если вы хотите узнать больше о iCloud Storage, я рекомендую прочитать серию о iCloud Storage, которую я написал ранее в этом году.

Вывод

Теперь у вас должно быть хорошее представление о возможных вариантах сохранения данных при разработке для платформы iOS. Имейте в виду, что не все стратегии, которые мы рассмотрели, равны.

Эта серия постепенно подходит к концу. В следующих двух статьях мы создадим еще одно приложение, чтобы применить на практике то, что мы узнали на данный момент. Лучший способ учиться — это делать.