イベント駆動型サービス実行基盤としての Service Worker - Qiita
当初は better AppCache1 として開発が始まった Service Worker2 ですが、ページとは独立したライフサイクルを持つことでイベント駆動型のサービス3実行基盤としての色合いが強くなっています。本記事では、イベント駆動型のサービス実行基盤とは何なのか、そこへと発展していった流れについて紹介します。 なお本記事は Service Worker の使い方を紹介するものではありません。Service Worker をある程度理解している開発者を想定読者としています。また、本記事はすべて私の個人的な意見や調査に基づくものであり、所属する組織、団体とは一切関係ありません。前置きおわり。 AppCache、そして Service Worker へ 冒頭でも述べた通り、Service Worker は当初 better AppCache として開発が始まりました4 5 6。AppC
お疲れさまXMLHttpRequest、こんにちはfetch - Qiita
Service Workersでプッシュ通知を受信できるようになったわけですが([1]: GCM)([2]: Web Push)、Chromeではバージョン48まではGCMで通知だけができるようになっただけで、メッセージ本体は通知を受けてからService Workerでサーバから改めて受け取るような実装をする必要があったりします。 ここで、Service Workersでは、XMLHttpRequestが使えません。その代わり、XMLHttpRequest (以下、XHR)に代わるWHATWGの仕様としてFetch APIがあり、Service WorkersではこのFetch APIを使うことになっていますので、その使い方を簡単に紹介します。 Fetch API自体は、Service Workers専用のものではなく、メインスレッドでもXHRの代わりに使うことが可能です。現時点で実装し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
