Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アプリのメンテナンス画面・強制アップデートを再考する #DroidKaigi
Search
m.coder
October 19, 2021
Technology
5
7.8k
アプリのメンテナンス画面・強制アップデートを再考する #DroidKaigi
DroidKaigi2021 Day01 (2021/10/19 15:20-16:00)に発表したスライドです。
m.coder
October 19, 2021
Tweet
Share
More Decks by m.coder
See All by m.coder
小さいアウトプットを続けること
m_coder
1
110
Compose で Android/iOS アプリを作る
m_coder
0
6.1k
Androidでもドラッグ&ドロップがしたい!
m_coder
1
890
Other Decks in Technology
See All in Technology
ガバメントクラウド単独利用方式におけるIaC活用
techniczna
2
120
Snowflakeでスロークエリ改善に取り組んだ話
tabata0208
0
160
CAMERA-Suite: 広告文生成のための評価スイート / ai-camera-suite
cyberagentdevelopers
PRO
1
130
Capybara+生成AIでどこまで本当に自然言語のテストを書けるか?
yusukeiwaki
6
720
生成AI、LLMの いまさら聞けないキホンのキ!/ Generative AI and LLM 101
gakumura
1
230
Creating Intuitive Developer Tool in Swift
giginet
PRO
0
480
端末が簡単にリモートから操作されるデモを通じて ソフトウェアサプライチェーン攻撃対策の重要性を理解しよう
kitaji0306
0
130
Jamstack でリニューアルするグリーグループのメディア
gree_tech
PRO
2
210
品質の高い機能を”早く”提供するために技術的な面でチームでやったこと、やりたいこと
sansantech
PRO
2
220
Measuring the Success of Developer Experience
nikokivela
1
130
WebRTC と AI の組み合わせ
tnoho
0
450
次は君だ。~Japan AWS Jr. Champions 受賞までの奇跡~
fukuchiiinu
0
210
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
How GitHub (no longer) Works
holman
311
140k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9k
Embracing the Ebb and Flow
colly
84
4.4k
Thoughts on Productivity
jonyablonski
67
4.3k
Facilitating Awesome Meetings
lara
49
6k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
360
Measuring & Analyzing Core Web Vitals
bluesmoon
0
27
Designing on Purpose - Digital PM Summit 2013
jponch
114
6.9k
Code Review Best Practice
trishagee
64
17k
Transcript
アプリのメンテナンス画面・ 強制アップデートを再考する m.coder
1 自己紹介 m.coder (@_m_coder) フラー株式会社所属 ( 2021/01〜 ) Androidエンジニア歴3年
We are Hiring!
スマホアプリの 自動アップデート、 ONにしてますか?
不具合が怖い 自分で管理したい 以前使えていた機能が使えなくなったetc... (ユーザー側の視点で) 自動アップデートしたくない理由
アプリを出す側としては、 最新版を使って欲しい…
→強制アップデート
(アプリ提供側の視点で) 強制アップデートさせたい理由 API側のデータ構造が変わる 追加機能をどうしても使って欲しい 不具合・脆弱性の解消
API側のデータ構造が変わる 追加機能をどうしても使って欲しい 不具合・脆弱性の解消 →サーバー側のメンテナンスを行う可能性が高い (アプリ提供側の視点で) 強制アップデートさせたい理由
メンテナンス画面が欲しい
メンテナンス画面 いつ出す? 強制アプデで ユーザー離脱 怖いな 手軽にアップデート させる方法ないかな どう実装する? 考えることがいっぱいで 後回しになりがち…
メンテナンス画面と 強制アップデートを いい感じに実現する方法を 改めて考えたい 【本スライドのテーマ】
※諸説あります いい方法知っている方は 教えて下さい🙏
【対象】 小〜中規模なサービスや 個人開発 メンテナンス専用のサーバーを立てられるほどじゃないけど、 メンテナンス画面や強制アップデートは実装したい
説明すること 以下のサービスを利用したメンテナンス画面・強制アッ プデートの実現方法とメリット・デメリット APIのレスポンスから判断する Firebase Remote Configを使う Cloud Firestoreを使う In-app
updatesを使う(強制アップデート)
説明しないこと 取り上げるサービス (Firebase Remote ConfigやCloud Firestore) の細かい使い方や解説
観点 即時性 カスタマイズ性 (メンテ・リリースにすぐ反応して欲しい) (メンテナンス時間とか説明とか表示したい)
APIのレスポンスから判断する
サーバー側と 「メンテナンスの時は503を返す」など取り決めをして、 該当のレスポンスが返ってきた時はメンテナンス画面を表示する APIのレスポンスから判断する 503 (メンテナンス画面)
APIのレスポンスヘッダーにアプリの必須バージョンを 埋め込んでおいてもらい、アプリ側でパースする アップデート 通知 APIのレスポンスから判断する (強制アップデート) X-Require-Build- Version: 1.2.0
メリット 実装の負荷が一番少ない APIアクセス時に判断できるので即時性がある
デメリット メンテ時間や文言等を取得できないのでカスタマ イズ性が低い メンテ時間や文言などの情報を持った静的なJSONファイルをサ ーバーに置いておく WebViewでメンテ用のWebページに飛ばす 【回避策】 1. 2.
Firebase Remote Configを使う
Firebase Remote Config サーバーやAPIを用意しなくても アプリに動的な値を読み込ませられるサービス SharedPreferencesのようにKey-Value形式で値をフェッチ 可能 A/BテストやAPIを立てるまでもないパラメータのフェッチ などに使われることが多い
Firebase Remote Configの特徴 指定条件(日時・プラットフォーム・ビルド番号 など)によってパラメータを出し分けられる パラメータはJSON形式で記述 無料
Firebase Remote Config利用方法 2021/10/21 19:00から21:00までメンテナンス を行いたい 【例】
Firebase Remote Config利用方法 適用条件を指定する(Firebase コンソールの例)
Firebase Remote Config利用方法 指定条件時に反映させたいJSONを指定する
Firebase Remote Config利用方法 メンテナンス終了時刻(21:00-)のJSONも同じ様に指定する
Firebase Remote Config利用方法 メンテナンス終了時刻(21:00-)のJSONも同じ様に指定する
Firebase Remote Config利用方法 ViewのonResume時やAPIアクセス前などにRemoteConfigの値をフ ェッチする
Firebase Remote Config利用方法 ViewのonResume時やAPIアクセス前などにRemoteConfigの値をフ ェッチする
メリット 時刻やバージョン、プラットフォームなどの条件 でJSONの出し分けが可能なため、カスタマイズ性 が高い
デメリット フェッチ間隔に制限があるため、即時性に難点が ある
Remote Configの注意点
Remote Configの注意点 →短時間での多数のフェッチは想定されていない
仮にフェッチ間隔を60(1分)に設定したとしても、 状態の反映に最長で1分間のラグがあると想定する必 要がある Remote Configの注意点
Remote Configの注意点 →サーバーのメンテナンス開始時刻よりも少し早くメン テナンスモードに設定するなどの工夫が必要 仮にフェッチ間隔を60(1分)に設定したとしても、 状態の反映に最長で1分間のラグがあると想定する必 要がある
Cloud Firestoreを使う
Cloud Firestoreの特徴 NoSQLなクラウドデータベース ※ドキュメントの読み取り 50,000/日 ドキュメントの書き込み 20,000/日 SnapShotListenerというものを用いてリアルタイ ム通信が可能 無料通信枠あり
Cloud Firestore利用方法 Firestoreのドキュメントにパラメータを指定する
Cloud Firestore利用方法 ApplicationクラスやMainActivityのonResume時などに SnapShotListenerを設定してリアルタイム監視する
Cloud Firestore利用方法 ApplicationクラスやMainActivityのonResume時などに SnapShotListenerを設定してリアルタイム監視する 値はMap形式で流れてくる
Cloud Firestore利用方法 なぜ「ApplicationクラスやMainActivityのonResume時」?
Cloud Firestore利用方法 なぜ「ApplicationクラスやMainActivityのonResume時」? →SnapShotListenerは一度設定すれば Detach するまで値が流れ続 ける
Cloud Firestore利用方法 なぜ「ApplicationクラスやMainActivityのonResume時」? →SnapShotListenerは一度設定すれば Detach するまで値が流れ続 ける →アプリがフォアグラウンド時に Listener を設定して、アプリがバ
ックグラウンドに移行した時に Detach することで、アプリ起動中 は常時値を監視できる
Cloud Firestore利用方法 なぜ「ApplicationクラスやMainActivityのonResume時」? →SnapShotListenerは一度設定すれば Detach するまで値が流れ続 ける →アプリがフォアグラウンド時に Listener を設定して、アプリがバ
ックグラウンドに移行した時に Detach することで、アプリ起動中 は常時値を監視できる →アプリのライフサイクルに合わせられるApplicationクラスや MainActivity(SingleActivity構成の場合)がよさそう
メリット 値がリアルタイムで反映されるので即時性がある →アプリ起動中にメンテナンスフラグが立ったら 即メンテナンス画面を表示させることも可能 パラメータのもたせ方は自由なのでカスタマイズ 性もある
デメリット ユーザーの数だけSnapShotListenerを登録するの で、ユーザー数が増えた時の負荷を考慮する必要 がある ライフサイクルを考慮して実装しないと、無限に Listenerを生やしてしまい通信量が爆発する可能 性も…
In-app updatesを使って 強制アップデートを実現する 番外編
Play Core ライブラリ で提供されるアプリ内 アップデート機能 Play ストアの情報を 取得してアップデート の有無を判定 In-app
updates ※Google公式より引用
ユーザーが任意でアップデートを選択可能な flexible アップ デートと、強制でアップデートさせる immediate アップデー トが用意されている In-app updates ※Google公式より引用
In-app updatesの特徴 アップデートの優先度を設定できる(普段のアップデート は flexible、必須アップデートは immediate などの出し分 けが可能) アップデート配信からの経過時間が取得できるため、配信 から数日後にアップデートしていなかったユーザーにはア
ップデート通知を出すなどの調整も可能
In-app updatesの利用例
In-app updatesの利用例
In-app updatesの利用例 アップデートの存在チェックを行う
In-app updatesの利用例 →versionCodeで判断
In-app updatesの利用例 →startActivityForResult的なもの
参考 Google公式 アプリ内アップデート https://developer.android.com/guide/playcore/in-app- updates DroidKaigi 2020 Lite アプリのアップデート浸透率を上げろ! ~in-app
updatesを 実戦投入して見えてきたもの~ / masaibar https://youtu.be/u-zUIIe8IfA
In-app updatesの注意点 アップデートの優先度の設定は、今のところGoogle Play Developer APIを使用しないとできない(Play Consoleから直接 設定できない) ストアにリリースされたものと同じパッケージ名・同じキーで 署名したバイナリでのみテストができる(flavorを分けていたり
する場合は要注意) immediate アップデートは実は強制じゃない(バックキーでア ップデート画面を抜けられる)
In-app updatesの注意点 アップデートの優先度の設定は、今のところGoogle Play Developer APIを使用しないとできない(Play Consoleから直接 設定できない) ストアにリリースされたものと同じパッケージ名・同じキーで 署名したバイナリでのみテストができる(flavorを分けていたり
する場合は要注意) immediate アップデートは実は強制じゃない(バックキーでア ップデート画面を抜けられる)
In-app updatesの注意点 アップデートの優先度の設定は、今のところGoogle Play Developer APIを使用しないとできない(Play Consoleから直接 設定できない) ストアにリリースされたものと同じパッケージ名・同じキーで 署名したバイナリでのみテストができる(flavorを分けていたり
する場合は要注意) immediate アップデートは実は強制じゃない(バックキーでア ップデート画面を抜けられる)
In-app updatesの注意点 アップデートの優先度の設定は、今のところGoogle Play Developer APIを使用しないとできない(Play Consoleから直接 設定できない) ストアにリリースされたものと同じパッケージ名・同じキーで 署名したバイナリでのみテストができる(flavorを分けていたり
する場合は要注意) immediate アップデートは実は強制じゃない(バックキーでア ップデート画面を抜けられる)
In-app updatesのメリット Playストアと連携できる(手動で必須バージョンなどを管 理しなくていい) デフォルトで immediate と flexible が用意されているので 柔軟に対応できる
ユーザーがストアに遷移する手間を省ける(ユーザー離脱 を防げるのでは?)
In-app updatesのデメリット Android版しか対応できない アップデートを拒否された場合やアップデート中にタスク キルした場合のハンドリング対応など、実装コストがそれ なりに高い ノウハウがまだ少なくハマりポイントが大いにある(あり そう)
In-app updatesでハマったポイント バージョンの低いバイナリを用意しているのに UPDATE_NOT_AVAILABLE( 更新なし) しか返ってこない
In-app updatesでハマったポイント →UPDATE_AVAILABLE になる条件は Play ストアに 「更新」と表示されていること バージョンの低いバイナリを用意しているのに UPDATE_NOT_AVAILABLE( 更新なし)
しか返ってこない
In-app updatesでハマったポイント bundletool などでapk をインストールすると バージョンを下げていても「開く」表示になってしまった
In-app updatesでハマったポイント bundletool などでapk をインストールすると バージョンを下げていても「開く」表示になってしまった →テストの時はPlay ストアの内部テスト版などの利用が 必要そう
In-app updatesでハマったポイント 内部テスト版を公開しても「開く」のままになっている
In-app updatesでハマったポイント 内部テスト版を公開しても「開く」のままになっている →Play ストアアプリのキャッシュクリアで解消
In-app updatesでハマったポイント デバイスに複数アカウントを登録している場合も要注意
In-app updatesでハマったポイント デバイスに複数アカウントを登録している場合も要注意 アカウントA :内部テスター登録済み アカウントB :非内部テスター の状態で内部テスト版を公開
In-app updatesでハマったポイント デバイスに複数アカウントを登録している場合も要注意 アカウントA :内部テスター登録済み アカウントB :非内部テスター の状態で内部テスト版を公開 →アプリで非内部テスターと判断されたのか「更新なし」 と判定されていた
まとめ
まとめ REST APIならAPIレスポンスで判断、サーバーレスなら Firestoreあたりがやりやすそう? In-app updatesはハマりポイントに気をつければユーザ ー体験はよさそう メリデメに気をつけながら自分のサービスに合ったメン テナンス画面・強制アップデートを実装しよう
おしまい