hamburger-tech-nits

主にプログラミングのNITSな話

Firebase App DIstributionの招待リンク機能

AppDistributionの招待用URLにはグループを設定できる。

てっきりアプリに対してグループで制限をつけたURLが発行されると思っていたがそうではないらしいということを知った。

つまり、以下のようにURLごとにタップできるグループとインストールできるアプリが制御されていると思っていた。

アプリ グループ URL 制御
アプリA グループ1 https://urlA1 グループ1の人がタップしたら、アプリAをインストールできる
アプリA グループ2 https://urlA2 グループ2の人がタップしたら、アプリAをインストールできる
アプリB グループ1 https://urlB1 グループ1の人がタップしたら、アプリBをインストールできる

正しくはグループに発行されたURLをタップするとアクセス許可されているアプリをすべてインストールできるようになるらしい。つまり上の例でいうと、https://urlA1https://urlB1をタップするとグループ1の人は両方のアプリの権限が手に入る模様。

firebase.google.com

テスターは、そのグループがアクセスできるすべてのアプリのすべてのリリースに追加されます。

ということを、別部署の人にURLを共有したときに気づいた。

Xcode15にアップデートした後にやったこと

Xcode15にアップデートしたら、Flutterのビルドが通らなくなったりSimulatorが起動しなくなったりした。

元々Xcode15.0.1を利用していたが、新しいバージョンがでていたので15.2に更新し、最初からやってみることにした。

まず、Xcodeの最新を利用するように切り替える。

$ sudo xcode-select --switch 
/Applications/Xcode_15.2.app/Contents/Developer 
Password:

$ sudo xcodebuild -runFirstLaunch

cocoapodを更新する。

$ pod --version
1.12.1

どうやらcocoapodのバージョンが古いのがビルドできない原因だった模様。commitされているPodfile.lockでも差分が出ている。

$ gem update cocoapods

$ pod --version 
1.14.3

$ pod install

これでビルドが通るようになった。

ビルドして、Simulatorにインストールしようとしたところ、またエラー。Simulatorのクラッシュとともに以下のログ。

[ERROR:flutter/shell/platform/darwin/graphics/FlutterDarwinContextMetalImpeller.mm(42)] Using the Impeller rendering backend.

Error connecting to the service protocol: failed to connect to http://127.0.0.1:55528/ZoWqMhYj8UY=/

Impellerを無効化すれば良いのかと思ったが、別記事でiOS17の再インストールによって解決した旨を見かけたので試してみる。

qiita.com

XcodeのWindowメニュー

+を選択

OS Versionを選択

iOSを右クリックして、Delete

削除完了したらコマンド経由で再インストールした。

$ xcodebuild -downloadPlatform iOS 

インストール完了後再度ビルドしたら、無事実行できるようになった。

DeepLinkとAppLinkとUniversalLink

ややこしい

一般用語がDeepLink。基本的にはこれを使って会話したい。

e-words.jp

WebのhttpsスキームのURLをフックしたい場合、

AndroidはApplink

developer.android.com

iOSはUniversalLink

developer.apple.com

WebのhttpsスキームのURLをフックしたい場合、

この機能をまとめる一般用語がほしい。バックグラウンドがAndroidiOSかで使う言葉が違うのが面倒。


この機能をまとめる一般用語がほしい。

同僚はUniversalLinkと区別してDeepLinkを表現したい時、カスタムURLスキームのリンクという言い回しにしているそう。回りくどいが正確。

コンポーネントよりプロダクトをデザインする

toBプロダクトのデザインを考える時間が以前よりも増えた結果、コンポーネントよりもプロダクト、UIよりもUXのデザインを重視するようになってきた。

ビジネスユーザは見た目が良さより体験を重視する気がする。見た目も当然大事だけど。

直近だと、モバイルアプリはユースケース実現のためのタップ数や認知コストを気にすることが多い。

ダミーデータだけ見ていると忘れがちだが、データのパターンやデータ量でユーザの行動が変わることがあるので注意。たとえば、データが少ないときは上からタップするがデータが多いときは検索する、とか。

この場合、検索が機能していればまだ良くて、検索しても条件が足りず不要なデータもチェックしたりする場合もある。

プロトタイプで静止画を見ていると想像しにくいので、デザインもアジャイルっぽく改善できる体制を作ってみたい。

Vue3で推奨される状態管理ライブラリはPinia

Vue3における状態管理はPiniaが推奨された。

Vue2ではVuexが推奨されていたので、Vue3移行に伴いツールを移行している。

pinia.vuejs.org

💡 直感的
ストアはコンポーネントと同じくらい身近なものです。適切に整理されたストアを作成できるように設計された API。

🔑 タイプセーフ
型は推論されます。つまり、ストアでは JavaScript でもオートコンプリートが提供されます。

⚙️開発ツールのサポート
Pinia は Vue devtools に接続して、Vue 2 と Vue 3 の両方で強化された開発エクスペリエンスを提供します。

🔌 拡張可能
ストアの変更に反応して、トランザクションやローカル ストレージの同期などで Pinia を拡張します。

🏗 モジュラー設計
複数のストアを構築し、バンドラー コードでそれらを自動的に分割します。

📦 非常に軽い
ピニアの重さは約 1.5kb で、その存在を忘れてしまうほどです。

とのこと。

Flutter(というかモバイルアプリ界隈)では、状態管理アーキテクチャがあってそれの実現のためにライブラリを使うという感じだった気がする。RiverpodしかりProviderしかりBlocしかり、単方向データフローを実現するツールとしてライブラリを利用しているイメージ。Riverpodはライブラリ先行の毛色が強めかも知れないけど。どっちにしろ、メジャーバージョンの変更とともにアーキテクチャ変更するのはあまりない。

Webの文化なのか所属企業の文化なのかは分からないが、Webはライブラリがアーキテクチャを提唱していて、ライブラリ導入によって設計の実現にこぎつけている印象があって慣れない。Vueをアップデートして、ライブラリを変更して、設計を変更して、Nuxtをアップデートして、というプロセスをしているうちに次のメジャーバージョンが視野に入ってきてそう。

なんにせよ同僚が忙しそう。

targetSDK34対応アプリはAGP8.1.1以上でGradle8以上

developer.android.com

developer.android.com

targetSDKを上げるためにGradle周りも更新必要とのこと。同僚からの連絡で気づいた。

AndroidSDK34はAndroid用Gradleプラグイン8.1.1以上が必要で、Gradleプラグイン8.1.1はGradle8以上が必要。

更新頻度が年一なのでそれほど困っていないものの、検知と対応がいつまで経っても手動だなぁ。もう少し自動化できないものか。