Обновление обложки пакета при добавлении нового элемента временной шкалы

У меня есть приложение для Android, и я разрабатываю приложение для очков в качестве компаньона.

Код приложения находится в двух местах:

  • Веб-приложение (аутентификация OAuth/создание токена, создание подписки, обработка обратных вызовов уведомлений с сервера Google)
  • Приложение для Android (создание контакта для обмена, удаление контакта для обмена и создание обложки пакета для «фотоальбома»)

После обработки всей аутентификации OAuth и взаимодействия с Mirror API пользователь может в приложении Android создать общий контакт. Часть этого процесса включает в себя создание элемента временной шкалы, который служит обложкой пакета для фотоальбома.

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

Все это работает нормально - проблем нет.

С чем сталкиваюсь, так это с тем, что через 7 дней из интерфейса Glass начинают падать карточки таймлайна. Сюда входит моя обложка для "фотоальбома".

Очевидно, мне нужно обновить обложку пакета, чтобы оставаться активным, но я не совсем уверен, как это сделать (то есть без быстрого разрыва моей квоты). Используя API-интерфейс Mirror, я смог получить элементы из временной шкалы, а затем проверить каждый из них на наличие покрытия моего пакета (на основе идентификатора пакета и флага isBundleCover), но это ужасно неэффективно, когда речь идет о сохранении моих 1000 запросов на каждый. день. Я просто использую пакет не по назначению?

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

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

Спасибо за любые предложения!


google-glass google-mirror-api
person Kyle    schedule 16.07.2013    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

Кроме того, есть некоторые вещи, которые вы можете сделать, чтобы упростить поиск карточки на временной шкале через Mirror API, поскольку timeline.list предлагает несколько дополнительных параметров для сужения результатов.

  1. ?bundleId=yourBundleId

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

  2. &sourceItemId=something

    Если ваши наборы становятся настолько большими, что обложку пакета нельзя найти на первой странице результатов, вы можете дополнительно определить sourceItemId, который вы устанавливаете только для обложки пакета и ни для одной из других карт внутри расслоение. Таким образом, при поиске bundleId + sourceItemId (которое вы также можете установить на тот же пакетId, чтобы упростить его) будет только один элемент, обложка пакета, в результате.

Используя эти методы, вы сможете найти правильную карту в одном запросе и обновить ее во втором запросе.

person Scarygami    schedule 16.07.2013
comment
Спасибо за комментарии и подтверждение части моей теории о том, как справиться с обновлением. Если в ближайшие пару дней не будет представлено никаких других идей, я приму это как ответ. Спасибо еще раз! - person Kyle; 17.07.2013