Struct ServicesBinding 

pub struct ServicesBinding { /* private fields */ }

Hands the host’s lifecycle messages to the scheduler and the layers above, answers the host’s requests to exit the application, and asks the host to exit it.

Implementations

impl ServicesBinding

pub fn instance(app: &mut App) -> Handle<ServicesBinding>

The current ServicesBinding, created on first use.

Creating it reads the lifecycle state the host started in, as Dart’s initInstances does.

pub fn clipboard(self: Handle<Self>, app: &App) -> Handle<ChangeNotifierData>

Listenable that notifies when another app has changed what is on the clipboard, or a copy of this app’s expired and was cleared, as far as the host can tell (EmbedderClient::clipboard_changed). The app’s own writes are not told, but where the host’s system does not tell them apart, as a browser’s does not.

What shows whether the clipboard can be pasted, such as a toolbar’s Paste button, should listen to this and look again.

pub fn handle_clipboard_changed(self: Handle<Self>, app: &mut App)

Notifies clipboard: the host says what is on the clipboard changed.

pub fn set_overrides( self: Handle<Self>, app: &mut App, overrides: Rc<dyn ServicesBindingOverrides>, )

Registers the binding layered above this one, as Flutter’s WidgetsBinding does by overriding handleRequestAppExit.

pub fn read_initial_lifecycle_state_from_native_window( self: Handle<Self>, app: &mut App, )

Initializes the SchedulerBinding::lifecycle_state with the Platform::initial_lifecycle_state.

Once the lifecycle state is populated through any means (including this method), this method will do nothing. This is because the Platform::initial_lifecycle_state may already be stale and it no longer makes sense to use the initial state at startup as the current state anymore.

The latest state should be obtained by subscribing to WidgetsBindingObserver::did_change_app_lifecycle_state.

pub fn handle_lifecycle_message( self: Handle<Self>, app: &mut App, state: AppLifecycleState, )

Handles a lifecycle state the host reports: Dart’s _handleLifecycleMessage, which SystemChannels.lifecycle calls with the state’s name, and which the host reaches through EmbedderClient::app_lifecycle_state_changed. The states between the one the app is in and state are handled first, in order.

pub fn handle_request_app_exit( self: Handle<Self>, app: &mut App, ) -> Task<AppExitResponse>

Handles any requests for application exit that the host sends through EmbedderClient::request_app_exit.

By default, returns AppExitResponse::Exit.

Not all exits are cancelable, so not all exits will call this function. Do not rely on this function as a place to save critical data, because you will be disappointed. There are a number of ways that the application can exit without letting the application know first: power can be unplugged, the battery removed, the application can be killed in a task manager or command line, or the device could have a rapid unplanned disassembly (i.e. it could explode). In all of those cases (and probably others), no notification will be given to the application that it is about to exit.

See also:

• WidgetsBindingObserver::did_request_app_exit, which can be overridden to respond to this message.
• WidgetsBinding’s override of this method, which notifies its observers.

pub fn exit_application( self: Handle<Self>, app: &App, exit_type: AppExitType, exit_code: i32, ) -> Task<AppExitResponse>

Exits the application by calling the native application API method for exiting an application cleanly.

This differs from calling std::process::exit in that it gives the engine a chance to clean up resources so that it doesn’t crash on exit, so calling this is always preferred over calling std::process::exit. It also optionally gives handlers of handle_request_app_exit a chance to cancel the application exit.

The exit_type indicates what kind of exit to perform. For AppExitType::Cancelable exits, the application is queried through a call to handle_request_app_exit, where the application can optionally cancel the request for exit. If the exit_type is AppExitType::Required, then the application exits immediately without querying the application.

For AppExitType::Cancelable exits, the returned response value is the response obtained from the application as to whether the exit was canceled or not. Practically, the response will never be AppExitResponse::Exit, since the application will have already exited by the time the result would have been received.

The exit_code argument will be used as the application exit code on platforms where an exit code is supported. On other platforms it may be ignored. Dart’s default is zero.

Flutter’s engine asks the framework back for a cancelable exit. Here the framework asks itself, on a later turn as the engine’s request would come, and only a decided exit reaches the host, as AppExit::quit; a host that cannot quit cancels every exit.

See also:

• WidgetsBindingObserver::did_request_app_exit for a handler you can override on a WidgetsBindingObserver to receive exit requests.

Trait Implementations

impl Default for ServicesBinding

fn default() -> Self

Returns the “default value” for a type.