スタディプラスは、中高生を中心に700万人のユーザーを支えるサービスです。

Mobile向けには2018年よりFlutterを取り入れ、新機能の開発を行なってきました。
2022年、この知見をもとに、Flutter WebによるWeb向けアプリケーションのリプレースを進めています。

本セッションでは、リプレースプロジェクトの概要と、リアルな知見を紹介します。

予定しているセッション内容は、下記の通りです。
なお、アプリケーションは2022年中の公開を目指しており、内容に若干の変更が入る可能性があります。

• なぜFlutter Webを採用したのか
• Flutter Webの懸念や制限
• 開発で工夫したこと
  • モバイルクライアントチームをクライアントチームにする
  • MobileとWebの体験、開発を一つにまとめる
  • PhoneとTablet、Browser向けの開発を意識する
• Flutter Webを採用して良かった点
  • 既存コードの利用による、工数の削減
  • Mobile向けに開発した新機能の横展開
• Flutter Webを採用して感じる課題
  • 宣言的Navigation
  • Mobileでは問題ないがWebでは問題がある(またはその逆の)実装

東急株式会社の内製開発組織「URBAN HACKS」では、「東急ホテルズ」アプリを開発し、その開発フレームワークとしてFlutterを採用しました。
その中で、ホテルの部屋の鍵を開ける「デジタルルームキー」機能を開発したのですが、思いのほか苦労をしたので、実際の開発において得られた知見を皆様に共有しようと思います。

なお、本セッションで解説するアプリでは、実際にBLE通信を行う実装は「鍵解錠SDK」を用いましたので、
「鍵を解錠するためのBLE通信方法」といったものの解説はいたしません。予めご了承下さい。

【解説すること（予定）】

• 鍵解錠SDKのFlutter版というものは存在しないので自作プラグインの実装
• Bluetoothが「使えるかどうか」を「静かに」知ることは思ったより難しい（特にiOSでは）
• BLE関係のランタイムパーミッションにおける機種依存問題と解決策（「どうしてBluetoothなのに位置情報の権限が必要なんですか？？？」問題）
• 現地検証をして得られた気づき

【聴講対象者】

• Flutterが生成したAndroidやiOSプロジェクトを極力汚さずにFlutter非対応SDKを組み込みたい方
• BLEを使用するアプリのランタイムパーミッションで苦労したくない方
• ホテルのデジタルルームキーに関心がある方

2021 年、Dart 2.12 で Null safety がデフォルトで有効になり、とても快適に開発できるようになってきました。

Null safety 以降もさまざまな機能が追加され、Dart はまだまだ進化を続けています。

このセッションでは、近年の進化の振り返りを簡単にした後、Dart の進化プロセスの紹介をして、これから Dart がどんな進化をしていくのかをできる限り詳しく紹介します。

トーク内容

01 近年、どのような進化を遂げてきたか
02 Dart の進化プロセス
03 仕様化を進めている新機能
　・Views on an object without a wrapper object
　・Static Metaprogramming
　・Sound declaration-site variance
　・Patterns and related features
04 おわりに

対象者

・Dart の近年追加された機能について振り返りたい方
・Dart の進化プロセスに興味のある方
・Dart のこれからに興味のある方

Flutterは基本的にWidgetを組み合わせることで多彩なUIを実現させることができます。しかしWidgetというのはあくまでRenderObjectのツリーを作るための設定を示したものに過ぎません。実際に画面を構築するための様々な描画演算処理はRenderObjectより深い世界で行われているわけです。このトークではFlutter FrameworkとEngineの実装を読み解きながら、UIフレームワークの下の部分である描画パイプラインやSkiaによる2次元レンダリングがどのように行われているのかについて考えていきます。Flutterは後発のUIフレームワークですが、ChromiumやAndroidなどに組み込まれたものとも共通した実装がなされていることがわかります。

話すこと(予定)

• Flutter FrameworkとEngineの関係
• RenderObjectと描画パイプライン
• Layerツリーとキャッシュの仕組み
• Skia描画

「Flutter における高価なネイティブ処理実装の発展」

Flutter において、高価なネイティブ(e.g. Java/Swift/C++)処理を実装する方法は、年を経て変わりました。その歴史と将来について話します。

dart:ffi が拓いた世界

Flutter が注目を集めだした 2018年頃、Dart はまだ FFI を備えておらず、ネイティブ処理の組込は実装面でもパフォーマンス面でも厳しいものでした。2022年に dart:ffi の v1 が公開されましたが、これの登場は革新的なものでした。C/C++ を呼ぶ際に Java や Swift を介す必要がなくなった上に、C/C++ の高価な処理を並列処理できるようになりました。この変化の詳細について話します。

Isolate Platform Channels が拓く世界

dart:ffi は、Java や Swift の高価な処理を並列可能にすることまでは叶えてくれません。この課題に対して、Flutter チームは Isolate Platform Channels の検討を始めています。これの詳細について話します。

対象者

Dart Isolate, Platform Channel, FFI について概要を見聞きしたことある方

HOKUTOでは、2019年の8月から3年以上の間、Flutter×Firebase構成でアプリを開発してきました。

開発当初はFirebaseはともかく、Flutterにはあまりプロダクト運用の事例も少なかったため、
快適に開発できていた一方で、幾分か疑問を抱えながら開発を開始しておりました

今回はFlutter×Firebaseの3年間の運用でアーキテクチャや低レイヤーの実装をどのようにおこなってきたかや、
開発当初疑問だったことに対して、今どのように考えているかについてお話ししたいと思います

トーク内容：

• Flutterで開発を始めて3年間、どんなことをしてきたのか
  • アーキテクチャの変遷とその間の意思決定の背景
  • 低レイヤーのUI実装を行なっていて感じたFlutterの良い点、難しい点
  • Flutter×Firebaseの生産性に関して
• Flutter×Firebaseを採用する前の疑問と今の所感
  ex.)
  • FlutterのUIフレームワークとして実現したいものを簡単に実現可能なの?
  • Firebaseでの開発って対応できる要件などで限界こないの？どういうことができないの？

1. abstract
   以前までは、Flutterがロボティクスまで活用されて使用することは想像できませんでした。最近、ロボットは生活周辺のどこでも探すことができるようになりました。ロボットは主にROS/ROS2ミドルウェアを使用し、ユーザーアプリは主にコンピュータ、Web、モバイル（スマホ）まで、様々なプラットフォームで提供されています。従来使用されていたクロスプラットフォームは生産性が低く、不便な点がたくさんあります。
   今回の発表では、既存のロボットアプリケーション開発においてFlutterを適用した経験を共有し、どのような不便な点を克服したのか、そして軽い例を通して使い方を紹介していきたいと思います。

2. 対象者

   • ロボットに興味がある方
   • Flutterアプリ開発経験のある方
   • ソケット通信やgrpcなどのネットワーク通信に興味のある方

3. 注意

   • まったく難しくありません。発表を聞いた後、Flutterの生産性にもう一度驚くかもしれません。

アプリは1度作ったら終わりでは無く、継続的に変化と拡大を続けることが多く、変化の過程で既存機能に不具合が発生すること(デグレード)は極力避けたいです。そのために必要となる考え方がアーキテクチャと単体テストです。ガイドラインに基づいて適切な粒度で分割された部品に対して単体テストを作成することで、規模や開発メンバーが増えても安全にアプリを変化させていくことが可能です。

このセッションではFlutterアプリのアーキテクチャや単体テストについて、Android公式のアーキテクチャガイドと、PEAKSから出版されている「チームで育てるAndroidアプリ設計」を主な引用元として、以下のことをソースコードを含めて解説する予定です。

• RiverpodとFreezedで単体テストが書きやすい3層のレイヤードアーキテクチャを構築する
• ソースコードのディレクトリ構成とクラス/関数の命名規則をガイドライン化してチームの共通認識にする
• 各レイヤーの部品に対して単体テストを作成する
• Mockitoで下のレイヤーのモック実装を作成して単体テストで使用する
• Codecovで単体テストの網羅性を確認する

トーク内容

10Xでは"チェーンストアEC垂直立ち上げプラットフォーム Stailer" というプロダクトを開発しています。このプロダクトはFlutterとDartをフル活用し、クライアント/サーバーで開発言語を統一するという世界的に見ても稀な技術構成、開発スタイルで開発を行なっています。

FlutterとDartを採用するという技術意思決定は2019年になされました。当時は技術として注目を浴び始めていたものの、採用事例が少なく今ほどメジャーではない時代です。そんな時代に、2つの技術に賭けるという冒険的な意思決定をした結果、プロダクトの立ち上げに成功することができ、事業を軌道に乗せることができました。

この冒険的な技術意思決定を支えた根拠は何だったのかを考察し、立ち上げに奔走した3年間の開発を振り返った中で得られた、成功と失敗の教訓をお話しします。

対象者

CTOやTech Leadといった、技術意思決定による成果を事業に還元する責任を持つロールの方向け

Dartには、dart analyzeというコマンドがあります。これはコードを実行せずに予め決められたルールに反する部分を発見しエラーや警告を出すコマンドで、静的解析という仕組みが利用されています。

また、発表者が所属する10XではサーバサイドもフロントエンドもDartを利用してプロダクトを作っており、たくさんのコードを運用していくうえでいくつかの問題を静的解析を使って解決してきました。

今回は、どのような問題があって静的解析が必要になったのか？から始まり、ライブラリやFlutterアプリの開発で静的解析をどのように活かしているのか、また活かそうとして出てきた課題はなにか、そしてその課題をどう解決したのか、成功したのか失敗したのか、最後に今後やっていきたいことを自分たちの実体験を交えて紹介・解説します。

[対象者]
FlutterやDartに慣れてきた初心者・中級者向け

Androidをはじめ、多くのプロジェクトではモジュール（PackageやServiceという場合も）を分割することで開発効率の向上を目指すのが、トレンドの一つです。

個人的にこの方針での開発を「マイクロモジュール開発」と（サーバーサイドにおけるマイクロサービスのようなイメージで）呼んでいます。

約一年前から始まった弊プロジェクトでは、その手法をflutterアプリに当てはめようとしましたが、いくつかの問題がありました。マイクロモジュール開発を進める中で突き当たった壁や、その解決方法（できたこと、できなかったこと）についてトークを行います。

トーク内容予定：
（トーク時間に収まらない場合は内容を一部変更/省略するかもしれません）
・モノリシックじゃだめなのか
・プロジェクトの設計寿命と老後、新陳代謝
・Flutter/dartの問題と解決
　・開発環境
　・pubspec仕様
　・dart言語機能
　・依存ライブラリ管理
　・多言語対応の文字列の分割
　・Unit Testとビルドオプション
　・CI
・コードレビューの要所
・発生した新陳代謝の例
・モジュール分割の基準を考える
・銀の弾丸ではない、この開発手法における先延ばしと諦め

現在弊社ではとあるプロトタイプをFlutterで作成しています。
元々1人チームだったところに、Flutterは未経験/モバイル開発の経験がある私が入社し、プロトタイプの開発を進めていました。
いざ、社内版を出そうとしたときに、今までわかっていたのですが、アプリの立ち上げが異様に遅くなっており、これを改善しないと社内版でも出せないとなりました。
実際に現在も改善を行っているのですが、その改善を行うにあたって取り組んだことを具体的に紹介していこうと思います。
※2022/08/12現在でも、機能の追加もしつつ、まだまだアプリの立ち上げが遅く改善の余地があるので、発表日までの成果を話していきます。

"Flutter DarkMode" で検索すると大体こう書かれてます。
「ダークテーマを用意して切り替えましょう」
そのとおりですね。まったく間違ってないです。さあダークテーマを用意しましょう。

さて、デザイナーさんから渡されたFigmaやXDには何が書かれてるでしょうか。

• DarkModeの場合はこちらのアイコンを使ってください
• この画面はLightModeとDarkModeの違いがありません
• エラーメッセージの色は #EF5353 DarkModeの場合は #FC7463 です
• このボタンのテキストカラーは #FFFFFF です
• このボタンのテキストカラーは #333333 DarkModeの場合は #FFFFFF です
• このトーストのカラーは...

困りましたね。テーマにはそんな細かな設定がありません。もしかしたらあるかもしれませんがひとつずつ調べるのは大変です。

そんな困ったときの、ひとつの解決方法をお話しようかと思います。

近年、モバイルアプリのクロスプラットフォーム対応を進める目的で Flutter が導入されることが増えてきています。くわえて、とりわけ少数のチームで開発を進める場合、開発効率を高めるために mBaaS が導入されることも少なくありません。そこで課題となるのが、中長期的な運用に足る拡張性やスケーラビリティと短期的な開発効率のバランスをどのように確保していくか、ということです。

本セッションでは、短期的な開発効率を高めつつも将来のインフラ移行に備えることが可能な疎結合なアーキテクチャを Flutter プロジェクトの初期から採用することを提案し、その具体的な設計やコードのサンプルを解説します。

• Flutter とオニオン・アーキテクチャ
• インフラ層を隔離することの意義とその方法
• モックと単体テスト
• 疎結合を実現する状態管理モデル（Riverpod, StateNotifier）

FlutterはモバイルからWeb、デスクトップまで幅広いアプリケーションを一度に開発でき、解決できるビジネス上の問題の幅を大きく広げました。
一方で、実世界ではアプリケーションのみで解決できる問題は少なく、ハードウェアを必要とするものもあります。

Raspberry Piを筆頭としてシングルボードコンピューターが普及し、OSが無いなどの組み込みソフトウェアに特有の事情を理解しなくてもハードウェアのプロトタイピングが可能な環境が一般にも普及してきました。また、シングルボードコンピューターの安価さを活かし、シングルボードコンピューターを組み込んだ製品の開発も可能になりました。
今セッションではシングルボードコンピューターの一つとしてRaspberry Pi 4 Model Bを使用して、FlutterアプリケーションからGPIO（General-purpose input/output）ポートを制御して種々のハードウェアを制御する方法を説明します。

セッション内容（案）

・Flutterとシングルボードコンピューター（Raspberry Pi）
・GPIOとは
・DartでGPIOポートを制御する（Ｌチカする）
・DartでI2C機器を制御する
・作例：二酸化炭素が一定値を上回ったら換気する
・Linux以外のOSでのGPIOの制御（もし調査ができれば…）