「PWA」の記事 - Crieit

【個人開発】アイデア出しから公開・プロモーションまでまとめ(Nuxt3、Cloudflare、GooglePlay)

2023-07-29T05:35:55+09:00

1. はじめに

個人開発の大体の流れがつかめるように、アイデア出しから公開・プロモーションまでをまとめました。

1-1. 作ったアプリ

About	List	History

	基本操作
① リスト作成 ② 買い物完了でチェック ③ チェック済みを削除 ※これらの手順だけで簡単操作

『買い物リスト・メモ - Lisble リスブル』

iOS,PC	Android

iOS,PCの方は、PWAの為、メニューから｢ホーム画面に追加｣をお願いします。	このアプリは Google Play で入手できます。

2. 0から公開までの流れ

2-1. アイデア

1番大事だけど一番頭を悩ませました。
新しいものか、既存のサービスでの差別化の二択で、はじめてということで後者にしてしまいました。
これからもアンテナをはって次につなげたいです。

アイデアの出し方
* とにかく紙に書く
* 不満・面倒・悩み・困っていること
* 人間観察(周りの人)・他業種の業務課題
* 真似 → シンプル化・別分野へ応用・既存のサービスの不満解消
* 海外のサービス調査
* ニッチ・マニアック(自分の強み・趣味)
* 合体・逆

既存のサービスの発展系か、何かの組み合わせか
思いついたらメモ 📝

参考サイト
アプリ開発でアイデアが浮かばないあなたへ。独創的なアイデアの出し方
 ポートフォリオや個人開発で使えそうなアイデア

2-2. 要件定義

①要件(こうだったらいいな)
* 出来る、出来ないを考えずあげていく

②要件の為の機能
* ここで出来る、出来ないを考える
* 最低限必要な機能を絞る
* 実装方法が思いつかない機能は省略

出先で「あれあったかな❓」を解決したい → 買い物履歴を残して最近買ったものをわかるようにする機能
在庫の把握・重複購入を減らしたい → 買い物履歴から同じ単語入力時に色の変化で知らせる → 入力中に知らせることにより在庫を思い出すきっかけにもなる
etc...

③出来ればマネタイズも考える
1. 広告：アフィリエイト､AdSense(web)､AdMob(アプリ)
2. 課金：広告削除､追加コンテンツ､アイテム
3. 寄付
4. 有料：買い切り
5. サブスク：月額制

とにかく一連の流れを経験したく、マネタイズまでの道のりが見えたのが本アプリ案で、結果Amazonアソシエイト､AdSenseになりました。
AdSenseは受かりませんでした。継続して挑戦します。

④利用技術
🔑 ログイン・ユーザー登録無し、、広告も可でとにかくお金をかけずにを優先して、SPAで制作することにしました。
- GooglePlay Developer 申請・登録25ドル(当時3,352円)
- 独自ドメイン Xserverドメイン初年度のみ1円
- 更新、移管はCloudflare予定

アイデア・デザイン
Xmind(マインドマッピング)
Figma
コード
Nuxt3(Composition API)・TypeScript・Tailwind CSS
インフラ
Cloudflare
開発環境
VSCode・Git、GitHub

参考サイト
【5ステップ】初めてのオリジナルアプリの作り方！アイデアの出し方も公開

2-3. 設計

①画面設計
1. 必要なﾍﾟｰｼﾞ列挙 ➡ 階層・整理
2. ワイヤーフレーム(紙手書き)下書き
3. ワイヤーフレーム(figma)清書

参考サイト
ワイヤーフレーム(画面設計)の作り方
 Web画面設計の手順と重要なポイント

デザインの４原則
1. ｢近接｣：関連する要素をグループ化
2. ｢整列｣：関連する要素を見えない線で整列
3. ｢反復｣：要素の一貫性、デザインの統一
4. ｢対比｣：要素の優先度を強弱で示す

参考サイト
お役立ち知識：デザインの4原則 - デザインパートナー

②データ設計(構造)
* データの設計図

2-4. 開発

設計通りに作る
最低限の機能
制作途中で機能の追加案を我慢して、とにかく完成させることに集中する(追加の機能を制作してしまいました。なのでここに残しておきます。)

①工夫した機能
- 並べ替え(D&D)・スワイプ機能をライブラリ(Vue.Draggableは､思うような機能にならなかった)を使用せずに作成
- ↳シンプル化のため､同じ発火点で､参考サイト様(Trello風タスク並び替えドラッグ&ドロップクローン(Vue.js利用))を参考に､【マウス、タッチ、処理回数削減、d&dとswipeの融合、グループ間並べ替え、d&d中の上下の画面端scroll】ロジックを考え自作しました。

並び替え機能	スワイプ

	←色 →削除※ﾀｯﾁﾃﾞﾊﾞｲｽのみ

スマホとPCの挙動の違いなど(ENTER､終了時の処理...)
日本､世界の日時の表示形式(履歴)
Amazonアソシエイトの各国の設定(OneLink)
アニメーション(数字のドラムロール、追加削除時...)etc...

②多言語化(i18n)
@intlify/nuxt3使用
日/英で単語の長さの違いによる表示崩れに注意

未解決問題
日本語で検索時、検索結果が英語サイトのtitleとdescriptionになってしまう問題(同じURLで日/英にしたい)

確認
meta tagの設定(title、description等)日/英切替時にきちんと切り替わっている。

↓ためしたこと↓
- Nuxt.jsのi18n多言語対応したら、日本語で検索した時の検索結果が英語になってしまった。解決できたので対応方法を記載します。
- @intlify/nuxt3 で detectBrowserLanguage: false,にあたる設定がない??
- sitemapの設定 (hreflang属性)
- Google Search Consoleに日/英を認識させる方法??...
- (2023年7月) Nuxt3での多言語化はまだ開発中らしいので情報待ち🍥 → intlify/nuxt3: Nuxt 3 Module for vue-i18n-next

③プライバシーポリシー
参考サイト
プライバシーポリシーとは何か？必要性、記載事項をわかりやすく解説

④テスト
- 個人情報を扱っているなら､徹底的に安全確認
- 例外処理

2-5. 公開

①(SPA SSG) 静的ファイルホスティングサービス【無料】
1. GitHub Pages
2. Firebase Hosting
3. Netlify
4. Vercel
5. Cloudflare Pages

無料プランの枠・サイトのパフォーマンス・商用利用可でCloudflare Pages

参考サイト
Cloudflare Pages・Vercel ・Netlify の違いや使い分けをまとめる
 NetlifyからCloudflare Pagesに引っ越しました

②Google Play Store 配信方法
PWA → TWA
* TWA変換ツール「Bubblewrap CLI」使用
* Lighthouse で 80 以上のパフォーマンススコアが必要(↓に記述)

参考サイト
信頼できるWebアクティビティ
 【TWA】完全開発ガイド＝超簡単にPWAをPlay Storeで配信しよう
 PWA対応サイトをAndroid APK（AAB）に変換する

③Lighthouse のパフォーマンス改善(リファクタリング)
- cssの最適化 → 読み込み順､削除､animation(transform,opacity...)etc...
- googleFonts, Analytics → GTM使用､読み込むタイミング､読み込み方､文字の限定etc...
- 【2022年3月】Google Fontsのパフォーマンス比較＆ハリー・ロバーツ方式の勝手に改良版
- Google Fontsを簡単にサブセット化する方法
- Web Worker → 並列処理 Web Workerの使い方
- requestAnimationFrame() → 「60fps」 requestAnimationFrame の使い方
etc...

Mobile :arrow_down:

Desktop :arrow_down:

2-6. リリース後

①掲載用スクリーンショット、画像作成
* figma制作
* サイトにより、サイズ、比率、枚数、が異なる

②登録サイトに投稿/掲載依頼
当たって砕けろ、チャレンジ精神で色々掲載依頼を出してみた結果です。
個人開発者に告ぐ！「告知＝恥ずかしい」を脱却しよう～実例データから重要性を解説

登録or掲載 → 🎉
メール・問い合わせ反応待ち → 📧
更新が止まっているサイトが多い

日本
- Appliv → 🎉 レビュー、とても丁寧な対応 :thumbsup:
- APPLION → 🎉 ランキング
- 放課後ｱﾌﾟﾘ部 →🎉 登録
- Applishow → 🎉 登録
- AppRoom → 🎉 登録 アプリ記事掲載
- SeekUps → 🎉 登録
- ロケットリリース → 🎉 登録
- Appstimes → 🎉 登録
- AnyMake → 🎉 登録
- makepost → 🎉 登録
- MITSUKARU! → 🎉 登録
- DevHaunt! →🎉 登録、とても丁寧な対応 👍
- 個人dev → 🎉 登録
- アプリゲット → ゲームのみ
- AppBank → 📧
- Applision → 📧
- ツクログ → 📧 クリエイター登録済み､まだ作品は掲載されない(2度投稿)
- octoba → 📧
- NewLaun-ch → 📧
- appllio → 📧
- appnavi → 📧
- Androライオン → 📧条件:レビュー
- AndroRank → 📧条件:レビュー
- Androidアップス → 📧
- Androidコレクション → 📧
- マイナビニュース → 📧
- ITmedia → 📧
- ITmedia ねとらぼ → 📧
- AndRock → 📧
- AppVIP → 📧
- AppLink → 📧
- GAPSIS → 📧

海外

Product Hunt → 🎉 登録から１週間待つ必要がある
AlternativeTo → 🎉 登録
app store apps → 📧
AppCraver → 📧
arttechnica → 📧
Apps Review → 📧
community → 📧
App Log → 📧
Get Android Stuff → 📧
Android Guys → 📧
androlib → 📧
APKMirror → 📧
PCMag → 📧
NEWSREPORTS → 📧
iFanzine → 📧

※上記以外で無料で宣伝できるサイト、方法があれば教えていただけると嬉しいです。

③記事を書く
- Qiita
- 【Nuxt3】はじめての個人開発「買い物リストアプリ」開発記録
- Zenn
- Nuxt3で初めての個人開発記録【買い物リストアプリ】
- Crieit
- シンプルな買い物リストアプリ「lisble リスブル」の紹介
- 【個人開発】アイデア出しから公開・プロモーションまでまとめ(Nuxt3、Cloudflare、GooglePlay)
- note
- 値上げ対策！買い物リスト作成で節約
- シンプルな買い物リストアプリ「Lisble リスブル」のご紹介
- Medium(英語記事)
- Price increase measures! Save money by making a shopping list

④Twitter(日本語/英語)
- Twitter日本語ver.：@arieight_8
- Twitter英語ver.：@Lisble_en
- 登録or掲載 → つぶやく
- 機能一覧、設定一覧、動画(gif)でツイート
- 開発中からつぶやいた方が良い

参考サイト
個人開発したWebサービスをリリースした後にやったこと / やり続けていること

3. 気付き・反省点・まとめ

開発を0からして、初めてコードをさわって新しい概念にふれた時くらい勉強になり、とても知見が広がり良かったです。
プログラミング以外の作業が初だったので「プログラミング：他＝ 3：7」くらいの感覚でした。様々なデザインが予想より大変でした。
一番面白いと感じた作業は、ロジックを考えて形になった時でした。
アイデア → 紙やXMindに思いつく限りまとめたのですが、総合的な判断で結局既存のサービスに追加機能の方向になってしまいました。マネタイズまで含めたアイデアが難しいです。どうせやるなら一通りやってみたかったので次回以降にしました。常にアンテナをはって知見を広げていいこうと思いました。
要件定義 → 運用費がかからない、個人情報は扱わない、AdSense以外のマネタイズまで考える､などを考慮してアイデアを絞り、考え、すでにあるサービスと見比べ、アイデアと要件定義をぐるぐるしていました。
AdSenseは、コンテンツ不足でwebアプリは受かりづらいらしいです。
利用技術 → 平凡なアイデアだったので初めて挑戦する技術(Nuxt3､TypeScript､etc...)を使用してしまいました。
デプロイ先など、お金をかけずに運用していくための他の効率の良い方法やサービスを引き続き調査していきます。(Firebaseをﾃﾞｰﾀﾍﾞｰｽ等)
設計 → 画面デザインは、UI足したら引き算・データ設計は構造整理
開発 → 追加の機能を制作してしまいました。最低限の機能でまず完成を目指すべき
工夫した機能 → ToDoの変化型アプリで平凡なアプリで非常に多く数があるため、機能にこだわりました。
多言語化して作業が増えた。[Amazon設定､時間形式､表示崩れ､metaタグ､etc...]
テスト → 多視点が重要
公開 → 運用費をかけないにこだわる
パフォーマンス改善 → 良い学習
マネタイズ → Amazonまでの導線が弱い要検討
著作権・プライバシーポリシー・DDoS対策etc...
プロモーション → Twitterは開発中から・アイデア段階でSNSを考慮したサービス・地道にor金をかけるか・個人の場合限られるので勉強段階からブログや記事など書いておけばまた違ったかも
「告知＝恥ずかしい」があったので、経験せずにはわからないからできることは全部しようと思いました。

作る前に想像していたよりコード以外の作業が多いとうことに改めて気付かされました。
制作中、何度も宇宙兄弟のセリフが脳内再生してました。ありがとうございました。

「また積めばいいよ」
「次はもっと上手く積めるようになってるよ」

出典: 『宇宙兄弟』17巻小山宙哉（講談社、2012年3月23日第1発行）

購入履歴が残せるシンプルな買い物リストアプリ 『買い物リスト - Lisble リスブル』 です。メモ、ToDoアプリとしても機能します。
購入履歴の保存機能により、無駄な重複購入を防ぎ、在庫の備忘録にもなります。
ログイン・ユーザー登録不要、無料ですぐにご利用いただけます。
もしよかったら、触ってみてください。

『買い物リスト・メモ - Lisble リスブル』

iOS,PC	Android

iOS,PCの方は、PWAの為、メニューから｢ホーム画面に追加｣をお願いします。	このアプリは Google Play で入手できます。

Twitter:＠arieight_8

Google Play および Google Play ロゴは、Google LLC の商標です。

シンプルな買い物リストアプリ「Lisble リスブル」について

2023-07-25T20:16:30+09:00

1. はじめに

シンプルな買い物リスト・メモ - Lisble リスブル
アプリの解説・紹介をするために記事を書きました。

シンプルな買い物リストのアプリです。メモ、ToDoアプリとしても機能します。ログイン・ユーザー登録不要、無料ですぐにご利用いただけます。

「買い忘れ、衝動買い、同じものを買ってしまう、出先での在庫確認、ネットショップとの比較など」考える事が多く、余計な負担だったので、リストをつけることにより改善したいと思いました。
購入履歴の保存機能は、在庫の備忘録にもなります。また買い物中の操作性を重視し、レイアウトの左/右切り替えが可能です。
事前に買うべきものをメモしておくことで、より計画的に買い物をして、結果的に節約につながります。

2. 買い物リストアプリ「Lisble リスブル」について

『買い物リスト・メモ - Lisble リスブル』

iOS,PC	Android

iOS,PCの方は、PWAの為、メニューから｢ホーム画面に追加｣をお願いします。	このアプリは Google Play で入手できます。

2-1. アプリの概要

購入履歴が残せるシンプルな買い物リストのアプリです。メモ、ToDoアプリとしても機能します。ログイン・ユーザー登録不要、無料ですぐにご利用できます。

About	List	History

2-2. アプリの3つの特徴

① 買い物中の操作性(UI,UX)
片手操作での誤操作防止のため編集機能を片側に寄せ、かつ 左/右表示切替可能。
チェックしたメモ、まだしていないメモを切り替え、すぐに確認できるようにしました。

② 購入履歴の保存
日付時間と共に保存をして、入力時に同一品目を色の変化でお知らせをします。
購入履歴を残すことにより、直近で購入したものがわかり、無駄な重複買いと共に在庫を思い出すきっかけにもなると思いました。

③ Amazon検索
入力したメモをそのままAmazon検索できます。買い物中の値段の比較や、欲しいものリストとしてご活用してもらえればと思いました。

2-3. アプリの画面案内

	スマホ
① 購入履歴へ ② メニュー(移動・設定) ③ タブ切り替え ④ ↑↓並べ替え ④ ←色､→削除 ⑤ 編集 ⑥ チェック ⑦ リスト追加 ⑧ ｢チェックあり｣のみ削除 ⑨ すべて削除

	タブレット・PC
① 編集 ② 色 ③ 削除 ④ ↑↓ 並べ替えのみ

2-4. アプリの基本操作

①②③これらの手順だけで簡単操作

	基本操作
① リスト作成 ② 買い物完了でチェック ③ チェック済みを削除 ※これらの手順だけで簡単操作

2-5. アプリの機能一覧

並び替え機能	スワイプ

	←色 →削除※ﾀｯﾁﾃﾞﾊﾞｲｽのみ

タブ切り替え	Amazon検索

すべて、チェックあり、なし	そのままAmazon検索

購入履歴の保存	重複買い防止

1. チェックあり削除 2. 購入履歴の保存	履歴と同じ品目を入力時に色の変化でお知らせ

続けて追加	全削除

＋ボタン、ENTERキｰ	チェック済みは購入履歴に保存

2-6. アプリの設定

テーマカラー	レイアウト	多言語

5種	片手操作での誤操作防止(左利き)	日本語 / 英語

自動削除	入力中のEnterキー操作

終了時に｢チェックあり｣を自動削除(保存)機能	追加 / 改行切り替え

3. 最後に

購入履歴が残せるシンプルな買い物リストアプリ『買い物リスト - Lisble リスブル』です。メモ、ToDoアプリとしても機能します。
購入履歴の保存機能により、無駄な重複購入を防ぎ、在庫の備忘録にもなります。
ログイン・ユーザー登録不要、無料ですぐにご利用いただけます。
もしよかったら、触ってみてください。

『買い物リスト・メモ - Lisble リスブル』

iOS,PC	Android

iOS,PCの方は、PWAの為、メニューから｢ホーム画面に追加｣をお願いします。	このアプリは Google Play で入手できます。

Google Play および Google Play ロゴは、Google LLC の商標です。

気分が落ち込んだ時に、自動で周囲の人に通知するアプリを作りました

2022-04-09T22:40:57+09:00

こんにちは！

「metnal」というアプリを作りましたので、ご紹介させてください。

metnalとは

metnelは、「気分が落ち込んだ時に、自動で家族や友人、パートナーなどに通知することで、周囲の人の助けを受けることをサポートする」アプリです。

特徴として、
1. 手軽に始められるように、LINEでのみログイン可能。メールアドレスやパスワードでアカウントを管理すると、アカウントを紛失したり、ログインが面倒になったりすることで、離脱してしまうリスクがあります（多くの人がアカウントを紛失した経験があると思います笑）。
2. 機能は非常にシンプル。その時の気分をつけるだけで、独自のスコアリングに基づき、自動で気分のスコアが表示されます。
3. 周囲の人に、気分のスコアを共有できます。また周囲の人が登録することで、スコアが極端に低くなった時（気分が落ち込んだ時）にLINEのbotを通じて自動で通知されます。

となっております。
このアプリが十分に機能した場合、周囲の人の落ち込みを即座に発見できることが期待されます。

利用方法

こちらをご覧ください！

利用技術等

qiitaにまとめてみました。
一読して頂ければ幸いです！

【メモ】SPAとPWAのこと。

2021-04-30T00:02:35+09:00

SPA（Single Page Application）

単一ページによるWebアプリケーション。
返された結果をクライアント側でリアルタイムにレンダリングできるようになった。
瞬時に画面を書き換えることができる。（いいね！ボタンとか）
画面遷移はDOM操作。
ページのリフレッシュは不要。
リッチなエクスペリエンス。
クライアントとサーバーのロジックを分けて、保守性を上げることができる。（分業）

PWA（Progressive Web Apps）

ネイティブアプリのようなUXを提供するWebアプリの概念。
デバイスに合わせた機能提供がWebコンテンツ自体で行われている。

～これまでのWebになかった機能～

Service Worker
* オフラインサポート（Cache API）
* プッシュ通知（Push API）
* バックグラウンド処理（Background API）

Web Application Manifest
* アイコンの追加

～PWAのメリット～

ブラウザUIなしで起動できてオフラインでも使える。
アプリを公開するためにストアに提出する必要がない。
プラットフォームごとに修正する必要がない。
インストールしなくても使える。
サーバー側から通知をプッシュできる。（タイムセールの開始など）
オフラインでの使用が可能なため、ネットワークの状態に左右されないように作れる。
低機能なブラウザやPWA非サポートのデバイスにもサービスを提供できる。
ユーザの強い権限で動作しない。
HTTPS接続でしか動作しないのでサーバーとのやり取りを安全に行える。
ハイパーリンクがあればサービスに接続できる。
*各メリットを状況に合わせて取捨選択できる。

Service Worker

（バックグラウンドで動作するプログラミング可能なネットワークプロキシ）
* PWAを実現する上で中心となる機能。
* Webページのネットワークリクエスト全てをインターセプトできる。
* キャッシュ
* リクエストのハンドリング
* Push
* バックグラウンド同期

Web Application Manifest

（ホーム画面のアイコンやアプリ起動時のウィンドウの状態を指定）
* ホーム画面に追加するアイコン、スプラッシュ、背景色、ウィンドウスタイルを定義するもの。

まとめ

SPAは物理的なページ遷移を行わずWebクライアント上で画面が描画されるものでリアクティブな動作が可能。
PWAはWebクライアントの機能に合わせて、Webアプリにネイティブアプリライクな機能を実装したものでデバイスへのインストールやPush通知が可能。

Nuxt+Firebase Cloud Messaging(FCM)でWebプッシュ通知を送る

2020-05-24T17:18:35+09:00

WebでもFCMが使えるようになったので、試してみたときの備忘録。
これでSafari以外には、通知が送れるようになる(´ω｀)

使い方

構成は、@nuxtjs/pwaでPWA化している感じ。

コンソール側

Settingsでウェブプッシュ証明書を作成して、鍵ペアを取得する。

これを、PUBLIC_VAPID_KEYという環境変数に設定しておく。

クライアント側

firebaseの初期化

~/plugins/firebase.tsというファイルを用意し、firebaseを初期化

// ~/plugins/firebase.ts
import * as firebase from "firebase/app";
import "firebase/auth";
import "firebase/firestore";
import "firebase/messaging";


if (!firebase.apps.length) {
  // まずは、firebaseの初期化
  firebase.initializeApp({
    apiKey: process.env.API_KEY,
    authDomain: process.env.AUTH_DOMAIN,
    databaseURL: process.env.DATABASE_URL,
    projectId: process.env.PROJECT_ID,
    storageBucket: process.env.STORAGE_BUCKET,
    messagingSenderId: process.env.MESSAGING_SENDER_ID,
    appId: process.env.APP_ID,
    measurementId: process.env.MEASUREMENT_ID
  });

  // Push通知をサポートしているかをチェック
  // サポートしていないと、firebase.messaging()を呼んだときに例外が発生
  const isSupported = firebase.messaging.isSupported();

  // コンソールで発行した、ウェブプッシュ証明書の鍵ペアを取得
  const publicVapidKey = process.env.PUBLIC_VAPID_KEY;
  if (!!publicVapidKey && process.client && !!isSupported) {
    // FCMの初期化。鍵ペアを設定する
    const messaging = firebase.messaging();
    messaging.usePublicVapidKey(publicVapidKey);

    // @nuxtjs/pwaが生成するsw.jsと、
    // 後で作成するFCM受信処理用のsw-firebase-messaging.jsを統合するための設定
    navigator.serviceWorker
      .register("/sw.js")
      .then(registration => messaging.useServiceWorker(registration))
      .catch(err => console.error(err));
  }
}

export default firebase;

トークンの取得

Push通知を送る際の宛先として、トークンを指定しないといけないので取得。
トークンは端末ごとに取得する必要があるので、注意が必要。
※PCとスマホだとそれぞれトークンが違う

import firebase from "~/plugins/firebase";

// トークンの取得
public async getToken(user: User) {
  const isSupported = firebase.messaging.isSupported();
  if (!isSupported) return;
  const token = await firebase.messaging().getToken();

  // firestoreにトークンを保存しておく処理(中身は略)
  await saveToken(user, token);
}

Firestoreなどへユーザごとにトークンを保存しておく。

firebase.messaging().getToken();を呼んだ際に、
通知の設定が「確認」だと、許可を求めるダイアログが表示される。

これが許可されていないと、トークンも取得できない。

メッセージを受け取ったときの処理

メッセージを受信したときに受け取る関数は2つあり、

フォアグラウンド(画面を見ている時) ... onMessage
バックグラウンド(画面を見ていない時) ... setBackgroundMessageHandler

・【参考】JavaScript クライアントでメッセージを受信する | Firebase

今回はバックグラウンドのときに通知を送りたいので、
setBackgroundMessageHandlerを設定していく。

こんな感じ。

ドキュメントを見ると、『firebase-messaging-sw.jsというファイル名で作成』と書かれているけど、
その名前にすると、自動で読み込まれてしまう。。

開発用と本番用で切り替えたいときなどもあるので、@nuxtjs/pwaが生成するsw.jsと統合できるように、
sw-firebase-messaging.jsという名前でファイルを作成しておく。

ファイル名を変更したので、上で書いている「firebaseの初期化」の部分で、
messaging.useServiceWorker(registration)を呼んでいる形。

// ~/static/sw-firebase-messaging.js
importScripts("https://www.gstatic.com/firebasejs/7.14.2/firebase-app.js");
importScripts("https://www.gstatic.com/firebasejs/7.14.2/firebase-messaging.js");

// Firebaseの初期化
firebase.initializeApp({
  apiKey: "...",
  authDomain: "...",
  databaseURL: "...",
  projectId: "...",
  storageBucket: "...",
  messagingSenderId: "...",
  appId: "...",
  measurementId: "...",
});

// [START background_handler]
const isSupported = firebase.messaging.isSupported();
if (!!isSupported) {
  const messaging = firebase.messaging();
  // バックグラウンド時の処理
  messaging.setBackgroundMessageHandler(function(payload) {
  　// 受け取ったFCMの内容を取得
    const notificationTitle = payload.notification.title;
    const notificationOptions = {
      body: payload.notification.body,
      icon: payload.notification.icon,
    };

    // 通知を作成する
    return self.registration.showNotification(notificationTitle, notificationOptions);
  });
}
// [END background_handler]

nuxt.config.tsでPWA関連の設定をする

作成したsw-firebase-messaging.jsを取り込む設定と、
@nuxtjs/pwaが生成するmanifest.jsonに、gcm_sender_idを追加する設定を追加

import { Configuration } from "@nuxt/types";

const config: Configuration = {
  // 略
  modules: [
    "@nuxtjs/pwa",
  ],

  workbox: {
    // sw-firebase-messaging.jsをimportするように追加
    importScripts: [
      "sw-firebase-messaging.js"
    ]
  },

  pwa: {
    manifest: {
      // manifest.jsonにgcm_sender_idを追加
      gcm_sender_id: process.env.MESSAGING_SENDER_ID || ""
    }
  },
};

export default config;

これでクライアント側はOK！

サーバ側: メッセージを送信する

メッセージの送信は、firebase-adminでできる。
・アプリサーバーからの送信リクエストを作成する | Firebase

firestoreを利用しているので、Cloud Functionsのfirestoreトリガーを使い、
ドキュメントが追加されたら通知するようにしている例。

import * as functions from "firebase-functions";
import admin from "../common/firebaseAdmin"; // 初期化済みのfirebase-admin

export default functions
  .firestore.document("ドキュメントのパス")
  .onCreate(async (snap, context) => {
    // getTokenで保存しておいたトークンを取得(中身は略)
    const token = getToken();

    // 通知の送信
    const title = "通知するタイトル";
    const body = "通知する本文";
    const icon = "通知で表示するアイコン画像のURL"
    const link = "通知をタップしたときに開くURL"
    await admin.messaging().send({
        // 送信先の端末のトークン
        token: token,
        // 通知する内容
        notification: {
          title: title,
          body: body
        },
        // Web Push向けの通知内容
        webpush: {
          notification: {
            icon: icon
          },
          fcmOptions: {
            link: link
          }
        }
    });
  });

送信はこれだけ！

ほかの小ネタ

トークンを削除する

firebase.messaging().deleteToken();でトークンを無効化できる。

// トークンの削除
public async deleteToken(user: User) {
  const isSupported = firebase.messaging.isSupported();
  if (isSupported) {
    const token = await firebase.messaging().getToken();
    await firebase.messaging().deleteToken(token);
  }
}

フォアグラウンドで通知を受け取ったときになにかする

onMessageを使うと、通知を受け取ったときに呼び出してくれる。

firebase.messaging().onMessage(async (payload) => {
  // 受け取ったときの処理
});

トークンが変更されたときになにかする

onTokenRefreshを使うと、トークンが更新されたときに呼び出してくれる。
新しいトークンは再度getToken()を呼ばないといけない。

firebase.messaging().onTokenRefresh(async () => {
  // トークンが更新されたときの処理
});

通知の許可状態を確認する

通知の状態は、Notification.permissionで確認できるらしい。
・Notification.permission - Web API | MDN

if (Notification.permission === "default") {
  // 確認(デフォルト)
} else if (Notification.permission === "granted") {
  // 許可
} else if (Notification.permission === "denied") {
  // 拒否
}

以上!!

【PR】これをつかって、こんなのつくりました！

こんな通知を受け取れます！

１週間でWebサービスを作るイベント web1weekへの投稿作品です！
よかったら、遊んでみてください(´ω｀)

■エアで投げ銭できるWebサービス「エア銭」
URL: https://air-money.netlify.app/

参考にしたサイトさま

PWA対応WebサービスをTWAとしてGoogle Playに登録してみた

2020-01-17T09:22:44+09:00

現在PWA対応のWebサイトはTWAとしてGoogle Playストアに登録してAndroidアプリとしてインストールできるようになっています。当サービスCrieitも試しにやってみました。Laravel + Laravel Mix(Vue.js)という構成です。

PWA対応

まずはサイト自体がPWA対応していることが前提ですのでそちらの準備を行います。利用しているフレームワークによっては最初からPWA対応されているものもあるのでその場合は特に設定は不要です。

色々キャッシュしてトラブルになると面倒だと思ったのでホーム画面追加機能だけ利用しました。

Workboxを導入

Service Workerの作成のためWorkboxを導入します。

yarn add -D workbox-sw workbox-webpack-plugin

デフォルトだとLaravel Mixでビルドしたファイルをキャッシュ設定にしてしまうため、今回はそれを無効にしておきました。webpack.mix.jsに下記を追記します。excludeで全無視しています。

const workboxPlugin = require('workbox-webpack-plugin')

mix.webpackConfig({
  plugins: [
    new workboxPlugin.GenerateSW({
      swDest: 'service-worker.js',
      clientsClaim: true,
      skipWaiting: true,
      exclude: [/.*/],
      runtimeCaching: []
    })
  ],
  output: {
    publicPath: ''
  }
})

PWA用のmanifest.jsonを公開ルートフォルダに作成します。

{
    "name": "Crieit - プログラマー、クリエイターが何でも気軽に書けるコミュニティ",
    "short_name": "Crieit",
    "icons": [
        {
            "src": "/img/card.png",
            "sizes": "144x144",
            "type": "image/png"
        }
    ],
    "start_url": "/",
    "display": "standalone",
    "theme_color": "#448AFF",
}

表示するHTMLにmanifest.jsonを位置を記述します。

JavaScriptでService Workerの登録を行います。Laravelプロジェクト作成時に自動的に作られていたbootstrap.jsに追記しておきました。

if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/service-worker.js')
  })
}

これでビルドしたら完了です。ビルドすると precache-manifest.なんちゃらかんちゃら.js というファイルがされるためそれもコミットします。ただ、これは毎回生成されてしまうので、一度生成した後にwebpack.mix.jsの記述はコメントアウトしておきました。シンプルなPWA対応の場合は以後もう何も変更がありませんので。

TWA対応

次にTWAの対応です。これはAndroid StudioでAndroidアプリケーションを作成します。具体的なやり方は下記に書かれています。

【実践】Google Play Store でPWA配信 (TWA) - Qiita

ただしちょっとインストールするもののハッシュ値が古かったりするので本家も参考にすると良いでしょう。

Using Trusted Web Activities | Google Developers

丁度この記事を書いている最中に見つけたできたてほやほやの記事もありました。多分色々情報が最新ですので日本語情報では一番参考になりそうです。

話題のTWAでPWAをGoogle Play Storeに配信してみた

ハマったところ

build.gradle

似たようなセクションがあったりして追記するところを間違えてうまくいかなかった事がありました。

customtabsだとうまくいかない

実は前述リンクでやっているcustomtabsを使った方法ではうまくいきませんでした。ということで、代わりにandroid-browser-helperというものを使いました。なぜうまく行かなかったかというと、多分丁度最近android-browser-helperに変わったばかりで、微妙に各所の情報が古かったのではないかと。

具体的には、app/build.gradleに追記したcustomtabsのimplementationの代わりに下記を追記しました。

    implementation 'androidx.browser:browser:1.0.0'
    implementation 'com.github.GoogleChrome:android-browser-helper:ff8dfc4ed3d4133aacc837673c88d090d3628ec8'

僕は試していませんが、実は公式も変わったようなので下記のほうが正しそうです。ハッシュ値からバージョンに変わっているのでもしかしたら丁度ちゃんとリリースしたよ、というところなのかもしれません。

    implementation 'com.google.androidbrowserhelper:androidbrowserhelper:1.0.0'

あとはAndroidManifest.xmlのActivityもこれを使った形に変更が必要です。

assetlinks.json

あとはassetlinks.jsonを公開フォルダに追加する必要があります。前述のリンクどれでも作り方の説明が書かれています。

アイコンの調整

そのままだとデフォルトのアイコンでアプリになってしまいますので、適宜アイコンを置き換えます。最近は最新の方の機種用にXMLのアイコンファイルも作成するようです。容量自体も軽量になり、あとはforegroundとbackgroundがあり、Android側でアイコンを揺らしたりするアニメーションなどで利用されるようです。

今回は作るのが面倒だったので元々のXMLを削除することで画像を使ってもらうことにしました。

まとめ

ということでTWAの対応方法を書きました。詳しい説明と言うよりは主にハマったところをメインに書いているため詳しくは記事中のリンクを参考にしてください。

Nuxt+Firebaseでセッション管理: PWA(Service Worker)編

2019-12-29T19:07:03+09:00

FirebaseとSSRなNuxt.jsでアプリを作っていて、
クライアント側で認証チェックするとFirebaseの初期化などでラグが...
サーバ側で認証情報とかを取得してもう少しなんとかできないかなと。

まだベータっぽい?けど、公式の以下の内容を試してみたときの備忘録。

Service Worker によるセッション管理 | Firebase

よく出てくる言葉

単語はよく聞くけど、ちゃんと見てなかったので、ざっくりとしたまとめ

PWA: ネイティブアプリみたいなUXを提供するWebアプリ
- Progressive Web Apps | Google Developers
Service Worker: PWAを実現するための基盤技術。独自のライフサイクルを持ってる
- Service Worker の紹介 | Web Fundamentals | Google Developers
Workbox: PWAでよく使うコード(ボイラープレート)やベストプラクティスを提供するライブラリ
- Workbox | Google Developers
Nuxt PWA: NuxtでPWAするときに使うプラグイン。workboxを使ったService Worker(sw.js)とかを生成してくれる
- ⚡ Nuxt PWA

Nuxt PWAを使ってみる

インストール

$ npm install @nuxtjs/pwa

設定

設定は簡単。modulesに@nuxtjs/pwaを追加するだけ。

// nuxt.config.ts
import { Configuration } from "@nuxt/types";

const config: Configuration = {
  // ...略
  modules: [
    // ... 略
    "@nuxtjs/pwa",
  ],
  // ...略
};

export default config;

Firebase Authと組み合わせる

このあたりを見つつ、Firebase Authの情報を扱えるようにする。
- Service Worker によるセッション管理 | Firebase
- Firebase (Hosting × Functions) × Nuxt.js (universal) でユーザ認証のベストプラクティスを探る旅その２ - Qiita

流れ的には、以下の通り。

Firebase Auth用のService Workerの作成して、リクエストにIDトークンを付与するように変更
作成したService Workerを使うよう、nuxt.config.tsに設定を追加

Firebase Auth用のService Workerの作成

長めだけど、ほぼ公式ドキュメントのまま。

// ~/static/sw-firebase-auth.js

// firebaseを初期化
firebase.initializeApp({
  apiKey: /* API_KEY */,
  authDomain: /* AUTH_DOMAIN */,
  databaseURL: /* DATABASE_URL */,
  projectId: /* PROJECT_ID */,
  storageBucket: /* STORAGE_BUCKET */,
  messagingSenderId: /* MESSAGING_SENDER_ID */,
  appId: /* APP_ID */,
  measurementId: /* AUTH_DOMAIN */
});

// onAuthStateChanged()で現在のuserからidTokenを取得
const getIdToken = () => {
  return new Promise((resolve, reject) => {
    const unsubscribe = firebase.auth().onAuthStateChanged(user => {
      unsubscribe();
      if (user) {
        user.getIdToken().then(
          idToken => resolve(idToken),
          error => resolve(null)
        );
      } else {
        resolve(null);
      }
    });
  });
};

// URLからルートのURLを取得する処理
const getOriginFromUrl = url => {
  // https://stackoverflow.com/questions/1420881/how-to-extract-base-url-from-a-string-in-javascript
  const pathArray = url.split("/");
  const protocol = pathArray[0];
  const host = pathArray[2];
  return protocol + "//" + host;
};

/**
 *  Service Workderのライフサイクルでfetchしたときの処理
 */
self.addEventListener("fetch", event => {

  // リクエストをラップして、ヘッダにFirebase AuthのIdTokenを追加する処理
  const requestProcessor = idToken => {
    let req = event.request;
    // URLを取得して、httpsもしくはlocalhostかなどをチェック
    if (self.location.origin == getOriginFromUrl(event.request.url) &&
      (self.location.protocol == "https:" || self.location.hostname == "localhost") &&
      idToken
    ) {
      // ヘッダ情報をクローンする
      const headers = new Headers();
      for (let entry of req.headers.entries()) {
        headers.append(entry[0], entry[1]);
      }
      // クローンしたヘッダにFirebase AuthのIdTokenを追加
      headers.append("Authorization", "Bearer " + idToken);
      try {
        req = new Request(req.url, {
          method: req.method,
          headers: headers,
          mode: "same-origin",
          credentials: req.credentials,
          cache: req.cache,
          redirect: req.redirect,
          referrer: req.referrer,
          body: req.body,
          bodyUsed: req.bodyUsed,
          context: req.context
        });
      } catch (e) {
        console.error(e);
      }
    }
    return fetch(req);
  };

  // 上の関数を使って、全リクエストでIdTokenの取得し、Firebase AuthのIdTokenを追加ようにする
  event.respondWith(getIdToken().then(requestProcessor, requestProcessor));
});

/**
 *  Service Workderのライフサイクルでactivateしたときの処理
 */
self.addEventListener("activate", event => {
  event.waitUntil(clients.claim());
});

やっていることは、以下のような感じ。

リクエストするときに、
現在のユーザからIDトークンを取得して
IDトークンをリクエストヘッダーに追加する

ヘッダーにIDトークンが付与されているので、
サーバ側でそれを見て、認証済みかをチェックする。

nuxt.config.tsへの取り込み

作成したサービスワーカを使うように、nuxt.config.tsに設定を追加する。
ドキュメントだとこのあたりを参照。

// nuxt.config.ts
import { Configuration } from "@nuxt/types";

const config: Configuration = {
  // ...略
  modules: [
    // ... 略
    "@nuxtjs/pwa",
  ],
  workbox: {
    // 追加するスクリプトを指定。
    // バンドルされないので、CDNのfirebase-appを追加しておく。
    importScripts: [
      "https://www.gstatic.com/firebasejs/7.6.1/firebase-app.js",
      "https://www.gstatic.com/firebasejs/7.6.1/firebase-auth.js",
      "sw-firebase-auth.js"
    ],
    // 開発中でもsw.jsが生成されるように設定。
    dev: process.env.MODE != "production",
  },
  // ...略
};

export default config;

nuxtServerInitなどで認証状態をチェックする

IDトークンもJWTデコードすると、UIDを取得できるけれど、
有効かどうかをfirebase-adminでチェックする必要がある。

なので、まずは、firebase-adminのインスタンスを初期化するファイルを用意。

// ~/utils/firebaseAdmin.ts
let admin;

if (process.server) {
  admin = require("firebase-admin");
  if (!admin.apps.length) {
    const serviceAccount = require("./path/to/your/key.json");
    admin.initializeApp({
      credential: admin.credential.cert(serviceAccount),
      databaseURL: "https://your-database-url.firebaseio.com"
    });
  }
}

export default admin;

次にこれを使って、以下をしていく。

リクエストヘッダからIDトークンを取得し、
firebase-adminを使ってIDトークンの有効性を確認

以下は、vuex-module-decoratorsを使ったnuxtServerInitでチェックするサンプル。

// ~/store/index.ts

import { Context } from "@nuxt/types";
import { ActionContext } from "vuex/types";
import { ActionTree, Store } from "vuex";
import { initialiseStores } from "~/utils/store-accessor";

export const state = () => ({});
export type RootState = ReturnType;

const initializer = (store: Store) => initialiseStores(store);
export const plugins = [initializer];

export const actions: ActionTree = {
  async nuxtServerInit(
    context: ActionContext,
    server: Context
  ) {
    // requestのAuthorizationからIDトークンを取得
    const authorizationHeader = req.headers.authorization || "";
    const components = authorizationHeader.split(" ");
    const token = components.length > 1 ? components[1] : "";
    if (!token) return;

    // firebase-adminの初期化
    const admin = require("~/utils/firebaseAdmin").default;
    if (!admin) return;

    // IDトークンの検証: 有効期限などをFirebaseでチェック
    const decodedClaims = await admin.auth().verifyIdToken(token);

    // 検証結果からUIDを取得
    const uid = decodedClaims.uid;

    // TODO: 認証状態に応じてなにかする
  }
};

export * from "~/utils/store-accessor";

firebase-adminを取得する部分を

const admin = require("firebase-admin");

としていたり、if (process.server)やif (!admin.apps.length)などのチェックをせずにいたら、
クライアント側でもバンドルされていて、うまく動かいない状態に...

注意点

これで認証が必要なページでもいい感じSSRできた気がする(´ω｀)

ただ、課題が残っていて、スーパーリロード/ハードリロードすると、
Service Workderを介して、リクエストされないので、ヘッダに認証情報が付与されない...

ログを見ていると、スーパーリロード時には、描画されたあとに、Service Workderの登録されているよう。

そういった場合でも、利用したい場合には、従来のセッションCookieを利用する方法がよいかも？

セッション Cookie を管理する | Firebase

(もし良い方法があれば、教えてほしいです...)

おまけ: Service Workerのライフサイクル

ここに書いてあった。
- Service Worker の紹介 | Web Fundamentals | Google Developers

以上!!

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで♪

参考にしたサイト様

React PWA + Rails GraphQLで作ったポモドーロRPGに使った技術やその選定理由を書いてみた

2019-09-26T22:08:54+09:00

先日、『g4』というポモドーロ+RPGなサービスをリリースしました。

そのサービスで使った技術について聞かれることがあったので残しておきます。

どんなサービス?

ポモドーロ・タイマーを使い25分間集中すると経験値をもらえ、その経験値でレベルが上がる。
って言う感じのやつです。

https://www.g-g-g-g.games

こんな特徴があります。

ポモドーロ・タイマーやRPG的なUIはリッチで動きがある
現在のステータスをOGP画像にしてシェアできる
上昇する能力値や覚えるスキルは登録した文章を解析して決まる

構成はこんな感じ

フロントエンドの選定理由

フロントエンドはSSRしたReactアプリをfly.ioにおいています

[React]

自分は過去に仕事でNuxt.jsや生Vue.jsを使ったことがあり、個人ではExpoやNext.jsでReactにも触っていました。

今回Reactを選択した理由は以下です。

型が欲しかった。Typescriptを使いたかった
Reactのほうが書いていて楽しい（個人の感想です）
- React Hooksめっちゃいい
Apolloを使うならVueよりReactのほうが色々揃っている

[fly.io]

SSRするためにNode.jsをホスティングするやつが欲しかったので選定。
mizchiさんのブログで知り、面白そうだなと思ったのがきっかけ。
べつにfirebase hostingでもよかったですが、以下が決め手

firebase hosting同様初期導入費用がほぼ0
CDN
キャッシュコントロール
svgを使ったOGP画像の生成ができる

特に、

svgを使ったOGP画像の生成ができる

に有用性を感じて選定したんですが、現時点ではカスタムフォントと日本語への対応が十分でなく、別途Cloud Runを使うことになってしまっています（後述）
（サポートに聞いたらリポジトリ教えてもらったので（OSS）対応できるようなら自分で対応してなげたいなぁ）

キャッシュコントロールもよい

キャッシュの操作も面白くて、
g4の公開用ページではAPIからもらった結果をキャッシュして、キャッシュがあればそれをそのまま返すということをしています。

これによってAPIサーバーへの負荷はかなり低くなってると思います。
APIサーバー側からは、データ更新時にfly.ioのキャッシュを削除する操作をしていて、データが更新されるまではfly.ioはキャッシュを使い続けてます。

この辺のAPIが普通に使いやすくて簡単にかけるのでめっちゃ良きです。

fly.io良いよ

fly.io自体ははデプロイも早いし、導入コストも安いのでnowとかと並べて、手軽にNode.jsをホスティングするための選択肢にしてもいいんじゃないかなって思います。

Next.jsを選ばなかった理由

SSRする予定ではありましたが、OGPだけ生成できればいいなというレベルだったので、通常のReactアプリで作りました。
なるべく継続開発するため、アップデートの手間と依存を減らしたかったのも少しある

[PWA]を選定した理由

最初は、Expoで作ろうかと思っていました。

もともとSPAでアプリっぽいUIを作る仕事を受けたときに、Nuxt.js + Firebaseで作り、マルチブラウザ対応が辛いと思った経験がありました。

RNならその辺いい感じに作れるかもと思ってみんなの成長というアプリでExpoを試しみて、使い勝手が良い事までは確認してました。

ただ今回はモバイルより、デスクトップアプリのほうが欲しいということに気づき、
Electronで作りやすかったり、PWAならそのままインストールもできちゃうのでWebでいいかなって思いPWAにしました。

なのでマルチブラウザ辛いは解決してないです。
ここは個人開発なので修行と割り切って本業に生かしていきます。
Safari対応が結構めんどいけど、ユーザー多くて無視できない...

マルチブラウザと言っても、現状Chrome、Safari以外はほぼ無視してまっす。

[Apollo Client (react-apollo)]

これもSPAでアプリっぽいUIを作る仕事で、Nuxt.js + Firebaseで作ったときに、Firebaseのデータベース（このときはrealtime database使ってた)をフロントに反映するのが辛くて、同じようにREST APIも辛いだろうなと思って、GraphQLに手をだしたのがきっかけでした。

GraphQLだけでもすごく良いのですが、Apollo Clientがいいのはキャッシュコントールで、
クエリ毎にキャッシュを優先するかサーバーを優先するかを選択できます。

また、キャッシュがあれば再取得しないなどを簡単に書けたり、とにかくこれはSPAのベストプラクティスだなって感じの実装をシンプルに書けます。

Mutationするとキャッシュが書き換わったりするのもめっちゃ良き

正直この辺のこと考えながらSPA実装するのってかなり大変じゃない?ってか大変だった
アプリライクなUIのSPAならApollo Client使おうぜ！

こいつのおかげでこれまたAPIサーバーの負荷はまあまあ抑えられてそうです。

[Firebase Auth, Storage]について

バックエンドはRailsですが、APIサーバー作るのに正直Deviseとか使いたくないです（完）

Twitter連携やら諸々簡単なので選ばない理由がない。
Auth0は選択肢に入るけど今回GCPなのでGoogleでまとめられるし、そこまで込み入った認証必要ないしでこれにしました。

Storageは別に何でもよかったですが、Firebase Authの認証ユーザー単位での権限指定が楽なので使い勝手は良いです。

デザインについて

g4のデザインはレスポンシブのヘルパーとしてbootstrap-gridだけ使わせてもらってます。
めっちゃ便利なのでおすすめ。

それ以外はcss全部自分で書いてます。

コンポーネントファーストで作成しており、Atomic Designの粒度で、Storybook作ってコンポーネントを作ってる感じです。
Storybookは割とぶっ壊れやすかったり、他のビルド設定と競合とか重複したり、辛みもありますが、storyshotsによるスナップショットの差分確認ができるのと、テストの安心感があるので、無いと無いで不安ではあります。