昨今、Flutterをはじめに宣言的UIが当たり前になりました。
それに伴いバックエンドとのデータのスキーマ設計に悩まれたことが多いのではないでしょうか？
そのような状況の解決にはGraphQLの活用が考えられるのではないでしょうか。

今回のトークではその入門の題材に「Hasura」と呼ばれるGraphQLマネージド・サービスを使ったアプリケーション開発を
約半年ほど個人開発で続けて、様々な学びのポイントありました。
その中で得たい以下の内容のトークします。

• FlutterとHasuraの組み合わせについて
• 「Artemis + graphql_flutter」の組み合わせたものを今回は採用しましたが、その理由とferryとの比較について
• GraphQLを用いたFlutterアプリケーションのテストコード戦略

Flutterは、クロスプラットフォーム開発ができ、モバイルアプリやWebアプリ、デスクトップアプリを作ることができます。
そのため、多くの開発者がFlutterを利用しアプリケーションを作成しています。
しかし、作成されているアプリケーションは、AndroidやiOSのモバイルアプリとしての形が多い状況となっており、
Webアプリは少なく、Web周りの実装についての知見が余り公開されていないように思います。
そこで、Flutter Webで開発していく中で、ハマった点や対処方法などをモバイルアプリ開発者の視点から紹介します。
筆者は、モバイルアプリ開発(iOS)をメインにやっており今年からFlutterを利用してFlutter Webの開発を進めています。

現時点で予定している、セッションの大まかな流れは下記の通りです。

• 画面サイズの可変対応
• Web renderers
• HotReload
• Webでの並列処理
• Webでのパス設定

アプリケーションの開発では、モデルクラスの実装が多く、さまざまなケースでモデルクラスに色々な機能が足されていきます。
例えば、モデルクラス同士の比較や一つのモデルに複数の状態を持ちたい（Union Type）などです。
KotlinやSwiftにはそういったモデルクラスの実装に便利な言語機能がありますが、残念ながらDartにはありません。
そのため、自前で実装するしかありませんがDartの標準機能だけでは難しく、できたとしても冗長なコードやコーディングミスによるエラーが発生しがちです。
そこで、freezedというコードジェネレーターのパッケージを利用し、様々な機能を持ったモデルクラスを自動生成し、円滑に開発を進める術をご紹介します。

このセッションでは、freezedの解説や実装方法、実際に書いているときにハマった点や便利だった点などを紹介します。
このセッションを通して、freezedについて知り実際に書けるようになることを目指します。
現時点で予定している、セッションの大まかな流れは下記の通りです。

• freezedとは何か
• freezedの使い方
  • モデル定義
  • copyWith
  • Union型
  • FromJson/ToJson
• freezed利用中のハマった点、便利だった点

Flutterでのアプリ開発で、BaaSとしてもはやデファクトスタンダードとして定着しつつあるFirebase(Cloud Firestore)。
そこにFirebase Alternativeとして名乗り上げているBaaS、”Supabase”
そのSupabaseの良いところを、特に個人開発者目線で紹介します。

メインで話したいこと

Firebase(Cloud Firestore)と比較した際のSupabaseの良いところ

• RDB（Cloud FirebaseはNoSQL）
  • Supabaseの特徴は、RDBであるということ。Cloud FirestoreはNoSQL特徴があるが、多くの開発者はRDBのほうが慣れていてNoSQLの正しい設計をわかっている場合は少ない。今まではFirebaseがデファクトとして存在していたのでほぼ一択の状態だったが、本当はRDBのBaaSを求めていたのではないか。
• RLS（Cloud Firebaseはセキュリティルール）
  • SupabaseはPostgreSQLベースなので、PostgreSQLの知識が使える！
• 料金設定
  • 基本的に月額制なので、開発中にリクエスト投げ過ぎないようにする心配がない！

Flutterに限らず、アプリ開発ではバックエンドを開発・本番環境（時にはもっとたくさん）と使い分けることが一般的かと思います。

iOS Xcodeプロジェクトの変更、なんとなくやっていませんか？
一筋縄ではいかないFirebaseプロジェクトの使い分けに苦労していませんか？

このセッションでは、Flutterの環境使い分けの様々なTipsをご紹介します。

• dart-defineの扱い方
• 環境ごとにfirebaseプロジェクトを使い分ける
• メンテ不能に陥らないためのXcodeプロジェクト管理方法
• Debug / Releaseコードの分岐方法
  ...etc

位置情報を使用したアプリ開発をしたことがある人は一度は感じたことがあるかもしれませんが、
位置情報取得に関するポリシーは年々制約が厳しくなってきており、OSやOSのバージョンごとの制約が複雑になってきています。
そこで、Android, iOS(できたらその他のPlatformも)の制約を整理しつつ、それぞれで考慮したことや苦労したことを紹介します。

予定しているセッション内容は、下記の通りです。（変更可能性あり）

• 各OS・OSバージョンによる位置情報の権限周りの違い
• 位置情報系packageのそれぞれの違い
• Geofenceについて
• 位置情報を用いたアプリの権限の例

最近仕事でBLE通信アプリを開発しました。
BLE関連知見がなく且つFlutter初心者だったですが、安定して通信できるBLE通信基盤を設計できました。
本セッションでは、BluetoothデバイスのBLE仕様に合わせて、アプリの方のBLE通信基盤どう設計したのかを紹介します。

内容は主に以下です（変更が入る可能性あります）
・BLE通信を実装するときに使ったpackage: flutter_blue_plus
・BluetoothデバイスのBLE仕様と課題
・アプリのBLE通信基盤の設計
・安定している通信を実現するために工夫したこと

FlutterにはMaterialやiOSのUIkitを参考にしたアニメーションが標準で実装されています。このおかげで、特に何も気にすることなく普段iOSやAndroidで見るようなアニメーション込のコンポーネントを実装することができます。
しかし、実際にアプリを開発する際には、プロダクトに合わせたカスタムアニメーションを作ることもあるでしょう。その時、どのような方法で実装すればいいか、適切な方法を選ぶにはどうすれば良いでしょうか。
本セッションでは、「Flutterにおいて適切な方法でアニメーションが実装できるようになる」ことを目標に、アニメーションの種類・特性に合わせていくつかの実装方法を紹介します。

アプリにおいて正常に処理が完了しないときに適切なエラーメッセージを表示することは、適切なユーザ体験とサポートコストの軽減につながります。またエラー処理は多くの画面で同じような処理になることが多いので、使い回し可能な部品にすることは開発者体験の向上につながります。このセッションでは以下の内容で、Flutterアプリでのエラー処理の設計と実装例をソースコードと併せて解説します。

• エラーを分類する
  • 原因と対処
    • ネットワークエラーなど、ユーザに原因があるので、ユーザが対処できる
    • サーバエラーなど、サービス提供元に原因があるので、ユーザは待つことしかできない
  • 発生場所
    • API呼び出しエラーなど、多くの画面で発生する
    • パスワード間違いなど、特定の画面でのみ発生する
• エラーの表示方法
  • Scaffold上のコンテンツ、AlertDialog、Toastのどれで表示するかを、material.ioを参考にして考える
  • ネットワークエラーの場合は再読込可能にする
  • ページングに対応した画面でのエラー表示
• 使い回し可能なエラー処理部品の実装
  • UIの状態管理担当のヘルパ
  • ウィジット

FlutterのWidgetを利用していると、Key?プロパティがちらほら見え隠れします。
このKeyはなんのためにあるのでしょうか？ どのように設定するのが正しいのでしょうか？

このセッションでは、FlutterのKeyクラスを改めて紹介します。
その上でFlutterのソースコードを読み解き、Keyがどのように使われているかを理解することを目指します。
Keyの使われ方を理解することで、Keyをより効果的に利用し、一歩上のFlutterアプリケーション開発に取り組みましょう。

• Keyとはなんのためにあるのか
• LocalKeyとGlobalKey
• StatefulWidgetとKey
• ListとKey

Flutter Desktop 製のアプリを 2021/04 にストア公開してから、約1年半の時が経ちました。
Flutter Desktop でアプリを開発してリリースする上で、最高な体験も辛い体験もありましたが、その話をしたいと思います。

Flutter 3.0より、FlutterはMobile/Web/Desktopをサポートするフレームワークになりました。
また、ここ数年のコロナ禍により、Tablet端末をサポートする機会も多くなっています。

複数のプラットフォームをサポートするためには、画面幅に応じたUIの調整が大切になります。
しかし、全ての画面に対して、画面幅に応じた実装を行うのは高コストです。
宣言的UIを採用することでシンプルな実装の組み合わせになるものの、コードやクラスの量が膨大になってしまいます。

このセッションでは、画面サイズごとのクラス分割をしない程度の工数で対応する、マルチデバイス対応について検討します。
少ない工数で大多数の画面に対応し、作り込みたい画面に全力投球できる環境を作りましょう。

現時点で予定している、セッションの大まかな流れは下記の通りです。
ただし、Flutterやライブラリのアップデートなどにより、内容が一部変更される可能性があります。

• Material Design Breakpoint
• PaddingとScrollbar
• CustomScrollViewとSliverPadding
• adaptive_components(material.io)

スタディプラスは、中高生を中心に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では問題がある(またはその逆の)実装

ハイパフォーマンスな Flutter アプリ開発に関する、歴史と将来の話をします。

トーク内容

歴史について

Flutter が注目を集めだした 2018年頃、Dart はまだ FFI を備えておらず、ネイティブコードの組み込みは実装面でもパフォーマンス面でも厳しいものでした。
そして時が経った 2022年の今、dart:ffi は stable 版が公開されています。その dart:ffi が「Flutter 開発の世界をどう拓いたのか」をお話しします。

将来について

Flutter で計画されている Isolate Platform Channels にも触れ、今後のハイパフォーマンスな Flutter アプリ開発がどのような世界になるかをお話しします。

対象者

FFI や Platform Channel を見聞きしたことがある方

あなたのアプリにもFlutterを導入してみませんか？

既存のモバイルサービスではAndroidやiOSそしてWebまで別の開発チームが必要になり、コミュニケーションコストやプラットフォームによって差分が発生することが多いと思います。

そして会社的にはAndroid、iOS、Webまで別々のチームを作って数人で維持することは難しいと思います。

上記の問題を解決できるクロスプラットフォームを提供するFlutterがありますが、一気に変更することは現実的ではないのでネイティブから頑張って開発している会社もあると思います。

そこで、既存アプリの一部をFlutterで変更することはどうでしょうか？
少しでも上の問題を解決できるし、少しづつFlutterを学習することもできると思います。

弊社では既存サービスにFlutterをのせることを検討していますが、検討しながら得た情報を皆さんと共有したいと思います。

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

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

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

provider や riverpod にはじまり、Redux、MobX、Triple、BLoC など、pub.dev には数多くの状態管理パッケージが公開されています。もちろん、Flutter の標準 API である StatefulWidget や InheritedWidget も無視できません。

Flutter を学習する上で「状態管理」は避けて通れない話題です。しかし、重要だからこそそれを便利に、安全に、一貫性を保って行えるようにしてくれる「状態管理パッケージ」がさまざまな開発者からさまざまな思想を基に開発・公開され、その状況自体が Flutter の初学者に対するハードルを上げているのも事実です。

このトークでは、Flutter 公式ドキュメントの "List of state management approaches" ページに記載された「全て」の状態管理パッケージのドキュメントやソースコードを読み、サンプルアプリを作成し、その上で発見できた共通点や考え方の違い、適切な使いどころについて議論することで、「状態管理」自体に対する苦手意識を取り除き、また新規プロジェクトにおいて適切な技術選定が行えることを目的とします。

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

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

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

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

DartはGoogleがJavascriptの代替言語として開発したプログラミング言語で、Flutterに採用されてからは現代的な機能を取り込みつつ成長を続けています。
このトークでは、これからFlutterを始めたい人が最初のアプリを書き始めるまでに必要な言語知識を、背景となる歴史的経緯から最新の言語仕様まで30分でざっくり理解できるような発表をします。

トーク内容
・Dartの生まれた経緯
・Dartの基本的な言語仕様(関数、変数、クラス、型システム等)
・Dart2.0以降の新しい言語仕様(collection if, null safety, enhanced enum等)
・その他Dartの特徴的な言語機能(mixin, factory constructor等)

対象者
・他のプログラミング言語を少しでも触ったことのある人