ウェブページを2画面対応にするPresentation APIを使ってみる - Qiita
ウェブページでは既にFullscreen APIで全画面表示にすることはできますが、現在表示中のページをそのままにして、例えばスライドショーやプレゼンテーションを別画面で全画面表示する、といったことができればもっと便利になります。 Chromeでは、外部接続のディスプレイやChromecast等(以下、レシーバ)に別のウェブページを表示させて、ブラウザ側のデバイス(以下、コントローラ)から操作できる、Presentation APIが実装されていますので、その使い方を簡単に説明します。 Chrome 59以降ではChromecastやAndroid TVへのキャスト、Chrome 66以降ではHDMI等のケーブル接続の外部モニタへの表示に対応しています。現時点での対応プラットフォームは、Chrome OS, Linux, Windows, macOS (外部接続モニタのみChrome 69
Web Pushでブラウザにプッシュ通知を送ってみる - Qiita
本記事のアップデートについて ※ Chrome 60以降、Firefox 55以降では、暗号化の手順に変更が生じます。詳細は、[改訂版] Web Pushでブラウザにプッシュ通知を送ってみるを参照してください。 2022-05-03: 今後メンテナンスを行わない見通しであることから、Javaで動作するデモの公開を終了いたします。長らくありがとうございました。なお、GitHubリポジトリはそのまま残しますので、古いコードでよろしければ参考になれば幸いです。 はじめに 先に「ChromeでW3C Push APIを使ってみた」や「Firefox (Developer Edition)でW3C Push APIを使ってみる」で書きましたように、ブラウザでのプッシュ通知の対応が徐々に形になってきています。 ChromeやFirefoxでプッシュ通知を通知だけではなくデータ(ペイロード)付きで送れる
お疲れさま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の代わりに使うことが可能です。現時点で実装し
ChromeでW3C Push APIを使ってみた - Qiita
※ (2017/7/4: Chrome以外のブラウザとの相互運用性を考慮する場合は、Web Pushへの移行を推奨します。Web Pushについては[改訂版] Web Pushでブラウザにプッシュ通知を送ってみる[旧仕様対応版]にまとめています。(なお、AndroidやiOSへのFirebaseプッシュ通知と統合して運用する場合は、Firebase JavaScript SDKの利用を検討した方がよいかもしれません。)) ※ (2015/11/27: 関連してFetch APIの使い方を簡単ながら別記事に書いてみました。) もう既に、ググると参考記事がいくらでも出てくるような内容ではありますが、個人的にいろいろと上手く行かなかったりしたこともあるので、参考までにまとめてみました。 さて、Chrome 42 (Android版を含む(!))では、Service Workersとの組み合わせで
モバイルブラウザのビデオ再生でアプリキャッシュが使えるかを再度検証 - Qiita
(2016/7/25): 最近のChromeやSafariでのアップデート関連を新しい記事にまとめてみました。 モバイルブラウザでは、<video>タグを使ってビデオの再生を行うとき、ユーザに無断でダウンロードを開始して通信料金が過剰にかからないようにするために、preload属性を指定しても無効になるようになっています。 ですが、ユーザが再生を開始するためにボタンをクリックしてからバッファリングを開始するのではなく、先にダウンロードを始めておいて、ユーザが操作するときにはダウンロードが完了していて、ボタンをタップすれば即座に再生が開始される、といった動作を実現させたい場合もあるのではないでしょうか。 そこで、第一歩目として、HTML5のアプリケーションキャッシュが本当に<video>タグで上手く活用できないのか、iOSとAndroidで検証してみたいと思います。 とりあえず、やってみた
Media Source Extensionsを使ってみた (WebM編) - Qiita
モバイルブラウザのビデオ再生でアプリキャッシュが使えるかを再度検証で紹介したように、Androidのブラウザでは、アプリケーションキャッシュを使っても、<video>タグでデータを先読みしてタップしたら直ちに再生する、といった挙動を実現することができませんでした。 そこで、少し手の込んだ方式になってしまいますが、Chrome等でサポートされている、Media Source Extensionsを使って、キャッシュされたWebMファイルをXMLHttpRequestでロードして<video>タグで再生してみます。 なお、だったらXMLHttpRequestでデータを取得してBlobを生成すればいいのではないか、という声も聞こえてきそうですが、残念ながら、これもまたモバイルブラウザでは上手く行かなかったりします。 Media Source Extensionsの予備知識 そもそも、Media
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
