Есть ли какая-то ценность в использовании основных данных для приложений iPhone?

Question

Могут ли люди привести примеры того, почему они используют coreData в приложении?

Я спрашиваю об этом, потому что большинство приложений - это просто клиенты для центрального сервера, где какой-то API предоставляет вам необходимую информацию.

В моем случае я пишу приложение расписания для веб-приложения, у которого есть API, и я спорю, есть ли смысл реплицировать структуру данных на моем сервере в базовые данные (Sqlite)

например,

В проекте много расписаний, у сотрудника много расписаний

Мне кажется, что я могу просто подключаться к API при каждом вызове списков проектов или существующих расписаний, например.

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

Может ли какой-нибудь опытный разработчик пролить свет на опыт, когда базовые данные являются подходом наилучшей практики?

РЕДАКТИРОВАТЬ

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

Answer 1

Вы не должны думать о CoreData просто как о базе данных SQLite. Это не просто база данных SQLite. Конечно, SQLite - это вариант, но есть и другие варианты, такие как оперативная память и, с iOS5, целый ряд пользовательских хранилищ данных. Очевидно, самое большое преимущество CoreData - это постоянство. Но даже если вы используете хранилище данных в памяти, вы получаете преимущества очень хорошо структурированного графа объектов, и вся тяжелая работа, связанная с извлечением информации из нее или ее помещением в хранилище данных, обрабатывается CoreData для вам, без вас обязательно нужно заботиться о том, что поддерживает это хранилище данных. Конечно, сегодня вас не слишком заботит постоянство, поэтому вы можете использовать хранилище данных в памяти. Что произойдет, если завтра, через месяц или год вы решите добавить функцию, которая действительно выиграет от постоянства? С CoreData вы просто изменяете или добавляете постоянное хранилище данных, и все ваши методы для получения или вывода информации остаются без изменений. Затраты на такого рода добавления минимальны по сравнению с тем, если вы пытаетесь получить доступ к SQLite или другому хранилищу данных напрямую. ИМХО, это самое большое преимущество: абстракция. И, по сути, абстракция является одной из самых мощных вещей в ООП. Конечно, построение модели данных только для хранения в памяти может быть излишним для вашего приложения, в зависимости от того, насколько приложение вовлечено. Но, как примечание, вы можете подумать о том, что быстрее: запрашивать информацию у вашего веб-сервиса каждый раз, когда вы хотите выполнить какое-либо действие, или запрашивать информацию один раз, сохранять ее в памяти и воздействовать на это сохраненное значение для остаток сессии. Хранилище данных в памяти не будет сохраняться после этого конкретного сеанса.

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

Answer 2

Существуют в основном два вида приложений.Те, которые предоставляют вам локальную функциональность (игры, профессиональные приложения, навигационные системы ...) и те, которые предоставляют доступ к удаленному сервису.

Похоже, ваше приложение относится ко второй категории.Если вы обращаетесь к удаленным службам, ваши пользователи захотят получить доступ к новым данным или данным в режиме реального времени (вы не хотите читать 2-недельные сообщения Facebook), но в некоторых случаях имеет смысл локальное кэширование (например, чтение ваших писем, когда выв поезде с нестабильной сетью).

Я предполагаю, что ценность доступа к кэшированным записям, когда они не подключены к сети, довольно низка для ваших клиентов (внутренних или внешних) по сравнению с важностью доступа в режиме реального времени.данные.Таким образом, локальное хранилище может вообще не понадобиться.

Если в вашем расписании нет сотен записей, «нормальной» сериализации (NSCoding-protocol) может быть достаточно.Если вы получите доступ только к некоторым «данным панели», вы сможете обойтись простым кэшированием запросов / ответов (NSURLCache может многое сделать ...).

Базовые данные имеют больше смыслаЕсли у вас есть сложные структуры данных, которые должны быть синхронизированы с сервером.Это добавляет много логики синхронизации в ваш проект, а также усложняет интеграцию с Core Data (параллелизм, безопасность потоков, конфликты внутри приложения ...).

Если вы хотите создать «клиента»-app с пользовательским интерфейсом, управляемым сервером, локальное хранилище вообще не требуется, поэтому я предлагаю следующее: держите его как можно более простым, если только нет реальной потребности в автономном хранилище.

Answer 3

Это идеально подходит, если вы хотите хранить данные локально на телефоне.

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

Решение проблем с синхронизацией, которые у вас возникли бы в «автономном» режиме, будет подробно описано в вашем дизайне вашего приложения. Например - не разрешать удалять проекты. Почему ты? Не хотите ли вы вернуться назад во времени и посмотреть на предыдущие данные по конкретным проектам? Вместо этого просто добавьте маркер в проект, чтобы показать его как неактивный, и дату / время, когда он был сделан неактивным. Если данные, синхронизируемые с устройства, предназначены для этого проекта и находятся до даты / времени, когда они были помечены как неактивные, синхронизация возможна. В противном случае отобразите сообщение, и пользователь должен будет его отсортировать.

Answer 4

Это зависит исключительно от дизайна вашего приложения, нужно ли вам хранить некоторые данные локально или нет, если это реальная проблема или тонкий GUI-клиент вокруг вашего веб-сервиса. Помимо режима «офлайн», другой причиной для кэширования данных сервера на стороне клиента может быть загрузка трафика с вашего сервера. Подумайте, что означает, что ваш сервер каждый раз отправляет все данные расписания клиенту или только изменения. Да, это означает больше реализации с обеих сторон, но в некоторых случаях это имеет серьезные преимущества.

РЕДАКТИРОВАТЬ: пример добавлен

У вас есть 1000 записей на пользователя в приложении расписания, и одна запись составляет около 1 Кбайт. В этом случае каждый раз, когда пользователь запускает ваше приложение, оно должно извлекать данные размером ~ 1 Мбайт с вашего сервера. Если вы кэшируете данные локально, сервер может сказать вам, что, скажем, две записи были обновлены с момента вашего последнего обновления, поэтому вам нужно будет загрузить только 2 Кбайт. Теперь вам нужно увеличить это значение для нескольких десятков тысяч пользователей, и вы сразу заметите разницу в пропускной способности сервера и загрузке процессора.