Reputation: 1196
Flutter provides two distinct solutions for observing app lifecycle changes: AppLifecycleListener and WidgetsBindingObserver.
AppLifecycleListener and WidgetsBindingObserver. Given these two options, when should I use AppLifecycleListener vs. WidgetsBindingObserver? What are the specific use cases for each, and what are the key differences I should consider when choosing between them?
This Answer dont provide any difference between them or use case about it
Upvotes: 0
Views: 29
Reputation: 7117
WidgetsBindingObserver
is a class that you can register in WidgetsBinding
, which is a glue between the widgets layer and the Flutter engine. It allows you to write code that will be done when some of the concepts managed by this binding change, or some action is invoked. That's pretty low-level as far as the framework goes. You need to manually register and unregister the observer to the binding when appropriate.
The AppLifecycleListener
on the other hand is a more high-level thing. It's an abstraction over the WidgetsBindingObserver
that you're supposed to instantiate rather than mix-in. It also hides the global binding instance used away (unless you pass it to the constructor) and lets you dispose it using an instance method.
AppLifecycleListener
gives you the ability to react to state changes (you get a new state in parameter of onStateChange
) and also to transitions from one state to the other (all the other constructor params). If you want to react only on lifecycle states or their transitions - this is the way to go.
If you also want to listen to other engine-related changes, like the platform brightness or the accessibility text scale, you'd need to use WidgetsBindingObserver
.
Under the hood, the former uses the latter and it is nothing more than an abstraction giving you a cleaner interface for the subset of widgets binding stuff.
Upvotes: 0