I have a grid view which is showing the heal status of many different services, and coloring them and/or auto-opening a webpage when the service goes down. The problem is that the elements which are off the screen are not being checked, which is more efficient, but not what is desired in this case.
I guess it's behaving similarly to the RecyclerView in android?
I want to be building the widgets which are checking service health even when they are not visible on the screen.
Currently the services don't start being checked until the moment I scroll them into the screen.
Assuming you are currently using the GridView.builder constructor, I recommend using the "normal" GridView constructor (with a children property). Since GridView.builder only builds the elements currently visible for efficiency reasons, the elements that are not rendered on the screen won't run your back end logic.
For more information, see the official docs:
[GridView.builder] constructor is appropriate for grid views with a large (or infinite) number of children because the builder is called only for those children that are actually visible.
Here you'll find alternatives:
The most commonly used grid layouts are GridView.count, which creates a layout with a fixed number of tiles in the cross axis, and GridView.extent, which creates a layout with tiles that have a maximum cross-axis extent.
Related
We currently use react-base-table as our solution for an infinitely scrolling table component, but it runs into performance problems with a large number of columns because it does not virtualize horizontally. My understanding is that ag-grid does, so we are looking at it for primarily performance reasons.
Our app defaults to displaying data (log events) from bottom to top. The user is initially placed at the bottom of a potentially large virtual dataset (could be millions of events), and they scroll up to load and view more events (200 at a time).
After reading through ag-grid docs and searching here, I don't see anything about support for an upward direction for infinite scroll. Am I missing anything?
I've tried implementing it with the default row model, but am running into errors (eg "cannot draw while in the middle of drawing rows"). The 'onViewportChanged' event I'm using to trigger a fetch is called several times when rendering, and messes up our data model. Infinite scroll seems like the correct approach.
Yes, it is possible.
You will need to set serverSideInitialRowCount={1000} so the grid could adjust scroll size. And then in the onGridReady event call api.ensureIndexVisible(999).
The grid will request only the last data block, and will request other blocks as you scroll up.
I am working on building a mobile application using flutter and am stuck on building a resposive login screen layout. To be precise, I am using the MediaQuery to find the screen size and to find the safe area and based on that I am spacing and building containers based on percentage of screen height. I would like to know if this is the best way or if I am unnecessarily complicating the entire process. I did come across a few youtube videos where most of them give random numbers but when I try doing that, my layout most often than not ends of overflowing!
So far, I have mostly done this with just mathematical calculations. i.e. I have stuck to calculating the available height (total height - safe area) and then built all my containers based on this height (including their spacing). But, I am struggling with getting the right font size and this constant struggle to balance the UI in both android and iOS setup is eating up most of my time.
I built hundreds of screens in Flutter. It is very rare that you need to use exact screen height for a layout. Most screens fall into one of the three categories:
There are too many elements to fit into a screen of any size.
In this case you wrap your layout in SingleChildScrollView widget that has a Column child, and then put all other widgets in that Column. Users scroll down to see all visible elements they need to see.
There are too many elements to fit into smaller screen sizes, but they fit into larger screens.
In this case you still wrap your layout in SingleChildScrollView widget. Then you make your layout look nice on larger screens, but users on smaller screens still have to scroll down. This is not ideal, but sometimes it's the right solution. Making design elements smaller on a small screen often makes it hard to use or even totally unusable. Plus, having various calculations related to a screen size in your layout logic makes it a nightmare to test your app: you have to test it on all sorts of screen sizes.
All design elements can fit into a small screen.
In this case you should use Flex widgets (like Column, Row, Spacer, Center, etc.) to create your layout. These widgets already have a logic for spacing their children in the available space (for example, using mainAxisAlignment and crossAxisAlignment properties in Column and Row).
There are also widgets that can take a specified percentage of a screen (or their parent widget), but I never use them. I can imagine situations where these widgets can be useful, but for the vast majority of designs using Flex layout is a better option that results in better looking screens.
If you post your design and the layout you came up with, we can point if there are ways to optimize it.
I need to create a list view that has a few key requirements
Infinite scroll of a fixed number of items (ie looping)
Multiple child item types (images, text, inputs)
Multiple child item heights
"3d" wheel look/feel. 2d perspective changes and shadowing/coloring should suffice
It needs to be iOS and Android compatible in Flutter.
I've tried the List Wheel Scroll View widget (https://api.flutter.dev/flutter/widgets/ListWheelScrollView-class.html) and am currently using Carousel Slider (https://pub.dev/packages/carousel_slider), but neither quite get the job done. List Wheel can't do interactive inputs or mixed child heights and the carousel can't do mixed heights or '3d'.
Has anybody created or come across something that might at least get me going in the right direction?
UPDATE
Currently playing with CustomScrollView with some success. It allows me to have multiple child heights and I ~think~ I'll be able to add some perspective to the children in the scroll listener.
What I can't figure out with CustomScrollView is how to get the looping/infinite scroll.
I liked using the flutter_swiper package a while ago. Not sure if it supports mixed heights, but it has 3D effects. But it doesn't seem maintained, so I would try this null-saefty unofficial fork : flutter_swiper_null_safety
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 am wondering what is the equivalent of the web api DocumentOrShadowRoot.elementFromPoint() in flutter.
Specifically, I am wondering how I could figure out what is the leaf element/widget instance in a widget hierarchy, given an Offset.
For example, consider the following structure:
For the First Offset marked with a dark circle, I would expect to get some sort of data that can help me figure out the offset is over Container.
For the Second Offset marked with a dark circle, I would expect the stack.
For the last one, it would be the positioned element.
A bit of context
I'm exploring the implementation of a visual editor similar to FIGMA in Flutter. I have experience in implementing such a rendering system with web technologies.
I want to render a selection indicator or outline when a tap/click happens on each element. These elements are nested. Adding multiple nested event handlers triggers all of them. For example, mouse enter and mouse leave when moving the mouse over the Stack or Positioned element would trigger all the parent event handlers as well.
Any help or guidance would be appreciated.
Simple answer to your exact question: No direct equivalent. Possible to implement but not advisable.
You could theoretically implement your own version of elementFromPoint() by looking at how GestureBinding works in Flutter. That would be a deep dive for sure, and you might learn from it, but there is a simpler solution. Even if you implement your own method, then you would still need to resolve conflicts when more than 1 element is found - and this is something Flutter solves out of the box with the gesture arena.
I see that you expect the top-most or deepest child to be reported, something that you can obtain by using the GestureDetector widget. What you're looking for is making your gesture detectors opaque. A GestureDetector has a property called behaviour of type HitTestBehaviour. The default for it is deferToChild. Here are the possible values:
/// How to behave during hit tests.
enum HitTestBehavior {
/// Targets that defer to their children receive events within their bounds
/// only if one of their children is hit by the hit test.
deferToChild,
/// Opaque targets can be hit by hit tests, causing them to both receive
/// events within their bounds and prevent targets visually behind them from
/// also receiving events.
opaque,
/// Translucent targets both receive events within their bounds and permit
/// targets visually behind them to also receive events.
translucent,
}
What follows is slightly related, so consider it a deep dive in your use-case
Since you're going down this path: I also built a WYSIWYG design system, with selection indicators, handles for rotating, resizing, etc. and have one advice: Completely separate your design rendering from your gesture detectors and selection indicators.
I initially put the gesture detectors "around" the design elements - in your example, the gesture detectors would sit in between yellow / blue / green / red. The reason this is a bad idea is that it complicates a few things. In some cases I needed to create touch areas larger than the design elements themselves, in which case I needed to add padding and reposition the GestureDetector parents. In other cases the design elements would become fixed or locked and would not have a GestureDetector parent and Flutter would completely rebuild the contents of the layer since tree comparing got confused. It gets messy fast. So, stack these layers:
Design on bottom, no interactivity.
Selection indicators, resize / rotate handles. Still no interactivity
Gesture detectors for all design elements. If you're lucky, you know the exact size, position, rotation for the design elements you can simply use Positioned. If you have groups of design elements, then your gesture detectors also get grouped and transformed together. If you also have self-sizing design elements (like images), it gets a bit more complicated, but I got around my issues by adding the design element as an invisible child. The way I would do this now is by loading meta-data about the images and knowing them at build time (as opposed to waiting for images to load and produce layout changes).
Selection indicators + resize / rotate handles gesture detectors. They are top-most and also opaque, so they catch everything that hits them.
This setup then allows you to experiment more in the gesture department, it allows you to use colored boxes to debug and in general will make your life easier.
TLDR: Use opaque gesture detectors.