I have around 100 data in my list.
I need to display the list, it would be easy if i could display the list by fixing a frame for a single cell and reuse it...
This is possible in 'ios'.
Is it possible in windows phone??
If so could you please tell me how to do it?
Look for virtualization. In a short, it keeps in memory only items you're going to render.
http://shawnoster.com/2010/08/improving-listbox-performance-in-silverlight-for-windows-phone-7-data-virtualization/
WP7 Listbox how UI virtualization work
PS: if you're looking for out-of-box solution, take a look at Telerik Controls. Here is documentation about virtualization. It allows to keep in list thousands of items and render them smoothly. I'm using it for a several months, controls are of high quality + support is lightspeed fast.
Related
I'm allowing users to select an icon from the full list of FontAwesome icons (using a List<ImageVector>). I'm going to open a dialog, and show the icons as IconButtons arranged in the list. There are ~1600 icons.
I implemented it using a LazyVerticalGrid, with a fixed number of columns. It works, but there's some lag loading the icons, and lag when scrolling the icons.
I'm converting this from a React Native project where I did the same thing (with a larger set of icons, actually) and scrolling that was pretty snappy, so I'm assuming it's possible to do performantly on native. Perhaps ImageVectors are heavier than the SVGs I was using in React Native?
I'm planning to provide a search box in the dialog where users can filter the list down by doing a fuzzy search on icon names, so the grid will change over time.
What sort of patterns should I be looking at here? Is LazyVerticalGrid the way to go, or should I be using a different approach entirely?
On Laziness
For an overview of use cases and appliable patterns you might be interested in the Android Dev Docs' page on Lists and Grids, încluding the topics Large data-sets (Paging) and the Tips on using Lazy layout.
This might wake your interest on the Android Jetpack Paging Library androidx.paging, which is designed for loading and displaying pages from large datasets, basically uniting the concepts of Laziness and Caching.
Currently you're only using Laziness. As Bartek Lipinski commented, that should usually be fine when the graphics to display are static. However, when they have to be loaded asynchronously, Paging will probably improve your performance.
Some Rules of Thumb
Scrolling
Pattern
No
Column or Row will be enough
Some
Column or Row with modifiers verticalScroll and horizontalScroll
More, static content
LazyColumn or LazyRow, resp. for gridding LazyVerticalGrid or LazyHorizontalGrid
More to mass, dynamic content
LazyColumn or one of its relatives with LazyPagingItems, so using the Paging Library androidx.paging
Also, as the docs say, consider adding contentType
. However, as Bartek Lipinski remarked, one usually benefits of contentType when there are scrollable elements of various types -- not only SVGs as maybe in your case. Still, giving hints to the system doesn't hurt, at least.
On Vector Graphics
As discussed in the comments, esp. by Subfly and Bartek Lipinski, though Laziness should be the main thing here, another bottleneck could be the loading of vector graphics during runtime.
If the graphics used are of static nature, then consider the usage of vector graphic assets. Those are supported for SVG and PSD since Android 5.0 (API level 21). Take also a look on the recommendations and some aspects of support and restrictions on SVG.
Summary
The basic formula is Laziness + Vector Assets with focus on the first. One might spice that with contentType and Paging.
I have a large federated model loaded in Autodesk Forge Viewer (~300k elements from several IFC files). I'm doing a cross-model (aggregate) selection like this:
var selection = [{model1 : [ids...]}, {model2 : [ids...]}, {model3: [ids...]}, etc...);
viewer.impl.selector.setAggregateSelection(selection);
Now, given that the number of selected elements goes to 100k+, this freezes the UI for a couple of seconds, then once all of the elements get highlighted in the viewer the performance (fps) of the viewer degrades significantly. Switching to isolation instead of selection (highlighting) improves viewer performance but it still freezes the UI for a couple of seconds while doing it.
Are there any performance tips when doing these large selections, can the selection/isolation process be done async so the UI feels more responsive?
Cheers
I'm afraid the selection mechanism (both the state toggling and the rendering) isn't optimized for such numbers, and there's no way to optimize it yourself. This would require a code update in the internal viewer implementation.
Before we pass this to the engineering team, however, I would like to ask about your actual use case. The selection functionality is typically used to bring user's attention to one (or a small number) of elements in the design, or to allow the user to choose one (or a small number) of elements for some further processing. But selecting 100k+ elements, and then continuing the use of the viewer with those 100k+ elements selected? What exactly do you need that for? Have you considered using other features of the viewer such as the theming colors?
I have a lot of FlexLayout element in my template and it is so slow on iOS devices.
i replaced that with StackLayout and now it became little fast than before.
I'd like to know which Layout Container is fastest layout in Nativescript.
There is never one right solution for all various needs, which is why we always have options and that applies to layouts in {N} too.
Learn more about layouts interactively at nslayouts.com and choose the one that suits your use case.
If you show use what exactly you are trying to achieve, we may able to give you some suggestion. There are some general guidelines you may have to follow for better performance,
Avoid nested layouts
Use GridLayout when you need known number of partitions in your UI, the less the number of partitions are, the better the performance would be. Use FlexboxLayout otherwise.
If you just want to stack items in vertical or horizontal order, StackLayout may be a good option. Use FlexboxLayout only when you want to use flex box specific features, like when items has to be wrapped to next line, change order of items etc.,
Try to not use StackLayouts just for the shake of borders around, since you can add border to the component itself.
If you have really complicated heavy UI components, you may load it once the page has completed navigation, that may be faster.
Prefer ListView over Repeater / for loop as much as possible.
By following the above at least I can confirm, I don't hit performance issues in my apps where I have 100s of elements and 10s of partitions on screen. If you still face issues, try creating a Playground example where we can see the issue.
I noticed this same thing with FlexboxLayouts on IOS where I was doing animations with the layouts. It worked great on Android, but was very slow on IOS. I switched it to a GridLayout, and things worked a lot better.
I would like to ask which controls can be used to create a design similar to the built-in Weather app - that means different sets of data (tables, lists, etc.) that stretch horizontally and can be scrolled and can use the semantic zoom (which just shows the names of individual sections). I was trying to find some ways, but I have always found only examples using a list of same-type items, that are grouped somehow and shown in a GridView, but nothing similar to those built-in apps.
Thank you very, very much
You can achieve your goal using ItemTemplateSelector.
See here for more information: http://msdn.microsoft.com/en-us/library/system.windows.controls.itemscontrol.itemtemplateselector.aspx
In my app, I've a panorama-page which contains around 10 panorama items. Each panorama item has some path drawings, a list picker and few input fields.The problem i'm facing is that whenver i navigate to this page the navigation is very slow due to lot of content to initialize. If i comment the InitializeComponent(); the loading becomes fast.I thought of adding the XAML content in code, but the problem is that i've to access the input fields by their name in code, so it didn't worked.Any idea how i can speed up the navigation to the page.Thanks..
From the UI Guide:
Use either a single color background
or an image that spans the entire
panorama. If you decide to use an
image, any UI image type that is
supported by Silverlight is
acceptable, but JPEGs are recommended,
as they generally have smaller file
sizes than other formats.
You can use multiple images as a
background, but you should note that
only one image should be displayed at
any given time.
Background images should be between
480 x 800 pixels and 1024 x 800 pixels
(width x height) to ensure good
performance, minimal load time, and no scaling.
Consider hiding panorama sections
until they have content to display.
Also, 10 PanoramaItems seems like a lot since the recommended maximum is 4. You should either cut down on the number, or hide the content until it's required. Have a read of the best practice guide for Panoramas on MSDN.
I think you could improve page performance by creating usercontrols for the specific panorama items, add an empty panorama control to your page (with only the headers) and as picypg suggests load these usercontrols when they are needed.
Another way could be that you load the first page and show this one already to the user. In the background you could start loading the other panorama items.
My suggested approach would be for the first one. Using the lazyloading principle.
I woudl assume that your delays are due to the number of items on the page. This will lead to a very large object graph which will take a long time to create. I'd also expect it's using lots of memory and you have a very high fill rate which is slowing down the GPU.
Having input items/fields on PanoItems can cause UX issues if you're not careful.
That many panoItems could also cause potential navigation issues for the user.