I just have read about "const" widget allocation in build method, so in this scenario, widgets get allocated when the app starts, how they stores and where?. Do they increase apps size?
How compiled Flutter widgets are stored and where?
Flutter application is AOT-compiled (ahead-of-time) to native platform code. Each Flutter widget is compiled to native widgets and they are rendered to Skia canvas which is shown to the end user platform. Platform sends back all events which are than handled by compiled Flutter code.
I do highly recommend to check those articles:
https://github.com/flutter/flutter/wiki/The-Engine-architecture
https://medium.com/47billion/flutter-how-does-it-works-6e4c73842e67
When to use const widgets in Flutter?
Use const widgets where possible in StatefullWidget
Why? Simply remember that calling StatefullWidget setState will rebuild the whole widget. By specifying const for the child widgets of StatefullWidget you'll say that they do not need to be rebuilt on setState call.
Here is the link to official documentation:
https://api.flutter.dev/flutter/widgets/StatefulWidget-class.html#performance-considerations
Regarding whether they increase app size:
I believe Dart 2.0 made const optional, that is, the compiler will mark it as const on its own given the right context. Here are a few resources that point to this:
"Don't use const redundantly" - Effective Dart Usage
"Dart 2 introduces optional new and const" - Announcing Dart 2.0
So, if the compiler does this automatically, I think it's safe to assume that there won't be a compromise on app/size performance. I hope this answers your question.
Related
I have a flutter widget ProgressBar, which needs to be notified when a change happens to a value in Flame,
I followed a tutorial which is using overlays.notifyListeners(); to update the StatelessWidget progressBar, but after I updated to the newest Flame version (v1.6.0), this method can not be used anymore, what is the correct way of doing this now?
There are a few different ways to do this, either you can use state management libraries like flame_riverpod or flame_bloc to achieve this, or you can wrap your value in a ChangeNotifier/ValueNotifier and update the state once the value updates.
I have 4 widgets named OptionCard (it's their Type) i'de like to iterate through them to check the value of their variables how can I do it ?
tried OptionCard.forEach but it doesn't work
This is not the way Flutter widgets are supposed to be used. Widgets (even StatefulWidgets) generally do not hold application state. They should only provide a view on state managed elsewhere.
There are many proven methods of application state management that are popular and well supported in Flutter.
I have a flutter application which uses a MultiProvider widget at the root of the widgets tree.
The problem is, I need to add a ChangeNotifierProvider to the MultiProvider widget, but later because I can't create it at the beginning (well I could but it makes more sense to do it later *).
How am I supposed to do?
(* for more details about why I would like to create the ChangeNotifierProvider later: The associated ChangeNotifier represents a bluetooth connection that will not be available at the start of the application.)
In these situations I create Provider with object which have some initial values and later I change initial values to actual.
I understand the general approach to building UI layouts using Flutter. However, I'm still unclear which classes or UI widgets require a .build() method when I'm creating my own vs. using the defaults generated by the project.
I haven't found a clear explanation yet - even in the Flutter tutorials. They all seem to just gloss over how "the build method takes a BuildContext" and then go on to the next subject without explaining further.
Does anyone have a succinct explanation of the build method and when it is or isn't needed? And more specifically: what does it actually do?
build() method describes the part of the user interface represented by this widget.
The framework calls this method in a number of different situations:
After calling initState.
After calling didUpdateWidget.
After receiving a call to setState.
After a dependency of this State object changes (e.g., an InheritedWidget referenced by the previous build changes).
After calling deactivate and then reinserting the State object into the tree at another location.
You can find more Here
TLDR: The build methode is used to create a new widget tree by placing the Widget reurned in the page tree. This method is essentially called when you create or update the widget (by calling setState((){})
Web view takes more than 4 sec to load the webpage. The same page takes less than 2 sec in Native app. Is there a way to speedup the load time. I tried both Official webview_flutter and flutter_webview_plugin.
If you app relies on WebView, just choose other tools: Swift for iOS & Kotlin for Android.
Here is why:
WebView actually does not load pages slow. Instead, creating the WebView widget is slow;
In order to solve 1, you might want use a cached WebView. Unfortunately, that is not easy. Layout changes (e.g. animation) might trigger a WebView "recreating" (the cached WebView becomes invalid/staled). And the "recreating" is very slow;
Flutter's widgets depend on "state" outside of the widgets, and widgets' creating are supposed to be fast/simple. Unfortunately, WebView (which is not a native widget) is not the case. WebView has its complex internal "state", a recreation simple discard everything and you returns to the WebView's initial state (initial URL). And it is very slow (Creating time + LoadTime: Network overhead);
It is very hard to create a "external state" outside a WebView, therefore after a WebView's recreating it cannot resume from the external state;
Since WebView's recreating is very slow, it totally kills animation and gives user a very bad experience. A solution might be put a WebView as your main page and never try to animate to a new WebView (just like a Wiki App Demo in YouTube).
Conclusion:
So, now, WebView in flutter is not ready and please don't consider use it seriously.
Discussion:
Flutter's widgets design is quite "unusual" since they are basically immutable. States outside widgets (external state) are used. When state changes, instead of modify the widget, Flutter choose to create a new widget based on the new state. Therefore, widgets are deigned to be light weighted so they can be created/destroyed very quickly. Unfortunately, WebView cannot fall into this category. WebView is as complex as the whole Flutter framework, so it cannot be a native widget but a plug-in. And WebView has its own internal state which is not compatible with the framework, which results in keep on being destroyed/recreated by the framework.
I am not sure why Flutter's widgets are designed in this way, maybe it is easier/faster for creating the framework? I saw some complex examples (~100 lines) using Redux/BLOC/Steam just in order to "change" a widget, which might just need a one-line of code in other frameworks.
Performance is also an issue. Rebuild a complex widgets tree is slow. Then you need writing a lot of code (Redux/BLOC/Stream/ScoppedModel...) in order to implement a partial widgets tree build.
Even for a very simple app, performance of Flutter is still not as good as native (https://thoughtbot.com/blog/examining-performance-differences-between-native-flutter-and-react-native-mobile-development). In fact, I'd like considering Flutter as "native" since it is compiled into machine code instead of Java's ByteCode.
Finally:
I am a new Flutter learner and start playing with Flutter for a couple of weeks. The widgets framework and the WebView plug-in just made me headache. A lot of time spent on the UI interface instead of the core logic of my app.
I am not saying Flutter is not good. Actually, I think it is the best cross-platform framework for iOS/Android. It just might be something (e.g. complex external widget like WebView) was not being taken into consideration while the framework was being designed. Hope the Flutter team can find a solution for this, maybe a special case for handling a complex external plug-in?
I will keep on learning/playing with Flutter.
And now Hybrid-Composition is default in webview_flutter 3.0.0:
https://pub.dev/packages/webview_flutter/changelog
Just tried it on my side and since it's not perfect, it's much more faster
cheers!
Updated to webview_flutter 1.0.x and adopted Hybrid-Composition. It performances much better on Android now.
Announcement: announcing-flutter-1-22-44f146009e5f
How to: webview_flutter
Docs: Hybrid-Composition