Лучший способ сохранить данные локально на устройстве в приложении iOS

Question

Я работаю над своим первым приложением iOS, которое будет развернуто как для iPhone, так и для iPads. Приложение содержит данные, которые необходимо добавить в приложение, которые будут использоваться, когда устройство будет отключено.

Автономная версия имеет по крайней мере 35-40 записей с каждой записью, содержащей изображения (которые будут сгруппированных в приложении, только имена будут сохранены), и varchar поле, которое было бы зарегистрировано не менее 1000 слов и boolean поле.

я нашел три возможных решения для одной и той же

1. Сохранить все поля с использованием базы данных (SQlite или Coredata), однако я обеспокоен за столом, который будет иметь 1000 слов. Но так как поле VARCHAR может меняться, мне нужно выделить не более 2000 (или более, в зависимости от фактической длины ключевых слов) предела (что приведет ненужное выделение ресурсов памяти)

2. Другой подход, который я хотел бы есть информация в форме json локально и использовать его как и когда требуется, и сохранять логические поля (только true локально в NSUserDefaults)

3. Используйте подход JSON, как обсуждалось выше, и создайте базу данных для управления булевыми полями.

Я хотел бы узнать мнение сообщества StackOverflow о том, что было бы идеальным/оптимизированным подходом для этого сценария. Кроме того, я открыт для любого другого подхода.

Редактировать 1 Предлагаемая предварительная databased структура

Listing Table 
id -> int (autoincrement) 
name -> varchar(25) 
imagename -> varchar(10) 
desription -> varchar(2000) 
favorite -> boolean 

Answer 1

Это звучит так, как будто текстовое поле (с 1000-2000 слов) статический текст, который поставляется в комплекте с приложением и не может быть изменен пользователем приложения. Если это так, то вы можете сохранить эти данные в комплекте приложения с файлами plist или JSON-файлами и загрузить его по требованию (при условии, что вам не нужно искать, хотя он).

Тогда, если каждая из этих записей имеет только одно значение boolean, которое может быть изменено пользователем, они могут быть легко сохранены в NSUserDefaults (поскольку вы заявили, что имеете дело только с 35-40 записями). Вы должны использовать id, чтобы связать boolean с файлом данных.

Для хранения данных вы можете использовать Core Data или Realm, но может быть излишним, если вам не нужна функция поиска, и пользователь не может изменить текст. Но если вы поедете с опцией базы данных, имейте в виду, что вы не можете хранить статические данные (текст) в месте, которое поддерживается iCloud, или Apple отклонит ваше приложение. Независимо от того, используете ли вы iCloud в приложении или нет.Поэтому, если вам нужно создать постоянное хранилище Core Data и сохранить его в папке пользователей Documents, тогда загрузите все статические данные, вы будете отклонены. Вы хотите сохранить это хранилище данных в папке Cache пользователей, чтобы iCloud не поддерживал его. Проблема, с которой вы столкнетесь после этого, состоит в том, что вы хотите, чтобы пользовательские варианты были резервными значениями boolean. Это означает, что их нужно хранить в другом месте. Core Data имеет функцию, которая позволяет вам создавать Configurations, где он будет отделять пользовательские данные от неизменяемых данных, но опять же, это излишний случай для вашего дела.

Я рекомендую начинать с Realm над «Основными данными» для такого небольшого набора данных. Гораздо легче вставать и работать.

Answer 2

Если вам нужно посмотреть на поля, CoreData является й лучший подход, потому что вы можете легко получить доступ к данным с помощью NSPredicates (Подобно SQL where заявление`).

Но если вам нужно загружать все при каждом запуске, вы можете просто сохранить все в файл (plist, son ...), потому что его действительно проще управлять и обновлять (если вы обновите CoreData Model , изменение может быть затруднено при обновлении приложения).

Так что мой короткий ответ:

Если вам нужно учить в данных =>Core Data

Else =>файла на локальном хранилище

Do не используйте UserDefault для этого, это не предназначено для этого.

Answer 3

Это зависит от сложности и эффективности вашей базы данных.

См., Во-первых, какая система базы данных вы использовали, нет разницы в производительности.

Каждая система баз данных имеет различную сложность и ограничения по работе.

Например, для хранения и извлечения данных очень удобно использовать NSUserDefaults.

Но если вам нужно сделать relational operation между массивными данными, тогда лучше использовать sqlite or core data. Relational database operations легко выполнить sqlite or coredata по сравнению с другими.

Существует еще один вариант: property - list также доступен, если вы являетесь только типом пары значений ключа.

Core data полностью основан на sqlite. В самих корневых данных ядра используется sqlite.

Разница между основными данными и sqlite: основные данные обеспечивают большую гибкость при ее использовании, но это сравнительно сложно или сложно изучить. Где sqlite не обеспечивает гибкость по сравнению с основными данными, но он менее сложный для изучения и использования. Например, гибкость означает: вы можете видеть визуальное представление основных данных. Можно визуально добавить сущность или атрибуты и т. Д.

Итак, выберите базу данных в соответствии с вашими потребностями и сложностью использования или базы при выполнении операций, которые вам понадобятся. Ваша база данных не очень большая и не сложная и не требует каких-либо реляционных операций или нескольких таблиц, тогда вы также можете использовать user defaults or property list.

Надеется, что это поможет :)

Answer 4

качка с опционом.

Чтобы облегчить для себя позже, я бы предложил использовать CoreData. Это позволяет вам легко управлять продуктами для чтения и записи. Это также дает вам хорошее постоянное хранилище.

К описанию проблемы; вы можете сохранить описание для каждого продукта в своем собственном файле с уникальным именем, которое ссылается на продукт, который вы храните в CoreData. В объекте CoreData вы определяете descriptionFile, который будет содержать путь к файлу.

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

Счастливый Coding :)