アプリのメンテナンス画面・強制アップデートを再考する #DroidKaigi

DroidKaigi2021 Day01 (2021/10/19 15:20-16:00)に発表したスライドです。

Transcript

1. アプリのメンテナンス画面・ 強制アップデートを再考する m.coder
2. 1 自己紹介 m.coder (@_m_coder) フラー株式会社所属 ( 2021/01〜 ) Androidエンジニア歴3年
3. We are Hiring!
4. スマホアプリの 自動アップデート、 ONにしてますか？
5. 不具合が怖い 自分で管理したい 以前使えていた機能が使えなくなったetc... (ユーザー側の視点で) 自動アップデートしたくない理由
6. アプリを出す側としては、 最新版を使って欲しい…
7. →強制アップデート
8. (アプリ提供側の視点で) 強制アップデートさせたい理由 API側のデータ構造が変わる 追加機能をどうしても使って欲しい 不具合・脆弱性の解消
9. API側のデータ構造が変わる 追加機能をどうしても使って欲しい 不具合・脆弱性の解消 →サーバー側のメンテナンスを行う可能性が高い (アプリ提供側の視点で) 強制アップデートさせたい理由
10. メンテナンス画面が欲しい
11. メンテナンス画面 いつ出す？ 強制アプデで ユーザー離脱 怖いな 手軽にアップデート させる方法ないかな どう実装する？ 考えることがいっぱいで 後回しになりがち…
12. メンテナンス画面と 強制アップデートを いい感じに実現する方法を 改めて考えたい 【本スライドのテーマ】
13. ※諸説あります いい方法知っている方は 教えて下さい🙏
14. 【対象】 小〜中規模なサービスや 個人開発 メンテナンス専用のサーバーを立てられるほどじゃないけど、 メンテナンス画面や強制アップデートは実装したい
15. 説明すること 以下のサービスを利用したメンテナンス画面・強制アッ プデートの実現方法とメリット・デメリット APIのレスポンスから判断する Firebase Remote Configを使う Cloud Firestoreを使う In-app updatesを使う（強制アップデート）
16. 説明しないこと 取り上げるサービス （Firebase Remote ConfigやCloud Firestore） の細かい使い方や解説
17. 観点 即時性 カスタマイズ性 　（メンテ・リリースにすぐ反応して欲しい） 　（メンテナンス時間とか説明とか表示したい）
18. APIのレスポンスから判断する
19. サーバー側と 「メンテナンスの時は503を返す」など取り決めをして、 該当のレスポンスが返ってきた時はメンテナンス画面を表示する APIのレスポンスから判断する 503 （メンテナンス画面）
20. APIのレスポンスヘッダーにアプリの必須バージョンを 埋め込んでおいてもらい、アプリ側でパースする アップデート 通知 APIのレスポンスから判断する （強制アップデート） X-Require-Build- Version: 1.2.0
21. メリット 実装の負荷が一番少ない APIアクセス時に判断できるので即時性がある
22. デメリット メンテ時間や文言等を取得できないのでカスタマ イズ性が低い メンテ時間や文言などの情報を持った静的なJSONファイルをサ ーバーに置いておく WebViewでメンテ用のWebページに飛ばす 【回避策】 1. 2.
23. Firebase Remote Configを使う
24. Firebase Remote Config サーバーやAPIを用意しなくても アプリに動的な値を読み込ませられるサービス SharedPreferencesのようにKey-Value形式で値をフェッチ 可能 A/BテストやAPIを立てるまでもないパラメータのフェッチ などに使われることが多い
25. Firebase Remote Configの特徴 指定条件（日時・プラットフォーム・ビルド番号 など）によってパラメータを出し分けられる パラメータはJSON形式で記述 無料
26. Firebase Remote Config利用方法 2021/10/21 19:00から21:00までメンテナンス を行いたい 【例】
27. Firebase Remote Config利用方法 適用条件を指定する（Firebase コンソールの例）
28. Firebase Remote Config利用方法 指定条件時に反映させたいJSONを指定する
29. Firebase Remote Config利用方法 メンテナンス終了時刻(21:00-)のJSONも同じ様に指定する
30. Firebase Remote Config利用方法 メンテナンス終了時刻(21:00-)のJSONも同じ様に指定する
31. Firebase Remote Config利用方法 ViewのonResume時やAPIアクセス前などにRemoteConfigの値をフ ェッチする
32. Firebase Remote Config利用方法 ViewのonResume時やAPIアクセス前などにRemoteConfigの値をフ ェッチする
33. メリット 時刻やバージョン、プラットフォームなどの条件 でJSONの出し分けが可能なため、カスタマイズ性 が高い
34. デメリット フェッチ間隔に制限があるため、即時性に難点が ある
35. Remote Configの注意点
36. Remote Configの注意点 →短時間での多数のフェッチは想定されていない
37. 仮にフェッチ間隔を60(1分)に設定したとしても、 状態の反映に最長で1分間のラグがあると想定する必 要がある Remote Configの注意点
38. Remote Configの注意点 →サーバーのメンテナンス開始時刻よりも少し早くメン テナンスモードに設定するなどの工夫が必要 仮にフェッチ間隔を60(1分)に設定したとしても、 状態の反映に最長で1分間のラグがあると想定する必 要がある
39. Cloud Firestoreを使う
40. Cloud Firestoreの特徴 NoSQLなクラウドデータベース ※ドキュメントの読み取り 50,000/日 　ドキュメントの書き込み 20,000/日 SnapShotListenerというものを用いてリアルタイ ム通信が可能 無料通信枠あり
41. Cloud Firestore利用方法 Firestoreのドキュメントにパラメータを指定する
42. Cloud Firestore利用方法 ApplicationクラスやMainActivityのonResume時などに SnapShotListenerを設定してリアルタイム監視する
43. Cloud Firestore利用方法 ApplicationクラスやMainActivityのonResume時などに SnapShotListenerを設定してリアルタイム監視する 値はMap形式で流れてくる
44. Cloud Firestore利用方法 なぜ「ApplicationクラスやMainActivityのonResume時」？
45. Cloud Firestore利用方法 なぜ「ApplicationクラスやMainActivityのonResume時」？ →SnapShotListenerは一度設定すれば Detach するまで値が流れ続 ける
46. Cloud Firestore利用方法 なぜ「ApplicationクラスやMainActivityのonResume時」？ →SnapShotListenerは一度設定すれば Detach するまで値が流れ続 ける →アプリがフォアグラウンド時に Listener を設定して、アプリがバ ックグラウンドに移行した時に Detach することで、アプリ起動中 は常時値を監視できる
47. Cloud Firestore利用方法 なぜ「ApplicationクラスやMainActivityのonResume時」？ →SnapShotListenerは一度設定すれば Detach するまで値が流れ続 ける →アプリがフォアグラウンド時に Listener を設定して、アプリがバ ックグラウンドに移行した時に Detach することで、アプリ起動中 は常時値を監視できる →アプリのライフサイクルに合わせられるApplicationクラスや MainActivity(SingleActivity構成の場合)がよさそう
48. メリット 値がリアルタイムで反映されるので即時性がある →アプリ起動中にメンテナンスフラグが立ったら 即メンテナンス画面を表示させることも可能 パラメータのもたせ方は自由なのでカスタマイズ 性もある
49. デメリット ユーザーの数だけSnapShotListenerを登録するの で、ユーザー数が増えた時の負荷を考慮する必要 がある ライフサイクルを考慮して実装しないと、無限に Listenerを生やしてしまい通信量が爆発する可能 性も…
50. In-app updatesを使って 強制アップデートを実現する 番外編
51. Play Core ライブラリ で提供されるアプリ内 アップデート機能 Play ストアの情報を 取得してアップデート の有無を判定 In-app updates ※Google公式より引用
52. ユーザーが任意でアップデートを選択可能な flexible アップ デートと、強制でアップデートさせる immediate アップデー トが用意されている In-app updates ※Google公式より引用
53. In-app updatesの特徴 アップデートの優先度を設定できる（普段のアップデート は flexible、必須アップデートは immediate などの出し分 けが可能） アップデート配信からの経過時間が取得できるため、配信 から数日後にアップデートしていなかったユーザーにはア ップデート通知を出すなどの調整も可能
54. In-app updatesの利用例
55. In-app updatesの利用例
56. In-app updatesの利用例 アップデートの存在チェックを行う
57. In-app updatesの利用例 →versionCodeで判断
58. In-app updatesの利用例 →startActivityForResult的なもの
59. 参考 Google公式 アプリ内アップデート https://developer.android.com/guide/playcore/in-app- updates DroidKaigi 2020 Lite アプリのアップデート浸透率を上げろ！ ~in-app updatesを 実戦投入して見えてきたもの~ / masaibar https://youtu.be/u-zUIIe8IfA
60. In-app updatesの注意点 アップデートの優先度の設定は、今のところGoogle Play Developer APIを使用しないとできない（Play Consoleから直接 設定できない） ストアにリリースされたものと同じパッケージ名・同じキーで 署名したバイナリでのみテストができる（flavorを分けていたり する場合は要注意） immediate アップデートは実は強制じゃない（バックキーでア ップデート画面を抜けられる）
61. In-app updatesの注意点 アップデートの優先度の設定は、今のところGoogle Play Developer APIを使用しないとできない（Play Consoleから直接 設定できない） ストアにリリースされたものと同じパッケージ名・同じキーで 署名したバイナリでのみテストができる（flavorを分けていたり する場合は要注意） immediate アップデートは実は強制じゃない（バックキーでア ップデート画面を抜けられる）
62. In-app updatesの注意点 アップデートの優先度の設定は、今のところGoogle Play Developer APIを使用しないとできない（Play Consoleから直接 設定できない） ストアにリリースされたものと同じパッケージ名・同じキーで 署名したバイナリでのみテストができる（flavorを分けていたり する場合は要注意） immediate アップデートは実は強制じゃない（バックキーでア ップデート画面を抜けられる）
63. In-app updatesの注意点 アップデートの優先度の設定は、今のところGoogle Play Developer APIを使用しないとできない（Play Consoleから直接 設定できない） ストアにリリースされたものと同じパッケージ名・同じキーで 署名したバイナリでのみテストができる（flavorを分けていたり する場合は要注意） immediate アップデートは実は強制じゃない（バックキーでア ップデート画面を抜けられる）
64. In-app updatesのメリット Playストアと連携できる（手動で必須バージョンなどを管 理しなくていい） デフォルトで immediate と flexible が用意されているので 柔軟に対応できる ユーザーがストアに遷移する手間を省ける（ユーザー離脱 を防げるのでは？）
65. In-app updatesのデメリット Android版しか対応できない アップデートを拒否された場合やアップデート中にタスク キルした場合のハンドリング対応など、実装コストがそれ なりに高い ノウハウがまだ少なくハマりポイントが大いにある（あり そう）
66. In-app updatesでハマったポイント バージョンの低いバイナリを用意しているのに UPDATE_NOT_AVAILABLE( 更新なし) しか返ってこない
67. In-app updatesでハマったポイント →UPDATE_AVAILABLE になる条件は Play ストアに 「更新」と表示されていること バージョンの低いバイナリを用意しているのに UPDATE_NOT_AVAILABLE( 更新なし) しか返ってこない
68. In-app updatesでハマったポイント bundletool などでapk をインストールすると バージョンを下げていても「開く」表示になってしまった
69. In-app updatesでハマったポイント bundletool などでapk をインストールすると バージョンを下げていても「開く」表示になってしまった →テストの時はPlay ストアの内部テスト版などの利用が 必要そう
70. In-app updatesでハマったポイント 内部テスト版を公開しても「開く」のままになっている
71. In-app updatesでハマったポイント 内部テスト版を公開しても「開く」のままになっている →Play ストアアプリのキャッシュクリアで解消
72. In-app updatesでハマったポイント デバイスに複数アカウントを登録している場合も要注意
73. In-app updatesでハマったポイント デバイスに複数アカウントを登録している場合も要注意 アカウントA ：内部テスター登録済み アカウントB ：非内部テスター の状態で内部テスト版を公開
74. In-app updatesでハマったポイント デバイスに複数アカウントを登録している場合も要注意 アカウントA ：内部テスター登録済み アカウントB ：非内部テスター の状態で内部テスト版を公開 →アプリで非内部テスターと判断されたのか「更新なし」 と判定されていた
75. まとめ
76. まとめ REST APIならAPIレスポンスで判断、サーバーレスなら Firestoreあたりがやりやすそう？ In-app updatesはハマりポイントに気をつければユーザ ー体験はよさそう メリデメに気をつけながら自分のサービスに合ったメン テナンス画面・強制アップデートを実装しよう
77. おしまい