I'm involved with the FlutterSound project which is shipped as a package containing an api that, for the purposes of this question, doesn't contain a widget.
The api needs to handle events when the application changes its state (AppLifecycleState.pause/resume). (we need to stop/resume audio when the app is paused/resumed).
I can see how to do this in a widget using WidgetsBindingObserver but the api needs this same info without having to rely on a widget.
The SchedulerBinding class has a method handleAppLifecycleStateChanged which seems to provide the required info but its unclear how to implement this outside of a widget.
Below is a code sample that can listen to AppLifecycleState change events without directly involving a widget:
import 'package:flutter/material.dart';
class MyLibrary with WidgetsBindingObserver {
AppLifecycleState _state;
AppLifecycleState get state => _state;
MyLibrary() {
WidgetsBinding.instance.addObserver(this);
}
/// make sure the clients of this library invoke the dispose method
/// so that the observer can be unregistered
void dispose() {
WidgetsBinding.instance.removeObserver(this);
}
#override
void didChangeAppLifecycleState(AppLifecycleState state) {
this._state = state;
}
void someFunctionality() {
// your library feature
}
}
Now you can instantiate the library in a flutter widget, for instance, from which point it will start listening to any change in AppLifecycleState.
Please note that, the above code doesn't take care of redundant bindings. For example, if the client of your library is meant to initialize the library more than once in different places, the didChangeAppLifecycleState() method will be triggered multiple times per state change (depending on the number of instances of the library that were created). Also I'm unsure whether the solution proposed conforms to flutter best practices. Nevertheless it solves the problem and hope it helps!
Related
The official Mobx documentation for Flutter says that in order to transfer data correctly, you must use a Provider and refer to the context to retrieve the data.
But why can't I just call the Mobx class at the root of the application and access the global variable to get the data?
CbtStore cbt = CbtStore();
void main() async {
runApp(const MyApp());
}
Why should I be doing this?
void main() async {
runApp(MultiProvider(
providers: [
Provider<CbtStore>(create: (_) => CbtStore()),
],
child: MyApp()));
}
And how do I refer to Mobx inside the widget methods in that case, for example, if I want to call the action in the Mobx class in initState method? Now I do it in the following way. But when using Provider in initState there is no context.
#override
void initState() {
cbt.init();
super.initState();
}
Provider is used only for dependency injection with mobx. It is not used for state changes.
Now when you are using mobx you don't need a stateful widget in most cases because you are handling your state changes inside your mobx store and if there is any changes in the state we use Observer to change ui.
if want something to initialise with the screen than prefer using constructor of mobx class rather then initState.
for example,
class MyStore = _MyStore with _$MyStore;
abstract class _MyStore with Store {
_MyStore(){
getData();
}
}
Now don't use global providers for your all of store. Only Initialise a provider whenever you need it. So when you push a route wrap it with a provider so that Provider.of(context); can find it. Only use global store if it required globally.
You mentioned creating an instance of store to use it. When you initialise a store in stateless widget it, the data will get destroyed when you close the screen and when you reopen it everything will start all over again. It is useful when you don't need to maintain state after screen pops. It will based on your use case.
You should do what works best for your use case.
The reason why providers are useful is that they can be provided where needed. This could be in the application root, but also somewhere deeper in the widget tree.
Another advantage of the providers is that you can have a provider that notifies listeners. Widgets will rebuild automatically in this case, which can be useful if you have stored and need data to update everywhere in the application.
The initState does indeed not allow the use of providers directly. There are 3 solutions for this:
Don't have the provider listing (Provider.of(context, listen: false); This allows you to use the methods, but not listen to changes.
Use the provider in the build method, using the consumer.
I am by no means an expert on flutter, but this is just what I have experienced so far.
I'm working on an app that accesses two api's that contain location data that updates regularly (every 5 seconds or so). I want to utilize flutter and flutter_bloc to manage my state, but I'm not sure where the interval would come into play. I understand bloc and how the ui interacts with it with BlocBuilder and BlocProvider, as well as providing a repository that handles the api calls. What I'm not sure about is where to put the interval/timer. My idea was to do a normal bloc setup:
class DataBloc extends Bloc<DataEvent, DataState> {
//constructor
#override
Stream<DataState> mapEventToState(DataEvent event) async* {
if (event is FetchData) {
var data = repository.getData();
yield* _mapFetchDataToState(data);
}
}
}
In the ui:
class MainPage extends StatelessWidget {
#override
Widget build(BuildContext context) {
final dataBloc = BlocProvider.of<DataBloc>(context);
Timer.periodic(fiveSeconds, (Timer t) => dataBloc.add(FetchData()));
return ui stuff
}
}
But I'm not sure if this is the right way to leverage BLoCs and/or timers. But I basically need to call the api on an interval and then have the data update in my ui without a full refresh of all the widgets. They're going to be icons on a google map, and I want the icons to update their locations when the data I pull is updated. How can I accomplish this? For reference, I've looked at the flutter_bloc docs for the timer app here and I thought it was a little overkill and that my idea above was simpler, just not sure if this is the right way. I'm pretty new to flutter so any help would be appreciated.
I'd recomend not to put initializing code inside build. Make it a StatefulWidget and add a dispose method to clear the timer. And inside initState setup the timer.
There's no right way in programming. There are best practices, so as long as it work for your use case is ok.
I would either put the timer into the bloc/cubit because its part of your logic and not of your ui.
Or if you use a repository I would probably use a stream listen to it in your bloc and periodically update the stream in your repo.
But any better suggestions are more than welcome, because I am also looking for some kind of 'the way to do'...
I am building a flutter app and I need to call a method in a provider when the app goes into background.
I can easily do this by creating a Stateful Widget using the WidgetsBindingObserver (like the example here).
Is there a way to do this without needing a Stateful Widget? Provider is a great architecture and state is an anti-pattern.
Possibly, You could try creating a class that isn't a widget and extending WidgetsBindingObserver.
Something like this perhaps
class MyListener extends WidgetsBindingObserver {
MyListener({this.providerInstance}){
WidgetsBinding.instance.addObserver(this);
};
MyProvider providerInstance;
#override
void didChangeAppLifecycleState(AppLifecycleState state) {
providerInstance.doSomethingWithState(state)
}
}
Then implement the listener say in main() or yourApp() where ever your Provider setup is.
Thing is, there really isn't any issue with having a stateful widget at the root of your app somewhere as in the example. I honestly don't think your Anti pattern argument holds any relevance. Its common practice in flutter to have statefull and not statefull widgets.
By not having the statefull widget your just having to keep the state somewhere else, i.e. where ever it is your configuring your providers.
Why are we using dispose() method? I'm little confused about it.
what will be issue occurs If we don't use it and what's the benefit of using it?
#override
void dispose() {
// TODO: implement dispose
super.dispose();
}
dispose method used to release the memory allocated to variables when state object is removed.
For example, if you are using a stream in your application then you have to release memory allocated to the stream controller. Otherwise, your app may get a warning from the PlayStore and AppStore about memory leakage.
dispose() method called automatically from stateful if not defined.
In some cases dispose is required for example in CameraPreview, Timer etc.. you have to close the stream.
When closing the stream is required you have to use it in dispose method.
dispose() is used to execute code when the screen is disposed. Equal to onDestroy() of Android.
Example:
#override
void dispose() {
cameraController?.dispose();
timer.cancel();
super.dispose();
}
The main purpose is to get a callback where in you can free-up all your resources.
If you have initialized any resource in a State, it is important that you close or destroy that resource when that state is disposed.
For e.g: If you are creating a stream in initState of your StatefullWidget, then it is important that you close that stream in dispose method of that state or else it will cause memory leak.
For more details you can refer following comments which I got from the source code of the dispose method of the StatefulWidget:
Called when this object is removed from the tree permanently. The
framework calls this method when this [State] object will never build
again. After the framework calls [dispose], the [State] object is
considered unmounted and the [mounted] property is false. It is an
error to call [setState] at this point. This stage of the lifecycle is
terminal: there is no way to remount a [State] object that has been
disposed. Subclasses should override this method to release any
resources retained by this object (e.g., stop any active animations).
{#macro flutter.widgets.subscriptions} If you override this, make sure
to end your method with a call to super.dispose(). See also: *
[deactivate], which is called prior to [dispose].
Or you can refer the docs: https://api.flutter.dev/flutter/widgets/State/dispose.html
So basically dispose is called when that current state will never be used again. So, if you are having any listeners that are active in that state then they can cause memory leaks and so you should close them.
dispose() method is called when this object is removed from the tree permanently.
For more information, you can refer official Docs: https://api.flutter.dev/flutter/widgets/State/dispose.html
Implementation Example:
#protected
#mustCallSuper
void dispose() {
assert(_debugLifecycleState == _StateLifecycle.ready);
assert(() {
_debugLifecycleState = _StateLifecycle.defunct;
return true;
}());
}
In general terms dispose means freeing the resources before the related object is removed from the focus. By focus, I mean from widget tree or navigation stack whichever is relevant.
When you call dispose on a widget state, the associated widget is supposed to be unmounted which means the widget will never rebuild.
Called when this object is removed from the tree permanently.
The framework calls this method when this State object will never build again.
After the framework calls dispose, the State object is considered unmounted and the mounted
property is false. It is an error to call setState at this point.
This stage of the lifecycle is terminal: there is no way to remount a State object that has been
disposed.
When you call dispose on a bloc, the bloc is supposed to be closing the event and state stream.
Update: New Bloc does not have dispose, instead it has close.
So, This is what dispose basically means.
TL;DR
In general, it means releasing the resources held by the associated instance/object.
The specific meaning of dispose, however, changes with the types of the object on which this method is called.
Well, the answer is in the word dispose of. so imagine you are at a party and there is a table where glasses of water are placed which are plastic glasses. Now you will get one glass use it and dispose (throw it into the dustbin). if you don't do that you place the same glass on the table then there will be no place for other new glasses to be put(memory error). Because the table is full now. The second thing is if you put a glass on the table it's possible there might some drink is left. so if someone else uses that glass then there will be something in it already. (controller already having some value if you don't dispose and the same form or animation controller on the same screen).
happy scene:- all take glasses of drink and dispose them into dustbin so all table will also get space and everybody will get new drink not the old drink of someone.
Practical where I got to know the accurate use- I made a screen where inline editing was needed means you click the button all text converts into text form fields and you change the required values and press that button again to submit(icon change of the same button on editing),
So the word dispose expose everything about its use I hope this real-life example will help a little bit. Thank you
void dispose() {
super.dispose();
_editButtonAnimationController.dispose();
_ageController.dispose();
}
You should not only override dispose method to free up some memory but also to dispose those objects that would otherwise be visible on the screen like a BannerAd.
Say, you have a BannerAd and you don't dispose the instance of bannerAd and navigate back to the previous page, your ad would still be visible on the screen which you don't want. So, you must dispose it like:
#override
void dispose() {
bannerAd?.dispose();
super.dispose();
}
Given all the answers above regarding garbage collection and examples of what to put in dispose(), it seems like the general idea is to dispose/cancel anything that has a future or is tied to hardware access, because you don't want to return to a non-existent object or to block other apps from using that resource (ex.camera, file system, microphone, etc.).
We uses dispose() method in order to stop/avoid memory linkage when state object is removed from the widget tree.
In the documentation it is written but I am not able to understand it.
Called when this object is inserted into the tree.
The framework will call this method exactly once for each State object it creates.
Override this method to perform initialization that depends on the location at which this object was inserted into the tree (i.e., context) or on the widget used to configure this object (i.e., widget).
If a State's build method depends on an object that can itself change state, for example a ChangeNotifier or Stream, or some other object to which one can subscribe to receive notifications, then the State should subscribe to that object during initState, unsubscribe from the old object and subscribe to the new object when it changes in didUpdateWidget, and then unsubscribe from the object in dispose.
You cannot use BuildContext.inheritFromWidgetOfExactType from this method. However, didChangeDependencies will be called immediately following this method, and BuildContext.inheritFromWidgetOfExactType can be used there.
If you override this, make sure your method starts with a call to super.initState().
But I'm not sure about its meaning. Can you explain it?
Credit to #Remi, initState() is a method which is called once when the stateful widget is inserted in the widget tree.
We generally override this method if we need to do some sort of initialisation work like registering a listener because, unlike build(), this method is called once.
And to unregister your listener (or doing some post work), you override dispose()method.
From here
A subclass of State can override initState to do work that needs to happen just once. For example, override initState to configure animations or to subscribe to platform services. Implementations of initState are required to start by calling super.initState
When a state object is no longer needed, the framework calls dispose() on the state object. Override the dispose function to do cleanup work. For example, override dispose to cancel timers or to unsubscribe from platform services. Implementations of dispose typically end by calling super.dispose
Uses of initState()
initState() is a method of class State and it is considered as an important lifecycle method in Flutter. initState() is called only Once and we use it for one time initializations.
Example :
To initialize data that depends on the specific BuildContext.
To initialize data that needs to executed before build().
Subscribe to Streams.
Thank you for the answers, but I will also reiterate what the guys above have state
#overrride
initState() { // this is called when the class is initialized or called for the first time
super.initState(); // this is the material super constructor for init state to link your instance initState to the global initState context
}
Please allow me to quote the content written by others. I think his explanation is excellent.
https://www.geeksforgeeks.org/flutter-initstate/
There are two types of widgets provided in Flutter.
The Stateless Widget
The Stateful Widget
As the name suggests Stateful Widgets are made up of some ‘States’. The initState() is a method that is called when an object for your stateful widget is created and inserted inside the widget tree. It is basically the entry point for the Stateful Widgets. initState() method is called only and only once and is used generally for initializing the previously defined variables of the stateful widget. initState() method is overridden mostly because as mentioned earlier it is called only once in its lifetime. If you want to trigger it again you have to shift the control to an entirely new screen and a new state.