What's New Qiita

20200927のHTMLに関する記事は5件です。

  • 投稿日：2020-09-27T19:47:19+09:00

【初心者でもわかる】ハンバーガーメニューをハンバーガーにする。

どうも7noteです。本日作る料理はハンバーガーです。

完成予定図

hamburger.gif

では、まずは一般的なハンバーガーメニューの作り方から。

一般的なハンバーガーメニューの作り方

normal.gif

index.html
<div class="menu">
  <input type="checkbox" id="check" class="hidden" >
  <label for="check" class="open"><span></span></label>
</div>
style.css
.hidden {
  display: none;
}

.open {
  width: 25px;
  height: 25px;
  display: block;
  position: relative;
  cursor: pointer;
}

.open span,
.open span:before,
.open span:after {
  content: '';
  display: block;
  height: 3px;
  width: 25px;
  border-radius: 3px;
  background: #333;
  transition: 0.5s;
  position: absolute;
}

.open span:before {
  bottom: 8px;
}

.open span:after {
  top: 8px;
}

#check:checked ~ .open span {
  background: rgba(255, 255, 255, 0);
}

#check:checked ~ .open span::before {
  bottom: 0;
  transform: rotate(45deg);
}

#check:checked ~ .open span::after {
  top: 0;
  transform: rotate(-45deg);
}

今回のメインはハンバーガー作りなので解説は省略します。

本物のハンバーガー メニュー

hamburger.gif

index.html
<div class="drawer">
  <input type="checkbox" id="check" class="hidden" >
  <label for="check" class="open">
    <span class="ue"></span>
    <span class="retas"></span>
    <span class="tomato"></span>
    <span class="meat"></span>
    <span class="retas"></span>
    <span class="shita"></span>
  </label>
</div>
style.css
.hidden {
  display: none;
}

.open {
  width: 25px;
  display: block;
  margin: 20px;
  position: relative;
  cursor: pointer;
}

.open span {
  content: '';
  display: block;
  width: 25px;
  background: #333;
  transition: 0.5s;

}

.open .ue {
    background: #E4AE54;
    border-radius: 10px 10px 0 0;
    height: 5px;
}
.open .retas {
    background: #98E357;
    height: 2px;
}
.open .tomato {
    background: #E34F50;
    height: 2px;
}
.open .meat {
    background: #975637;
    height: 2px;
}
.open .shita {
    background: #E4AE54;
    border-radius: 0 0 2px 2px;
    height: 3px;
}

#check:checked ~ .open span:not(.meat):not(.tomato) {
  background: rgba(255, 255, 255, 0);
}

#check:checked ~ .open .tomato {
  position: absolute;
  bottom: 5px;
  transform: rotate(45deg);
  background: #333;
}

#check:checked ~ .open .meat {
  position: absolute;
  top: 5px;
  transform: rotate(-45deg);
  background: #333;
}

おそまつ！

~ Qiitaで毎日投稿中!! ~
【初心者向け】HTML・CSSのちょいテク詰め合わせ

参考・アイデア元

・CSSだけで作るハンバーガメニュー
https://yuntu-tek.com/hamburger-menu/
・ロッテリア
https://www.lotteria.jp/sp/menu/category.php?c=burger

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-27T17:48:42+09:00

オンラインイナズマ 追加ワーク6日目 模範解答

index.html
<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="utf-8" />
    <title>TECH::MASTER</title>
    <link rel="stylesheet" href="reset.css" >
    <link rel="stylesheet" href="style.css" />
    <link href="https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css" rel="stylesheet" />
  </head>

  <body>
    <header class="header">
      <div class="container">
        <div class="header_left">
          <a class="header_logo" href="#">
            <img  class="logo_img" alt="TECH::MASTER" src="./images/logo.svg"  />
          </a>
        </div>

        <div class="header_right">
          <ul class="header_right_ul">
            <li class="header_right_li">
              お困りの方はこちら
            </li>
            <li class="header_right_li">
              カリキュラム変更
            </li>
            <li class="header_right_li">

                <img class="profile_img" alt="プロフィール画像"  src="./images/profile.jpg">

            </li>
          </ul>
        </div>

      </div>
    </header>
  </body>
</html>
style.css
body{
    font-family: "Helvetica Neue", Helvetica, Arial , "Hiragino Sans", "ヒラギノ角ゴ Pro W3", "HIragino Kaku Gothic Pro W3", "HIragino Kaku Gothic Pro", Meryo, "メイリオ", Osaka, "ＭＳ Ｐゴシック", "MS P Gothic", sans-serif;
  font-weight: 300;
  letter-spacing: 0.1rem;
}

.header{
    margin: 40px 0;
}

.container{
    width: 1170px;
    margin: 0 auto;
    display: flex;
    justify-content: space-between;
}

.logo_img{
    height: 30px;
}


.header_right_ul{
    display: flex;
}

.header_right_li{
    font-size: 12px;
    margin: 0 15px;
    color: #333;
    line-height: 40px;
}



.profile_img{
    height: 36px;
    border-radius: 50%;
    border: 2px solid #eee;
}
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-27T14:37:42+09:00

Googleが「QUIC」で切り開くインターネットの未来

こちらのクロス記事です。
こんにちはこんばんは。はすです。今回はQUICについて調べてみたのでそれをまとめてみようと思います。間違ってるところとかありましたらご指摘お願いいたします。

この記事でわかること

  • QUICの大まかな歴史と種類
  • QUICの仕組みとメリット

QUICの大まかな歴史と種類

2012　Googleが開発を開始
2015　標準化のためIETFにドラフト提出
2016　IETF、QUICワーキンググループ設置
・QUICはGoogleが開発した独自プロトコルでChromeや自社サービス提供のためのサーバに実装している
生まれた経緯として
・速度面でTCPよりもUDPのほうがいいからそっち使おう。
↓
・UDPだと信頼性の確保ができないからそういった処理を行う拡張機能的なものが必要
そこで生まれた拡張機能的存在が「QUIC」です。
詳しくはこちらを御覧ください。私よりも遥かによくまとまっています。

QUICの仕組みとメリット

QUICは、TCPの輻輳制御、ロスリカバリー、HTTP/2の機能の一部であるストリーム制御、フロー制御をUDPに対し提供します。

QUICの主なメリットは

  • UDPとTLS1.3の利用でハンドシェイクの処理を可能な限り効率化できる
  • コネクションID によりIPアドレスが変わっても通信が途切れない
  • パケットロス発生時QUICは並行して他のパケット処理ができる

UDPとTLS1.3の利用でハンドシェイクの処理を可能な限り効率化できる

TCPではデータのやり取りを行うために「3wayハンドシェイク」というものを必要とします。
3wayハンドシェイクはTCPにおける通信の信頼性を実現するためのとても重要な機能です。
しかし、3wayハンドシェイクは通信効率を悪化させる原因になります。

なぜかというと「相手の応答が返るまで後続の機能を実行できない」事が挙げられます。

しかしUDPはこのハンドシェイクを必要とせずにデータのやり取りを開始できます。
そしてUDPのデメリットである信頼性の低さをQUICが補います。
QUICは暗号化通信を前提とするためTLSハンドシェイクが発生し、QUICはTLS1.3を使用します。TLS1.2と比較するとハンドシェイク時に発生するやりとりがTLS1.2よりも1往復少なく、ここも通信の効率化における重要な要素になります。

コネクションID によりIPアドレスが変わっても通信が途切れない

QUICではコネクションIDと呼ばれるもの導入することにより、データ通信(特にモバイルクライアントの再接続ロス)を効率化します。
例えばコネクションIDの利用により、モバイル端末上でダウロード進行中、モバイル回線→WiFiに切り替えてもセッション維持をしつつWiFiに切り替えることが可能になります。

パケットロス発生時QUICは並行して他のパケット処理ができる

まず、大まかにTCPとUDPのパケット通信での違いをまとめてみようと思います。

TCP UDP
パケットが処理される順序が重要 パケットの受信順序に左右されない

TCPはパケットロスが起こると自動的に再送が始まります。そして再送が行われている間、後続のパケットを送信することはできません。
それに比べQUICを使うと、再送中でも並行して他のパケットの処理が可能になります。

感想

QUICについて調べるためにTCPとUDPも学びましたが小さな頃から使ってきていたインターネットがこんなにも面白い技術で成り立っていることがわかってとてもおもしろかったです。時代に合わせて素早い進化を遂げていることがインターネットの普及の大きな理由だと言うことを改めて実感できました。ではまた！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-27T02:07:21+09:00

通知がしたいだけならPWAでいいじゃない【iOS非対応】

本当にあるかもしれない怖い話

作成したウェブサイトを活性化させたい、サイトの更新を知らせる仕組みがあれば活性化するはず。プッシュ通知と言えばアプリ。WebViewアプリを作りましょう。ブラウザと通知機能だけだから簡単にできるでしょ？

はい分かりましたとアプリ開発経験がなかった開発会社は安い見積を提出してしまいました。

…あなたが開発会社の窓口だとしたらどうしますか？

アプリプロジェクトの難しさ

顧客が本当にやりたいことは、今までできたことが普通にできることに加えて 『通知をしたい』 だけなので安い見積しか通らない。それにも関わらずプロジェクトの難易度が高い点を以下にあげてみます。

難しさ 1. Android / iOS 両対応

コード量は大変少ないものの、Android Studio で Java(Kotlin)、Xcode で Swift も書ける要員を確保しないといけない。こんな事ができる要員はなかなかいない。

難しさ 2. WebView

WebView は標準のブラウザに比べて不自由なことだらけ。タブは複数開けないし、戻るや進むボタンもなければ、ピンチズームなんかも制限されてたり。
工数をかけて元のサイトより品質の悪い物を作ることになりがち。

難しさ 3. 開発者登録 / 開発環境

開発者登録費用(Android: 2500円くらい/初回 / iPhone: 1万円くらい/毎年)も必要、バイナリを作成して申請するのにMacも必要。

難しさ 4. OSバージョンアップ

OSのバージョンが上がった時に色々と不具合が出る可能性がある。
いつ上がるか分からないOSのバージョンアップのために開発要員を抱え続けられない。

Webプッシュ

顧客が本当にやりたいことが 『通知をしたい』 だけであれば、『アプリを作る』ことは妥当でしょうか？顧客のビジネスに全く関係のないところでリスクを増やしたり、開発物に対しては妥当だが要件に対して無駄に高額な費用を請求することになっていないか？

通知をしたいだけでよければ、Webプッシュができればよいので、既存のWebサイトをPWA化することも視野に入れて良いのではないでしょうか？

※色々書きましたが、2020/9時点では、iOS は Push通知非対応の模様。対応してくれててもいいのに。顧客とよく話し合ってくださいね。

既存サイトの PWA (Progressive Web Apps)化

いささか大げさでしたが、PWAを知らない人に向けて『なぜ』PWAを使うのかを書いてみました。わたしも顧客との距離を縮めて妥当な提案をするべく勉強していますが、誤り等あったらご指摘頂けますと助かります。

既存のWebサイトが https のサイトであれば、いくつかのファイルを追加するだけで簡単に PWA 化できます。

  1. manifest ファイル追加
  2. icon ファイル追加
  3. service worker ファイル追加
  4. service worker 登録

https のサイトを作るのは面倒に思えますが、github のリポジトリを github pages で公開する設定にすれば、費用も手間も不要で簡単に作成できます。

github-pages.png

実際に非PWAサイトをPWA化したソースコードをgithubに公開しています。よろしければ、あわせてご参照ください。

砂漠のひつじ : github

PWA 構成

PWA化に際して追加したファイルは以下で、前述の通り非常に少ないです。
PWAフォルダの中に全部配置してポータビリティを上げたかったのですが、service worker 本体と manifest ファイルは、公開サイトのルートに配置する必要があるようでした。

manifest.json   # PWAアプリの設定。entry point など記述
sw.js           # offline でも動作可能とする service worker。
                # いくつかのイベントハンドラを記述する必要がある
pwa/
  main.js       # service worker 登録処理。定形処理。
  icons/
    icon-192x192.png    # Home Screen に配置するアイコン
    icon-512x512.png    # 起動スプラッシュアイコン

manifest ファイル追加

このファイルは特に難しくはないです。
start_url には、FQDN部分以降の起動ページの path を記述します。

https://kaku3.github.io/the-sheep-in-the-desert/ なので、
/the-sheep-in-the-desert/index.html?utm_source=homescreen と記述します。

manifest.json
{
    "name":"砂漠のひつじ",
    "short_name":"砂漠のひつじ",
    "icons": [{
        "src": "pwa/icons/icon-192x192.png",
        "sizes":"192x192",
        "type": "image/png"
      }, {
        "src": "pwa/icons/icon-512x512.png",
        "sizes":"512x512",
        "type": "image/png"
      }],
    "start_url": "/the-sheep-in-the-desert/index.html?utm_source=homescreen",
    "display": "standalone",
    "background_color": "#FFFFFF",
    "theme_color": "#FFFFFF"
}

また、index.html を修正して、manifest.json を読み込む様にします。

index.html
<head>
    ...
    <link rel="manifest" href="manifest.json">
    ...
</head>

icon ファイル追加

このファイルも特に難しくないです。
Home Screen と、起動スプラッシュ2種類用意してください。
ひょっとしたら起動スプラッシュは画像がなくても大丈夫かもしれません。

service worker ファイル追加

簡単と書きましたが、このファイルは難しいです。
ただ書くだけなら難しくないのですが、『キャッシュするファイル』を正しく管理するには、webpack などで、キャッシュ対象ファイルのバージョンを管理できる仕組みが必要と思われます。

Service Worker の処理の記述には、Workbox を利用するのがよさそうです。

sw.js 自体は、webpack を利用していない場合は urls 以外の部分はそのまま利用できるかと思います。

sw.js
// CDN から Workbox を読み込み
importScripts('https://storage.googleapis.com/workbox-cdn/releases/5.1.2/workbox-sw.js');
workbox.loadModule('workbox-strategies');

const precacheController = new workbox.precaching.PrecacheController();

// キャッシュするファイルを定義する。
const baseUrl = location.href.replace(/\/sw.js$/, '');
const urls = [
    ...
    { url:'/css/fonts.css', revision: '0.01' },
    ...
].map(o => {
    o.url = baseUrl + o.url;
    return o;
})

precacheController.addToCacheList(urls);

self.addEventListener('install', (event) => {
    event.waitUntil(precacheController.install());
});
self.addEventListener('activate', (event) => {
    event.waitUntil(precacheController.activate());
});
self.addEventListener('fetch', (event) => {
    event.respondWith(
        caches
            .match(event.request)
            .then(function(response) {
                return response ? response : fetch(event.request);
            })
    );
});

キャッシュ容量はブラウザにより異なり、ブラウザによっては50MB程度であるためサイト内のどのファイルをキャッシュするかは設計が必要になると思います。

キャッシュは以下のような形で保存されます。

cache.png

上記より分かる通り、?__WB_REVISION__={revision} パラメータつきでキャッシュするため、読み込みタグも同様に?__WB_REVISION__={revision} をつける必要があります。

index.html
<link rel="stylesheet" href="css/fonts.css?__WB_REVISION__=0.01">
main.css
.game {
    ...
    background-image: url("../image/bg.png?__WB_REVISION__=0.01");
    ...
}

読み込むファイル数にもよりますが、この部分を手動で更新するのは難しいと思いますので、実務レベルでは「パフォーマンスを確認した上で全てキャッシュしない」か「webpack」を利用するという判断になるのかなあと思います。

service worker 登録

別ファイルにする必要もなかったのですが、再利用しやすい様に別ファイルとしました。

index.html
<script src="pwa/main.js"></script>
pwa/main.js
if('serviceWorker' in navigator) {
    // service worker のファイル名を変更するのであればこの行を修正。
    const serviceWorkerJs = `${location.href}sw.js`
    console.info('register service worker : ', serviceWorkerJs)
    navigator.serviceWorker.register(serviceWorkerJs)
    .then((r) => {
        console.info('Service worker registered.', r)
    })
}

動作させるまでには試行錯誤が必要になると思います。
https 環境ではないと動作しないとありますが、localhost については http でも大丈夫でした。
また、初回のみキャッシュされる動作をしますが、毎回キャッシュを消して確認するのが大変だったので、適当に php でサーバを立てて開発しました。

php -S localhost:8000
php -S localhost:8001
php -S localhost:8002
php -S localhost:8003
...

ローカルで動作確認が済んだら、github に push して確認してみてください。
A2HS(Add to Home Screen) ダイアログが確認できれば実装完了です。
おつかれさまでした。

a2hs.jpg

おわりに

通知についての記事のはずでしたが、PWA実装確認までで時間切れでした。
次回は通知について書きたいと思います。

参考

大変分かりやすかったです。ありがとうございました。
https://qiita.com/umamichi/items/0e2b4b1c578e7335ba20

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-27T02:07:21+09:00

通知がしたいだけならPWAでいいじゃない

本当にあるかもしれない怖い話

作成したウェブサイトを活性化させたい、サイトの更新を知らせる仕組みがあれば活性化するはず。プッシュ通知と言えばアプリ。WebViewアプリを作りましょう。ブラウザと通知機能だけだから簡単にできるでしょ？

はい分かりましたとアプリ開発経験がなかった開発会社は安い見積を提出してしまいました。

…あなたが開発会社の窓口だとしたらどうしますか？

アプリプロジェクトの難しさ

顧客が本当にやりたいことは、今までできたことが普通にできることに加えて 『通知をしたい』 だけなので安い見積しか通らない。それにも関わらずプロジェクトの難易度が高い点を以下にあげてみます。

難しさ 1. Android / iOS 両対応

コード量は大変少ないものの、Android Studio で Java(Kotlin)、Xcode で Swift も書ける要員を確保しないといけない。こんな事ができる要員はなかなかいない。

難しさ 2. WebView

WebView は標準のブラウザに比べて不自由なことだらけ。タブは複数開けないし、戻るや進むボタンもなければ、ピンチズームなんかも制限されてたり。
工数をかけて元のサイトより品質の悪い物を作ることになりがち。

難しさ 3. 開発者登録 / 開発環境

開発者登録費用(Android: 2500円くらい/初回 / iPhone: 1万円くらい/毎年)も必要、バイナリを作成して申請するのにMacも必要。

難しさ 4. OSバージョンアップ

OSのバージョンが上がった時に色々と不具合が出る可能性がある。
いつ上がるか分からないOSのバージョンアップのために開発要員を抱え続けられない。

Webプッシュ

顧客が本当にやりたいことが 『通知をしたい』 だけであれば、『アプリを作る』ことは妥当でしょうか？顧客のビジネスに全く関係のないところでリスクを増やしたり、開発物に対しては妥当だが要件に対して無駄に高額な費用を請求することになっていないか？

通知をしたいだけでよければ、Webプッシュができればよいので、既存のWebサイトをPWA化することも視野に入れて良いのではないでしょうか？

※色々書きましたが、2020/9時点では、iOS は Push通知非対応の模様。顧客とよく話し合ってください。

既存サイトの PWA (Progressive Web Apps)化

いささか大げさでしたが、PWAを知らない人に向けて『なぜ』PWAを使うのかを書いてみました。わたしも顧客との距離を縮めて妥当な提案をするべく勉強していますが、誤り等あったらご指摘頂けますと助かります。

既存のWebサイトが https のサイトであれば、いくつかのファイルを追加するだけで簡単に PWA 化できます。

  1. manifest ファイル追加
  2. icon ファイル追加
  3. service worker ファイル追加
  4. service worker 登録

https のサイトを作るのは面倒に思えますが、github のリポジトリを github pages で公開する設定にすれば、費用も手間も不要で簡単に作成できます。

github-pages.png

実際に非PWAサイトをPWA化したソースコードをgithubに公開しています。よろしければ、あわせてご参照ください。

砂漠のひつじ : github

PWA 構成

PWA化に際して追加したファイルは以下で、前述の通り非常に少ないです。
PWAフォルダの中に全部配置してポータビリティを上げたかったのですが、service worker 本体と manifest ファイルは、公開サイトのルートに配置する必要があるようでした。

manifest.json   # PWAアプリの設定。entry point など記述
sw.js           # offline でも動作可能とする service worker。
                # いくつかのイベントハンドラを記述する必要がある
pwa/
  main.js       # service worker 登録処理。定形処理。
  icons/
    icon-192x192.png    # Home Screen に配置するアイコン
    icon-512x512.png    # 起動スプラッシュアイコン

manifest ファイル追加

このファイルは特に難しくはないです。
start_url には、FQDN部分以降の起動ページの path を記述します。

https://kaku3.github.io/the-sheep-in-the-desert/ なので、
/the-sheep-in-the-desert/index.html?utm_source=homescreen と記述します。

manifest.json
{
    "name":"砂漠のひつじ",
    "short_name":"砂漠のひつじ",
    "icons": [{
        "src": "pwa/icons/icon-192x192.png",
        "sizes":"192x192",
        "type": "image/png"
      }, {
        "src": "pwa/icons/icon-512x512.png",
        "sizes":"512x512",
        "type": "image/png"
      }],
    "start_url": "/the-sheep-in-the-desert/index.html?utm_source=homescreen",
    "display": "standalone",
    "background_color": "#FFFFFF",
    "theme_color": "#FFFFFF"
}

また、index.html を修正して、manifest.json を読み込む様にします。

index.html
<head>
    ...
    <link rel="manifest" href="manifest.json">
    ...
</head>

icon ファイル追加

このファイルも特に難しくないです。
Home Screen と、起動スプラッシュ2種類用意してください。
ひょっとしたら起動スプラッシュは画像がなくても大丈夫かもしれません。

service worker ファイル追加

簡単と書きましたが、このファイルは難しいです。
ただ書くだけなら難しくないのですが、『キャッシュするファイル』を正しく管理するには、webpack などで、キャッシュ対象ファイルのバージョンを管理できる仕組みが必要と思われます。

Service Worker の処理の記述には、Workbox を利用するのがよさそうです。

sw.js 自体は、webpack を利用していない場合は urls 以外の部分はそのまま利用できるかと思います。

sw.js
// CDN から Workbox を読み込み
importScripts('https://storage.googleapis.com/workbox-cdn/releases/5.1.2/workbox-sw.js');
workbox.loadModule('workbox-strategies');

const precacheController = new workbox.precaching.PrecacheController();

// キャッシュするファイルを定義する。
const baseUrl = location.href.replace(/\/sw.js$/, '');
const urls = [
    ...
    { url:'/css/fonts.css', revision: '0.01' },
    ...
].map(o => {
    o.url = baseUrl + o.url;
    return o;
})

precacheController.addToCacheList(urls);

self.addEventListener('install', (event) => {
    event.waitUntil(precacheController.install());
});
self.addEventListener('activate', (event) => {
    event.waitUntil(precacheController.activate());
});
self.addEventListener('fetch', (event) => {
    event.respondWith(
        caches
            .match(event.request)
            .then(function(response) {
                return response ? response : fetch(event.request);
            })
    );
});

キャッシュ容量はブラウザにより異なり、ブラウザによっては50MB程度であるためサイト内のどのファイルをキャッシュするかは設計が必要になると思います。

キャッシュは以下のような形で保存されます。

cache.png

上記より分かる通り、?__WB_REVISION__={revision} パラメータつきでキャッシュするため、読み込みタグも同様に?__WB_REVISION__={revision} をつける必要があります。

index.html
<link rel="stylesheet" href="css/fonts.css?__WB_REVISION__=0.01">
main.css
.game {
    ...
    background-image: url("../image/bg.png?__WB_REVISION__=0.01");
    ...
}

読み込むファイル数にもよりますが、この部分を手動で更新するのは難しいと思いますので、実務レベルでは「パフォーマンスを確認した上で全てキャッシュしない」か「webpack」を利用するという判断になるのかなあと思います。

service worker 登録

別ファイルにする必要もなかったのですが、再利用しやすい様に別ファイルとしました。

index.html
<script src="pwa/main.js"></script>
pwa/main.js
if('serviceWorker' in navigator) {
    // service worker のファイル名を変更するのであればこの行を修正。
    const serviceWorkerJs = `${location.href}sw.js`
    console.info('register service worker : ', serviceWorkerJs)
    navigator.serviceWorker.register(serviceWorkerJs)
    .then((r) => {
        console.info('Service worker registered.', r)
    })
}

動作させるまでには試行錯誤が必要になると思います。
https 環境ではないと動作しないとありますが、localhost については http でも大丈夫でした。
また、初回のみキャッシュされる動作をしますが、毎回キャッシュを消して確認するのが大変だったので、適当に php でサーバを立てて開発しました。

php -S localhost:8000
php -S localhost:8001
php -S localhost:8002
php -S localhost:8003
...

ローカルで動作確認が済んだら、github に push して確認してみてください。
A2HS(Add to Home Screen) ダイアログが確認できれば実装完了です。
おつかれさまでした。

a2hs.jpg

おわりに

通知についての記事のはずでしたが、PWA実装確認までで時間切れでした。
次回は通知について書きたいと思います。

参考

大変分かりやすかったです。ありがとうございました。
https://qiita.com/umamichi/items/0e2b4b1c578e7335ba20

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧