FlutterKaigi 2023公式アプリ開発の感想とまとめ

FlutterKaigi 2023にて、アプリチームのリーダーとして活動していた koji-1009です。

カンファレンス参加、そして運営の皆様、お疲れさまでした。 アプリ開発者として、クラッシュもデータの入稿ミスもなく、1日を過ごせたことに安堵しています。


カンファレンスのアプリ経験は、なかなか得難いものです。 そんなわけで、思い出深いFlutterKaigi 2023アプリについて、忘れないうちに書き記しておきます。

github.com

よろしければお付き合いください。

開催前、下記の記事を書きました。 まだリリース前ということで、開発の経緯やコンセプトの紹介が主なものとなっています。 *1 *2

medium.com

カンファレンスアプリの要件と目的

カンファレンスのアプリは、アプリの開発者がほとんどの要件をコントロールすることができません。 一覧にすると次のような項目になります。開催日が決まらないと、開催場所が決まらず。開催場所が決まらないと、設置できるトラック数が決まらず。と順々に巡っていくのがミソです。

  • 開催日、日数
  • 開催場所
  • トラック数、セッション数
  • セッションの掲載内容
  • スポンサー数、掲載内容
  • 参加者が利用する端末(OS、言語、ディスプレイサイズ)

どれもアプリ開発者がコントールできない、もしくはコントールするべきではない項目です。 一方で、カンファレンスアプリにおいては、これらの情報が軸となります。これらの情報が適切に表示されるからこそ、カンファレンスのためのアプリを作る意味があることになります。

そんなわけで、今回のアプリ開発では「開発者としてこだわりを持たないことにこだわる」ことにしました。 mediumに記載した3つのコンセプトは、こだわるべきではない場所以外でこだわりたいところを表現したものになります。

  • シンプルな構成、状態管理
  • M3の全面採用による、可読性の確保
  • 「参加者が主役」であることを重視したカスタマイズ性

このため、「アプリは便利だったけど、特に気になるところがなかったな」と思われていれば、今年の開発としては成功だと思っています。

エンジニアコミュニティとカンファレンスアプリ

カンファレンスの主役は、コミュニティです。

コミュニティは、具体的には登壇者と聴講者の皆さま。そしてスポンサーの皆さまだと考えています。 カンファレンススタッフ、そしてカンファレンスアプリは、そららを支える役割を持っています。

以上の前提を踏まえて、カンファレンスアプリを作る理由や目的について、非常に悩みました。 2023年のアプリを作るにあたっては、次の2つの観点を重視することとしています。どちらも、ここから始めるぞという決意的なものですね。

カンファレンスへの参加の一形態としてのアプリ

カンファレンスアプリは、開発の途中で公開されるものと、開発が完了した後に公開されるものがあります。 DroidKaigiのconfernce-appや、Googleのioschedを見比べると、その違いはわかりやすいのではないでしょうか。 どちらが優れているというものではなく、どちらの選択肢もアリだと思っています。

github.com

github.com

そして、FlutterKaigi 2023のアプリを作るにあたっては、開発の途中で公開する選択をしました。


私見になりますが、カンファレンスアプリの開発に関わることができると、カンファレンスを通して得られる経験が大きくなります。 もちろん技術的に得られるものもあるのですが、それ以上にモチベーションが高まり、より前向きにカンファレンスに参加できる印象です。 たとえばカンファレンス会場で書いたコードが動いていると、嬉しくなりますよね? 私はなります。

こういった事情もあったので、アプリ開発カンファレンスイベントの一部として位置づけました。 23年の9月にコード公開に踏み切ったのも、こういった事情によるものです。 気づいてもらえるかな……と不安に思う面もあったのですが、本日までコア・メンバーを含めて22名のコントリビュータの協力を得ることができました。

github.com

FlutterKaigiとして、また国内のFlutterのカンファレンスイベントとして、前例が無い中で多くの人に参加いただけたことを嬉しく思います。 大変ありがとうございました!

技術交流としてのアプリ

懇親会などでは、どうしても話題を気にする必要が生じます。特に、コードについては難しいものです。 オープンに開発されているライブラリについてであっても、利用シーンなどに踏み込んでいくと、徐々に話しにくくなります。 ここに、コミュニティの誰もが見ることのできるアプリのコードの重要性があります。

また、技術的なチャレンジをしやすい点も見逃せません。カンファレンス当日に使えないことを避けることができるのであれば*3、知見の少ない技術を取り入れやすい環境となります。というのも、オープンな状況で失敗したとしても、それを一つの知見とすることができるためです。 今回のアプリでは、Flutterのbetaチャンネルの採用を試みました。そのほか、riverpod_generatorgo_router_builderなどのコード生成も積極的に採用しています。

アプリの規模感としては物足りないかな、と思うところはあります。 ただカンファレンスを楽しむための機能や、実験的な実装などを行うことで、より技術的に交流しやすいアプリを目指せるのではないか、と感じています。

FlutterKaigi 2023公式アプリで(こっそり)こだわったところ

運用やコードにおいて、こだわってたところのアピールです。 こんなことを考えてたのか、ぐらいで見てもらえれば。

簡単に実行できること

git cloneflutter run したら実行できる状態を保つことを、意識していました。 実際はfvmのセットアップなどが必要になるため、初めてFlutterを触る人にはハードルが高かったかもしれません。 一方で、VSCodeIntelliJ用の起動設定を管理するなど、ある程度の経験があれば対応できるレベルだったのではないかなと思います。

また、AndroidiOS、Webの3環境が常に利用できるようにしていました。 Flutterは開発できるアプリの環境が多いため、利用している開発環境にも多様性があります。 このため、今回サポートしていた環境では、常にビルドができることは必須の条件であったように思います。

PRが作成された時にweb版のpreviewを作成するのも、こだわっていた事柄です。 previewが生成されることで、同時に複数のPRが出ていても、それぞれの実装とその影響を確認しやすくなります。 こちらの処理については、publicなrepositoryだと表出する問題がありました。次の記事に内容はまとめてあるのですが、この対応も興味深かったです。

zenn.dev

可読性とカスタマイズ

コンセプトそのものになるのですが、FlutterKaigi 2023アプリでは可読性が高い状態になるような努力をしました。 具体的には、次のような項目に取り組んでいます。

  • M3を採用し、文字が見えやすい状態を保つ
  • BIZ UDGothicをfontの選択肢に入れる
  • tooltipやcontent descriptionのセット
  • (標準設定を保つことによる)Dynamic Type等のサポート

まだまだやるべきこと、やれることは多いと思っています。 どのようなことができるのか、やるべきなのかは、引き続き勉強が必要だなと痛感しました。 ぜひ、対応した内容とその効果から、各所にフィードバックいただければと思っています。


他方でユーザーにとって見えやすいことには、ユーザーが見ていて違和感がないことも含まれるのではないか? と考えました。 このことから、以下のような機能を追加しています。

  • Material Youをサポートしている
  • 複数のフォントが設定できるようにする
  • ライトモード、ダークモードがアプリ内で設定できる
  • 表示言語をアプリ内で設定できる

FlutterKaigi 2023アプリは文字が多いアプリになるので、破綻するケースが発生するのではないかと思っていたのですが、問題はありませんでした。 M3のデザインシステムとしての実力を知る、良い機会になったように思います。

ランチマップについて

データ作成を、ナビタイムジャパン株式会社のみなさまにご協力いただきました。 本当にありがとうございました!


マップ機能においては、ナビタイムとGoogleの2つの地図を並列に扱っています。 これは2社にスポンサーいただいていることから、アプリチームで検討した項目です。 せっかくスポンサーしていただいたので、この機会に、ぜひサービスを使ってみてほしい! という想いの表れになります。 現地でご参加いただいた皆様には、ご利用いただけましたでしょうか?

そしてランチマップの表現にはTableViewを利用しました。 これは、次のような意図のもとに実装しています。

  • Map上にピン留めした情報では、どのピンを選ぶかの一覧性が悪くなること
  • 作成いただいたデータを見ながらお店を考える場合には、表形式が比較しやすいこと
  • two_dimensional_scrollablesが新規に登場したので、試験的に実装しやすかったこと

当日会場で伺った感想などを見ると、うまくいった試みだったのではないかな、と考えています。 性質上、毎回できる類のものではありませんが、チャレンジできるタイミングでチャレンジできるとよいなと。 なにより、お祭りっぽくて良いですよね?

当日運用とFirebase

FlutterKaigi 2023では、午前中に一部セッションの時間が変更となりました。

FlutterKaigi 2023アプリでは、2つの処理でこちらの対応を行いました。 どちらも、会場での運営の合間に実施しています。 *4

  • Real-time Remote Config (Firebase Remote Config)によるデータ更新
  • Firebase Cloud MessagingによるPush通知

特にFirebase Remote ConfigのReal-time更新については、非常に良い採用例になったのではないかなと思います。 今回のような規模のイベントにおいて、非常に小さな手間*5で対応できるため、非常に良い仕組みだと感じます。 もともと「会場で何かデータを更新するかもしれない」と思って追加していた機能であったので、意図通りに動作させることができてよかったです。


話題は外れてしまうのですが、データの運用については、Webページとアプリで方針が異なっておりました。 この差異から得られた知見については、どこかでまとめられればと思っています。

実現したかったけどできなかったこと

最後に、追加しきれなかった機能について。

複数の日本語表記

FlutterKaigiは日本で開催されるFlutterのカンファレンスです。 この日本で開催されるということを強く意識すると、カンファレンス用のアプリは日本の開催に合わせたものであるべきではないか、と感じます。 一方で、現在用意されている日本語表記は、母語を日本語にされている方以外には扱いづらいものです。

このことから母語が日本語でもない方向けの、日本語表記を用意できないかな、と考えていました。 1つのLocaleに対して、標準のarbでは複数の表記をもてないため、Dartのクラスによる言語切り替え機能を入れたのもこの下準備となります。

ただ、セッション内容をはじめ、一部の英語表記の準備が間に合っていない状態でした。 外部のコントリビューターが実装を行えるようにするため、複数の言語ファイルをなぜ用意するのかを紹介する必要もあり、間に合わせることができませんでした。 やりようはあったような気がする、というのが今の率直な気持ちです。

mobile以外のプラットフォームサポート

カンファレンスイベントでは、会場にPCを持ち込むのが一般的となります。 このため、FlutterによるmacOSWindowsLinuxのサポートを行いたいと考えていました。

2023年現在では、FirebaseがmacOS程度しかサポートできていません。 このため、取り急ぎWeb版のサポートを行うことで、mobile以外のプラットフォームのサポートとしています。 ただ、Web版ではFirebase Cloud MessagingのTopic通知が利用できず、Push通知を送る準備ができていませんでした。

Flutterの発展に合わせて、今後サポートできるプラットフォームが増やせればといいなと思っています。

まとめ

FlutterKaigi 2023公式アプリをたくさんの方に使っていただけて、とても嬉しかったです。 会場で歩いている方が「次にどのセッションにしようか」と話しながら、アプリを利用してもらえた経験は、何事にも変え難いものだなと。

カンファレンス当日は、受付前の誘導として歩き回っていました。 「こんなに人が来ているのか……!」というのを直に感じることができ、大変楽しかったです。 みなさま、ありがとうございました!

*1:こちらを発表することで、知名度やコントリビューションのモチベーションが高めればいいなーと思っていました

*2:medium用に作った画像が、なかなかいい感じにハマってよかったです

*3:ここは運営チームの努力のしどころ

*4:もしかしたら、入り口近辺でMBPを広げているところをご覧になった方がいらっしゃるかもしれません

*5:配信しているJSONを手で書き換えていました