Suppose we've the following structure of widgets / panels in a GWT application -
A Tree menu in the left of the DockLayoutPanel which is used for navigation to different applications.
A panel in the center of the DockLayoutPanel and different content widgets getting loaded in this panel (this is controlled by the navigation tree menu.
These content widgets are composites containing one or more widgets.
One way to deal with such application is to keep singletons for all widgets / panels, which means composites will hold singletons to all of their child widgets. But I feel this is excess usage of singleton. The other alternative is to construct new Widget object every time one is needed, but this must be expensive.
What are the best practices around this? Are there any standard patterns which take care of this problem?
The other alternative is to construct new Widget object every time one is needed, but this must be expensive.
You'd be surprised. While Widget creation isn't free, in most cases, it is pretty cheap, even in DevMode. There are several widgets that are expensive to create in DevMode (specifically, the FlexTable/Grid), but those speed up drastically once you compile the application.
There doesn't seem to be any pattern specifically for this, nor can I point to any one guru giving a best practice, but in our application we had previously treated all of our top level widgets as singletons and it caused a load of issues for us. (Managing state between different screens, handling event bus events, stale data on the screen when not cleared)
We just refactored most of the code to be created on demand more (and subsequently destroyed when no longer needed) and we gained simpler code and a faster startup time.
In the end, if you do create widgets on demand, there may be a few cases where you need to increase performance by making those widgets singletons, but I think you'll find that only a few would warrant that effort.
All in all, don't assume something will be slow if you haven't tried it, and don't preemptively optimize your code.
Related
Can i render an imagens only it'll visuble in scrollview?
My app has an list view with many products, when I scrolling down many times the performance of my app is down (i'm using a lazy list), i guess it's becase there many imagens (from web) render up my screen.
I'm thinking to do something like it:
You'll need to use Listview.builder with itemBuilder instead of a child
It will allow you to only render what is on the screen or what is likely to be on scrolled in the very near future - your performance will be considerably improved
I recommend watching this video from the Flutter Team on this topic (lazy load a big list view) at flutter.io - if you'd like to go deeper into the topic
use .builder when ever you can find.
Creates a scrollable, linear array of widgets that are created on demand.
This constructor is appropriate for list views with a large (or infinite) number of children because the builder is called only for those children that are actually visible.
for more follow ListView.builder
I'm working on a Flutter app that has features similar to whatsapp where there can be a bunch of messages that are essentially audio players. I'm using AnimatedList so the chat bubbles animate in and out.
The issue is it doesn't seem that AnimatedList supports keepAlive and I haven't come across any alternatives. I don't want the widgets to be recycled because if a message is playing and I scroll the message in and out of view, I want the message to keep playing AND animating and right now I instantiate an audio player and animation controller in each child widget. I could see this being more "optimal" if I maintained all this state outside of the child widgets (at the same level as the list) but the max amount of chat bubbles per conversation in this app is ~50 and we want to move fast instead of be optimal right now so I think this simplification is a good idea if I can keep the widgets alive.
I tried wrapping the child widgets in a KeepAlive with no luck. Below seem like my options:
There is some supported way to do this and I'm not aware of it
There is some alternative / 3rd party lib that supports this
Try using a non animated list and explore other ways to animate
Implement the state above the children
I'd be curious to hear of potential solutions from the community. Thanks!
All the proposed solutions are fine (the fourth is probably the most reliable if you need it to work quickly but not the most efficient for sure...).
Did you think about using one InheritedWidget that you would place above your animated list, which would control the audio player. (I am assuming that you only want one audio playing at a time).
So concretely, you would have an inherited widget that would expose a start(File file) method and a pause(File file) method and the duration property and a unique identifier for the current message being played. This would allow you to keep your state structure simple and still be quite efficient.
I can write a piece of code if my explanation is not clear enough .
I have a strong background with Android development and I'm now trying to develop my first app with Flutter.
It is a common knowledge in the Android community that it's bad have too many nested views. It's bad for performance. (That's one of the reason why ConstraintLayout exists)
However, in Flutter tutorials I see that people nest a lot of widgets.
Could somebody confirm that it's not a problem to nest widgets with Flutter? Will my app suffer of bad performance if I do it?
Thanks in advance
TL;DR: Deeply nesting single-purpose widgets in Flutter is recommended.
There are fundamental differences in how Android and Flutter render view elements (aka widgets or views).
In Android, there are relatively few, complex views that inherit each other.
Each and every view provides a huge API surface, including stuff like padding, margin, colors etc.
Flutter, on the other hand, favors composition over inheritance.
Most widgets exist for a single purpose only and are very lightweight.
That means you need to nest widgets more deeply to achieve the same effects, but because their layout and rendering logic is easier, the rendering is typically faster.
For example, there's a Padding widget that makes some space around its child.
The Padding widget's rules are very simple, making the rendering very fast.
Additionally, the rules of every other widget also get simpler because they don't need to worry about padding anymore.
Basically, nesting widgets deeply is recommended in Flutter.
It's quite the opposite to Android's model:
If there's not much nesting, you probably did something wrong, because you have a huge widget that can often be split into simpler, faster, smaller widgets.
Here's an interesting Google Tech Talk about Flutter's rendering pipeline, which I recommend to anyone interested in this topic.
Nesting widgets is not a problem and is actually recommended.
In fact, the default counter application contains no less than 150 widgets.
Widgets are lightweight objects optimized specifically to create and destroy tons of them every frame. This is further prooved by Flutter FAQ:
Rather than having each widget provide a large number of parameters, Flutter embraces composition. Widgets are built out of smaller widgets that you can reuse and combine in novel ways to make custom widgets. For example, rather than subclassing a generic button widget, RaisedButton combines a Material widget with a GestureDetector widget. The Material widget provides the visual design and the GestureDetector widget provides the interaction design.
This quote says that you should purposefully nest widgets.
I've been Googling like crazy for a while now, and I simply can't find any answers to the question: is it possible to implement the Android List scrolling, without using an actual list UI?
I'm trying to make a grid of rectangles such as the kind you would find in a typical game app respond to finger movement in the same way that it does using Android lists (bounce on the bounds, the 'flick' effect, etc), but all of the approaches I've found involve over-complicated solutions involving extending the list, defining XML layouts, etc.
Would it not be possible to simply give an object variables for 'document' height, 'viewable' height and y-offset? I'm happy to give the delta (MS since last update) to the object on every update. It would also be good if the actual interactive region was also definable.
Additionally; are there strong advantages to using the ListView instead that I'm missing? I assume responsiveness comes into play, but I'm quite happily managing that manually at the moment.
Just use ScrollView directly, assuming you only need vertical scrolling.
I'm currently making apps for iOS, and I had a quick question about making UIViews. In the process of designing a UIView, I was wondering if everything should be based off of the bounds of the rectangle that contains my view.
For example, the one I'm currently working on is designed as a header that only occupies the upper 25% of the screen. Despite this intention, should I still design the code so that if the view were to occupy the entire screen , it would still work?
To provide a scenario, lets say I need to draw a line. Should I just draw it 20 pixels across, or should I always go 30% of the width of my rectangle.
I understand the concept of reusability, but if I'm designing this view only for this particular purpose, is it acceptable to make it somewhat rigid in nature?
Designing for change and reusability is always a good practice. However, as you have also realized, it introduces overhead which can sometimes outweigh the benefits of the flexible design.
I would say that it is fine to hard code some values if the view is used only for a particular purpose with a particular size. It is fairly common to create fixed size images for UI components which is just like using fixed size values in your code. Nevertheless, it is a good practice to use constants for all your hard coded values and collect all of these at a centralized place of your code e.g.:
static const CGFloat centerLineWidth = 20.0;
This way you can relatively easily reconfigure your views if something needs to be changed.
Finally, if there is even a slight chance that the view might be used with different sizes, you should go for the flexible design. You can also mix these concepts, e.g. create a view which is designed with flexible width in mind but its height should be a fixed value.