各イベントの情報をデータストアに複製しようとするのは最適ではないと思います。すべてが必要な場合は、大量のデータを保存することになり、その大部分は役に立たないと思います。
統計分析用にデータを保存する場合は、追跡するフィールドの最小セットを決定し、それらを保存することをお勧めします。適切なフィールドのセットは、イベント ID、名前、時間、出席者、場所、説明、簿記用の内部バージョン番号です。フィールドが変更されるたびにバージョン番号を増やし、新しいフィールド情報を保存します。追加のクレジットとして、フィールドのハッシュを保存し、最近取得したエントリのハッシュが既に保存されているものと一致する場合、新しいバージョンを保存しないようにすることができます。
イベント全体をサーバーに保存する必要がなくなったため、イベントの詳細が必要なときに API を直接クエリするかどうかという問題は、明らかに「はい」です。
Google カレンダーは、カレンダーの予定が作成または変更されたときにメール通知を提供します。カレンダーに表示される新しいイベントについてユーザーに通知されることに関心がある場合は、フィールドを ( insert a new eventsendNotifications
の呼び出しで)に設定することで簡単に対処できます。API (およびユーザーがイベントを変更するときのカレンダー UI) の update および delete 呼び出しにも同様の機能があります。true
この実装で最も難しい部分は、ユーザーが変更を加えたときにイベントがいつ変更されるかをアプリケーションがどのように判断するかを決定することです。(コードで行った変更は、データストアに保持しているデータにすぐに反映できます。) 1 つのカレンダーにすべてのイベントが表示される場合は、API をポーリングしてイベントのリストを取得し、フィールドを使用updatedMin
して時刻を指定できます。更新のために最後にクエリされました。イベントが複数のカレンダーにある場合、アプローチは同じですが、カレンダーごとに 1 つのリストを作成する必要があります。
アプリケーションに提供する資格情報は、変更する予定表に対して読み書きできる必要があることに注意してください。最初のアプローチとして、追跡しているすべてのイベントの出席者としてリストされるアプリケーションのマスター カレンダーを作成することをお勧めします。ユーザーに代わって作成するイベントには、ユーザーが出席者としてリストされます。ユーザーが作成したイベントをアプリケーションに関連付けるには、マスター カレンダーを出席者として追加する必要があります。この最後のポイントでは、管理ユーザーがシステムとやり取りするための正しい方法についてトレーニングを受ける必要がある場合があります。
上記の代わりに、すべてのユーザーに自分のカレンダーへのアクセスをアプリケーションに委任させることもできますが、複数の資格情報セットを管理し、追跡する必要のないユーザーのカレンダーのイベントを除外する必要があります。