Когда я должен использовать различные механизмы хранения в iOS?

Question

Я думал, что это уже будет рассмотрено, но мой поиск не дал ничего значимого.

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

Использование веб-серверов против Core Data очевидно, но как насчет NSUserDefaults против списков? Основные данные против объектного архивирования? Простая разбивка вариантов использования действительно помогла бы мне понять, почему в iOS так много вариантов хранения.

Answer 1

Я пытаюсь написать быстрый и простой список распространенных случаев использования, потому что, как говорит @rmaddy, этот ответ может заполнить главу книги:

• NSUserDefaults: хранит простые пользовательские настройки, ничего слишком сложного или безопасного. Если в вашем приложении есть страница настроек с несколькими переключателями, вы можете сохранить данные здесь.

• Keychain (см. SSKeychain для отличной обертки): используется для хранения конфиденциальных данных, таких как учетные данные.

• PLists: используется для хранения структурированных данных большего размера (но не большого размера): это действительно гибкий формат, который может использоваться во множестве сценариев. Вот некоторые примеры:

  • Пользовательское хранилище контента: простой список Geopoint, который будет отображаться на карте или в списке.
  • Предоставьте простые исходные данные для вашего приложения: в этом случае список будет включен в NSBundle, а не генерируется пользователем и заполняется пользовательскими данными.
  • Отделите данные, необходимые для определенного модуля вашего приложения, от других данных. Например, данные, необходимые для создания пошагового руководства по запуску, где каждый шаг похож на другие, но просто нужны разные данные. Жесткое кодирование этих данных легко заполнило бы ваш код, так что вы могли бы стать лучшим разработчиком и использовать списки для хранения данных и чтения из них.
  • Вы пишете библиотеку или фреймворк, который может быть каким-то образом настроен разработчиком, который его использует.

• Object archiving может быть полезным для сериализации более сложных объектов, возможно, полных двоичных данных, которые (или вы не хотите) отображать на более простые структуры, такие как списки.

• Core Data является мощным средством, может поддерживаться различными постоянными хранилищами (SQLite является лишь одним из них, но вы также можете выбрать файлы XML или даже написать свой собственный формат!) и дает взаимосвязи между элементами. Он сложный и предоставляет множество функций, полезных для разработки, таких как KVO и контексты. Вы должны использовать его для больших наборов данных многих коррелированных записей, которые могут быть созданы пользователем или предоставлены сервером.

• Raw SQLite полезно, когда вам нужен действительно очень быстрый доступ к реляционному источнику данных (Core Data вносит некоторые накладные расходы) или если вам необходимо поддерживать один и тот же формат SQLite на нескольких платформах (вам никогда не следует связываться с внутренним SQLite CoreData: он использует свой собственный формат, поэтому вы не можете просто "импортировать" существующий SQLite в CoreData). Например, для проекта, над которым я работал, веб-сервис предоставил мне несколько больших SQLite вместо jsons или xmls: некоторые из этих SQLite были импортированы в CoreData (операция, которая может занять некоторое время, в зависимости от размера источника), потому что мне нужно было все особенности этого, в то время как другие SQLites были прочитаны непосредственно для действительно быстрого доступа.

• Webserver storage ну, это должно быть очевидно: если вам нужно хранить данные на сервере, это потому, что устройство не должно быть единственным владельцем этих данных. Но если вам просто нужно синхронизировать одно и то же приложение на разных устройствах iOS (или даже с версией приложения, портированной на Mac), вы, очевидно, также можете взглянуть на хранилище iCloud.