plists по сравнению с Базовыми Данными для содержания параметров
Я пишу приложение для iPad, которое будет расширяемо с новыми объектами через покупку в приложении. Например, мой текущий план состоит в том, чтобы иметь jpg шаблон и соответствие plist файл с параметрами, я должен развернуть тот шаблон в полное изображение.
Пользователь выберет один jpg/png из списка маленьких миниатюр - список сохранен в Базовых Данных - и приложение найдет соответствие plist для отображения jpg/png правильно. У меня только будет приблизительно 10 из них, открываются когда-то. Но я мог закончить с хранением 1000-х jpgs и plists.
Устройство хранения данных большого количества маленьких файлов вызывают проблемы приложения?
Я иду plist путем, вместо того, чтобы хранить параметры в Базовых Данных, так, чтобы, если я должен добавить параметры позже, я не перемещал базу данных, просто изменить доступ в коде. (И когда я создаю шаблоны, легче сконцентрироваться на plist файле, а не Базовой строке Данных.)
Приложение, кажется, работает действительно хорошо в данный момент, но я волнуюсь по поводу фьючерсов...
Мое приложение действительно также использует Базовые Данные для других вещей, таким образом, я мог переключиться, если приложение увязнет с количеством файлов.
Спасибо.
1 ответ
Сохранение большого количества небольших файлов не проблема, если у вас есть хорошо продуманные средства именования и отслеживания файлов.
Помните, что пользователь не имеет такой гибкости и простоты управления файлами на мобильном телефоне, как на немобильных платформах. Дизайны, которые работают на немобильных телефонах, не работают на устройстве, которое можно использовать в движении одним пальцем.
Однако, когда вы говорите:
И когда я создаю шаблоны, легче сконцентрироваться на листе файл, а не строку Core Data.
... использование слова «row» предполагает, что вы не до конца поняли полезность Core Data. Core Data не использует строки, столбцы, таблицы или объединения. Это система управления графом объектов, которая иногда использует SQL «за кулисами».
Core Data разработан для обработки данных таким образом, чтобы он легко взаимодействовал с остальной частью объектно-ориентированного API для пользовательского интерфейса и других сервисов. Когда вы используете другие системы управления данными, такие как plist, вы, скорее всего, в конечном итоге вручную дублируете большую часть функций Core Data.