2024年11月21日(木)、22日(金)にFlutterKaigi2024が開催されました。
弊社リンクウェルもアプリをFlutterで開発しており、ブロンズスポンサーとして協賛しています。
私はFlutterを学び始めてから初めての大きなイベントへの参加だったため、Flutter界隈の流行や各社の取り組みを学ぶ機会になりました。
今回は受講したセッションの紹介と社内で行った共有会について紹介します。
また、弊社のメンバーがDay1の参加レポートを紹介しているのでそちらもどうそ。
社内共有会について
FlutterKaigiへの参加後に社内で共有会を開催しました。
目的としては以下のためです。
- イベントに参加していないメンバーにもセッションの学びを効率よく共有すること
- セッションの学びとチームの現状とを照らし合わせ、チーム内での認識をそろえること
FlutterKaigiはありがたいことに全セッションを公開してくれています
各自でセッションを見るに留めずに、チームで共有会を行うことで講演のエッセンスを短時間で効率よく共有でき、Ask The Speakerや懇親会で得た登壇者との対話による情報もメンバーに共有できます。
また、FlutterKaigiは最新の情報や他社の事例を多く学べるため、それを受けて自分たちのポジションやスタンスをあらためて議論する時間にしました。
セッションと社内でのディスカッション
特に印象に残ったものと、それを受けてチームで行ったディスカッションについて紹介します。
キャンセルします！処理を
非同期処理のキャンセルの話で、協調的キャンセルというワードが印象的でした。
講演後のAsk The Speakerで深ぼったお話が聞けました。
例えば、キャンセルはnullやレスポンスで扱うよりも例外として扱ってtry catchで管理したほうがよいとのことや、asyncメソッド全てにキャンセルを入れるよりは、明示的にキャンセルする必要があるメソッドにのみ適用するのがよいとのことでした。
asyncメソッドは最上位の呼び出しまで非同期処理となることが多く、CancelTokenはどの関数にも渡して、常にキャンセルを考慮する必要があると考えていましたが、ここは簡易的でよいことに安心しました。
また、弊社の開発でもキャンセルのルールは暗黙的に例外処理としていたため、チーム内で今後も例外として扱うという意思の統一が図れました。
講演ではdioのCancelTokenを扱った例が紹介されていましたが、弊社では通信のプロトコルにおいてはGraphQLを採用しているためdioは使用していません。もしRESTならばdioパッケージがよいことも議論しました。
ImpellerとSkiaについて
Flutter専用のレンダリングエンジンImpellerとGoogleの汎用レンダリングエンジンSkiaを比較しそれぞれの構成やImpellerのメリットについての紹介でした。
SkiaはRasterizeとShadingを並列に行う点が特徴的で、それがメリットでもありながら2D専用のエンジンになっていたのだと理解できました。
Impellerはシェーダーを事前コンパイルする方式になったため、compilataion jankが発生しないことがメリットです。また、Impellerはレンダリングが一般的なGPUパイプラインと近い直列型になっています。個人的にはゲームエンジンなどのレンダリングはこの直列型が多いためより馴染みのあるパイプラインに感じます。
最近のFlutter界隈でもゲームエンジンやゲーム制作にFlutterを使用する例が紹介されているのもこの取り組みが背景にあるのかなと考えています。
iOSではImpellerが正式導入されていますが、AndroidではImpellerがまだプレビュー版であり導入されていないため今後の発展に期待しています。
Figma Dev Modeで変わる！Flutterの開発体験
FigmaのDevモードを活用し、デザイナーとFlutterエンジニアが共通の認識を持つことで開発の効率化を目指していました。Devモードは弊社でも活用できており、デザインルールの共有や細かいデザイン適用の際に便利です。
Compare Changes機能による差分の明示化については、弊社の現状のフローでは本来差分がないところに差分が出てしまったり、逆に差分を表示してくれなかったりとまだまだ改善が必要でした。
FigmaとWidgetの対応について、弊社でもどのWidgetを使うか困ることは多く、Figmaでコンポーネント一覧を作っても、実際のアプリと細かい点が乖離してしまうという問題があります。WidgetBookの導入を考えましたが、メンテナンスコストやデザイナーへの共有フローなども含め整備することが多く、まだ答えが見つかっていません。
本講演はそういった悩みへのアプローチの一つとして学びが多くためになりました。
ほかにもFigmaからのFlutterのコード生成にAIエディタのCursorを活用している点は参考になりました。以前にChatGPTによるコード生成は試してみましたが、プロジェクト内の共通Widgetを参照してくれなかったり、プロジェクトのルールを都度プロンプトに含める必要があったりと、ハードルの高さを感じていました。講演ではCursorのルール（プロンプト）を別ファイルとして設置し、ルール自体を育てていくことでより高精度なコード生成ができていました。
Effective Form ~ Flutterによる複雑なフォーム開発の実践 ~
複数入力箇所がある複雑な画面を扱う話でした。
ポイントとしては、
- 単一画面内ではflutter_hooksで入力状態の管理を行うこと
- Dirty管理にformzを使うこと
- Enumで入力状態を管理せず、Classで管理すること
- 複数の画面にまたがる場合はSingle Source Of Truthに従い、状態を一箇所で管理すること
- AppState（画面にまたがるグローバルな状態）とEphemeralState（特定の画面に依存したローカルな状態）を意識すること
などが挙げられます。
ちょうど自身でも入力画面の実装を行なっていたところだったのでピンポイントな講演でした。
その際に、作成中の機能では、
- ViewModelがFlutterに依存したTextEditingContollerを参照している
- EphemeralStateでよいところをAppStateにしている
といった課題が見つかり、さっそく学びから改善できています。
チーム内でも設計に関する議論が行え、あらためて設計の方針をそろえる機会となりました。
感想
FlutterKaigiは初参加でしたが非常に多くの学びが得られました。
講演を聞くだけではなく、Ask The Speakerを通じた対話や、懇親会でのFlutterエンジニアとの情報交換など、現地参加ならではのメリットもありました。
また、各社のスポンサーブースにもFlutterエンジニアがおり、悩みを相談し議論できたことも有意義でした。
主催者や運営の方々、参加者による熱量を感じられたイベントでした！
次回の開催も楽しみにしています！
Discussion