Как пропустить известные записи при синхронизации с 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-запроса). Если все они новые, в следующем запросе, в котором вы используете продолжение, попросите большее число, скажем, 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 МБ, хотя и при очень быстром широкополосном соединении.)

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

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

Google API еще не выпущен, после чего этот ответ может измениться.

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