targetSDKを上げるためにGradle周りも更新必要とのこと。同僚からの連絡で気づいた。
AndroidSDK34はAndroid用Gradleプラグイン8.1.1以上が必要で、Gradleプラグイン8.1.1はGradle8以上が必要。
更新頻度が年一なのでそれほど困っていないものの、検知と対応がいつまで経っても手動だなぁ。もう少し自動化できないものか。
<key>UIApplicationSupportsIndirectInputEvents</key>
FlutterアプリをXcode15を利用してビルドしたらInfo.plistが勝手に編集された。
<key>UIApplicationSupportsIndirectInputEvents</key> <true/>
A Boolean value indicating that the app generally supports indirect input mechanisms.
AppleTVのリモコンなど、直接タップする以外の方法を想定しているのかも
In iOS 17 and later, the system defaults to supporting indirect input events, meaning it treats your app the same as if you specify YES.
In versions of iOS earlier than iOS 17, the system defaults to not supporting indirect input events, meaning it treats your app the same as if you specify NO.
iOS17からってことはXcode14の時から出てきて良さそうな差分だが、なぜ今になったのかはよくわかってない。
FlutterKaigi2023参加メモ
基調講演
- 9年前からあったんだーとか、そういえば昔はOptional無かったなぁとか、知らなかった時期の変遷と懐かしい話とで初のオフライン開催一発目のセッションとしてちょうどよかった。アイスブレークのような感じで、少し一体感が出たような気がする。
- 懇親会で知らない人と話すときの会話のネタにもなった。
Flutter アプリにおけるテスト戦略の見直しと自動テストの導入
https://flutterkaigi.jp/2023/sessions/df52c995-5fbb-4ff0-abbc-e6332af98797
- アプリとしてのSREチームという概念が新鮮。単に障害を減らすという観点から一歩踏み込んでいるのはさすが
- リファクタリングした結果の検知にはE2Eテストが役立ったという話(があった気がする。記憶が曖昧)。とあるレイヤーの変更は上位レイヤーから観測しないと分からないということなのか、全然関係ないのか。もう少し自分の中で整理したい
- コストとしてはユニットテストだが、結局E2Eテストで振る舞いを見るのが、一番僕らが見たいテストに近い分活用の幅はあるのかも
出前館におけるFlutterの現在とこれから
https://flutterkaigi.jp/2023/sessions/5b402df3-9e5d-4c0b-80fa-61d9ba356594
- 直前にブースでも別の方から話を聞けたので、話についていきやすかった。単に技術周りを整理しただけでなく、開発元が外部から内部に変わったということも難易度をあげる一員にはなってそう
- Flutterがどうこうというより、チームビルディングを泥臭く頑張った結果大きな課題を解決できた、という話だった気がする。実際そうなのだろうし、それができるチームだからやれたんだろう
- 個人的にもFlutterをチームで使うときは技術の良し悪し以上にメンバーが積極的かどうか?が重要だと考えているので、新しいプロジェクトをやる前に見直したい
Master of Flutter lifecycle
https://flutterkaigi.jp/2023/sessions/f76c37b8-172d-4072-ad4a-bd870bc15728
- M3の人がM3MacでM3デザインスライドを使って発表してた。
- ライフサイクルの関数は徐々に整備されている印象。ある時期を堺に新規の関数が知らないものばかりになっていた、ということに気づいた
- Flutterだから何か特別なものが生まれたというよりもAndroidと似たような役割のIFも似た関数がFlutterにも追加された、という印象。
Dart のコード自動生成の仕組みと、コード自動生成のパッケージを自作する方法について
https://flutterkaigi.jp/2023/sessions/d9cc75af-a3a2-4d0e-af6c-f12aa143ba4c
- パッケージ構成は理解できた。追っていくコードの順番もぎりぎりわかった。中身の実装は一回セッションを聞いただけでは無理だった。
- これ以上無いくらい簡単に説明してくれたと思うので、あとは自分で時間をかけて理解を深めるだけ。なんだけど、普段と微妙に違う考え方が必要だと思うので腰が重い・・・
- 決まったルールの関数を大量に生やしたくなることは山ほどあるので、できるようになれば一番レバレッジが効きそう。
Flutterアプリのセキュリティ対策を考えてみる
https://flutterkaigi.jp/2023/sessions/090ad5b8-7066-40e6-8ca8-58fff766f046
- どこまで対策して何を保証するか・保証しないのは何なのかを言語化するのが第一歩。取り組む範囲を決める指針の一つとしてOWASPのような一般的な指標で整理していく
- 技術が変わっても攻撃対象となるIFや目的は似ているので、結局ネイティブアプリでやっていることをFlutterでも同じように進めていくのが基本方針としてアリかも
- 直接関係ないけど、セキュリティ周りは基本思想があまり変わっていない気がする。昔学んでおいてよかった
なぜわれわれは Riverpod を使うのか
https://flutterkaigi.jp/2023/sessions/0b32515e-2c80-45f4-8ea2-c6c269d2609f
- Riverpodが飛び抜けて優れているというよりも使っている人が多いから設計の議論をショートカットし易い、という自分の考えと似たフレーズが書かれていて少し安心した
AsyncValue推しの話が初耳で重要な考え方だったので、早めにドキュメントを見直したい
その他
- 真面目に取り組むとテストコードはプロダクトコードと同じくらい(かそれ以上)のボリュームになるので、テストコードも1つのプロダクトと捉えて運用コストかけるべきか?
- 懇親会とかで聞いた感じ、Flutterをプロダクト開発に利用して大丈夫か?という話はまだあるっぽい。一時期のKotlinとかJetpackとかも辿った道だけど、もうちょっと何か信用できる何かがないと導入しにくい企業があるのかもしれない。
Visual Studio CodeのThemeの一部の設定を変更する
VisualStudioCodeのThemeをMaterial Theme Darker High Contrastにした。
ステータスバーのテキストの色のコントラストが低く、それだけ気になったのでsettings.jsonで設定を上書きした。
"workbench.colorCustomizations": { "[Material Theme Darker High Contrast]": { "statusBar.foreground": "#ffffff", } }
FlutterのTabのラベルの色はLabelStyleで設定できない
This does not influence color of the tab labels even if TextStyle.color is non-null. Refer labelColor to color selected tab labels instead.
LabelStyleにcolorを設定しても無視される。代わりにLabelColorに色を設定する。
何か理由があって分けているのだろうか?
FlutterのBottomNavigationItemのデザインをThemeで設定するときは気をつけよう
FlutterのBottomNavigationBarに設定するBottomNavigationItemの色を変更したい。その時にウィジェットのselectedLabelStyleやunselectedLabelStyleを変更すれば値が反映されるが、Themeの設定を変えてもデフォルトのままになり設定は反映されない。というバグがあり、それがPRで取り込まれていた。
この変更により今までThemeが反映されなかったアプリもアップデートでThemeが優先されてUIが変わってしまう。つまり破壊的な変更であり、予期せぬ変更のリスクが高い。
なのでこの変更はuseLegacyColorSchemeというBottomNavigationBarのプロパティをデフォルトのtrueからfalseに変更し直す必要がある。
そういうバグがあり得ること、そういう思考プロセスで変更を取り込んでも自動で反映されないようにすること、が全く頭になかったので自分がこの事象に遭遇した時に地味に時間を使ってしまった。
