フロントエンド開発スタイルの変遷と、私がFlutterにハマったわけ

BPStudy#185での資料です。108枚を50分で話すという暴挙です。
https://bpstudy.connpass.com/event/271251/

Transcript

1. フロントエンドの開発スタイルの変遷と、 私がFlutterにハマったわけ gothedistance a.k.a ござパイセン https://twitter.com/gothedistance BPStudy#185 at 2023.01.25
2. YUMOTO Michitaka Hello! 2 • ゆもと みちたか(ござパイセンというHNで生きてます) • 1979年生まれです。松坂世代。 • GoTheDistanceというブログを書いてます。たまに。 • 新卒SIer→雑貨製造業で内製→独立してもうすぐ7年。 • フロントエンドが好き。修行するぞ修行するぞ。 • やきうを愛する東京ヤクルトスワローズのファン！
3. 経歴等 3 アプリ開発の実績 私の経歴 • 商社系SIer新卒入社。Javaメイン。 PG→SE→PL→PMなどを経験。 • 家庭の事情で、叔父が経営してる雑貨 製造業の会社に転職。主に社内のシス テム開発に従事。たまに受託。 • ブログで出会った人にお仕事を頂いたの がきっかけで独立して、今に至る。 • 要件定義・ディレクション回りで独立する も、今はFlutterばっかり。
4. 【PR】女性限定推し友マッチングアプリをリリース！ 4 ➔ Flutter ➔ Firebase ➔ FastAPI ➔ Flask(管理画面) ➔ CloudRun ➔ ほぼ全部俺 Favomatch の告知にご協力頂きたく伏してお願い申し上げる候
5. BPStudy History • BPStudy#79(野球) • BPStudy#91(野球) • BPStudy#92 • BPStudy#100(野球) • BPStudy#103(野球) • BPStudy#108 • BPStudy#112(野球) 5 • BPStudy#115(野球) • BPStudy#122 • BPStudy#124(野球) • BPStudy#127(野球) • BPStudy#140(登板回避) • BPStudy#142 • BPStudy#185(NEW!!)
6. お話させて頂くこと 6 ➔ Flutterにハマったきっかけ 〜FE開発スタイルの変遷を添えて〜 ➔ Flutterアプリ開発のTipsあれこれ ◆ Flutterアプリのアーキテクチャ、状態管理、利用したライブラリ ◆ Firebaseと戯れた日々の記録 ◆ アプリ内課金、チャット、広告などの実装 ◆ テスト手法 ➔ 謝辞
7. フロントエンドと私 フロントエンドには３つの開発スタイルがあるのでは？ 1 7
8. 嗜んだフロントエンド ➔ Windows Form (2011〜2014) ➔ WPF(2018〜) ➔ Android(2015〜2019) ➔ iOS (2015〜2019) ➔ Vue.js (2019.07〜09) ➔ Flutter (2020〜) 8 仕事でやったことがあるフロントエンドを列挙しています。
9. フロントエンドの開発スタイル 9 GUI型 UIをD&Dで貼り付け、対応す る変数やイベントを定義して、 処理を記述するスタイル HTML型 テキストファイルにUIを別 の言語や枠組みで書い て、コードと紐付けるスタ イル ALL CODE型 UIの記述からビジネスロ ジックから全てを、単一の コードベースで書くスタイ ル ◉ Windows Form ◉ iOS(UIKit) ◉ WPF(Xaml) ◉ Android(xml) ◉ jQuery(html/css) ◉ Flutter(Dart) ◉ React(TypeScript) ◉ iOS(Swift UI) ◉ Android(Jetpack) ※ iOSもAndroidも、公式がALL CODE型なライブラリをリリースしている所がポイントです。結局こうなるんです。
10. GUI型スタイル UIをドラッグアンドドロップで貼り付けるやつだね 2 10
11. GUI型(Windows Form) 11 ➔ 最も原始的な開発スタイル ◆ 絶対配置でパーツを貼る ◆ イベントハンドラを作る ◆ ロジックを書く ➔ レスポンシブにならない ◆ やればできるっぽいが、相当頑 張る必要がある。 ◆ 漢はWindowsサイズ固定。
12. Windows Form(コードビハインド) 12 ➔ イベントハンドラと同義 ◆ キーダウン・タップ等の UIが持 つイベントに対して処理を差し 込む。 ◆ Code Behindっていうぐらいな ので、private な関数が生成さ れる。 ◆ ビジネスロジックを実装すると 再利用性が一気に低くなる
13. GUI型(iOS UIKit) 13 ➔ Storyboard ◆ 画面遷移図のようなもの ◆ ViewControllerを継承したクラスを紐付ける • この例だと6個のクラスが必要。 ◆ スタイルは原則プレビューされない。 ➔ Interface Builder (IB) ◆ Windows Formと同じく、D&Dで貼り付け。 ◆ 貼り付けるのはUIだけで、スタイリングや、 TableViewのセルは別途定義する必要がある。
14. iOS UIKit (ViewController) 14 UIKitの根幹 ➔ UIKItではViewControllerを起点にして画面遷移が動く。 ◆ 先程のStoryboardで表示されたパネルに対応するクラス。これがないと何も出来ない。 ◆ ViewControllerのライフサイクルに合わせてコードを書くのも面倒である。 • ViewDidLoadでスタイルを書いたりしてしまう。 BaseViewControllerはびみょい。 • ViewDidAppearで画面が戻ったときの UI更新処理を書いたり。 ◆ ViewController間の値渡しもStoryboard経由で行う(コードでも書けるが) • Storyboardを使う場合、Segueというものを定義する必要がある。 • Segueに渡したいデータを定義して受け取る側はキャストして受け取った記憶。 • 数年前の記憶なので、今は <T>とかでもらえるかもしれません。
15. GUI型(iOS UIKit / Interface Builder) 15 ➔ IBOutlet ◆ GUIで貼り付けたパーツのこと ◆ !があるのは貼り付け先がないと Nullで エラーになるため ➔ viewDidLoad ◆ 画面の初期化時に呼び出される。 ◆ 他にもライフサイクルに合わせたフック が存在する。 ➔ addTarget ◆ イベントハンドラの登録など。
16. iOS UIKit (Auto Layout) 16 https://zenn.dev/mikomokaru_jpn/articles/45a66d84d0acfc ➔ ボタンがあるとしたら... ◆ 上部の要素に対して Margin:10 ◆ 下部に対して Margin:10 ◆ 右と横はスクリーンから各々 Margin10 ◆ 最低のサイズは120px ◆ これをIB or コードで設定する。 ➔ 「直近の要素」とのMarginを上下左右に対し、UI パーツごとに設定する。 ➔ SwiftUIによって直接AutoLayoutを触れなくても良く なったらしい。そらそうよ。
17. GUI型はつらみが多い 17 再利用性・拡張性が乏しい ➔ D&DでUIを貼り付けると再利用性・拡張性に乏しくなる ◆ UIはツリー構造で管理するのに、その構造が表現できない。全部フラットになる。 ◆ 繰り返し（動的な数量）の配置が不可能。 ◆ if文で表示を差し替える等が、表現できない。 ◆ スタイルの共通化が困難。 CSS的な機能が基本的にない。 ◆ 共通化のためにコードで UIを表現すると、全体の見通しが悪くなる。 • UIを決定するための情報源がGUIとコードの２つに分かれてしまうので。 ◆ メタレベルのコンフリクトが発生することが多々ある。 • iOSのStoryboard/XIBのメタ情報でコンフリクトするなど。
18. HTML型スタイル UIはテキストファイルで、ロジックはコードで。 3 18
19. HTML型(WPF / XAML) 19 ➔ WPFではXAMLを使ってUIを定義 ◆ UIに応じた属性が定義された XMLです。 ◆ TexBox, Label, ComboBox, Button, Panel, Grid Layout, DataGrid…etc ◆ Bindingを経由することで、UI/Modelの双 方向の更新が可能になります。 ◆ Windows Formから変わりすぎなので、も うちょい手心あってもなと思う Extensible Application Markup Language
20. WPF(データバインディング) 20 ➔ XAMLでは Binding を定義することが出来る。 ◆ 変数を参照先に指定して、変更があったら自動的に変数の中身が更新される仕組み。 ◆ UIとデータを完全に分離できるため、再利用性が高まる。 ◆ お作法がめんどくさいのが難点。 • UserControlのDataContextを指定する。 • XAMLでBindingを書いて変数を指定する。 (IDE補完が効かないのが辛い ) • BindされたデータにはBindableBaseという抽象クラスを実装して、 • データのsetterでSetPropertyを実装し、双方向のバインディングができる ◆ Prism/LivetあたりのMVVMフレームワークがないと即カオスになると思います。 データの更新を伝搬させ UIを更新する
21. WPF(MVVM) 21 View⇔ViewModel⇔Model View ViewModel Model ➔ MVVMの考え方が提唱されたのは2010年頃っぽい。WPFが先駆者かも。 ◆ View(UserControl 以下 UC)をXAMLで書きます。 ◆ UCのDataContextプロパティにバインドするクラスを定義します。 (ViewModel) ◆ ViewModelからModelを叩き、データのCRUD操作を行います。 ◆ Modelの戻り値はViewModelのプロパティに代入され、 XAMLでBindingされたプロパティが変 更を検知して、UIを更新します。 ◆ Androidもこういうスタイルだと思います。
22. WPF(MVVM/ロジックのバインド) 22 View⇔ViewModel⇔Modelであります。 ➔ WPFには Command インターフェイスがあります。 ◆ イベントハンドラに呼応する ViewModelのメソッドを呼び出すための仕組みです。 ◆ Commandを経由することで、ViewModelを変えるだけで処理の中身を差し替えることが出来ま す。VMと密結合になったらコードビハインドと一緒なので、一枚挟んでます。 ◆ 引数が欲しい場合は CommandParameter を定義して別途渡すことができます。 ◆ ボタンだけでなくキーイベントや、マウスイベントにも対応しています。 • <KeyBinding Gesture="Enter" Command="{Binding FilterCommand}"/> • <MouseBinding Command="{Binding SampleCommand}" MouseAction="LeftClick"/>
23. Android(View) 23 XAMLとは言ってないけどほぼ一緒 ➔ XMLを使ってUIを定義 ◆ XAMLっぽいけど、書ける内容は XAMLより全然少ないです。 ◆ IDを定義して、findViewById()で要素 を取得。最も原始的な手法がそれ。 ◆ イベントハンドラが書けません。 ViewModel(Fragment / Activity)側で 実装します。
24. Android(イベントハンドラ) 24 onCreateViewでイベント内容を書く ➔ setOnxxxListenerを定義し、クロージャで処理を 書きます。setOnClickListener、 setOnKeyListener等。 ➔ onCreateViewというライフサイクルメソッドで、イ ベントハンドラの定義を書きます。 ➔ iOSよりライフサイクル管理に苦労した記憶があ ります。Fragmentの中身がキャッシュされず初期 化されちゃった、みたいな。
25. Android(ButterKnife) 25 昔はButterKnife、今はView Binding ➔ ButterKnifeという、アノテーションで Viewとバイン ドできるライブラリを使ってた。 ➔ findByViewIdは実行時例外が出る可能性がある けど、アノテーションならコンパイル時に検出でき てナイス。 ➔ 2014年にリリース、2020年を最後に更新されて いない。JetPack Composeでお役御免？ ➔ Android界では有名な、Jake Whartonさんのライ ブラリです。retrofitのメンテナー。 https://github.com/JakeWharton/butterknife
26. Android(View Binding) 26 Android公式でサポートされた仕組み ➔ 命名規則に応じて自動的に ビューをバインドするクラスが生 成され、タイプセーフにビューの 要素にアクセス可能になります。 ➔ 2014年に欲しかったけど、 AndroidのJVMサポートなどの影 響もあると思います。 https://codeforfun.jp/android-studio-how-to-use-view-binding-with-kotlin/ XML ファイル名をキャメルケースにして Binding を末尾につけるという 命名規則。 activity_main.xml → ActivityMainBinding
27. Android(画面遷移と値渡し) 27 どこも一緒だね ➔ 新しい画面を呼び出すには startActivityForResult ➔ 戻りはonActivityResult ◆ Intent経由でデータを入れる。 ◆ オブジェクトはJSONにシリアライ ズして渡していた。 ◆ 今はもう違うかも。 ➔ AndroidはstartActivityすると、Stackし て上にかぶさります。
28. HTML型になったはいいけど、もう一声 28 ➔ UIがテキストで定義されたのは間違いなく良い。人類に必要。 ◆ GUIオンリーはかなり辛い。テキストで UIが表現できるのは正義。 ◆ 階層構造もネストで表現できるようになった。 ➔ ViewModelとViewを行き来するのが面倒。ロジックが追っかけにくい。 ◆ 全体を把握するコストがやっぱり高い。 ➔ テキストで表現できるなら、単一のコードベースにまとめて欲しさがある ◆ iOSは SwiftUI、Androidは Jetpack Composeにより、ALL CODE型の開発スタイルに移行し たと言って良いと思います。結局それが正義なのではと、わたしは感じました。 規模が大きくなると辛くなる
29. ALL CODE型スタイル この出会いからフロントエンドに傾倒していく 4 29
30. ALL CODE型スタイル 30 ➔ 全てをコードで定義し、コンパイル (or トランスパイル)するスタイル。 ◆ Flutterの場合はDart、ReactならTypeScriptですね。 ➔ 最大の魅力は「表現力」です。Viewで表現できるロジックの幅が違います。 ◆ ロジック・バリデーション・スタイル・副作用等がコードで書ける！最高！ ◆ これに慣れてしまったら、表現力の小さい開発スタイルに戻れるわけがない。 ➔ Reactが最も有名。FlutterはReactにインスパイアされている部分が多い。 ◆ UIの組み立て方の思想、状態管理のやり方など。先駆者 Reactの功績は大きい。 ◆ SwiftUI / JetPack Composeでやれるリソースのある現場はいいけど、無いなら Flutterでリプ レイスするのが現実的かもしれないですよ！ 全部コンパイルできるようにしたらいいんじゃないの
31. 宣言的UI 31 ➔ 宣言的UIはグレートです。 ◆ 私がフロントエンドに傾倒する きっかけとなったもの。 ◆ UIは最新の状態によって常に 描画される為、UI自体は不変 であるという考え方。 ◆ コンストラクタでUIを作り、表現 する。コンストラクタなので不 変。 これに慣れたら戻れない
32. 宣言的UIの良さ 32 ➔ UIで担保しなければならない動きがスッと頭に入る。 ◆ Reactの場合は、<Calendar onChange={{ xxx }} start={{ aa}} /> みたいな書き方。 ◆ 上記の書き方だと公開されるインターフェイスで大まかな仕様がわかる。 ➔ ロジックが書けるので、ifやforeach等と組み合わせてUIを表現できる。 ◆ ある項目をコンボボックスから選ぶ時だけ項目を増やす ◆ 画像の登録があればそれを、ない場合はプレースホルダーを出す ◆ 可変の要素に対して foreach を回してUIを構築できる。ToDoリストみたいなUI。 ➔ Flutterの場合Widgetをネストすることでビューの階層構造が表現できる。 ◆ UIはツリー構造で管理するしかないのよね。 これに慣れたら戻れない Part.2
33. 宣言的UIの良さ 33 ➔ 宣言的UIの場合、ビューはimmutable(不変)になる。 ◆ 不変＝初期化(ビルド)された時の状態から変更されないこと。 ◆ ビューの更新は状態に応じて再構築すればいいという考え。 ➔ ラベルで合計値を表示する場合で考える。 ◆ 宣言的UIじゃない場合は、sumLabel.text = "10,000" ってやる。UIが可変(mutable)。 ◆ Flutterだと「Text(value)」のみ。合計値は変動するが valueの値を出すのは同じ。 ➔ データの更新をUIに伝搬してリビルドすることで、 UIが更新される。データが先、 UIは後。 ◆ データによって状態 (State)が規定される。UIはデータと状態に準拠するだけが正しい。 これに慣れたら戻れない Part.3
34. UI = f (state) 34 宣言的UIの勝利の方程式 ➔ UIは、ビルド時に渡される 適切なstate によって常に最新化されるという考え。 ➔ stateに変化があったら、もう１度ビルドを呼び出して対応します。
35. Flutterにハマる僕 宣言的UI with バイブルとの出会いで、どハマりすることに 5 35
36. ➔ ワンソースで、iOS/Android(MacOS/ Windows / PWA / Linux)で動作するアプリケーションを 構築するフレームワーク、Google謹製。Dart製。 ➔ DartにはPlatform ChannelというAPIがあって、それがFlutter Engineに搭載されていること で、OSの差分を吸収している。バッジを付けたり、カメラやフォトの起動など。 ➔ コロナ禍(2020.01〜)の初期に本番稼働したという記事を見かけて、「え、 mjd？」となり、 2020.05からやり始めたのがきっかけ。独習です。 ➔ 自分でメンテしないといけないネイティブアプリが複数あり、ワンソースで管理するのが悲願 だったので、飛びついたというのが本音。飛びついて大正解でした・・・！ 36 Flutter is 何
37. Flutterに出会って脳汁プシャー 37 ネイティブアプリの常識が根本的に変わった。 時が止まったままの僕の心を〜 マジでワンソースでiOS / Androidに対応できるじゃん.. If とか foreachがViewに書ける のは嬉しい。動的な画面の変 更がやりやすいわ！ DartだけでUI・ロジック・スタイ ル・状態が可視化出来るのす げぇやりやすいじゃん .. レイアウトがめっちゃ組みやす い. Themeを使えばUIスタイル も一元管理できるんだ ... Hot Reloadすげえ。ほんとに HOTだ。UIの変更がすぐ反映 されてサクサク進められる！ FlutterはSwiftUIとかに比べる と簡潔に見えるし、UIが作りや すい。Dartのおかげかな？ Widgetなんでもあるじゃん。 なにこれすごい。ありがてぇあり がてぇ... Widgetをネストすることで、 様々なUXが定義できる。 これはすごい発想だな・・・ これが有名なHooksというもの か。これで状態管理できるなら 関数型推しになるわな！
38. バイブルとなるレポジトリと出会う 38 https://github.com/wasabeef/flutter-architecture-blueprints ➔ 最初は全然読めなかった ので、クラっときた。 ➔ Forkして、処理毎にコメント を書いて、処理内容を日本 語化して少しでも読み解く ようにした。 ➔ モダンなアプリの作り方に 触れて、抽象度の高い作 りに脳汁がプシャー。
39. Flutterアプリの礎的存在 39 ➔ 私にとって、Flutterのアーキテクチャの礎となっ たもの。wasabeefさんに圧倒的感謝。 ◆ モダン・フロントエンドのエッセンスを学ぶことが 出来る生きた教材 ◆ HooksやRiverpodというFlutterで愛用すべきラ イブラリの使い方も大いに勉強になった。 ◆ UIをテスト可能にするための抽象化、 Resultクラ スの使い方なども勉強になった。 ◆ ハイクラスのスタンダードを体感できた！ このレポジトリに出会ったことで、 Flutterにハマっていく
40. SoCの担保がまずあって 40 ➔ 重要なのはSoCの担保。 ◆ ViewはViewModelしか見ない。 ◆ ViewModelはRepositoryしか見ない。 ◆ RepositoryはDataSourceしか見ない。 ◆ 単方向データフローというものに近い。 ➔ RepositoryはMockできるようにする ◆ ビジネスロジックはMockable必須。 ◆ 外部通信するコードを直接 Viewに書いたら絶 対ダメ。UIテストが単体で出来ない。 依存先は１つでいいの、いいの
41. SSOTが次に来る 41 ➔ アプリの場合、画面遷移が深くなるけどもデータソースは 同じで、孫画面で選択したものを親画面に戻して更新した いみたいなことはとても多い。 ➔ データソースが散らばっているとろくなことがないので、 UI が参照するデータ(同じ型ならば尚更)は１箇所でまとめら れたほうが良い。 ➔ Androidの公式ページやmono0926さんの記事参照。 ➔ https://developer.android.com/topic/architecture?hl=ja ➔ https://mono0926.medium.com/architecture-240d3c56b597 Single Souce of Truth. ビジュアル系バンド名のようだ
42. SoCによる良いテンプレ化 42 ➔ 各々の責務に徹すれば、そんなに複雑なコー ドにならない、はず。 ◆ 人はそれをアーキテクチャと呼ぶのではなか ろうか。品質の担保ってそーゆー話。 ◆ ノウハウは結実するとテンプレになるもんで す。良いテンプレには哲学がある。 ◆ UIデザイン及びUXの最大化に時間を全振り するべきで、SoC/SSOTのあるべき議論に時 間を掛ける意味は薄い。 だんだんテンプレになってくるもの
43. Flutter開発Tips 6 43 ➔ 状態管理 ➔ Riverpod ➔ Hooks ➔ Firebase ➔ 広告とApp内課金
44. StatefulとStateless(状態管理) 44 Flutterにおける最も単純な状態管理手法 ➔ FlutterのUIパーツは、全てWidgetというクラスを継承して作ります。 ◆ StatelessWidgetとStatefulWidgetがあります。もう1個あるけど、都合上割愛。 ➔ 「State」はWidgetが初期化〜破棄までのライフサイクルのことです。 ◆ iOSだとUIViewControllerのライフサイクル。viewDidLoad,viewWillAppear… ◆ AndroidはActivity/Fragmentのライフサイクル。onDetach, onCreated,onResume… ➔ StatefulWidgetは任意のタイミングでstateを強制的に最新化できる。 ◆ Stateを更新するとbuild関数が呼びだされ、最新の状態で Widgetを再構築できます。 ➔ StatelessWidgetにはそれがない。fulとlessの違いはそこです。
45. StatefulとStateless 45 Flutterにおける最も単純な状態管理手法 setState→buildの流れに注目！！ Widget のライフサイクル
46. setStateでUIを更新する 46 Stateを操作して、buildを呼び出す ➔ StatefulWidgetが利用できる setState を呼び出します。引数はVoidCallbackです。 ◆ setStateの中でデータの更新処理を書きます。 ◆ build全体が呼び出されるので、この Widgetだけ！という制御はできません。 ◆ この例ですと、 _counterを参照しているWidgetの表示が更新される。
47. setStateのつらみ 47 https://note.com/mxiskw/n/n8e8f4fd1a77c ➔ データの更新が必要な箇所が増えるとだるくなる。 ◆ Stateのメンバ変数に依存してしまうので、ロジックの切り出しが難しい。 ◆ どこもかしこも似たような setStateが増えて、ボイラーテンプレ感が強くなる。 ◆ Widgetをふんだんにネストするようになると、見通しが悪くなる。 ➔ WidgetをまたいだUI更新が困難 ◆ ツリー上で離れた位置にある Widget の更新が難しくなる。setStateは自分のビルドを呼び出すもの であって、別のWidgetのビルドを呼び出すものではないため。孫画面→親画面的な。 ➔ setStateは利用せずに、Riverpodというライブラリに抱かれる現場が多い印象。
48. Riverpod is 何 48 ➔ Flutter界のロックスター、Remi Rousselet さんが作ったライブラリ ◆ データストア、UI状態管理、Mock差し替えができるツールキットが 1つになったもの。 ◆ 元々Flutter公式で「Provider」というパッケージがあったが、イケてない部分が目立つというこ とでゼロからRemiさんを中心に書き直された。 Flutter公式ではない。 ◆ FlutterにはInheritedWidgetというのがあり、Widgetを継承関係にすることで特定の Widgetに だけリビルドを走らせる仕組み がある。それを応用したもの。 ◆ RiverpodはProviderのアナグラム。denoとnodeと同じ関係。 ◆ 先日、Flutter公式YouTubeでも状態管理手法として紹介された。 Riverpodしか勝たん。 ➔ グローバルなデータストアを持って、対象の Widgetがそのデータをリッスンして UI再構築。
49. 49 Riverpodの公式ページ https://riverpod.dev 状態管理＝双方向なデータ更新が可能で、 キャッシュも可能なフレームワークを使う
50. Riverpod の概要 50 ➔ Providerを定義する。よく使うのはProvider/StateProvider/StateNotifierProvider ➔ 定義したProviderを自分がどう管理したいかを定義する。 ◆ read → その時の最新データを読むだけでよい！ ◆ watch → データに変更があったら検知して、 Widgetをリビルドさせたい！ ◆ refresh → データの初期化(コンストラクタ)を再実行したい！ ◆ listen → 更新前/更新後の差分を管理したい！ ➔ readを使う場面はWidgetの更新を伴わないデータストアを保持する時。 ◆ あとはRepositoryに該当するクラスのオブジェクトの DIなど。
51. freezedで自動生成しよう 51 ➔ freezedというライブラリを使うと、 JSONを 任意の型のオブジェクトに変換してくれる コードが自動で生える。 ➔ その他、copyWith等の便利メソッドも生 えてくる。 ➔ Union Typesやパターンマッチに近い コードを自動生成してくれる。 ➔ Dartは様々なコンストラクタの文法があ り、それが一番特色かなと思う。
52. Named Constructor 52 ➔ クラス名.関数でコンストラクタのオーバーロー ドが実装できる。 ➔ Flutter公式の Image クラスで確認できる。 ◆ 画像の取得先が異なると引数が違う • ファイル(ローカル領域) • メモリ • ネットワーク • アセット(アプリにバンドルされたファイル) ◆ 引数の型は違うが戻り値の型が同じな ので、オーバーロードと同義。
53. Factory Constructor 53 ➔ クラス名.関数は、Named Constructorと同じ。 ◆ Named Constructorは、同じクラスのインスタンスしか返せない ◆ Factroy constructorはサブクラスのインスタンスを返すことが出来る！ ➔ デザインパターンの Factory Patternに由来する予約語なのかも。
54. Whenでパターンマッチ 54 ➔ freezedを使うとwhenメソッドが自 動生成され、サブクラスのインス タンスによるパターンマッチが出 来る。 ➔ Kotlin / Swiftではデフォルトであ る言語仕様だけど、 Dartには 2023年1月時点では無いので、ラ イブラリに頼っている。 ➔ Dart3に期待！(2023 Mid)
55. AsyncValueで非同期処理 55 ➔ 非同期処理の制御はフロントエンドの華。 ◆ RiverpodにAsyncValueで、ステータスに応じてパターンマッチするのが簡単。
56. Flutter Hooks 56 ➔ ReactのHooksにインスパイアされたライブラリ。 ◆ useState → 毎度おなじみ。Flutterの場合は、xx.value で値を更新する。 ◆ useTextController → TextFieldの初期値セットや入力値を知るのに使う ◆ useTabController → Tabのタップ・スワイプのイベントなどを拾う ◆ useEffect → initStateの代わりになる。ビルド時に副作用を発生させる。 ◆ useMemoized → 何回ビルドが走っても初期値をキャッシュ。 ◆ useFuture → ビルド時に非同期処理を実行する。 useMemoizedと併用する。 ➔ Hooksには「使いたくなる魔力」がある。関数単位で状態管理ができるのは気持ち良い。 ◆ Hooksに慣れているチームなら Hooksのノウハウを活かせたほうがいいかも https://pub.dev/packages/flutter_hooks
57. Flutter Hooks (useState) 57 ➔ 引数に管理するデータの 初期値を入れる。戻り値 はValueNotifier<T> ➔ .value に新しいオブジェ クトを代入するとリビルド が走る ➔ HookWidgetを継承する 必要があります。 ➔ まぁ簡単。素敵。
58. Flutter Hooks (useFuture/useMemoized) 58 ➔ useFutureで非同期処理を実行 ◆ Riverpodでローティング の出し分けをしている。 ◆ whileLoadingの引数は Function Future<T>で、戻 り値がFuture<T> ◆ useFutureは毎回実行さ れるため、memoizedで キャッシュ wasabeefさんレポジトリより
59. Flutter Hooks (useEffect) 59 ➔ appLifecycleが変わると useEffectの第１引数の 関数が実行される。 ➔ リスナーとしてuseEffect を使うこともできるのかと 勉強になった。
60. 使用した主なライブラリ 60 状態管理等 Riverpod, flutter_hooks, freezed HTTP dio, retrofit ローディング flutter_easyloading チャット flutter_firebase_chat_core,flutter_chat_ui 広告 admob(google_mobile_ads) App内課金 in_app_purchase Firebase core,auth,firestore,analytics,crashlytics,storage,clo ud_function
61. チャット(flutter_chat_ui, flutter_firebase_chat_core) 61 ➔ よくあるチャットのUIを作ってくれる。 ◆ 多くのオプションが用意されているので、 UIカスタマイズはやりやすい ◆ イベントハンドラも豊富にある。 ➔ バックエンドは自分でやりなさいというもの ◆ Streamだけ公開されていて、 バックエンドはお前がやれです ◆ 同じ開発者が公開している「 flutter_firebase_chat_core」 と組み合わせ、Firestoreをチャットの バックエンドとして組み込むことができます。 ◆ 凄くシンプルなライブラリでコードも読みやすいが、チャットする以外の機能はほぼゼロなので、 バックエンドのFirestoreは自前のほうが良いかもです。
62. 広告(admob) 62 ➔ バナー広告やリワード広告を実装できる ◆ 実装自体は極めて簡単。設定さえ間違えなければ。 ➔ ユーザーは非常にせっかちなので広告の表示が遅いと離脱される ◆ UIをビルド後に広告を読み込む書き方にすると、 1秒はかかる。その間に別のページに遷移して しまうユーザーがすごく多い。ビビるぜ。 ◆ インタースティシャル広告とネイティブ広告以外はプリロード不可のようです。 ◆ 先に読み込む(Preload)できるものは、Preloadしておくのが吉。 ◆ 自分はバナー広告とリワード広告を使ったので Preloadできなかった。Googleとしてプリロードは NGらしいので。Google Group参照。 https://groups.google.com/g/google-admob-ads-sdk/c/OAGAtvMJyXE
63. アプリ内課金 63 ➔ すごおおおおおおおおおおく面倒 です。色んな準備が必要。 ◆ RevenueCatというアプリ内課金 or サブスクのマネジメント SaaSが良さそうです。 ◆ $10k/月まで無料で、そこから $1K毎に$8が課金されるけど、安いと思う。 ➔ In_app_purchaseで頑張りましたが、ベストプラクティスがない領域。 ◆ サーバーサイドのコードもガッツリ書く必要があります。 ◆ 1つは購入時に渡されるレシートの検証。 iOS / Androidでバラバラです。 ◆ もう1つはサブスクの通知です。 SlackのWebhookみたいなノリで飛んできます。 ◆ サブスクは購読・中止・解約・再開等、色んなイベントが起こります。 ◆ 今の所大きな問題はないけど、ちょっと不安です。運用経験が薄いので。
64. アプリ内課金(レシート検証) 64 ➔ アプリ内課金で最も面倒なのがこれです。 ◆ クライアントからApp内アイテムの購入リクエストを出す。 ◆ プラットフォームからレシートが返却される ◆ 返却されたレシートをプラットフォームの検証サーバに投げる ◆ 正当性が確認されたら購入完了とみなす。不正購入を防ぐために面倒になってる。 ➔ レシート検証の検証内容が明文化されていない ◆ 各プラットフォームでは明文化されておらず、開発者任せ。見つけられなかった。 ◆ iOSがだるい。サブスクと消耗品でレシートのレイアウトが異なる。 ◆ リストア処理(iOSではマスト)でも、同じ検証を行う必要がある。 ➔ iOS及びAndroid双方に個別のデコード処理が必要です。レシートの中身について。
65. アプリ内課金(サブスク通知) 65 ➔ サブスクが発生すると、任意のエンドポイントにリクエストが飛んでくる。 ◆ iOSはJWT形式、Androidはbase64エンコード。 ◆ JWTのヘッダのデコードをやったことがなく、ハマった。証明書チェーンなる概念を知らなかっ た。X.509証明書のことが少しわかった気がします。 ◆ 各プラットフォームで各々 10数個のイベントがあり、イベントが発生するとリクエストが飛ぶ仕組 み。とりあえず飛んできたら DBに保存するのが鉄則。 ◆ 200以外を返しちゃうと Appleは一定回数がすぎるとリクエストが飛ばなくなる。 Googleはデフォ ルトでエンドレスに再送信される。 ◆ 更新通知ならリワード付与、解約通知ならプレミアムユーザーから一般ユーザーに戻す等の処 理を行っています。
66. Lintはpedantic_monoで 66 ➔ みんな大好きLint。眺めてるだけで勉強になりますね。 ◆ 良い(人間にとってストレスのない )コードを書く習慣を身につけるもの ◆ ロジックの中身のレビューに集中できますね。 ➔ 日本のFlutterエンジニアのオピニオンリーダー的存在、 mono0926さんのLint ◆ https://pub.dev/packages/pedantic_mono ➔ Lintは後から導入すればするほど対応コストが高くなるので。。。 ◆ できればプロジェクト開始当初から導入しましょう。 ◆ 「use_build_context_synchronously」は無視してます。 ◆ 書き方を直してもらえると勉強になって楽しいですね。 https://dart-lang.github.io/linter/lints/index.html
67. Firebaseと戯れる アプリ開発でFirebase使わない人いないのでは 7 67
68. Firebase is 何 68 ➔ Googleが買収した、BaaSプラットフォーム。アプリ開発のマブダチ。 ◆ Cloud Firestore → KVSなデータストア ◆ Firebase Cloud Messaging → プッシュ通知 ◆ Firebase Authentication → ソーシャル認証 ◆ Cloud Functions → AWSのLamdba ◆ Cloud Stroage → AWSのS3 ◆ Crashlytics → アプリのエラーを検知してトラックし、レポート生成。 ◆ Analytics → アクセス解析。カスタムイベントを送ることも出来る。 ◆ Dynamic Links → よくある「アプリで開きますか」的な URLを生成する。
69. Cloud Firestore 69 ➔ KVSなデータストアです。 ◆ テーブルに該当する概念はコレクション ◆ レコードに該当するのはドキュメント ◆ ドキュメントの読み込み・書き込み件数に応 じて課金が入ります。 ◆ スキーマレスです。ドキュメント単位で全然 違う構造のデータを入れられます。 ◆ 「卒業生」を多数輩出しています ... 癖がスゴい！ by 心の千鳥ノブ
70. 70 https://zenn.dev/mitsuruokura/articles/5ec6511efeff48
71. 71 https://speakerdeck.com/keisuke69/migrate-from-firebase
72. Firestoreのデータ取得における制約（１） 72 ➔ RDB脳では考えられない制約が・・・ ◆ ＝＝での検索はすごい得意です。どのフィー ルドでも何個でもネストできる。 ◆ ”>=, <=, !=” 等の比較演算子の利用に制限が ある。１つのフィールドしか使えない。 ◆ WHERE price >= 5000 and stock > 0 はダメ です！！ stockAvailable == trueならいける ◆ 「==」と「>=」はOK。複合インデックスの構築が 必要ですけど。 卒業したくなる背景もわかる
73. Firestoreのデータ取得における制約（２） 73 ➔ 数字や文字などのスカラー値の OR検索にはin 句が用意されています。 ◆ IN句に入れられるのは最大 10個まで。 ➔ リストの場合は、array-contains を使う。 ◆ やっぱり10個までしか入らない。 ➔ in array-contains array-contains-any は WHEREで共存できない。1個だけ。 ◆ 最大10個までしか入らないIN句が１つだけ使 える。あとはわかるよな？な？ ➔ 1つのドキュメントに入るデータは 1MBまで。 IN句に入れられる要素は 10個まで
74. Firestoreのデータ取得における制約（3） 74 ➔ 集計関数が存在しない (最近になって、count関数がオフィシャルでリリースされた) ◆ GROUP BYがないので、sum/max/min/avg等の集計関数がない。 HAVINGあるわけない。 ◆ どうするかって？クライアント側で頑張る or Cloud FunctionsでViewを作る等。 ➔ EXISTS / NOT EXISTS / サブクエリ/ Window関数、当然ございません。 ➔ SELECT文もない。このフィールドだけ取得するという構文がありません。 ◆ SELECT文でデータを加工するという発想がゼロ。 CASE式なども当然ありません。 ➔ データ取得の制約がビジネスモデルの変遷についてこれなくなる恐れアリ。 ◆ 卒業生を生み出している背景に共通しているのはこの点ではないかと、と。 集合演算が存在しない。 GroupByがないので
75. Firestoreで比較を使わないテクニック 75 ➔ 全部AND条件で絞っていいなら、やれなくもない。 ➔ Mapのキーに条件、値にTrueを当てれば、複数条件の絞 り込みができる。TrueMapって言うらしい。 比較を全てTrue/Falseに置き換える
76. RDBとKVSのデータモデリング 76 ➔ FirestoreのデータモデリングはRDBより難しい。制約が強いから。 ◆ RDBはOne Fact, One Place/ ライフサイクル管理を意識すれば及第点になるはず。 • RDBってテーブル追加 or カラム追加の2択しかないんで。やれることが。 • テーブル分割で複雑さを吸収し、吸収した複雑さをSQLで単純に出来るが腕の見せ所。 • 詳しくはそーだいさんや川島さんにお問い合わせ下さい。 ◆ 限定的なユースケースから投入するのが無難に感じる。ビジネスは Firestoreの制限を良しとし てくれないし、できない要件をできるようにはできない。 PaaSの制約だから。 ◆ B向けの場合セキュリティルールでは担保できない要件 (IP制限/ロール制御等)があり得る。出て きたらぶった切るしかないのかもしれません。 KVSで全部やりきるのはマジで難しいと思う
77. こういう検索は無理 77 ➔ Favomatch開発当初、Firestoreをデー タストアに出来るかどうかも、検討し た。スキルセットな問題で。 ➔ 右記のようにSQLにおけるEXISTS or NOT EXISTSをネストする仕様は無理 と 判断し、RDBにした。 ➔ 限りなく正しい判断だと思ってる。 僕は無理だと判断した
78. 簡単なチャットの設計 78 User - nickname - avaterUrl - createdAt - updateAt rooms - roomName - imageUrl - createdAt - updateAt - userIds[List] - lastSeen[List] - lastMessage - messages[collection] messages - authorId - text - type - createdAt - updateAt - status flutter_chat_firebase_coreの設計を元にアレンジ ➔ 基本的には、ユーザー・ルーム・メッセージの 3つ。 ◆ LINEのようにメッセージ単位で既読にする場合は、 Cloud Functionsで頑張ることになりそう。 ◆ messageが作成されたら、その部屋にいるか否かを検知して、いるなら statusを既読に更新等。
79. セキュリティルール 79 ➔ Firestoreは直接クライアントからデータをCRUDするコードを書く前提の代物。 ➔ そのため、セキュリティルールが存在する。 ◆ ドキュメント or コレクション単位でCRUDできる権限を指定するものです。 ◆ FirebaseAuthで未認証のユーザーは一切何もできない、とかですね。 ◆ チャットにぶら下がったメッセージは、 userIds というコレクションの中に自分の userIdがない場 合、一切のCRUDができない。という感じのルールが作れます。 ◆ セキュリティルールのテストは DockerのFirebaseエミューレーターイメージを活用。 ➔ RBACを期待していると痛い目にあいます。 ◆ ロールの概念がないので、ロールに沿った権限を表現するとすぐカオスになる。 firestoreはクライアントから直接データを更新する前提の代物
80. セキュリティルールの例 80 ➔ ドキュメントIDがFirebaseAuthのuserIdと同じでなければ、読み取れない設定例。 ◆ 自分以外の他のユーザーに対して、usersに入っているデータは見られないようにしています。 独自のフォーマットで書きます。
81. Cloud Functions 81 ➔ サーバレスで任意の処理を書くことが出来るやつ ◆ AWSのLambdaみたいなもの。Node/Python/Ruby/Go…お好きなランタイムでどうぞ！ ➔ HTTPかイベントドリブンで発動することが出来る ◆ GCP上のサービスが持っているイベントをトリガーに処理を走らせることができる。 ◆ Firestoreのusersコレクションに新規にドキュメントが作られた、みたいな感じ ◆ messagesコレクションにcreateされたら、PUSH通知を送るなどを書いている ➔ FIrestoreの制約とうまく付き合うための緩衝材というイメージが強い ◆ 例えば、プロフィールに公開したい項目とそうでない項目があった場合、Firestoreではフィールド単位のアクセス 制限はできないので「公開用」「非公開用」でコレクションを分ける処理をCFで書くなど。 AWSのLambdaみたいなもんだね
82. Cloud Functionsの実例 82 https://docs.flyer.chat/flutter/firebase/firebase-cloud-functions ➔ roomsの任意のドキュメントでメッ セージが作成されたら、 lastMessagesというリストを書き換 えるというCloud Functions ➔ Firestore と Cloud Functionsだけ でイケるんじゃねって思うかもしれ ないけど、こんなトリガーがいっぱ いあったら、カオスになるような気 がしてならない。 ➔ あんまり使い込むもんじゃないと思 いますぞ、個人的にはね。
83. Firebase Cloud Messaging 83 ➔ PUSH通知を送ることが出来る。これがないとアプリの意味がないレベル。 ◆ 端末にデバイストークンが発行され、トークンに対して通知を送る。 ◆ 一斉通知の場合は「トピック」を作る。 Slackのチャンネルみたいな感じ。 ◆ トピックに対し短期間に連続してメッセージを送ると Too Manyって言われて怒られます。気をつ けましょう。狙い撃ちなら、デバイストークンで PUSH通知を送る。 ➔ バックグラウンドリスナーが鬼門で動かないことがあった。 ◆ アプリが起動していない状態でも通知は受け取れる。ここまではよい。 ◆ 起動してない時にアプリのバッジを更新する処理がバッググラウンドリスナーの例。 ◆ iOSで苦戦。なぜか動かない。 Whyなぜに。 これがないと生きていけない
84. 通知を送る時のフォーマット 84 ➔ 通知を送る一定のフォーマットがある。 ◆ Androidはpriorityをhighにする ◆ APNSはiOS専用の設定 ◆ content_available, mutable_content を Trueにセットする。これで OSが受け取った 通知をアプリリダイレクトしてくれるような雰 囲気の記述が公式にあった。 ◆ tokenは複数ある場合がある。 2台持ちと か。なので配列で渡す。 プロダクションのコード持ってきました
85. Method Swizzling よーわからん 85 ➔ info.plistで「FirebaseAppDelegateProxyEnabled」を「false」にする。 ➔ これをやらないとバックグラウンドリスナーが動かなかった。 iOSで。 https://firebase.google.com/docs/cloud-messaging/ios/client#method_swizzling_in iOSなんもわからん
86. Firebase Cloud Messaging(Flutter) 86 バックグラウンドリスナーはエントリポイントである main関数内で定義する必要がある。 @pragma(‘vm:entry-point’)というアノテーションが必要だった。
87. Firebase Authentication 87 ➔ SNS認証・電話番号認証・メール認証などを組み込むことが出来る。 ◆ 昨今のソーシャル認証は、全部これで実装しているのではなかろうか？ ◆ 電話番号認証はお金が発生することがある。 ◆ カスタム認証(LINE認証と連携する等)もできる。 ➔ iOSはAPNs Keyが必要、Androidはフィンガープリント(SHA-1/SHA256)が必要。 ◆ これらをアップロードしないとあかん。認証だけじゃないけれど。 ◆ Androidはdebugビルド、releaseビルドでフィンガープリントが異なるので注意。 ◆ AndroidはGoogle Playに用意されたアプリ開発者専用のフィンガープリントを登録しないと、 Google Playに配信した時だけ認証がコケるという罠があるので気をつけたい。
88. authStatusChangesを拾え 88 ➔ 認証ユーザーをcurrentUserというプロパティでアクセス可能。 ◆ しかし、このフィールドは Null許容型になっている。 ◆ 認証してない場合もあるなって思ったら、もう 1つNullになるケースがあった。 ➔ 認証後はCredential情報を端末のローカルに書き込むらしく、そいつが正当なのかを問い 合わせて認証済みであるかをチェックしている。 ◆ そのコールバックが authStatusChanges ◆ このコールバックを通さないと、 Firebase認証済なのに認証されていない状態でアプリが起動し てしまう罠があった。ごくまれにこういう事が起こる。 ◆ 公式ドキュメントにしれっと書いてある。一番前に持ってきてほしいなぁ！
89. 89 https://firebase.google.com/docs/auth/flutter/manage-users 公式ドキュメントのスクショ
90. これは本質情報なのですが 90 Firebaseは特にそう ➔ FirebaseのようなmBaaSを使う場合、ハマる時は大抵コード以外に原因がある。 ◆ SDKへの理解・知識不足が原因になることが多い。自分はそうだった。 ◆ Exceptionの内容を見ても「error_no=10ですか！それで？」みたいな事が多い。 ◆ 設定方法が間違っている or バージョンアップした時に変わっている可能性もある。 ◆ OS固有のパラメーターがあり、それを設定しないと解決しないこともあった。 ➔ 前提知識がないと解決できない＝コード以前の問題。 ◆ 公式ドキュメント(英語)を関係なさそうとか判断せずにまずは全部見よう。 ◆ StackoverflowよりもGithubのissueを漁る。情報が新しい事が多いから。 ◆ 読み込む必要はさほどない。まず翻訳かまして、ざっと眺めて拾っていくのが良い。
91. Flutter Testing RiverpodとMockTailでやっていきだ 8 91
92. Flutterには3つのテストがある 92 Widget Testで留める現場が多いのでは？ Unit Test ビジネスロジック等を テストするためのもの。 あまり使ってない。 Riverpodの単体テストなどを書 いている人もいるみたい。 WidgetTestで担保すれば良い のではと思ってしまう。 Widget Test Widgetをエミュレートして、 UIの動作確認を行うテスト。 外部接続・ローカルのファイ ル読み込み等が一切できな いが、高速に動く。 テストコードはコスパ重要だ と思っているので、何の指定 もないならここだけを書く Integration Test いわゆるE2Eテスト。外部通 信もどんとこい。 FlutterでE2E書いて回して るって話、個人的に聞いたこ とがない。大抵はチームが 分かれるので。 どうしても必要な箇所だけ書 けばいいと思います。
93. Widget TestとMock 93 ➔ Widget Testでは外部接続が一切できない。 ◆ ネットワーク接続、sharedPreference、ローカルDBのアクセス不可 ◆ Widgetから直接この種の処理をベタ書きすると終わり。差し替えられない。 ➔ データアクセスを伴う処理は「メソッド単位で」差し替えたくなる。 ◆ RepositoryクラスをまるっとMock。 ◆ Mockしたメソッドの振る舞いを上書きする。 ◆ Riverpodの override機能を使ってmockしたクラスをDIする。 ◆ これで本番コードを一切汚さず Widget Testが実行できる。 外部接続を伴うコードを Mockする
94. MockTail with Riverpod 94 これでテストを書いていたのですが ➔ MockTailで、Fakeのレポジトリクラ スを作る ➔ メソッドの振る舞いを定義 ➔ Widgetを起動してfindXXして、ア サーションを実行。比較対象は Widgetになる。 ➔ https://qiita.com/KKusumi/items/f 458a42bbbf1958ad8d1
95. Fakeクラスで充分かもしれぬ 95 ➔ Flutter公式のテスティングライブラリに Fakeクラ スがあります。 ➔ Mocktailとほとんど同じだけど、メソッドの引数・ 戻り値を複数ケース用意できない。 ➔ 自分はMockTailで慣れちゃったけど、 Fakeで充 分かも。公式ってのが良い。 Mocktailは、ここ 10ヶ月更新がないのがちと心配。 シンプルで分かりやすいです
96. Widget Testの観点 96 正常系のデグレを検知するためのものだと思う ➔ イベントが適切に動くかを重点的に書いている ◆ タップ、スワイプ、スクロール、画面遷移、ダイアログ ON/OFF ◆ これが意図した状態で動かないとマジで死亡。 ➔ 状態の変化に応じたUIの切り替え ◆ 色が変わる・ボタンが押せる押せなくなるなど。 ◆ 商品一覧→詳細→カート追加→ボトムタブからカートへ →最新化されてる！とか ◆ 検索条件を追加する度に「 XX人が該当します」みたいな UIのテストとか。 ➔ アイコンはこれじゃないと！みたいな UIデグレを拾うテストはほぼ書いてません。 ◆ UIのデザインレベルのデグレを拾う良い方法を知らないのもある。スクショ比較？
97. Flutter Hooks Library 97 wasabeefさんが精力的にメンテされている ➔ Flutter Hooksの便利カスタムHooksを集めた flutter_use ➔ Flutter Hooksを使ってWidget Testを簡便に書けるflutter_hooks_test等がある。 ➔ Hooksに慣れたチームであれば、Riverpodをグローバルなデータストアとして活用して、 UI の描画まわりは flutter_hooksで統一して良いのではないでしょうか。 ➔ Flutter_Hooksは、バージョンが0.18.5。1.0になる気配が見えない。 ◆ 破壊的変更がほぼないので、枯れてきているのかなと感じるぐらい。 ◆ 1.0にならない背景はよくわからない。
98. アプリの難しさ 98 Webと違って修正が即時に適用できない ➔ ネイティブアプリは、Webと違って即時に修正できない ◆ AppStoreやGoogle Playにリリースするまでのタイムラグがある。 ◆ アップデートの強要はできない。強要させるダイアログは出せるけど。 ◆ 複数のバージョンが共存する前提で、サーバーサイドは組まないといけない。 • JSONのスキーマ、追加は簡単だけど変更するのは難しくなります。 ➔ 実行時例外が即死につながる。 コンパイル段階で可能な限り潰す。 ◆ 最大の敵は「NullPointerException」であります。即クラッシュにつながってしまう。 ◆ Lintで実行時例外が出る可能性があるなら警告出して潰せるのが理想。 ◆ ライブラリ・Flutterのコア・Firebaseなどで実行時例外が出るケースが多い（苦悩
99. アプリの難しさ その２ 99 特定の端末・ユーザーに不具合が出る ➔ ネイティブアプリは、100人中98人は動くけど2人は動かない的なものが多い ◆ チームメンバーの端末では動くが、ユーザーから不具合報告があがる事が多い。 • このユーザーだけローディングが終わらないんですけど... みたいな ◆ ライブラリのバグもあって、画像のキャッシュのライブラリで数名例外はいてた。 ◆ バックエンドに比べて環境依存・ユースケース依存のバグが多く、癖が強い。 • 画像も数枚ならいいけど、 50枚フェッチするとあかん、とか。 ◆ AndroidのSamsungの機種だけにバグ報告が上がっている issueがあったりする。 ◆ 実行時例外の多くが、 Flutterコア/ライブラリの内部コードで引き起こされる。 ➔ 不可解な不具合を踏んだら、まずは使ってるライブラリの issueを漁ろう！
100. 流れの速いFrondEnd 大切なのは思想（お気持ち）の理解 9 100
101. フロントエンドのおもしろさ 101 ➔ フロントエンドが「設計」する対象が拡大し続けている ◆ Google MapのUIが2005年に誕生して、17年が経過した。あの UIは衝撃だった。 ◆ ページの表示→イベント実装→状態管理/ロジック実装→コンポーネント設計→そして伝説へ ◆ コンポーネントを適切に作って開発者体験をあげていく。その結果、 UXが上がる。 ◆ Developer Experience重要。 ➔ ヒトの導線を設計する面白さを感じている ◆ 「どういう情報を、どういう見せ方で提供すれば、腹落ちしてくれるのか？」を考える。その過程 が好き。要件定義が好きだったのもそれの延長線上かも。 ◆ ノーヒントでタスクを渡され、ユーザーはスッと入れなかったら負けじゃん。やっぱ。 ◆ 導線を実装する武器を強くするために、モダン・フロントエンドに入門しますた。
102. FEは抽象的な概念が多い 102 各プラットフォームのお言葉を噛み締めないといけない ➔ フロントエンドは特に抽象的な概念が多い気がする。バックエンドに比べて。　 ◆ 似たような話なんだけど言葉が全然違っていることも多い。アーキテクチャの話が多い。 • Flutter → StatelessWidget, StatefulWidget • iOS → UIWindow, ViewController, IBOutlet • Android → Activity, Fragment, BindView • Windows → Form, UserControl, ViewModel ➔ カタカナを鵜呑みにせず、言い換えて自分の言葉に出来る必要がある。 ➔ 人間が絡む世界は複雑なんでしょうきっと。ほっほっほ。 ➔ 自分もFlutterのコードを最初見た時は何これ状態でした。
103. “お気持ち”を理解することに務めるのがFE修行かもしれん 103 FWの勃興にペインあり。ペインの腹落ちをする努力。 ➔ フロントエンドの速さは思想のアップデートの速さだと感じる ◆ Reactが特にそう。シンプルな APIセットがたくさんあって、これをお前らナイスに使えというフレー ムワークは、思想の理解がないと戦える気がしないんですね。 ◆ 言語仕様だけではなく、ビルドやランタイム回りも思想のアップデートが速い。 • node → deno、webpack → vite 等。 • アイランド・アーキテクチャ のようなJS配信まわり。 • レンダリング１つとっても 、色んな考え方が存在する。 (CSR/SSG/SSR/ISR) • バンドルサイズを縮小することがパフォーマンスに直結する世界線。 • GraphQLに代表されるエンドポイントまわりの考え方も色々ある。
104. Flutterはそこまで速くないかも 104 全てがOSSのWebモダンフロントエンドに比べるとね ➔ Webアプリに比べると追いかける対象は少なくてよいのかな、という印象 ◆ 環境構築・ビルド周りはプラットフォーム依存なのである意味楽。もちろんアプリサイズは小さい に越したことはないけど、バンドルサイズとパフォーマンスは直交しない。 ◆ CSSやHTMLがなく、Widgetしかない。Material Designありきなので、ある意味楽。 ◆ Flutterのコア、人気のあるライブラリの更新速度はかなり速い。 issueが多いのでね... ➔ 状態管理の流派はたくさんある。 公式もお前ら好きにしろ状態。 ◆ 状態管理の仕組みでアーキテクチャの大半が規定される。 ◆ 僕のまわりではRiverpod推しが多い。Remi is GOD.
105. テンションが上がるものに出会えた 105 Flutterフォーーーーゥ！ ➔ 2019年頃にエンジニアとしての頭打ち感を強く感じてた ◆ 当時よく書いていたのは Pythonでしたが、書いているだけって感じでした。 ◆ 発想が変わらないのでエンジニアとして頭打ち感 ➔ Flutterに出会えたおかげで、新鮮な驚きがたくさんあった ◆ プログラミングを覚えたての頃に戻った感覚。四十の手習い、楽しいです。 ➔ 2023年はTypeScriptをちゃんとやりたい。表現力を活かしきれていない。 ◆ まずは type-challenges から始めます。 ◆ T3 Stackの開発体験にビビッときたので、これをやっていきたい。 ◆ GraphQL興味あります。スキーマ駆動の向こう側へ。
106. Fluterは天下を取るかもしれぬ こんなお気持ち、OSSのフレームワークに感じたことはなかった。 行けるところまでFlutterと付き合って、少しでも恩返しがしたい。 裾野を広げることにちょっとでも貢献できたら嬉しい。 106
107. 107 https://speakerdeck.com/wasabeef/flutterkaigi-2022-keynote?slide=26
108. Happy Development Experience with Flutter! Thanks! 108 フロントエンドの海をもう少し泳ぎたいのだ ◉ @gothedistance ◉ michitaka@quality-start.in