最新のエントリを取得するには、最新のエントリから開始する標準の from-newest-date-descending ダウンロードを使用します。次のような XML 結果で「継続」トークンを受け取ります。
<gr:continuation>CArhxxjRmNsC</gr:continuation>`
結果をスキャンして、新しいものを引き出します。すべての結果が新しいか、ある時点までのすべてが新しく、その後はすべて既知であることがわかるはずです。
後者の場合はこれで完了ですが、前者の場合は、既に取得したものより古い新しいものを見つける必要があります。これを行うには、継続を使用して、取得したセットの最後の結果の直後から結果を取得しcます。たとえば、GET リクエストでパラメータとして渡します。
http://www.google.com/reader/atom/user/-/state/com.google/reading-list?c=CArhxxjRmNsC
すべてが揃うまでこの方法を続けます。
取得する項目数のnカウントであるパラメーターは、これでうまく機能し、必要に応じて変更できます。チェックの頻度がユーザー設定であり、非常に頻繁または非常にまれな場合は、適応アルゴリズムを使用してネットワーク トラフィックと処理負荷を軽減できます。最初に少数の最新エントリ (たとえば 5 つn=5) を要求します (GET 要求の URL に追加します)。すべてが新しい場合は、継続を使用する次のリクエストで、より大きな数、たとえば 20 を要求します。それらがまだすべて新しい場合は、フィードに多くの更新があるか、しばらく経っているため、続行します。 100人くらいのグループで。
ただし、ここで間違っている場合は訂正してください。アイテムをダウンロードした後、ユーザーが Google リーダー インターフェースを使用してアイテムを読んだために、アイテムの状態が「未読」から「既読」に変化したかどうかも知りたいと考えています。
これに対する 1 つのアプローチは次のとおりです。
- ローカルで読み取られたアイテムの Google でのステータスを更新します。
- フィードの未読数を確認して保存します。(次のステップの前にこれを行い、最新のアイテムをダウンロードしてから読み取りカウントを確認するまでの間に新しいアイテムが到着していないことを保証します。)
- 最新のアイテムをダウンロードしてください。
- 読み取り回数を計算し、それを Google と比較します。フィードの読み取り数が計算したよりも多い場合は、Google で何かが読み取られたことがわかります。
- Google で何かが読まれた場合は、既読アイテムのダウンロードを開始し、それらを未読アイテムのデータベースと比較します。データベース クレームが未読であることを Google が既読と言っているアイテムがいくつか見つかります。これらを更新します。これらの項目の数が、あなたの読み取り回数と Google の読み取り回数の差に等しいか、ダウンロード数が理不尽になるまで、この作業を続けます。
- すべての既読項目が見つからない場合は、c'est la vie ; 残りの数を「未読未読」の合計として記録します。これは、未読と思われるローカル番号の次の計算にも含める必要があります。
ユーザーが多くの異なるブログを購読している場合、彼はそれらに広範囲にラベルを付けている可能性が高いため、フィード全体ではなく、ラベルごとにこのすべてを行うことができます。これにより、データの量を抑えることができます。ユーザーが Google リーダーで新しいものを読んでいなかった場合、ラベルの転送を行う必要はありません。
このスキーム全体は、スター付きまたはスターなしなどの他のステータスにも適用できます。
さて、おっしゃるとおりこれは
...クライアントで自分の既読/未読状態を維持する必要があり、ユーザーがオンライン バージョンの Google リーダーにログオンしたときに、エントリが既に既読としてマークされていることを意味します。それは私にはうまくいきません。
十分に真実です。ローカルの既読/未読状態を保持すること (とにかくすべてのアイテムのデータベースを保持しているため) も、アイテムを Google で既読としてマークすること (API がサポートしている) も非常に難しいように思えますが、なぜこれがうまくいかないのでしょうか?
ただし、もう 1 つの問題があります。ユーザーは、Google で既読を未読としてマークする可能性があります。これにより、システムに少しのレンチが投げ込まれます。私の提案は、あなたが本当にこれを処理したいのであれば、一般的にユーザーが最近のものだけに触れていると仮定し、最新の数百程度のアイテムを毎回ダウンロードし、すべてのステータスをチェックすることです.彼ら。(これはそれほど悪いことではありません。非常に高速なブロードバンド接続ではありますが、100 個のアイテムをダウンロードすると、300KB の場合は 0.3 秒、2.5MB の場合は 2.5 秒かかりました。)
繰り返しになりますが、ユーザーが多数のサブスクリプションを持っている場合は、かなり多くのラベルも持っている可能性が高いため、ラベルごとにこれを行うと速度が向上します。実際には、ラベルごとにチェックするだけでなく、20 分に 1 回すべてをチェックするのではなく、1 分ごとに 1 つのラベルをチェックして、チェックを分散することをお勧めします。また、帯域幅を抑えたい場合は、「新しいアイテム」のチェックよりも少ない頻度で、おそらく数時間ごとに、古いアイテムのステータス変更のこの「大きなチェック」を行うことができます。
これは主に、ステータスを確認するためだけに記事全体を Google からダウンロードする必要があるため、帯域幅を少し消費します。残念ながら、私たちが入手できる API ドキュメントでは、それを回避する方法がわかりません。私の唯一の本当のアドバイスは、新品ではないアイテムのステータスのチェックを最小限にすることです.