1

我有一个基于 Android 的应用程序，我正在开发一个 Glass 应用程序作为伴侣。

该应用程序的代码位于两个地方：

  • Web 应用程序（OAuth 身份验证/令牌创建、创建订阅、处理来自 Google 服务器的通知回调）
  • Android 应用程序（创建共享联系人、删除共享联系人和为“相册”创建捆绑包封面）

在处理完所有 OAuth 身份验证并与 Mirror API 通信后，用户可以在 Android 应用程序中创建共享联系人。该过程的一部分包括创建用作相册捆绑封面的时间线项目。

在 Glass 上，当用户与该联系人共享照片时，我的 Web 应用程序中的通知处理程序会将照片分配给在建立共享联系人时创建的包。

所有这一切都很好 - 没有问题。

我遇到的是 7 天后，时间线卡开始从 Glass 界面脱落。这包括我的“相册”套装封面。

显然我需要更新捆绑包以保持活动状态，但我不太确定如何做到这一点（也就是说，没有快速突破我的配额）。使用 Mirror API，我已经能够从时间线中检索项目，然后检查每个项目的捆绑包封面（基于捆绑包 ID 和 isBundleCover 标志） - 但在保留我的 1000 个请求时，效率非常低天。我只是以不适合的方式使用捆绑包吗？

有没有一种更简单、更有效的方法来获取捆绑包封面并简单地更新它，这样它就不会在 7 天后脱离时间线？在某种程度上，我似乎不需要每次共享新照片时都更新捆绑包，但我不确定是否有替代方案。

正如我所提到的，捆绑包是在 ​​Android 应用程序中创建的，并且该 ID 被提交到 Web 应用程序和 Android 应用程序共享的后端数据库。没有使用 bundleID 查询该数据库以获取捆绑包的原始 ItemID，我不确定如何在通知处理程序中使捆绑 ItemID 可访问。

感谢您的任何建议！

4

1 回答 1

3

正如您所提到的，在保留 API 配额方面最有效的方法是将itemID捆绑包的封面保存在您自己的数据存储中，并在需要时从那里检索它

除此之外，您还可以做一些事情来通过 Mirror API 更轻松地在时间轴中查找卡片，因为该timeline.list方法提供了一些额外的参数来缩小结果范围。

  1. ?bundleId=yourBundleId

    这只会返回带有提供的 bundleId 的结果，具体取决于您的捆绑包中有多少张卡片，您可能会在第一个结果页面上找到必要的卡片，因此只需要一个 API 请求

  2. &sourceItemId=something

    如果您的捆绑包变得相当大，以至于在第一个结果页面上找不到捆绑包封面，您可以做的一件事是另外定义一个sourceItemId您只为捆绑包封面设置的，而不是里面的其他卡片捆。这样查找bundleId+ sourceItemId（您也可以将其设置为相同的 bundleId 以使其更容易）将在结果中只有一个项目，即捆绑包封面。

使用这些方法，您应该能够在一个请求中找到正确的卡并在第二个请求中更新它。

于 2013-07-16T20:02:57.010 回答