https://flutter.dev/docs/get-started/install https://www.udacity.com/course/build-native-mobile-apps-with-flutter--ud905 https://felangel.github.io/bloc/#/
最近は flutter を触っている。
Dart について
マルチプラットフォームアプリを実装するために Dart 言語の利用を選択した Google や flutter チームの哲学にはもしかしたらスマホアプリエンジニアをスムーズに flutter へ移行させる目的があるのかもしれない。そう感じるほどには Dart 言語は java 言語を継承した言語であると思えた。
良くも悪くも Dart は java に近いため、行末のセミコロンやlet や `val` と言った変数宣言が *できない* など煩わしい点もあるのだが、学習コストは極めて低い。また java で冗長な表現になりがちな無名クラスや無名関数の表現方法についてはシンプルに纏まっていること、言語機能に async
await
yield
と言った非同期/ストリーム用機能が備えられているためモダンなプログラミングを手詰まり無く実装できる。
総合的に見て Dartが選択されたことはスムーズな開発を行う上では適切な手段であったと感じられた。
flutter 本体について
React なんかの知識があればその概念を習得することはたやすい。だいたい同じ。State を持った Widget と State を持たない Widget を作って画面を構成していく。細かいところだけれど、React のように Widget を返す無名関数を作ることはできないっぽい。Widget のサブクラスを作って、インスタンスを生成する必要があるっぽい。 React と大きく違うところは Statefull な widget の State の管理方法。React では Widget の中に State としてプロパティを持たせたが、flutter の場合は StatefullWidget 自体は不変で、外部のコンポーネントからは不可視となる State インスタンスを可変なものとして扱う。この仕組で パフォーマンス上のメリット: Widget の生成や更新は State の変更があったときだけに限定できる プログラミング上の安全性: 外部から State が不用意に更新されることはない と言った恩恵が得られる。
bloc について
flutter と言えば bloc が最もポピュラーなアーキテクチャとして有名である。Business Logic Component パターンと呼ばれて、以下の制約のもと Redux っぽいアーキテクチャーを構成する
BLoCの入出力インターフェースはすべてStream/Sinkである
BLoCの依存は必ず注入可能でプラットフォームに依存しない
BLoC内にプラットフォームによる分岐処理を書くことは許されない
以上のルールに従う限り、他の実装をどうするかは問わない
要は、Bloc という仕組みで Redux の Store に相当する部分からプラットフォーム依存のコードを排除しようという考え。Redux に慣れていればとくに違和感なく受け入れられるが、レビューの際にはビジネスロジックにプラットフォーム依存のコードが入らないように注意する必要がある。lint をいい感じにして import
をチェックする仕組みを導入できると良いかもしれない。
懸念としては kotlin/scala の sealed class
や swift の enum
のようにパターンマッチに関する支援機能がDartに用意されていない点。Redux 的なアーキテクチャーなので
Event -> State -> Widget
の変換が発生するが、パターンマッチが提供されていないためコンパイラでは Event や State のパターン漏れが発生してしまう。また Dart はすべてのオブジェクトは nullable であり、また関数は暗黙的に null を返す仕様となっている。そのため、パターンの取りこぼしが発生した場合には実行時エラーのヌルポが出ることがある。これは Dart のアップデートに期待をしたいところ。
flutter の学習方法
公式のチュートリアルがしっかりしているので、一通りやるのが良い。Udacity でも flutter のコースが公開されているものの、リファレンスを見ながら進めていく必要もあってかなり大変だった。知識が無の状態でリファレンスを読むのは実質難しい。今は bloc を実現するためのライブラリであある、 `flutter_bloc` で公開されているチュートリアルを一通りやっている。実践的なアプリ開発を通していろいろなコンポーネントを一通り触ることができる。これをやった後で Udacity に手を出すのが良いかもしれない。