Чтобы получить последние записи, используйте стандартную загрузку от самой новой даты по убыванию, которая начнется с самых последних записей. В результате XML вы получите токен «продолжения», который выглядит примерно так:
<gr:continuation>CArhxxjRmNsC</gr:continuation>`
Просматривайте результаты, извлекая что-то новое для вас. Вы должны обнаружить, что либо все результаты являются новыми, либо все до определенного момента является новым, и все после этого вам уже известно.
В последнем случае все готово, но в первом случае вам нужно найти новый материал старше, чем тот, который вы уже получили. Сделайте это, используя продолжение, чтобы получить результаты, начиная сразу после последнего результата в наборе, который вы только что получили, передав его в запросе GET в качестве параметра c, например ::
http://www.google.com/reader/atom/user/-/state/com.google/reading-list?c=CArhxxjRmNsC
Продолжайте в том же духе, пока не получите все.
Параметр n, который является счетчиком количества элементов для извлечения, хорошо работает с этим, и вы можете изменять его по мере необходимости. Если частота проверок установлена пользователем и, таким образом, может быть очень частой или очень редкой, вы можете использовать адаптивный алгоритм, чтобы уменьшить сетевой трафик и нагрузку на обработку. Сначала запросите небольшое количество последних записей, скажем, пять (добавьте n=5 к URL-адресу вашего запроса GET). Если все новые, в следующем запросе,
там, где вы используете продолжение, попросите большее число, скажем, 20. Если они все еще новые, либо в ленте много обновлений, либо прошло какое-то время, поэтому продолжайте в группах по 100 или как угодно.
Однако, и исправьте меня, если я здесь не прав, вы также хотите знать, после загрузки элемента, меняется ли его состояние с «непрочитанное» на «прочитанное» из-за человека, читающего его с помощью Google Интерфейс считывателя.
Один из подходов к этому:
- Обновите статус в Google для всех элементов, которые были прочитаны локально.
- Проверьте и сохраните счетчик непрочитанных для канала. (Вы хотите сделать это до следующего шага, чтобы гарантировать, что новые элементы не поступили между загрузкой самых новых элементов и временем проверки количества считываний.)
- Загрузите последние версии.
- Подсчитайте количество прочитанных и сравните их с Google. Если в ленте больше считанных данных, чем вы рассчитывали, вы знаете, что что-то прочитано в Google.
- Если что-то было прочитано в Google, начните загружать прочитанные элементы и сравнивать их с вашей базой данных непрочитанных элементов. Вы найдете некоторые элементы, которые, по словам Google, прочитаны, а утверждения вашей базы данных непрочитаны; обновить это. Продолжайте делать это до тех пор, пока не найдете число этих элементов, равное разнице между вашим счетом чтения и Google, или пока загрузка не станет необоснованной.
- Если вы не нашли все прочитанные предметы, c'est la vie ; запишите оставшееся число в виде «непрочитанного непрочитанного» итога, которое вам также необходимо включить в следующий расчет локального номера, который вы считаете непрочитанным.
Если пользователь подписывается на множество разных блогов, вероятно, он также широко их помечает, поэтому вы можете делать все это отдельно для каждой метки, а не для всего фида, что должно помочь сохранить объем данных вниз, так как вам не нужно делать какие-либо переводы для ярлыков, где пользователь не прочитал ничего нового в Google Reader.
Вся эта схема может быть применена и к другим статусам, таким как помеченные или не помеченные звездочкой.
Теперь, как вы говорите, это
... означало бы, что мне нужно сохранять собственное состояние чтения / непрочитания на клиенте и что записи уже помечаются как прочитанные, когда пользователь входит в онлайн-версию Google Reader. Это не работает для меня.
Достаточно верно. Ни сохранение локального состояния чтения / непрочитанного (так как вы все равно сохраняете базу данных всех элементов), ни пометка элементов, читаемых в google (которые поддерживает API), не кажется очень трудным, так почему это не работает для вас?
Однако есть еще одна загвоздка: пользователь может пометить что-то прочитанное как непрочитанное в Google. Это бросает немного рывок в систему. Мое предложение, если вы действительно хотите позаботиться об этом, состоит в том, чтобы предположить, что пользователь в общем случае будет касаться только самых последних материалов, и загружать последние пару сотен или около того элементов каждый раз, проверяя состояние всех их. (Это еще не все , что плохо; загрузка 100 элементов заняла у меня от 0,3 с для 300 КБ до 2,5 с для 2,5 МБ, хотя и при очень быстром широкополосном соединении.)
Опять же, если у пользователя большое количество подписок, он также, вероятно, получил достаточно большое количество ярлыков, поэтому выполнение этого для каждого ярлыка ускорит процесс. На самом деле, я бы посоветовал вам не только проверять на основе каждого ярлыка, но также распределять чеки, проверяя один ярлык каждую минуту, а не все раз в двадцать минут. Вы также можете выполнять эту «большую проверку» для изменений состояния на более старых элементах реже, чем делать «новую проверку», возможно, раз в несколько часов, если вы хотите снизить пропускную способность.
Это немного снижает пропускную способность, в основном потому, что вам нужно скачать полную статью из Google, просто чтобы проверить статус. К сожалению, я не вижу никакого способа обойти это в документах API, которые у нас есть. Единственный мой реальный совет - минимизировать проверку статуса на не новинках.