Flutter-BLoC-第二講

Silence_Zhou發表於2019-04-02

本篇已同步到 個人部落格 ,歡迎常來。

[譯文]Reactive Programming - Streams - BLoC實際用例

原文地址

介紹

在介紹了BLoC,Reactive Programming和Streams的概念後,我在一段時間之前做了一些介紹,儘管與我分享一些我經常使用並且個人覺得非常有用的模式(至少對我而言)可能會很有趣。這些模式使我在開發過程中節省了大量時間,並使我的程式碼更易於閱讀和除錯。

我要談的話題是:

  • 1.BLoC Provider and InheritedWidget
  • 2.在哪裡初始化BLoC?
  • 3.事件狀態(允許根據事件響應狀態轉換)
  • 4.表格驗證(允許根據條目和驗證控制表單的行為)
  • 5.Part Of(允許Widget根據其在列表中的存在來調整其行為)

完整的原始碼可以在GitHub上找到。

1.BLoC Provider and InheritedWidget

我藉此文章的機會介紹我的BlocProvider的另一個版本,它現在依賴於一個InheritedWidget。

使用InheritedWidget的優點是我們獲得了效能。

1.1. 之前的實現

我之前版本的BlocProvider實現為常規StatefulWidget,如下所示:

abstract class BlocBase {
  void dispose();
}

// Generic BLoC provider
class BlocProvider<T extends BlocBase> extends StatefulWidget {
  BlocProvider({
    Key key,
    @required this.child,
    @required this.bloc,
  }): super(key: key);

  final T bloc;
  final Widget child;

  @override
  _BlocProviderState<T> createState() => _BlocProviderState<T>();

  static T of<T extends BlocBase>(BuildContext context){
    final type = _typeOf<BlocProvider<T>>();
    BlocProvider<T> provider = context.ancestorWidgetOfExactType(type);
    return provider.bloc;
  }

  static Type _typeOf<T>() => T;
}

class _BlocProviderState<T> extends State<BlocProvider<BlocBase>>{
  @override
  void dispose(){
    widget.bloc.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context){
    return widget.child;
  }
}
複製程式碼

我使用StatefulWidget從dispose()方法中受益,以確保在不再需要時釋放BLoC分配的資源。

這很好用但從效能角度來看並不是最佳的。

context.ancestorWidgetOfExactType()是一個為時間複雜度為O(n)的函式,為了檢索某種型別的祖先,它將對widget樹 做向上導航,從上下文開始,一次遞增一個父,直到完成。如果從上下文到祖先的距離很小(即O(n)結果很少),則可以接受對此函式的呼叫,否則應該避免。這是這個函式的程式碼。

@override
Widget ancestorWidgetOfExactType(Type targetType) {
    assert(_debugCheckStateIsActiveForAncestorLookup());
    Element ancestor = _parent;
    while (ancestor != null && ancestor.widget.runtimeType != targetType)
        ancestor = ancestor._parent;
    return ancestor?.widget;
}
複製程式碼

1.2. 新的實現

新實現依賴於StatefulWidget,並結合InheritedWidget:

Type _typeOf<T>() => T;

abstract class BlocBase {
  void dispose();
}

class BlocProvider<T extends BlocBase> extends StatefulWidget {
  BlocProvider({
    Key key,
    @required this.child,
    @required this.bloc,
  }): super(key: key);

  final Widget child;
  final T bloc;

  @override
  _BlocProviderState<T> createState() => _BlocProviderState<T>();

  static T of<T extends BlocBase>(BuildContext context){
    final type = _typeOf<_BlocProviderInherited<T>>();
    _BlocProviderInherited<T> provider = 
            context.ancestorInheritedElementForWidgetOfExactType(type)?.widget;
    return provider?.bloc;
  }
}

class _BlocProviderState<T extends BlocBase> extends State<BlocProvider<T>>{
  @override
  void dispose(){
    widget.bloc?.dispose();
    super.dispose();
  }
  
  @override
  Widget build(BuildContext context){
    return new _BlocProviderInherited<T>(
      bloc: widget.bloc,
      child: widget.child,
    );
  }
}

class _BlocProviderInherited<T> extends InheritedWidget {
  _BlocProviderInherited({
    Key key,
    @required Widget child,
    @required this.bloc,
  }) : super(key: key, child: child);

  final T bloc;

  @override
  bool updateShouldNotify(_BlocProviderInherited oldWidget) => false;
}
複製程式碼

優點是這個解決方案是效能。

由於使用了InheritedWidget,它現在可以呼叫context.ancestorInheritedElementForWidgetOfExactType()函式,它是一個O(1),這意味著祖先的檢索是立即的,如其原始碼所示:

@override
InheritedElement ancestorInheritedElementForWidgetOfExactType(Type targetType) {
    assert(_debugCheckStateIsActiveForAncestorLookup());
    final InheritedElement ancestor = _inheritedWidgets == null 
                                    ? null 
                                    : _inheritedWidgets[targetType];
    return ancestor;
}
複製程式碼

這來自於所有InheritedWidgets都由Framework記憶的事實。

  • 為什麼使用 ancestorInheritedElementForWidgetOfExactType ?
  • 您可能已經注意到我使用 ancestorInheritedElementForWidgetOfExactType 方法而不是通常的 inheritFromWidgetOfExactType 。
  • 原因是我不希望上下文呼叫的BlocProvider被註冊為InheritedWidget的依賴項,因為我不需要它。

1.3. 如何使用新的BlocProvider?

1.3.1.注入BLoC
Widget build(BuildContext context){
    return BlocProvider<MyBloc>{
        bloc: myBloc,
        child: ...
    }
}
複製程式碼
1.3.2. 檢索BLoC
Widget build(BuildContext context){
    MyBloc myBloc = BlocProvider.of<MyBloc>(context);
    ...
}
複製程式碼

2.在哪裡初始化BLoC?

要回答這個問題,您需要弄清楚其使用範圍。

2.1.應用程式中隨處可用

假設您必須處理與使用者身份驗證/配置檔案,使用者首選項,購物籃相關的一些機制, 可從應用程式的任何可能部分(例如,從不同頁面)獲得獲得BLoC(),存在兩種方式使這個BLoC可訪問。

2.1.1.使用全域性單例
import 'package:rxdart/rxdart.dart';

class GlobalBloc {
  ///
  /// 與此BLoC相關的流
  ///
  BehaviorSubject<String> _controller = BehaviorSubject<String>();
  Function(String) get push => _controller.sink.add;
  Stream<String> get stream => _controller;

  ///
  /// Singleton工廠
  ///
  static final GlobalBloc _bloc = new GlobalBloc._internal();
  factory GlobalBloc(){
    return _bloc;
  }
  GlobalBloc._internal();
  
  ///
  /// Resource disposal
  ///
  void dispose(){
    _controller?.close();
}

GlobalBloc globalBloc = GlobalBloc();
複製程式碼

要使用此BLoC,您只需匯入該類並直接呼叫其方法,如下所示:

import 'global_bloc.dart';

class MyWidget extends StatelessWidget {
    @override
    Widget build(BuildContext context){
        globalBloc.push('building MyWidget');
        return Container();
    }
}
複製程式碼

這是一個可以接受的解決方案,如果你需要有一個BLoC是唯一的,需要從應用程式內的任意位置訪問。

  • 這是非常容易使用;
  • 它不依賴於任何BuildContext ;
  • 沒有必要通過任何BlocProvider去尋找 BLoC;
  • 為了釋放它的資源,只需確保將應用程式實現為StatefulWidget,並在應用程式Widget 的重寫dispose()方法中呼叫globalBloc.dispose()

許多純粹主義者反對這種解決方案。我不知道為什麼,但是...所以讓我們看看另一個......

2.1.2. 把它放在一切之上

在Flutter中,所有頁面的祖先本身必須是MaterialApp的父級。這是由於這樣的事實,一個頁面(或路由)被包裝在一個OverlayEntry,一個共同的孩子堆疊的所有頁面。

換句話說,每個頁面都有一個Buildcontext,它獨立於任何其他頁面。這就解釋了為什麼在不使用任何技巧的情況下,2頁(路線)不可能有任何共同點。

因此,如果您需要在應用程式中的任何位置使用BLoC,則必須將其作為MaterialApp的父級,如下所示:

void main() => runApp(Application());

class Application extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocProvider<AuthenticationBloc>(
      bloc: AuthenticationBloc(),
      child: MaterialApp(
        title: 'BLoC Samples',
        theme: ThemeData(
          primarySwatch: Colors.blue,
        ),
        home: InitializationPage(),
      ),
    );
  }
}
複製程式碼

2.2.可用於子樹

大多數情況下,您可能需要在應用程式的某些特定部分使用BLoC。

作為一個例子,我們可以想到的討論主題,其中集團將用於

  • 與伺服器互動以檢索,新增,更新帖子
  • 列出要在特定頁面中顯示的執行緒
  • ...

因此,如果您需要在應用程式中的任何位置使用BLoC,則必須將其作為MaterialApp的父級,如下所示:

class MyTree extends StatelessWidget {
  @override
  Widget build(BuildContext context){
    return BlocProvider<MyBloc>(
      bloc: MyBloc(),
      child: Column(
        children: <Widget>[
          MyChildWidget(),
        ],
      ),
    );
  }
}

class MyChildWidget extends StatelessWidget {
  @override 
  Widget build(BuildContext context){
    MyBloc = BlocProvider.of<MyBloc>(context);
    return Container();
  }
}
複製程式碼

這樣一來,所有widgets都可以通過對呼叫BlocProvider.of方法 訪問BLoC

附: 如上所示的解決方案並不是最佳解決方案,因為它將在每次重建時例項化BLoC。 後果:

  • 您將丟失任何現有的BLoC內容
  • 它會耗費CPU時間,因為它需要在每次構建時例項化它。

一個更好的辦法,在這種情況下,是使用StatefulWidget從它的持久受益國,具體如下:

class MyTree extends StatefulWidget {
 @override
  _MyTreeState createState() => _MyTreeState();
}
class _MyTreeState extends State<MyTree>{
  MyBloc bloc;
  
  @override
  void initState(){
    super.initState();
    bloc = MyBloc();
  }
  
  @override
  void dispose(){
    bloc?.dispose();
    super.dispose();
  }
  
  @override
  Widget build(BuildContext context){
    return BlocProvider<MyBloc>(
      bloc: bloc,
      child: Column(
        children: <Widget>[
          MyChildWidget(),
        ],
      ),
    );
  }
}
複製程式碼

使用這種方法,如果需要重建“ MyTree ”小部件,則不必重新例項化BLoC並直接重用現有例項。

2.3.僅適用於一個小部件

這涉及BLoC僅由一個 Widget使用的情況。

在這種情況下,可以在Widget中例項化BLoC。

3.事件狀態(允許根據事件響應狀態轉換)

有時,處理一系列可能是順序或並行,長或短,同步或非同步以及可能導致各種結果的活動可能變得非常難以程式設計。您可能還需要更新顯示以及進度或根據狀態。

第一個用例旨在使這種情況更容易處理。

該解決方案基於以下原則:

  • 發出一個事件;
  • 此事件觸發一些導致一個或多個狀態的動作;
  • 這些狀態中的每一個都可以反過來發出其他事件或導致另一個狀態;
  • 然後,這些事件將根據活動狀態觸發其他操作;
  • 等等…

為了說明這個概念,我們來看兩個常見的例子:

應用初始化

  • 假設您需要執行一系列操作來初始化應用程式。操作可能與伺服器的互動相關聯(例如,載入一些資料)。 在此初始化過程中,您可能需要顯示進度條和一系列影像以使使用者等待。

認證

  • 在啟動時,應用程式可能需要使用者進行身份驗證或註冊。 使用者通過身份驗證後,將重定向到應用程式的主頁面。然後,如果使用者登出,則將其重定向到認證頁面。

為了能夠處理所有可能的情況,事件序列,但是如果我們認為可以在應用程式中的任何地方觸發事件,這可能變得非常難以管理。

這就是BlocEventState,兼有BlocEventStateBuilder,可以幫助很多...

3.1. BlocEventState

BlocEventState背後的想法是定義一個BLoC:

  • 接受事件作為輸入;
  • 當發出新事件時呼叫eventHandler;
  • eventHandler 負責根據事件採取適當的行動併發出狀態作為回應。

下圖顯示了這個想法:

image.png

這是這類的原始碼。解釋如下:

import 'package:blocs/bloc_helpers/bloc_provider.dart';
import 'package:meta/meta.dart';
import 'package:rxdart/rxdart.dart';

abstract class BlocEvent extends Object {}
abstract class BlocState extends Object {}

abstract class BlocEventStateBase<BlocEvent, BlocState> implements BlocBase {
  PublishSubject<BlocEvent> _eventController = PublishSubject<BlocEvent>();
  BehaviorSubject<BlocState> _stateController = BehaviorSubject<BlocState>();

  ///
  /// 要呼叫以發出事件
  ///
  Function(BlocEvent) get emitEvent => _eventController.sink.add;

  ///
  /// 當前/新狀態
  ///
  Stream<BlocState> get state => _stateController.stream;

  ///
  /// 事件的外部處理
  ///
  Stream<BlocState> eventHandler(BlocEvent event, BlocState currentState);

  ///
  /// initialState
  ///
  final BlocState initialState;

  //
  // 建構函式
  //
  BlocEventStateBase({
    @required this.initialState,
  }){
    //
    // 對於每個接收到的事件,我們呼叫[eventHandler]併發出任何結果的newState
    //
    _eventController.listen((BlocEvent event){
      BlocState currentState = _stateController.value ?? initialState;
      eventHandler(event, currentState).forEach((BlocState newState){
        _stateController.sink.add(newState);
      });
    });
  }

  @override
  void dispose() {
    _eventController.close();
    _stateController.close();
  }
}
複製程式碼

如您所見,這是一個需要擴充套件的抽象類,用於定義eventHandler方法的行為。

他公開:

  • 一個Sink(emitEvent)來推送一個事件 ;
  • 一個流(狀態)來監聽發射狀態。

在初始化時(請參閱建構函式):

一個初始化狀態需要設定;

  • 它建立了一個StreamSubscription聽傳入事件到
  • 將它們傳送到eventHandler
  • 發出結果狀態。

3.2. 專門的BlocEventState

用於實現此類BlocEventState的模板在下面給出。之後,我們將實施真實的。

class TemplateEventStateBloc extends BlocEventStateBase<BlocEvent, BlocState> {
  TemplateEventStateBloc()
      : super(
          initialState: BlocState.notInitialized(),
        );

  @override
  Stream<BlocState> eventHandler( BlocEvent event, BlocState currentState) async* {
     yield BlocState.notInitialized();
  }
}
複製程式碼

如果這個模板不能編譯,請不要擔心......這是正常的,因為我們還沒有定義BlocState.notInitialized() ......這將在幾分鐘內出現。

此模板僅在初始化時提供initialState並覆蓋eventHandler。

這裡有一些非常有趣的事情需要注意。我們使用非同步生成器:async * 和yield語句。

使用async *修飾符標記函式,將函式標識為非同步生成器:

每次 yield 語句 被呼叫時,它增加了下面的表示式的結果 yield 輸出stream。

這是非常有用的,如果我們需要發出一個序列的States,從一系列的行動所造成(我們將在後面看到,在實踐中)

有關非同步生成器的其他詳細資訊,請單擊此連結

3.3.BlocEvent和BlocState

正如您所注意到的,我們已經定義了一個 BlocEvent 和 BlocState 抽象類。

這些類需要使用您要發出的特殊事件和狀態進行擴充套件。

3.4. BlocEventStateBuilder小部件

模式最後一部分的是BlocEventStateBuilder小部件,它允許你在響應State(s),所發射的BlocEventState。

這是它的原始碼:

typedef Widget AsyncBlocEventStateBuilder<BlocState>(BuildContext context, BlocState state);

class BlocEventStateBuilder<BlocEvent,BlocState> extends StatelessWidget {
  const BlocEventStateBuilder({
    Key key,
    @required this.builder,
    @required this.bloc,
  }): assert(builder != null),
      assert(bloc != null),
      super(key: key);

  final BlocEventStateBase<BlocEvent,BlocState> bloc;
  final AsyncBlocEventStateBuilder<BlocState> builder;

  @override
  Widget build(BuildContext context){
    return StreamBuilder<BlocState>(
      stream: bloc.state,
      initialData: bloc.initialState,
      builder: (BuildContext context, AsyncSnapshot<BlocState> snapshot){
        return builder(context, snapshot.data);
      },
    );
  }
}
複製程式碼

這個Widget只是一個專門的StreamBuilder,它會在每次發出新的BlocState時呼叫builder輸入引數。


好的。現在我們已經擁有了所有的部分,現在是時候展示我們可以用它們做些什麼......

3.5.案例1:應用程式初始化

第一個示例說明了您需要應用程式在啟動時執行某些任務的情況。

常見的用途是遊戲最初顯示啟動畫面(動畫與否),同時從伺服器獲取一些檔案,檢查新的更新是否可用,嘗試連線到任何遊戲中心 ......在顯示實際主螢幕之前。為了不給應用程式什麼都不做的感覺,它可能會顯示一個進度條並定期顯示一些圖片,同時它會完成所有初始化過程。

我要向您展示的實現非常簡單。它只會在螢幕上顯示一些競爭百分比,但這可以很容易地擴充套件到您的需求。

3.5.1。ApplicationInitializationEvent

在這個例子中,我只考慮2個事件:

  • start:此事件將觸發初始化過程;
  • stop:該事件可用於強制初始化程式停止。

這是定義程式碼實現:

class ApplicationInitializationEvent extends BlocEvent {
  
  final ApplicationInitializationEventType type;

  ApplicationInitializationEvent({
    this.type: ApplicationInitializationEventType.start,
  }) : assert(type != null);
}

enum ApplicationInitializationEventType {
  start,
  stop,
}
複製程式碼

3.5.2. ApplicationInitializationState

該類將提供與初始化過程相關的資訊。

對於這個例子,我會考慮:

  • 2標識: isInitialized指示初始化是否完成 isInitializing以瞭解我們是否處於初始化過程的中間
  • 進度完成率

這是它的原始碼:

class ApplicationInitializationState extends BlocState {
  ApplicationInitializationState({
    @required this.isInitialized,
    this.isInitializing: false,
    this.progress: 0,
  });

  final bool isInitialized;
  final bool isInitializing;
  final int progress;

  factory ApplicationInitializationState.notInitialized() {
    return ApplicationInitializationState(
      isInitialized: false,
    );
  }

  factory ApplicationInitializationState.progressing(int progress) {
    return ApplicationInitializationState(
      isInitialized: progress == 100,
      isInitializing: true,
      progress: progress,
    );
  }

  factory ApplicationInitializationState.initialized() {
    return ApplicationInitializationState(
      isInitialized: true,
      progress: 100,
    );
  }
}
複製程式碼

3.5.3. ApplicationInitializationBloc

該BLoC負責基於事件處理初始化過程。

這是程式碼:

class ApplicationInitializationBloc
    extends BlocEventStateBase<ApplicationInitializationEvent, ApplicationInitializationState> {
  ApplicationInitializationBloc()
      : super(
          initialState: ApplicationInitializationState.notInitialized(),
        );

  @override
  Stream<ApplicationInitializationState> eventHandler(
      ApplicationInitializationEvent event, ApplicationInitializationState currentState) async* {
    
    if (!currentState.isInitialized){
      yield ApplicationInitializationState.notInitialized();
    }

    if (event.type == ApplicationInitializationEventType.start) {
      for (int progress = 0; progress < 101; progress += 10){
        await Future.delayed(const Duration(milliseconds: 300));
        yield ApplicationInitializationState.progressing(progress);
      }
    }

    if (event.type == ApplicationInitializationEventType.stop){
      yield ApplicationInitializationState.initialized();
    }
  }
}
複製程式碼

一些解釋:

  • 當收到事件“ ApplicationInitializationEventType.start ”時,它從0開始計數到100(單位為10),並且對於每個值(0,10,20,......),它發出(通過yield)一個告訴的新狀態初始化正在執行(isInitializing = true)及其進度值。
  • 當收到事件"ApplicationInitializationEventType.stop"時,它認為初始化已完成。
  • 正如你所看到的,我在計數器迴圈中放了一些延遲。這將向您展示如何使用任何Future(例如,您需要聯絡伺服器的情況)
3.5.4. 將它們全部包裝在一起

現在,剩下的部分是顯示顯示計數器的偽Splash螢幕 ......

class InitializationPage extends StatefulWidget {
  @override
  _InitializationPageState createState() => _InitializationPageState();
}

class _InitializationPageState extends State<InitializationPage> {
  ApplicationInitializationBloc bloc;

  @override
  void initState(){
    super.initState();
    bloc = ApplicationInitializationBloc();
    bloc.emitEvent(ApplicationInitializationEvent());
  }

  @override
  void dispose(){
    bloc?.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext pageContext) {
    return SafeArea(
      child: Scaffold(
        body: Container(
          child: Center(
            child: BlocEventStateBuilder<ApplicationInitializationEvent, ApplicationInitializationState>(
              bloc: bloc,
              builder: (BuildContext context, ApplicationInitializationState state){
                if (state.isInitialized){
                  //
                  // Once the initialization is complete, let's move to another page
                  //
                  WidgetsBinding.instance.addPostFrameCallback((_){
                    Navigator.of(context).pushReplacementNamed('/home');
                  });
                }
                return Text('Initialization in progress... ${state.progress}%');
              },
            ),
          ),
        ),
      ),
    );
  }
}
複製程式碼

說明:

  • 由於ApplicationInitializationBloc不需要在應用程式的任何地方使用,我們可以在StatefulWidget中初始化它;
  • 我們直接發出ApplicationInitializationEventType.start事件來觸發eventHandler
  • 每次發出ApplicationInitializationState時,我們都會更新文字
  • 初始化完成後,我們將使用者重定向到主頁。

特技

由於我們無法直接重定向到主頁,在構建器內部,我們使用WidgetsBinding.instance.addPostFrameCallback()方法請求Flutter 在渲染完成後立即執行方法

3.6. 案例2:應用程式身份驗證和登出

對於此示例,我將考慮以下用例:

  • 在啟動時,如果使用者未經過身份驗證,則會自動顯示“ 身份驗證/註冊”頁面;
  • 在使用者認證期間,顯示CircularProgressIndicator ;
  • 經過身份驗證後,使用者將被重定向到主頁 ;
  • 在應用程式的任何地方,使用者都可以登出;
  • 當使用者登出時,使用者將自動重定向到“ 身份驗證”頁面。

當然,很有可能以程式設計方式處理所有這些,但將所有這些委託給BLoC要容易得多。

下圖解釋了我要解釋的解決方案:

image

名為“ DecisionPage ” 的中間頁面將負責將使用者自動重定向到“ 身份驗證”頁面或主頁,具體取決於使用者身份驗證的狀態。當然,此DecisionPage從不顯示,也不應被視為頁面。

3.6.1. AuthenticationEvent

在這個例子中,我只考慮2個事件:

  • login:當使用者正確驗證時發出此事件;
  • logout:使用者登出時發出的事件。

程式碼如下:

abstract class AuthenticationEvent extends BlocEvent {
  final String name;

  AuthenticationEvent({
    this.name: '',
  });
}

class AuthenticationEventLogin extends AuthenticationEvent {
  AuthenticationEventLogin({
    String name,
  }) : super(
          name: name,
        );
}

class AuthenticationEventLogout extends AuthenticationEvent {}
複製程式碼

3.6.2. AuthenticationState 該類將提供與身份驗證過程相關的資訊。

對於這個例子,我會考慮:

  • 3點: isAuthenticated指示身份驗證是否完整 isAuthenticating以瞭解我們是否處於身份驗證過程的中間 hasFailed表示身份驗證失敗
  • 經過身份驗證的使用者名稱

這是它的原始碼:

class AuthenticationState extends BlocState {
  AuthenticationState({
    @required this.isAuthenticated,
    this.isAuthenticating: false,
    this.hasFailed: false,
    this.name: '',
  });

  final bool isAuthenticated;
  final bool isAuthenticating;
  final bool hasFailed;

  final String name;
  
  factory AuthenticationState.notAuthenticated() {
    return AuthenticationState(
      isAuthenticated: false,
    );
  }

  factory AuthenticationState.authenticated(String name) {
    return AuthenticationState(
      isAuthenticated: true,
      name: name,
    );
  }

  factory AuthenticationState.authenticating() {
    return AuthenticationState(
      isAuthenticated: false,
      isAuthenticating: true,
    );
  }

  factory AuthenticationState.failure() {
    return AuthenticationState(
      isAuthenticated: false,
      hasFailed: true,
    );
  }
}
複製程式碼
3.6.3.AuthenticationBloc

此BLoC負責根據事件處理身份驗證過程。

這是程式碼:

class AuthenticationBloc
    extends BlocEventStateBase<AuthenticationEvent, AuthenticationState> {
  AuthenticationBloc()
      : super(
          initialState: AuthenticationState.notAuthenticated(),
        );

  @override
  Stream<AuthenticationState> eventHandler(
      AuthenticationEvent event, AuthenticationState currentState) async* {

    if (event is AuthenticationEventLogin) {
      //通知我們正在進行身份驗證
      yield AuthenticationState.authenticating();

      //模擬對身份驗證伺服器的呼叫
      await Future.delayed(const Duration(seconds: 2));

      //告知我們是否已成功通過身份驗證
      if (event.name == "failure"){
        yield AuthenticationState.failure();
      } else {
        yield AuthenticationState.authenticated(event.name);
      }
    }

    if (event is AuthenticationEventLogout){
      yield AuthenticationState.notAuthenticated();
    }
  }
}
複製程式碼

一些解釋:

  • 當收到事件“ AuthenticationEventLogin ”時,它會(通過yield)發出一個新狀態,告知身份驗證正在執行(isAuthenticating = true)。
  • 然後它執行身份驗證,一旦完成,就會發出另一個狀態,告知身份驗證已完成。
  • 當收到事件“ AuthenticationEventLogout ”時,它將發出一個新狀態,告訴使用者不再進行身份驗證。
3.6.4. AuthenticationPage

正如您將要看到的那樣,為了便於解釋,此頁面非常基本且不會做太多。

這是程式碼。解釋如下:

class AuthenticationPage extends StatelessWidget {
  ///
  /// Prevents the use of the "back" button
  ///
  Future<bool> _onWillPopScope() async {
    return false;
  }

  @override
  Widget build(BuildContext context) {
    AuthenticationBloc bloc = BlocProvider.of<AuthenticationBloc>(context);
    return WillPopScope(
      onWillPop: _onWillPopScope,
      child: SafeArea(
        child: Scaffold(
          appBar: AppBar(
            title: Text('Authentication Page'),
            leading: Container(),
          ),
          body: Container(
            child:
                BlocEventStateBuilder<AuthenticationEvent, AuthenticationState>(
              bloc: bloc,
              builder: (BuildContext context, AuthenticationState state) {
                if (state.isAuthenticating) {
                  return PendingAction();
                }

                if (state.isAuthenticated){
                  return Container();
                }
                
                List<Widget> children = <Widget>[];

                // Button to fake the authentication (success)
                children.add(
                  ListTile(
                      title: RaisedButton(
                        child: Text('Log in (success)'),
                        onPressed: () {
                            bloc.emitEvent(AuthenticationEventLogin(name: 'Didier'));
                        },
                      ),
                    ),
                );

                // Button to fake the authentication (failure)
                children.add(
                  ListTile(
                      title: RaisedButton(
                        child: Text('Log in (failure)'),
                        onPressed: () {
                            bloc.emitEvent(AuthenticationEventLogin(name: 'failure'));
                        },
                      ),
                    ),
                );

                // Display a text if the authentication failed
                if (state.hasFailed){
                  children.add(
                    Text('Authentication failure!'),
                  );
                }

                return Column(
                  children: children,
                );    
              },
            ),
          ),
        ),
      ),
    );
  }
}
複製程式碼

說明:

  • 第11行:頁面檢索對AuthenticationBloc的引用
  • 第24-70行:它監聽發出的AuthenticationState: 如果身份驗證正在進行中,它會顯示一個CircularProgressIndicator,告訴使用者正在進行某些操作並阻止使用者訪問該頁面(第25-27行) 如果驗證成功,我們不需要顯示任何內容(第29-31行)。 如果使用者未經過身份驗證,則會顯示2個按鈕以模擬成功的身份驗證和失敗。 當我們點選其中一個按鈕時,我們發出一個AuthenticationEventLogin事件,以及一些引數(通常由認證過程使用) 如果驗證失敗,我們會顯示錯誤訊息(第60-64行)

提示

您可能已經注意到,我將頁面包裝在WillPopScope中。 理由是我不希望使用者能夠使用Android'後退'按鈕,如此示例中所示,身份驗證是一個必須的步驟,它阻止使用者訪問任何其他部分,除非經過正確的身份驗證。

3.6.5. DecisionPage

如前所述,我希望應用程式根據身份驗證狀態自動重定向到AuthenticationPage或HomePage。

以下是此DecisionPage的程式碼,說明如下:

class DecisionPage extends StatefulWidget {
  @override
  DecisionPageState createState() {
    return new DecisionPageState();
  }
}

class DecisionPageState extends State<DecisionPage> {
  AuthenticationState oldAuthenticationState;

  @override
  Widget build(BuildContext context) {
    AuthenticationBloc bloc = BlocProvider.of<AuthenticationBloc>(context);
    return BlocEventStateBuilder<AuthenticationEvent, AuthenticationState>(
      bloc: bloc,
      builder: (BuildContext context, AuthenticationState state) {
        if (state != oldAuthenticationState){
          oldAuthenticationState = state;

          if (state.isAuthenticated){
            _redirectToPage(context, HomePage());
          } else if (state.isAuthenticating || state.hasFailed){
           //do nothing
          } else {
            _redirectToPage(context, AuthenticationPage());
          }
        }//此頁面不需要顯示任何內容
        //總是在任何活動頁面後面提醒(因此“隱藏”)。
        return Container();
      }
    );
  }

  void _redirectToPage(BuildContext context, Widget page){
    WidgetsBinding.instance.addPostFrameCallback((_){
      MaterialPageRoute newRoute = MaterialPageRoute(
          builder: (BuildContext context) => page
        );

      Navigator.of(context).pushAndRemoveUntil(newRoute, ModalRoute.withName('/decision'));
    });
  }
}
複製程式碼

提醒

為了詳細解釋這一點,我們需要回到Flutter處理Pages(= Route)的方式。要處理路由,我們使用導航器,它建立一個疊加層。 這個覆蓋是一個堆疊的OverlayEntry,他們每個人的包含頁面。 當我們通過Navigator.of(上下文)推送,彈出,替換頁面時,後者更新其重建的覆蓋(因此堆疊)。 當堆疊被重建,每個OverlayEntry(因此它的內容)也被重建。 因此,當我們通過Navigator.of(上下文)進行操作時,所有剩餘的頁面都會重建!

那麼,為什麼我將它實現為StatefulWidget?

為了能夠響應AuthenticationState的任何更改,此“ 頁面 ”需要在應用程式的整個生命週期中保持存在。

這意味著,根據上面的提醒,每次Navigator.of(上下文)完成操作時,都會重建此頁面。

因此,它的BlocEventStateBuilder也將重建,呼叫自己的構建器方法。

因為此構建器負責將使用者重定向到與AuthenticationState對應的頁面,所以如果我們每次重建頁面時重定向使用者,它將繼續重定向,因為不斷重建。

為了防止這種情況發生,我們只需要記住我們採取行動的最後一個AuthenticationState,並且只在收到另一個AuthenticationState時採取另一個動作。

這是如何運作的?

如上所述,每次發出AuthenticationState時,BlocEventStateBuilder都會呼叫其構建器。

基於狀態標誌(isAuthenticated),我們知道我們需要向哪個頁面重定向使用者。

特技

由於我們無法直接從構建器重定向到另一個頁面,因此我們使用WidgetsBinding.instance.addPostFrameCallback()方法在呈現完成後請求Flutter執行方法

此外,由於我們需要在重定向使用者之前刪除任何現有頁面,除了需要保留在所有情況下的此DecisionPage 之外,我們使用Navigator.of(context).pushAndRemoveUntil(...)來實現此目的。

3.6.6、登出 要讓使用者登出,您現在可以建立一個“ LogOutButton ”並將其放在應用程式的任何位置。

  • 此按鈕只需要發出AuthenticationEventLogout()事件,這將導致以下自動操作鏈: 1.它將由AuthenticationBloc處理 2.反過來會發出一個AuthentiationState(isAuthenticated = false) 3.這將由DecisionPage通過BlocEventStateBuilder處理 4.這會將使用者重定向到AuthenticationPage
3.6.7. AuthenticationBloc

由於AuthenticationBloc需要提供給該應用程式的任何頁面,我們也將注入它作為MaterialApp父母,如下所示

void main() => runApp(Application());

class Application extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocProvider<AuthenticationBloc>(
      bloc: AuthenticationBloc(),
      child: MaterialApp(
        title: 'BLoC Samples',
        theme: ThemeData(
          primarySwatch: Colors.blue,
        ),
        home: DecisionPage(),
      ),
    );
  }
}
複製程式碼

4.表格驗證(允許根據條目和驗證控制表單的行為)

BLoC的另一個有趣用途是當您需要驗證表單時:

  • 根據某些業務規則驗證與TextField相關的條目;
  • 根據規則顯示驗證錯誤訊息;
  • 根據業務規則自動化視窗小部件的可訪問性。

我現在要做的一個例子是RegistrationForm,它由3個TextFields(電子郵件,密碼,確認密碼)和1個RaisedButton組成,以啟動註冊過程。

我想要實現的業務規則是:

  • 該電子郵件必須是一個有效的電子郵件地址。如果不是,則需要顯示訊息。
  • 該密碼必須是有效的(必須包含至少8個字元,具有1個大寫,小寫1,圖1和1個特殊字元)。如果無效,則需要顯示訊息。
  • 在重新輸入密碼需要滿足相同的驗證規則和相同的密碼。如果不相同,則需要顯示訊息。
  • 在登記時,按鈕可能只能啟用所有的規則都是有效的。

4.1.RegistrationFormBloc

該BLoC負責處理驗證業務規則,如前所述。

原始碼如下:

class RegistrationFormBloc extends Object with EmailValidator, PasswordValidator implements BlocBase {

  final BehaviorSubject<String> _emailController = BehaviorSubject<String>();
  final BehaviorSubject<String> _passwordController = BehaviorSubject<String>();
  final BehaviorSubject<String> _passwordConfirmController = BehaviorSubject<String>();

  //
  //  Inputs
  //
  Function(String) get onEmailChanged => _emailController.sink.add;
  Function(String) get onPasswordChanged => _passwordController.sink.add;
  Function(String) get onRetypePasswordChanged => _passwordConfirmController.sink.add;

  //
  // Validators
  //
  Stream<String> get email => _emailController.stream.transform(validateEmail);
  Stream<String> get password => _passwordController.stream.transform(validatePassword);
  Stream<String> get confirmPassword => _passwordConfirmController.stream.transform(validatePassword)
    .doOnData((String c){
      // If the password is accepted (after validation of the rules)
      // we need to ensure both password and retyped password match
      if (0 != _passwordController.value.compareTo(c)){
        // If they do not match, add an error
        _passwordConfirmController.addError("No Match");
      }
    });

  //
  // Registration button
  Stream<bool> get registerValid => Observable.combineLatest3(
                                      email, 
                                      password, 
                                      confirmPassword, 
                                      (e, p, c) => true
                                    );

  @override
  void dispose() {
    _emailController?.close();
    _passwordController?.close();
    _passwordConfirmController?.close();
  }
}

複製程式碼

讓我詳細解釋一下......

  • 我們首先初始化3個BehaviorSubject來處理表單的每個TextField的Streams。
  • 我們公開了3個Function(String),它將用於接受來自TextFields的輸入。
  • 我們公開了3個Stream ,TextField將使用它來顯示由它們各自的驗證產生的潛在錯誤訊息
  • 我們公開了1個Stream ,它將被RaisedButton使用,以根據整個驗證結果啟用/禁用它。

好的,現在是時候深入瞭解更多細節......

您可能已經注意到,此類的簽名有點特殊。我們來回顧一下吧。

class RegistrationFormBloc extends Object 
                           with EmailValidator, PasswordValidator 
                           implements BlocBase {
  ...
}
複製程式碼

with 關鍵字意味著這個類是使用混入(MIXINS)(在另一個類中重用一些類程式碼的一種方法),為了能夠使用with關鍵字,該類需要擴充套件Object類。這些mixin包含分別驗證電子郵件和密碼的程式碼。

有關詳細資訊,混入我建議你閱讀從這篇大文章 Romain Rastel

4.1.1. Validator Mixins

我只會解釋EmailValidator,因為PasswordValidator非常相似。

First, the code:

const String _kEmailRule = r"^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$";

class EmailValidator {
  final StreamTransformer<String,String> validateEmail = 
      StreamTransformer<String,String>.fromHandlers(handleData: (email, sink){
        final RegExp emailExp = new RegExp(_kEmailRule);

        if (!emailExp.hasMatch(email) || email.isEmpty){
          sink.addError('Entre a valid email');
        } else {
          sink.add(email);
        }
      });
}
複製程式碼

該類公開了一個 final 函式(“ validateEmail ”),它是一個StreamTransformer。

提醒 StreamTransformer被呼叫如下:stream.transform(StreamTransformer)。 StreamTransformer通過transform方法從Stream引用它的輸入。然後它處理此輸入,並將轉換後的輸入重新注入初始Stream。

4.1.2. 為什麼使用stream.transform()?

如前所述,如果驗證成功,StreamTransformer會將輸入重新注入Stream。為什麼有用?

以下是與Observable.combineLatest3()相關的解釋...此方法在它引用的所有Streams之前不會發出任何值,至少發出一個值。

讓我們看看下面的圖片來說明我們想要實現的目標。

image.png

如果使用者輸入電子郵件並且後者經過驗證,它將由電子郵件流發出,該電子郵件流將是Observable.combineLatest3()的一個輸入; 如果電子郵件地址無效,錯誤將被新增到流(和沒有價值會流出流); 這同樣適用於密碼和重新輸入密碼 ; 當所有這三個驗證都成功時(意味著所有這三個流都會發出一個值),Observable.combineLatest3()將依次發出一個真正的感謝“ (e,p,c)=> true ”(見第35行)。

4.1.3. 驗證2個密碼

我在網際網路上看到了很多與這種比較有關的問題。存在幾種解決方案,讓我解釋其中的兩種。

4.1.3.1.基本解決方案 - 沒有錯誤訊息

第一個解決方案可能是以下一個:

Stream<bool> get registerValid => Observable.combineLatest3(
                                      email, 
                                      password, 
                                      confirmPassword, 
                                      (e, p, c) => (0 == p.compareTo(c))
                                    );
複製程式碼

這個解決方案只需驗證兩個密碼,如果它們匹配,就會發出一個值(= true)。

我們很快就會看到,Register按鈕的可訪問性將取決於registerValid流。

如果兩個密碼不匹配,則該流不會發出任何值,並且“ 註冊”按鈕保持不活動狀態,但使用者不會收到任何錯誤訊息以幫助他理解原因。

4.1.3.2。帶錯誤訊息的解決方案

另一種解決方案包括擴充套件confirmPassword流的處理,如下所示:

Stream<String> get confirmPassword => _passwordConfirmController.stream.transform(validatePassword)
    .doOnData((String c){
      //如果接受密碼(在驗證規則後)
      //我們需要確保密碼和重新輸入的密碼匹配
      if (0 != _passwordController.value.compareTo(c)){
         //如果它們不匹配,請新增錯誤
        _passwordConfirmController.addError("No Match");
      }
    });
複製程式碼

一旦驗證了重新輸入密碼,它就會被Stream發出,並且使用doOnData,我們可以直接獲取此發出的值並將其與密碼流的值進行比較。如果兩者不匹配,我們現在可以傳送錯誤訊息。

4.2. The RegistrationForm

現在讓我們先解釋一下RegistrationForm:

class RegistrationForm extends StatefulWidget {
  @override
  _RegistrationFormState createState() => _RegistrationFormState();
}

class _RegistrationFormState extends State<RegistrationForm> {
  RegistrationFormBloc _registrationFormBloc;

  @override
  void initState() {
    super.initState();
    _registrationFormBloc = RegistrationFormBloc();
  }

  @override
  void dispose() {
    _registrationFormBloc?.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Form(
      child: Column(
        children: <Widget>[
          StreamBuilder<String>(
              stream: _registrationFormBloc.email,
              builder: (BuildContext context, AsyncSnapshot<String> snapshot) {
                return TextField(
                  decoration: InputDecoration(
                    labelText: 'email',
                    errorText: snapshot.error,
                  ),
                  onChanged: _registrationFormBloc.onEmailChanged,
                  keyboardType: TextInputType.emailAddress,
                );
              }),
          StreamBuilder<String>(
              stream: _registrationFormBloc.password,
              builder: (BuildContext context, AsyncSnapshot<String> snapshot) {
                return TextField(
                  decoration: InputDecoration(
                    labelText: 'password',
                    errorText: snapshot.error,
                  ),
                  obscureText: false,
                  onChanged: _registrationFormBloc.onPasswordChanged,
                );
              }),
          StreamBuilder<String>(
              stream: _registrationFormBloc.confirmPassword,
              builder: (BuildContext context, AsyncSnapshot<String> snapshot) {
                return TextField(
                  decoration: InputDecoration(
                    labelText: 'retype password',
                    errorText: snapshot.error,
                  ),
                  obscureText: false,
                  onChanged: _registrationFormBloc.onRetypePasswordChanged,
                );
              }),
          StreamBuilder<bool>(
              stream: _registrationFormBloc.registerValid,
              builder: (BuildContext context, AsyncSnapshot<bool> snapshot) {
                return RaisedButton(
                  child: Text('Register'),
                  onPressed: (snapshot.hasData && snapshot.data == true)
                      ? () {
                          // launch the registration process
                        }
                      : null,
                );
              }),
        ],
      ),
    );
  }
}
複製程式碼

說明:

  • 由於RegisterFormBloc僅供此表單使用,因此適合在此處初始化它。
  • 每個TextField都包裝在StreamBuilder 中,以便能夠響應驗證過程的任何結果(請參閱errorText:snapshot.error)
  • 每次對TextField的內容進行修改時,我們都會通過onChanged傳送輸入到BLoC進行驗證:_registrationFormBloc.onEmailChanged(電子郵件輸入的情況)
  • 對於RegisterButton,後者也包含在StreamBuilder 中。
  • 如果_registrationFormBloc.registerValid發出一個值,onPressed方法將執行某些操作
  • 如果未發出任何值,則onPressed方法將被指定為null,這將取消啟用該按鈕。

而已!表單中沒有任何業務規則,這意味著可以更改規則而無需對錶單進行任何修改,這非常好!

5.Part Of(允許Widget根據其在列表中的存在來調整其行為)

有時,Widget知道它是否是驅動其行為的集合的一部分是有趣的。

對於本文的最後一個用例,我將考慮以下場景:

應用程式處理專案; 使用者可以選擇放入購物籃的物品; 一件商品只能放入購物籃一次; 存放在購物籃中的物品可以從購物籃中取出; 一旦被移除,就可以將其取回。

對於此示例,每個專案將顯示一個按鈕,該按鈕將取決於購物籃中物品的存在。如果不是購物籃的一部分,該按鈕將允許使用者將其新增到購物籃中。如果是購物籃的一部分,該按鈕將允許使用者將其從籃子中取出。

為了更好地說明“ 部分 ”模式,我將考慮以下架構:

一個購物頁面將顯示所有可能的專案清單; 購物頁面中的每個商品都會顯示一個按鈕,用於將商品新增到購物籃或將其移除,具體取決於其在購物籃中的位置; 如果一個專案在購物頁被新增到籃,它的按鈕將自動更新,以允許使用者從所述籃(反之亦然)將其刪除,而不必重新生成購物頁 另一頁,購物籃,將列出籃子裡的所有物品; 可以從此頁面中刪除購物籃中的任何商品。

邊注 Part Of這個名字是我給的個人名字。這不是官方名稱。

正如您現在可以想象的那樣,我們需要考慮一個專門用於處理所有可能專案列表的BLoC,以及購物籃的一部分。

這個BLoC可能如下所示:

class ShoppingBloc implements BlocBase {
  // 所有商品的清單,購物籃的一部分
  Set<ShoppingItem> _shoppingBasket = Set<ShoppingItem>();

  // 流到所有可能專案的列表
  BehaviorSubject<List<ShoppingItem>> _itemsController = BehaviorSubject<List<ShoppingItem>>();
  Stream<List<ShoppingItem>> get items => _itemsController;

  // Stream以列出購物籃中的專案部分
  BehaviorSubject<List<ShoppingItem>> _shoppingBasketController = BehaviorSubject<List<ShoppingItem>>(seedValue: <ShoppingItem>[]);
  Stream<List<ShoppingItem>> get shoppingBasket => _shoppingBasketController;

  @override
  void dispose() {
    _itemsController?.close();
    _shoppingBasketController?.close();
  }

  //建構函式
  ShoppingBloc() {
    _loadShoppingItems();
  }

  void addToShoppingBasket(ShoppingItem item){
    _shoppingBasket.add(item);
    _postActionOnBasket();
  }

  void removeFromShoppingBasket(ShoppingItem item){
    _shoppingBasket.remove(item);
    _postActionOnBasket();
  }

  void _postActionOnBasket(){
    // 使用新內容提供購物籃流
    _shoppingBasketController.sink.add(_shoppingBasket.toList());
    
    // 任何其他處理,如
    // 計算籃子的總價
    // 專案數量,籃子的一部分......
  }

  //
  //生成一系列購物專案
  //通常這應該來自對伺服器的呼叫
  //但是對於這個樣本,我們只是模擬
  //
  void _loadShoppingItems() {
    _itemsController.sink.add(List<ShoppingItem>.generate(50, (int index) {
      return ShoppingItem(
        id: index,
        title: "Item $index",
        price: ((Random().nextDouble() * 40.0 + 10.0) * 100.0).roundToDouble() /
            100.0,
        color: Color((Random().nextDouble() * 0xFFFFFF).toInt() << 0)
            .withOpacity(1.0),
      );
    }));
  }
}
複製程式碼

唯一可能需要解釋的方法是_postActionOnBasket()方法。每次在籃子中新增或刪除專案時,我們都需要“重新整理” _shoppingBasketController Stream 的內容,以便通知所有正在監聽此Stream更改的Widgets並能夠重新整理/重建。

5.2. ShoppingPage

此頁面非常簡單,只顯示所有專案。

class ShoppingPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    ShoppingBloc bloc = BlocProvider.of<ShoppingBloc>(context);

    return SafeArea(
        child: Scaffold(
      appBar: AppBar(
        title: Text('Shopping Page'),
        actions: <Widget>[
          ShoppingBasket(),
        ],
      ),
      body: Container(
        child: StreamBuilder<List<ShoppingItem>>(
          stream: bloc.items,
          builder: (BuildContext context,
              AsyncSnapshot<List<ShoppingItem>> snapshot) {
            if (!snapshot.hasData) {
              return Container();
            }
            return GridView.builder(
              gridDelegate: SliverGridDelegateWithFixedCrossAxisCount(
                crossAxisCount: 3,
                childAspectRatio: 1.0,
              ),
              itemCount: snapshot.data.length,
              itemBuilder: (BuildContext context, int index) {
                return ShoppingItemWidget(
                  shoppingItem: snapshot.data[index],
                );
              },
            );
          },
        ),
      ),
    ));
  }
}
複製程式碼

說明:

  • 所述AppBar顯示按鈕,: 顯示出現在購物籃中的商品數量 單擊時將使用者重定向到ShoppingBasket頁面
  • 專案列表使用GridView構建,包含在StreamBuilder <List >中
  • 每個專案對應一個ShoppingItemWidget

5.3.ShoppingBasketPage

此頁面與ShoppingPage非常相似,只是StreamBuilder現在正在偵聽由ShoppingBloc公開的_shoppingBasket流的變體。

5.4. ShoppingItemWidget和ShoppingItemBloc

Part Of 模式依賴於這兩個元素的組合

  • 該ShoppingItemWidget負責: 顯示專案和 用於在購物籃中新增專案或從中取出專案的按鈕
  • 該ShoppingItemBloc負責告訴ShoppingItemWidget後者是否是購物籃的一部分,或者不是。 讓我們看看他們如何一起工作......
5.4.1. ShoppingItemBloc

ShoppingItemBloc由每個ShoppingItemWidget例項化,賦予它“身份”

此BLoC偵聽ShoppingBasket流的所有變體,並檢查特定專案標識是否是籃子的一部分。

如果是,它會發出一個布林值(= true),它將被ShoppingItemWidget捕獲,以確定它是否是籃子的一部分。

這是BLoC的程式碼:

class ShoppingItemBloc implements BlocBase {
   // Stream,如果ShoppingItemWidget是購物籃的一部分,則通知
  BehaviorSubject<bool> _isInShoppingBasketController = BehaviorSubject<bool>();
  Stream<bool> get isInShoppingBasket => _isInShoppingBasketController;

  //收到所有商品列表的流,購物籃的一部分
  PublishSubject<List<ShoppingItem>> _shoppingBasketController = PublishSubject<List<ShoppingItem>>();
  Function(List<ShoppingItem>) get shoppingBasket => _shoppingBasketController.sink.add;

   //具有shoppingItem的“標識”的構造方法
  ShoppingItemBloc(ShoppingItem shoppingItem){
    //每次購物籃內容的變化
    _shoppingBasketController.stream
                           //我們檢查這個shoppingItem是否是購物籃的一部分
                         .map((list) => list.any((ShoppingItem item) => item.id == shoppingItem.id))
                          // if it is part
                         .listen((isInShoppingBasket)
                              // we notify the ShoppingItemWidget 
                            => _isInShoppingBasketController.add(isInShoppingBasket));
  }

  @override
  void dispose() {
    _isInShoppingBasketController?.close();
    _shoppingBasketController?.close();
  }
}
複製程式碼
5.4.2。ShoppingItemWidget

此Widget負責:

  • 建立ShoppingItemBloc的例項並將其自己的標識傳遞給BLoC
  • 監聽ShoppingBasket內容的任何變化並將其轉移到BLoC
  • 監聽ShoppingItemBloc知道它是否是籃子的一部分
  • 顯示相應的按鈕(新增/刪除),具體取決於它在籃子中的存在
  • 響應按鈕的使用者操作 當使用者點選新增按鈕時,將自己新增到購物籃中 當使用者點選刪除按鈕時,將自己從籃子中移除。

讓我們看看它是如何工作的(解釋在程式碼中給出)。

class ShoppingItemWidget extends StatefulWidget {
  ShoppingItemWidget({
    Key key,
    @required this.shoppingItem,
  }) : super(key: key);

  final ShoppingItem shoppingItem;

  @override
  _ShoppingItemWidgetState createState() => _ShoppingItemWidgetState();
}

class _ShoppingItemWidgetState extends State<ShoppingItemWidget> {
  StreamSubscription _subscription;
  ShoppingItemBloc _bloc;
  ShoppingBloc _shoppingBloc;

  @override
  void didChangeDependencies() {
    super.didChangeDependencies();

    //由於不應在“initState()”方法中使用上下文,
    //在需要時更喜歡使用“didChangeDependencies()”
    //在初始化時引用上下文
    _initBloc();
  }

  @override
  void didUpdateWidget(ShoppingItemWidget oldWidget) {
    super.didUpdateWidget(oldWidget);

    //因為Flutter可能決定重新組織Widgets樹
    //最好重新建立連結
    _disposeBloc();
    _initBloc();
  }

  @override
  void dispose() {
    _disposeBloc();
    super.dispose();
  }

   //這個例程對於建立連結是可靠的
  void _initBloc() {
    //建立ShoppingItemBloc的例項
    _bloc = ShoppingItemBloc(widget.shoppingItem);

    //檢索處理購物籃內容的BLoC 
    _shoppingBloc = BlocProvider.of<ShoppingBloc>(context);

     //傳輸購物內容的簡單管道
    //購物籃子到ShoppingItemBloc
    _subscription = _shoppingBloc.shoppingBasket.listen(_bloc.shoppingBasket);
  }

  void _disposeBloc() {
    _subscription?.cancel();
    _bloc?.dispose();
  }

  Widget _buildButton() {
    return StreamBuilder<bool>(
      stream: _bloc.isInShoppingBasket,
      initialData: false,
      builder: (BuildContext context, AsyncSnapshot<bool> snapshot) {
        return snapshot.data
            ? _buildRemoveFromShoppingBasket()
            : _buildAddToShoppingBasket();
      },
    );
  }

  Widget _buildAddToShoppingBasket(){
    return RaisedButton(
      child: Text('Add...'),
      onPressed: (){
        _shoppingBloc.addToShoppingBasket(widget.shoppingItem);
      },
    );
  }

  Widget _buildRemoveFromShoppingBasket(){
    return RaisedButton(
      child: Text('Remove...'),
      onPressed: (){
        _shoppingBloc.removeFromShoppingBasket(widget.shoppingItem);
      },
    );
  }

  @override
  Widget build(BuildContext context) {
    return Card(
      child: GridTile(
        header: Center(
          child: Text(widget.shoppingItem.title),
        ),
        footer: Center(
          child: Text('${widget.shoppingItem.price} €'),
        ),
        child: Container(
          color: widget.shoppingItem.color,
          child: Center(
            child: _buildButton(),
          ),
        ),
      ),
    );
  }
}
複製程式碼

5.5. 這一切如何運作?

下圖顯示了所有部分如何協同工作。

image.png

結論

另一篇長篇文章,我希望我能縮短一點,但我認為值得一些解釋。

正如我在介紹中所說,我個人在我的開發中經常使用這些“ 模式 ”。這讓我節省了大量的時間和精力; 我的程式碼更易讀,更容易除錯。

此外,它有助於將業務與檢視分離。

大多數肯定有其他方法可以做到這一點,甚至更好的方式,但它只對我有用,這就是我想與你分享的一切。

請繼續關注新文章,同時祝您程式設計愉快。

相關文章