Как пропустить известные записи при синхронизации с Google Reader?

Чтобы получить последние записи, используйте стандартную загрузку по убыванию от новейшей даты, которая будет начинаться с самых последних записей. Вы получите токен «продолжения» в результате 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-запроса). Если все новые, в следующем запросе скажем, пять (добавьте n = 5 к URL-адресу вашего GET-запроса). Если все новые, в следующем запросе скажем, пять (добавьте n = 5 к URL-адресу вашего GET-запроса). Если все новые, в следующем запросе где вы используете продолжение, попросите большее число, скажем, 20. Если они все еще новые, либо в канале много обновлений, либо прошло некоторое время, поэтому продолжайте работу группами по 100 или что-то еще.

Однако и поправьте меня, если я ошибаюсь, вы также хотите знать, после того, как вы загрузили элемент, изменилось ли его состояние с «непрочитанного» на «прочитанное» из-за того, что человек читает его с помощью интерфейса Google Reader.

Один из подходов к этому:

1. Обновить статус в Google всех элементов, которые были прочитаны локально.
2. Проверить и сохранить счетчик непрочитанных для ленты. (Вы хотите сделать это до следующего шага, чтобы гарантировать, что новые элементы не будут доставлены между загрузкой новейших элементов и временем, когда вы проверите счетчик чтения.)
3. Загрузите последние элементы.
4. Рассчитайте ваш счетчик чтения, и сравните это с Google. Если канал имеет большее количество прочтений, чем вы рассчитали, вы знаете, что что-то было прочитано в Google.
5. Если что-то было прочитано в Google, начните загружать прочитанные элементы и сравнивать их с вашей базой данных непрочитанных элементов. Вы найдете некоторые элементы, которые, по утверждениям Google, прочитаны, что ваши требования к базе данных не прочитаны; обновите их. Продолжайте делать это, пока не найдете количество этих элементов, равное разнице между вашим счетчиком чтения и счетчиком Google, или пока количество загрузок не станет необоснованным.
6. Если вы не нашли все прочитанные элементы, c 'est la vie ; запишите оставшееся число как «ненайденное непрочитанное» общее количество, которое вам также необходимо включить в следующий расчет местного номера, который вы считаете непрочитанным.

Если пользователь подписывается на множество разных блогов, также вероятно, что он сильно помечает их, поэтому вы можете делать все это для каждой метки, а не для всего фида, что должно помочь уменьшить объем данных, поскольку вам не нужно будет делать какие-либо передачи для меток где пользователь не читал ничего нового в Google Reader.

Вся эта схема может быть применена и к другим статусам, таким как помеченный или не помеченный.

Теперь, как вы говорите, это

.. .это означает, что мне нужно сохранить мое собственное состояние чтения / непрочитанности на клиенте и что записи уже помечаются как прочитанные, когда пользователь входит в онлайн-версию Google Reader. У меня это не работает.

Достаточно верно. Ни сохранение локального состояния прочитанного / непрочитанного (поскольку вы все равно храните базу данных со всеми элементами), ни маркировка элементов, прочитанных в Google (что поддерживает API), не кажется очень сложным, Так почему у вас это не работает?

Однако есть еще одна проблема: пользователь может пометить что-то прочитанное в Google как непрочитанное. Это немного затрудняет работу системы. Мое предложение, если вы действительно хотите попытаться позаботиться об этом, состоит в том, чтобы предположить, что пользователь в целом будет касаться только более свежих материалов, и загружать последние пару сотен или около того элементов каждый раз, проверяя статус на всех их. (Это еще не все , что плохо; загрузка 100 элементов заняла у меня от 0,3 с для 300 КБ, до 2,5 с для 2,5 МБ, хотя и при очень быстром широкополосном соединении.)

Опять же, если Пользователь имеет большое количество подписок, у него также, вероятно, достаточно большое количество ярлыков, поэтому выполнение этого для каждого ярлыка ускорит процесс. На самом деле я бы посоветовал вам не только проверять каждую метку, но вы также распределяете чеки, проверяя одну метку каждую минуту, а не все каждые двадцать минут. Вы также можете выполнять эту «большую проверку» на предмет изменений статуса для старых элементов реже, чем «новую», возможно, раз в несколько часов, если вы хотите снизить пропускную способность.

Это небольшая пропускная способность. hog, в основном потому, что вам нужно загрузить полную статью из Google просто для проверки статуса. К сожалению, я не вижу никакого способа обойти это в документации по API, которая у нас есть. Мой единственный реальный совет - свести к минимуму проверку статуса не новинок.