IOS синхронизация по времени

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

Какие шаблоны проектирования лучше всего подходят для такой задачи в ios?

Некоторые приходят мне в голову, но я не так опытен.

Возможно, push push-уведомления, сервер должен выталкивать сообщение всем клиентам, когда доступна новая версия.
Или есть ли что-то похожее на Android Service, которое может помочь?
Или, может быть, каждый раз, когда приложение запускается (или выходит на передний план), просто пинговать сервер и посмотреть, есть ли что-то новое.
Или каждый раз, когда приложение запускает ping-сервер и добавляет таймер на следующие 12 часов, если это приложение все равно будет на переднем плане.
Или, каждый раз, когда приложение запускается, проверьте значение предпочтения, и если последний раз, когда сервер пинговал, было больше 12 часов назад, а затем пинговать его сейчас. И затем сохраните это время пинга.

Вариант 1 может быть более тяжелым на сервере и может быть сложнее реализовать (рассмотрим ios newbe), но может быть единственным вариантом для реального обновления фона. Но даже в этом случае я до сих пор не хочу, чтобы пользователь должен был реагировать на некоторые низкоуровневые обновления данных b/wa client и сервера (и то, что это такое), поэтому, если push-уведомления не могут перейти непосредственно к приложению и выполнить что-то без вмешательства пользователя, тогда этот вариант не летает.
Варианты 3-5 возможны и не звучат слишком сильно, но они будут работать только в том случае, если приложение находится на переднем плане.

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

Возможно, ограничения на месте имеют хорошую причину, поэтому, как я могу играть по правилам и быть в состоянии добиться периодического сервера ping (или, в более общем плане, решить проблему периодических клиентов и серверов с синхронизацией b/w, даже когда приложения находятся в bg)?

Спасибо

Ответ 1

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

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

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

Apple не предоставляет программистам механизм загрузки нового контента в фоновом режиме для большинства типов приложений. Согласно объявлениям Apple, функция ISS 5 Newsstand позволит обновлять подписки в фоновом режиме. Возможно, в будущем у разработчиков будет больше возможностей для загрузки фона.

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

Я бы использовал push-уведомления (метод 1), если люди захотят узнать как можно скорее, что новые данные доступны. Это будет зависеть от темы.

iOS не имеет ничего подобного службе Android (метод 2)

У меня есть приложение, которое проверяет канал RSS для новостей каждый раз, когда приложение запускается (метод 3). Это приложение в основном делает другие вещи, но показывает фид на начальном представлении. Поскольку приложение является простой утилитой, которая помогает людям найти конкретное решение, RSS-канал является вспомогательным.

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

Моя реализация метода 5 в моем доступном в настоящее время приложении имеет небольшое отклонение. Он загружает данные только для одного из многих видов. Каждый раз, когда этот просмотр посещается, он проверяет время хранения, чтобы увидеть, нужно ли ему загружать свежие данные. Затем он просит разрешения.

Ответ 2

Возможно, ограничения на месте имеют хорошую причину, поэтому как мне играть по правилам и иметь возможность добиться периодического сервера ping (или более как правило, решают проблему периодических клиентов и серверов синхронизации b/w даже когда приложения находятся в bg)?

Любой из вариантов 3, 4 или 5 - правильный путь.

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

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

Возьмите пользовательский ввод, но не покажите результат, пока не подтвердите, что данные обновлены (или загружены новые данные).
Возьмите пользователей и покажите результат с помощью данных, которые у вас есть, но покажите результат таким образом, чтобы он мог понять, что результат может измениться. Это может означать отображение вертушки рядом с числами, которые могут измениться или, возможно, показать сомнительные числа в другом цвете.
Отобразите сообщение "Последнее обновление данных:..." где-то поблизости.

Пользователи обычно не против ждать нескольких секунд, чтобы мобильное приложение выполняло свою работу, особенно если: а) они понимают, почему происходит задержка, и б) их устройство отлично работает в других отношениях, например, что значительно увеличивает срок службы батареи, чем другие устройства. Например, я постоянно удивляюсь, как долго мой iPad будет работать, прежде чем потребуется перезарядка; если компромисс в том, что я должен ждать несколько минут, чтобы приложения попали в сеть, я в порядке с этим.

Ответ 3

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

Одна из основных концепций дизайна в iOS заключается в том, что приложение делает то, что пользователь просит. поэтому, если у вас есть обновления, требующие большого объема данных, которые вам нужно установить, push-уведомления и диалог обновления - это то, как вы должны идти. Если ваши обновления очень часты (вы писали о 12h-проверках → предполагая цикл обновления 24-48 часов), вы можете загружать новые данные каждый раз, когда приложение запускается. Дружественным для iPad является хорошим примером этого - они загружают тонны html/javascript/css для использования в качестве рамки для отображения содержимого facebook в WebView, потому что структуры facebook быстро меняются.

Ответ 4

Я бы добавил строку режима фона voip в ваш файл Info.plist. Затем вы можете вызвать setKeepAliveTimeout:handler:, который позволяет периодически запускать запланированную задачу. Имейте в виду, что он будет использовать больше батареи.

Дополнительная информация: http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH5-SW15