Разработка и жизненный цикл корма iCal - PullRequest
0 голосов
/ 08 мая 2019

Моя конечная цель - предоставить iCal фид моим мобильным пользователям (iOS и Android).Это спортивное расписание с личными календарными расписаниями для каждого пользователя.Как правило, 20 событий в сезоне для каждого пользователя - и со случайным переносом / отменой некоторых из этих событий в течение сезона - и одноразовые события плей-офф добавляются для счастливых финалистов.

Создание начальной версии этого канала длякаждый пользователь не был проблемой (создал VCALENDAR и несколько VEVENT и т. д.).Разработка элементов отмены / перепланирования является более сложной для реализации / тестирования.

Для Android пользователей, я предполагаю, что пользователи имеют учетную запись Google и могут подписаться, используя службу календаря Google (Other Calendars -> + -> From URL).Это работает нормально, но интервал обновления (даже если он установлен быстрее REFRESH-INTERVAL;VALUE=DURATION:PT3H), по-видимому, округляется до не очень частых раз в 24 часа.Это делает тестирование изменений событий утомительно медленным.

Итак, у меня есть вопрос из двух частей:

Часть 1: Разработка

Есть ли службана Android, где я могу быстрее проверить изменения подачи?Может быть, iOS подписки iCal обеспечивают более высокую частоту обновления?Может быть, использовать мобильное приложение CalDAV?Я хочу, чтобы конечные пользователи должны были выполнить минимальные настройки для подключения к каналу.Таким образом, для производства не требуется установка мобильного приложения, но для разработки это нормально, если на мобильном устройстве предусмотрены идентичные события календаря.

Возможно, общий канал iCal для iOS иAndroid не подходит лучше всего?

Часть 2. Жизненный цикл

Как управлять жизненным циклом событий календаря?

Я назначилуникальный / постоянный UID для каждого события календаря - чтобы однозначно нацелить их с течением времени.Однако из-за устаревших решений (база данных расписаний не отслеживает исторические изменения, только текущее состояние расписания * 1040) нет способа узнать, изменилось ли отдельное событие / когда (и, следовательно, нет способа узнать, когдаувеличить число событий SEQUENCE).

Итак, моя первая мысль - и только с ограниченным (~ 20) количеством событий для небольшого числа пользователей (~ 30), если есть какое-либо переназначениесобытие - влияет ли оно на какого-либо пользователя или нет - просто увеличьте SEQUENCE на 1 для всех пользователей и всех событий.Это приведет к обновлению всех событий (независимо от того, изменились поля или нет), но будет гарантировать, что у каждого будет самое последнее расписание.Глобальный порядковый номер может быть легко сохранен в его собственной таблице - и не повлиять на существующую схему базы данных планирования.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...