スマホアプリの強制アップデート

スマホアプリの開発でほぼほぼ必要な機能

Webと違って、アプリは個々の端末にアプリがインストールされているので、アップデートするかどうかは端末所有者の個人の判断や設定に委ねられる。

問題点

例えば記事投稿の機能があったとして、「ver 2から予約機能を実装する」となったとき、「ver 2で予約していたものがver 1では先に表示されてしまう」という事態が起きる。

設定（半分余談）

特に設定していないが私は「Wi-Fi接続時のみアプリを自動更新する」だった

デフォルトでは、アプリの自動アップデートは「有効（オン）」になっています

回避策

○ Web APIを経由する。

メリット

前バージョンと新バージョン両方とも運用できる。

デメリット

管理が大変

設計も煩雑になる。

○ 強制アップデート

メリット

管理が一つのバージョンだけで済む。

最初に入れておけば簡単

デメリット

一番最初に入れておかなければならない。

実例

Firebaseを利用する

https://www.youtube.com/watch?v=_CXXVFPO6f0&list=PLl-K7zZEsYLmOF_07IayrTntevxtbUxDL&t=1s

クラウド上のシンプルなkey-valueストア

A/Bテストもできるらしい。

今回のサンプルコード

2022/9/27時点でAndroidの動作は確認済み。

app idもできれば「work.sendfun.flutter_app_sample」から変えた方がいい。

Remote Configを使ったやり方は完璧ではないかも

2023/3/27 FutureProviderで更新

参考

※有料記事

2023/3/25

厳密にやろうとすると、問題がありそうだったため。

問題点の整理

Remote Configのデータ構造を以下で考えていた。

code:update_info.json

{

"requiredVersion": "2.0.0",

"canCancel": false,

"enabledAt": "2022-08-31T17:00+09:00"

}

table:update_info

requiredVersion 求められるバージョン（アプリの最新のバージョンを指定する）

canCancel アップデートがキャンセル可能かどうか

enabledAt 「requiredVersion」が有効となる日付

以下の状況を考える。

table:version

version canCancel

1.0.0

2.0.0 false

3.0.0 true

問題となる場合

対応策

バージョンとバージョンの有効期間を全てRemote Configのjsonで管理する。

工数が肥大になるので不採用

結局複雑なロジックになるので不採用

canCancelはなくして「requiredVersion」「latestVersion」を定義する。

おそらく問題をシンプルに解決できるので採用

https://gyazo.com/d13eb79efba5e01998b920f4c74cc9c8

table:update_info

latestVersion 最新バージョン

requiredVersion 最低限必要なバージョン

enabledAt 設定の有効日

no : remote configを更新した回数を追加してもいいかも？

メモ

公式に則るならsnakeケースが良いかも　※ プロジェクトによるとは思う。

仕様

latestVersionの扱い

端末のバージョンがlatestVersionより小さいとき

アップデートを促すダイアログを表示

端末のバージョンがlatestVersionと同じ（あり得ないが「より大きい」）とき

アップデートを促すダイアログを表示しない。

requiredVersionの扱い

端末のバージョンがrequiredVersionより小さいとき

キャンセル不可能・キャンセルボタン非表示

端末のバージョンがrequiredVersionより大きいとき

キャンセル可・キャンセルボタン表示

enabledAtの扱い

enabledAtより現在日付が昔のとき

記載された設定は無視・ダイアログも無条件で表示しない

現在日付とenabledAtに差があるほど、「アップデートが必要なのに案内が出せなかった」となるので注意が必要

既存も同じ問題を抱えているはず。

enabledAtより現在日付が進んでいるとき