【Flutter】よく出てくる単語を雑に解説

Flutterでよく出てくるけど直ぐに忘れちゃう単語がありますよね。。
思い出せるように雑にメモしておきます。

ちなみに、Flutter初学者は日本語の情報が少なく心が折れてしまうかもしれないが、
公式で出しているYoutubeの動画は英語がわからなくても理解できると思うのでオススメです。

前置き

基本的なWidgetとして、StatelessWidgetとStatefullWidgetがある。
複雑なアプリでは動的に表示情報を書き換えることが多く、StatefullWidgetを使う機会が多い。
しかし、StatefullWidgetは子Widgetの一部のみを書き換えるなどの器用な事ができず、ごそっと全部書き換えてしまいがち。
そんな中で、これを回避するいろんな手法が出てきたり、Flutter公式で用意してくれたりしている、、んだと思う。
あとはReduxが出てきた背景と同じ事が起きているんじゃないかな。。

BLoCとは

Viewとビジネスロジックを分離しましょうというよくある話の実践手法の一つ。
Providerと呼ばれるビジネスロジックを提供するだけの擬似Widgetを作り、親として設定する。
WidgetからはProviderを介してビジネスロジックを参照できるので、Viewとロジックが混在しないようにできる。
(強い人や公式がpackageを作っているので、BLoCを使うときには乗っかるといい。)

InheritedWidget

Viewを持たない擬似Widget
これを継承したWidgetを親として設定すると、setStateされても参照している子のみ再描画(build)できる凄いやつ。
BLoCで出てきたProviderも実はこれ。
参照するにはof(context)という静的メソッドを作ろう、使い勝手はSingletonのinstanceメソッドに似ている。

StreamBuilder

Streamの値が更新される度に、子Widgetをbuildしてくれる便利Widget
Streamはリアルタイムに値を通知・受け取りできるトンネルで、Observerパターン的なやつ。

ScopedModel

基本的にはBLoCと似ていて、ビジネスロジックをModelに置き換えたイメージ。
親としてScopedModel<ビジネスロジック>というWidgetを設定し、
使うときにはScopedModelDescendant<ビジネスロジック>というWidgetでラップして使う。
ツリー構造上でビジネスロジックの使用可否が判別しやすく、スッキリ書けるが、buildの制御がまだイマイチらしい。