what is the difference between running a method before super.initState() and after super.initState()
#override
void initState() {
super.initState();
getCurrentUser();
}
#override
void initState() {
getCurrentUser();
super.initState();
}
Explanation for framework: Dart is class based object oriented programming language, so when you build a widget you extend it from a base class StatelessWidget or StatefulWidget. initState is lifecycle method in flutter widget (as you might know) which is only available to override in StatefulWidgets and it called only once. So, it call initState of base class which is StatefulWidget thats why you call super.initState()which in turn creates BuildContext and attached State.
Now your question: I didn't find anything different in calling a method before or after super.initState(). Event I tried adding addPostFrameCallback before super.initState() and it worked fine.
Even super.mounted is also true in both cases.
Suggestion
Dart/Flutter documentation "suggests" to call super.initState() as first method before your body implementation.
But if we look at how it is implemented Documentation
#protected
#mustCallSuper
void initState() {
assert(_debugLifecycleState == _StateLifecycle.created);
}
it's possible to see that it contains only an assert(). the assert built-in function it's called only in DEBUG mode, not in production mode. So, at the end of the day, it really doesn't matter, because the super.initState() would practically do nothing.
Related
Im using getx and i want to call api after bage build, because this api its not necessary part of the page build.. What i know is this way
#override
void initState(){
super.initState();
WidgetsBinding.instance.addPostFrameCallback((_){
});
}
But what about getx best way ?
the Getx package offers lifecycle methods that are very convenient in you're cases, what you need here is to use the onReady(), which is called one frame after the onInit() is executed, you can say that its equivalent to the:
#override
void initState(){
super.initState();
WidgetsBinding.instance.addPostFrameCallback((_){
// Here is the code which will be executed exactly after initState using StatefulWidget
});
}
you can use onReady() like this:
class TextController extends GetxController {
#override
void onInit() {
/*...*/
}
void onReady() {
// Here is the code which will be executed exactly after onInit using Getx
}
}
I see people usually initialize the controller like this, initializing it in initState() method.
late VideoPlayerController _videoPlayerController;
#override
void initState() {
super.initState();
_videoPlayerController = VideoPlayerController.network(
"https://assets.mixkit.co/videos/preview/mixkit-spinning-around-the-earth-29351-large.mp4");
}
but then I realize if I just put the controller like this without initState()just put the controller after the variables with late in before the variables, everything works fine. So what is the difference?
class _VideoDetailScreenState extends State<VideoDetailScreen> {
late VideoPlayerController _videoPlayerController = VideoPlayerController.network(
"https://assets.mixkit.co/videos/preview/mixkit-spinning-around-the-earth-29351-large.mp4");
As from the official documentation:
The framework calls initState. Subclasses of State should override initState to perform one-time initialization that depends on the BuildContext or the widget, which are available as the context and widget properties, respectively, when the initState method is called.
I had an error every time I restarted my App: This widget has been unmounted, so the State no longer has a context (and should be considered defunct). and saw that something was not correct with my initstate. The initState was:
#override
void initState() {
SchedulerBinding.instance.addPostFrameCallback((_) {
BlocProvider.of<TutSkippedCubit>(context).load();
});
super.initState();
}
the methods loads the data from sharedprefs if I have already skipped the tut or not. Now I solved this issue with removing the initState method and putting the function call inside the widget build:
#override
Widget build(BuildContext context) {
BlocProvider.of<TutSkippedCubit>(context).load();
....
The widget build gets called when the pages loads, so, isn't it the same as the initial state? For what exactly is the methode initState() and I have the feeling that my way of handling this problem is a bad practise, but what would be a better way, how do I solve it?
The initState() method is to control what happens after the app is built. The problem is that you call BlocProvider before the app begins. The correct way is to put all the actions after super.initState() call and add the context to the BlocProvider inside build method. Like this:
TutSkippedCubit? tutSkippedCubitProvider;
#override
void initState() {
super.initState();
SchedulerBinding.instance.addPostFrameCallback((_) {
tutSkippedCubitProvider!.load();
});
}
#override
Widget build(BuildContext context) {
tutSkippedCubitProvider = BlocProvider.of<TutSkippedCubit>(context);
...
}
The initState and build method is called when the widget is inserted into the widget tree, but the build method also is called every time the state is changed.
You do need to have in mind that every time the state is changed your method BlocProvider.of<TutSkippedCubit>(context).load(); also is called.
Maybe, the code below can help you:
WidgetsBinding.instance.endOfFrame.then(
(_) async {
if (mounted) {
BlocProvider.of<TutSkippedCubit>(context).load();
}
},
);
You wouldn't be surprise of getting that error since you are using BlocProvider.<T>(context) out of a BuildContext. This context in bracket is the just the same as the one given in the build function.
The initState() is a method that is called when an object for your
stateful widget is created and inserted inside the widget tree.
I am new to Getx's dependency injection, so can some one explain to me the benefits of Get.put() and Get.lazyPut() and tell me also what difference they have?
Short answer
Get.put() will put immediately
Get.lazyPut() will put when you need it
To my understanding put already puts an instance of the class directly in memory while lazyPut just puts a builder for it in it.
A benefit of lazyPut is that it saves memory until you actually find it. And you can also put more complex code in the builder for it. Another benefit of lazyPut is that you can also say fenix: true on it which means it's able to be reconstructed in case it got disposed of before.
I would think the only benefit of using put is that find should be slightly faster then when called because it doesn't need to call a builder first to get the instance. I don't know if there are other benefits.
In the case of lazyPut, it only creates the instance, and it'll be instantiated only when is used, check more details here
Get.put() :
Will inject a dependency and start executing immediately when it's injected, and I mean with that that its lifecycle methods like onInit() and onReady() will execute when you inject it like this:
class ControllerOne extends GetxController {
int a = 1;
#override
void onInit() {
print('ControllerOne onInit');
super.onInit();
}
#override
void onReady() {
print('ControllerOne onReady');
super.onReady();
}
}
final controller = Get.put(ControllerOne()); // will inject that dependecy, and immediately will call onInit() method then onReady() method
Debug log:
ControllerOne onInit
ControllerOne onReady
Get.lazyPut() :
will also inject a dependency, but it will not start executing the lifecycle methods onInit() and onReady() until you will really use that controller:
class ControllerTwo extends GetxController {
int b = 2;
#override
void onInit() {
print('ControllerTwo onInit');
super.onInit();
}
#override
void onReady() {
print('ControllerTwo onReady');
super.onReady();
}
}
final controller = Get.lazyPut(() => ControllerTwo()); // will inject that dependecy, and wait until it's used then it will call onInit() method, then onReady() method
Debug log:
/* nothing will be printed right now */
but if we do use the controller, as an example:
controller.b = 10;
then the controller will start running will start:
Debug log:
ControllerTwo onInit
ControllerTwo onReady
Hope this clarifies it!
Should the code that is being written to initState() function be written before super.initState(); or after?
Which one is proper:
#override
// code here
super.initState();
}
or
#override
super.initState();
// code here
}
both will work.
But if you see from any dependencies or official docs flutter, write your code in initSate() after super.initState();
#overrride
initState(){
super.initState()
//your code
}
reference to this initState
the opposite for dispose(), write your code before super.dispose();
#overrride
dispose(){
//your code
super.dispose()
}
reference to dispose
When I see #Kahoo answer, I check it by cmd + click at super.dispose and super.initstate, I found this for dispose
/// 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].
#protected
#mustCallSuper
void dispose() {
assert(_debugLifecycleState == _StateLifecycle.ready);
assert(() {
_debugLifecycleState = _StateLifecycle.defunct;
return true;
}());
}
abstract class State :
/// If you override this, make sure your method starts with a call to
/// super.initState().
#protected
#mustCallSuper
void initState() {
assert(_debugLifecycleState == _StateLifecycle.created);
}
Both will work fine, but the better practise is to write before super.initState(), because it will do all the initialisations before creating the state widget which will help you in maintaining the check on the Widget State.
But this does not means that the second method will not keep close eye on maintaining the state, But as of better practise the First way is preferred.