EDIT：My Brotkrumen Web Appの新しいバージョンが同じ場所にあります。ジオロケーションアップデートに対するServiceWorkerインスタンスの予想される比率
最も重要な設計/提案仕様変更は、トラベラーマネージャーのサブスクリプションがクライアント固有であることです。 TravelEventには、目的のClient.id（TravelEvent.source.id）が含まれている必要があります。つまり、UAはクライアントごとにGeoLocationの更新を監視してフィルタリングする必要があります。また、「到着」ボタンを押したときに表示される旅行概要などの新しいデモ機能も追加しました。 「Map Trip」または「Replay」を押すと、Googleマップにトリップを再生することもできます。トリップの最後と次のジオロケーション更新が両方ともマップウィンドウに表示されていれば、スムーズなマーカ移動はCSSトランジションによって実現されます。
お気に入りヘルプ背景GeoLocationが立ち上がり、Webアプリケーションがネイティブアプリと競合するのを手伝ってください！
私のTravelManagerソリューションデザインに問題がある場合は、教えてください。そこに涙穴！
オリジナル質問：
私はServiceWorkersは究極のWebアプリがで必要な背景のジオロケーション機能をホストするための理想的なプラットフォームであることをW3C/IETF（および従事したい他の誰）と主張してきたいくつかの時間のためにネイティブアプリとの競技場で競争するためです固執するポイントは、通常、ServiceWorkersの寿命の瞬間的な性質です。私はいつもすぐにそれらを殺すことは狂気であると主張しており、ほとんどの実装は同意しているようです。 （Firefoxが30秒で最も積極的になるのはBugだが、CPU /メモリのヒープでもこの現象が起こる）
とにかく、私が正しいことを証明するために、Jake Archibaldのお気に入りは非常に間違っていると書いてある。少しWeb App。
旅行のサマリーページを提供してGoogleマップで旅行をマッピングするにはまだ少しの作業が必要ですが、あなたはアイデアを得て、最も重要なのは現実の世界を見て、サービスワーカーインスタンスとジオロケーションの更新の実際的で実証可能な関係（私はヨーロッパ人が8月に消えた前にそれを手に入れたいと思っていた:-)
私はここで何か愚かなことをしたことがありますか？ 私は家に帰る途中で長い間ライトについていて、ポジションの更新がどこにも見られないときに、新しいService workerインスタンスを取得すると思いますか？ 私のコーディングスキルは嘆かわしく、テストスキルは存在しませんか？
もしそうでなければ、Web Appsが正当で非常に望ましいユーザー要件を満たすことができない理由はわかりません。確かに、ユーザーのエンパワーメント、アクセス許可、および検出は正しく行われますが、それに取り掛かりましょうか？ TravelManagerPolyfill.jsファイルはほぼです。 UAの開発者が行う必要があります！
Q：ServiceWorkerアーキテクチャを正しく理解し、時間の経過とともにServiceWorkerインスタンスの有効なヒューリスティックな質問を実装しましたか？