我的最终目标是为我的移动用户（iCal和iOS）提供一个Android供稿。这是一个运动计划，其中包含每个用户的个人日历计划。通常每位用户一个季节有20个事件-整个季节中偶尔会重新安排某些活动/取消比赛-并为幸运入围者添加一次季后赛活动。
为每个用户创建此供稿的初始版本不是问题（创建了VCALENDAR和多个VEVENT等）。设计取消/重新安排工作是实施/测试的难点。
对于Android用户，我假设用户拥有一个Google帐户，并且可以使用Google的calendar service（Other Calendars-> +-> {{1} }。这可以正常工作，但是刷新间隔（即使设置得更快，From URL）似乎也每隔24小时便会四舍五入一次。这使得事件更改测试非常缓慢。
所以我有一个两部分的问题：
第1部分：开发
REFRESH-INTERVAL;VALUE=DURATION:PT3H上有一项服务，可以更快地测试Feed更改吗？也许Android iCal订阅采用更快的刷新率？也许使用CalDAV移动应用程序？我希望最终用户必须做最少的设置才能连接到提要。因此，对于生产而言，不需要安装移动应用程序-如果在移动设备上提供相同的日历事件，则可以进行开发。
也许最适合iOS和Android的通用iOS供稿？
第2部分：生命周期
如何管理日历事件的生命周期？
我为每个日历事件分配了唯一性/持久性iCal-以随着时间的推移唯一地定位它们。但是，由于遗留决策（日程表数据库不跟踪历史更改，仅当前日程表状态），无法知道单个事件是否/何时发生了更改，因此也无法知道何时增加事件的UID号）。
所以我的第一个想法是，对于少数用户（〜30），事件数量有限（〜20），如果有任何重新安排事件-无论它是否影响任何用户-只需将{对于 all 用户和 all 事件，{1}}减1。这将强制更新所有事件（无论字段是否更改）-但可以确保每个人都有最新的日程表。全局序列号可以轻松地存储在它自己的表中-不会影响现有的调度数据库架构。
第二个问题是，这种设计方法是否被视为滥用iCal Feed协议？也就是说，将发送SEQUENCE到大多数日历事件的更新-实际没有更改任何字段-对用户的移动设备造成意想不到的后果吗？