编辑：我的Brotkrumen Web App有一个新版本在同一个位置。
最重要的设计/建议规范更改是TravelManager订阅现在应该是客户特定的。 TravelEvent必须包含预期的Client.id（TravelEvent.source.id）。这意味着UA必须监控和过滤每个客户端的GeoLocation更新。我还添加了新的演示功能，例如按下“到达”按钮时显示的行程摘要。也可以按“Map Trip”或“Replay”将行程重播到Google地图上。如果行程的最后一个和下一个地理定位更新都在地图窗口中可见，则通过CSS过渡实现平滑的标记移动。
PLEASE 帮助后台GeoLocation启动并帮助Web Apps与Native Apps竞争！
如果我的TravelManager解决方案设计出现问题，请告诉我。撕裂它！
原始问题：
有一段时间以来，我一直在与W3C / IETF（以及任何其他参与者）争论，ServiceWorkers是举办Ultimate Web Apps所需的背景地理位置功能的理想平台，以便在公平的竞争环境中竞争使用Native Apps。关键点通常是ServiceWorkers寿命的短暂性质。我一直认为立即杀死它们会很疯狂，大多数实现似乎都同意。 （Firefox在30secs中最具攻击性，请参见Bug，即使有大量CPU /内存，这种行为仍占主导地位）
无论如何，为了证明我是对的，Jake Archibald这样的人非常错误，我写了一点Web App。 （有一个aaa_readme.txt）
现在仍然需要一些工作来提供旅行摘要页面并在谷歌地图上绘制旅程，但我认为你会明白这一点，最重要的是看到服务工作者实例与实际的，可证明的关系。地理位置更新？ （我希望在8月欧洲人失踪之前把它拿出来： - ）
所以我在这里做了些蠢事吗？ 我想象的是，当我在回家的路上长时间停在灯光下并且无法看到位置更新时，我只获得了一个新的服务工作者实例？ 我的编码技巧是否可悲，测试技巧是否不存在？
如果没有，那么我不知道为什么不允许Web Apps满足这些合法且非常理想的用户需求。当然，我们将获得用户授权，权限和发现权，但让我们继续吧？ TravelManagerPolyfill.js文件几乎是 所有 UA开发人员必须做的事情！
问：我是否正确理解了ServiceWorker体系结构并实现了对ServiceWorker实例化的有效启发式查询？答案 0 :(得分：1)
答：是的，示例代码最终证明了服务工作者范例非常适合向Ultimate Web Apps提供备受吹嘘的背景地理位置。每次新位置更新的SW实例到期计时器的更新是SW寿命的关键。这是迄今为止Web应用程序背景地理位置难题中最具电池友好性和功能丰富的解决方案。
注意：我建议每个客户端使用一个单独的TravelManager实例（与POC示例不同）和Flex Box样式。
让我们希望UA供应商尽快接受这一点！