無いことに注目してください。関数でその状態について定義しておくことは必要でしょう。状態を変更するだけで良いのです。一から再構築されます。プログラミングにおいて宣言的な記述形式は、多くの利点をもたらします。いかなる状態もまかなえるということです。state.広く受け入れられている感覚からすると、アプリの状態とは、アプリが動いている間メモリに蓄えられているすべてです。フレームワークが保持するすべての変数が、含まれます。この広く受け入れられている感覚による状態の定義は、的を射たものではありますが、アプリのアーキテクチャを考える上であまり使いやすいとは言えません。フレームワークが担います。このため状態の定義は次のようにできます。再構築時に必要なデータの総体。必要が生じた時すぐ使えるように管理されている」。こちらの方が使いやすいでしょう。・ステートと、アプリ・ステートです。単一のウィジェットにコンパクトに収められる状態のことです。BottomNavigationBarこの定義は意図してぼかしたものにしています。それではいくつかの例を見てみましょう。StatefulWidget.ウィジェット・ツリーの他の部分が、この種の状態にアクセスすることはめったにありません。状態は、シリアライズすることが不要ですし、複雑な流れで変更されることもありません。この種の状態については、要らないのです。state.以下で見てみましょう。フィールドとして保持されています。イフェメラル・ステートです。クラス中のフィールドを使うのが、最も自然な方法です。アクセスする必要がありません。ウィジェットの中でのみ変更されます。ユーザーがアプリを閉じて再起動した時のことを考えてみましょう。ゼロにリセットすることは、気にかけなくて良いのです。state).イフェメラルでは無く、アプリの多くの部分と共有しなければならず、しかもユーザーのセッション更新時も保持したい状態について、考えてみましょう。(ケーション)・ステートです。(共有ステートと呼ばれることもあります。on.アプリ・ステートを管理する上で、どのような選択肢があるかを知りたいでしょう。何を選ぶかは、アプリの複雑さと特性、チームの経験値、それに他の多くの観点から、検討する必要があります。この点について考えてみましょう。create).はっきりと言っておきます。使えば、アプリの状態管理のすべてを行えます。チームは多数のシンプルなアプリサンプルでこのようにしています。作成できるスターターアプリも含まれます。salt:ステートをイフェメラルにするかアプリにするか決めるための、明確で普遍的な規約というものはありません。一方を他方にリファクタする必要が生じることもあるでしょう。初めはイフェメラル・ステートで綺麗に収められていたものでも、アプリの機能拡充によってアプリ・ステートに移行することが必要になるかもしれません。この理由から、次のダイアグラムに沿うと良いでしょう。こちらに盲目的に従うのでは無く、批判と検証の精神は忘れずに。その状態を必要としているウィジェットの割合が、どちらで状態管理するかを決める参考になる、というフローです。洗練されている方を採用するのが良い。