The current implementation ties the subscription to current chain's JSON-RPC responses to the home page (see here).
We should extract the light client -related logic into a separate component, that could provide the light client data to multiple UI widgets.
Worth mentioning, on the Rust side, the listen_json_rpc_responses function is blocking, and can only be called by one consumer at a time, because it is mutating a data stream that is held in a static context.
Therefore, on the Flutter side, the JSON-RPC responses should probably be exposed as Broadcast stream, to allow multiple concurrent subscriptions from more than one UI widget.
And the component encapsulating the light client logic can be exposed to various parts of the app using simple app state management techniques (e.g. Provider package), or more complex ones (e.g. Redux, MVVM, etc).
The current implementation ties the subscription to current chain's JSON-RPC responses to the home page (see here). We should extract the light client -related logic into a separate component, that could provide the light client data to multiple UI widgets.
Worth mentioning, on the Rust side, the
listen_json_rpc_responsesfunction is blocking, and can only be called by one consumer at a time, because it is mutating a data stream that is held in a static context.Therefore, on the Flutter side, the JSON-RPC responses should probably be exposed as Broadcast stream, to allow multiple concurrent subscriptions from more than one UI widget.
And the component encapsulating the light client logic can be exposed to various parts of the app using simple app state management techniques (e.g. Provider package), or more complex ones (e.g. Redux, MVVM, etc).
Some useful links