I have been developing an app using Titanium. I have a scrollview and i am trying to remove childs like below.
First
scrollview.removeAllChildren();
but there is another way to remove the subview by looping the scrollview children like below,
Second
for (var x = 0; x < scrollview.children; x++) {
var child = scrollview.childAt(x);
scrollview.remove(child);
}
My question is which of the above method is good to use when it come to performance wise?
When we deletes child using second method we can visually see the performance. but some suggests second method is the best way.
How much time difference are you observing between the two calls in the worst case scenario (where your scrollview might have hundreds of UI elements). Also you can look into the native implementation in the framework and decide on which is better suited for you. But generally, this first method should be good in most of the cases (also it looks clean)
Related
I'm building a UI test suite for an iOS app using XCUITest api. The app uses recycle lists and I need to access specific cells of those lists during my tests as shown in the code below:
let cells: XCUIElementQuery = app.descendants(matching: XCUIElement.ElementType.any).matching(identifier: "cells_accessibility_id")
let cell: XCUIElement = cells.element(boundBy: index)
cell.tap()
My problem is that since this is a recycle list, as soon it scrolls by any reason during the test (like animations), cells are unloaded, "cells" won't return all items and then "index" won't get the right cell from the list or becomes out of bounds.
Is there another way that I can retrieve the whole list regardless of element visibility? Or do I have to change my tests/try another approach?
You can not rely on the indices of reusable cells as you pointed out, however there is usually a way to eliminate the dependency on having to test cells at certain indices. The solution will depend on what you want to test, but here are some possible alternative strategies:
If your table cells are always the same, you could give them each a hard-coded identifier based on their contents.
If your table cells have dynamic content in them, you could use stub test data for each test to make it so that there is only one cell on screen (the one which is relevant to the test).
If you can identify the cell you want by the views contained within the cell, you can search each cell for the relevant views before selecting it, instead of relying on its index.
i search a lot but no single link found for Expandable listview in Blackberry, i know how to create Expandable list in android ,if someone having idea about Blackberry Expandable listview than please help me.
The standard way to create List on BB is to use the ListField class. This class is extremely efficient but has a couple of drawbacks
All the rows have to be the same height
All the rows have to contiguous on the display
This makes it difficult to use this class to replicate the Android ExpandingListView.
To replicate this look on a BlackBerry device, I suggest a series of VerticalFieldManagers (VFMs). Use one for the whole list, and add to this another for each expandable item. If the item is expanded, add child list entries to the associated VFM, when not expanded, delete the child entries.
This approach will work OK up to a point - adding and removing Fields can slow down the BB device significantly if there are significant number of Fields on display. So if you have, say 20 items in the list, then it will be fine. If you have 2000, it will slow the device down significantly when you expand and contract the list (add and remove the child list items).
You can improve this performance, by making your list items (parent and child) as efficient as possible. I recommend reviewing the code that is used for the ListStyleButtonField that you will find here: http://supportforums.blackberry.com/t5/Java-Development/Implement-advanced-buttons-fields-and-managers/ta-p/488276
Update
Just wanted to clarify why ListField does not work directly, and a possible work around.
The problem with ListField is each row has a specific height. To display the child elements you really need to expand the height of the parent item to include the children, which you can't do. So you can't just update the called back paint method (called drawListRow(..) in a ListField) to achieve this look. And the other problem, is that one list item on a ListField is focused as a single entity where as I assume you would want to select the children individually.
Instead, when expanding you can add additional rows, effectively inserting the children items in the list to be drawn. You will have to add these rows with a flag, so that your drawListRow(..) method knows to paint these as children. Reverse on deletion. Note that the children items have to be the same height as everything else.
Having attempted both, I have found the VFM approach easier to manage. I would only consider the ListField approach where the list was large enough to impact performance. And when it is that large, who is going to scroll through that number of entries on their BB? If you are getting to that number, then a paging mechanism would seem more user friendly.
if you mean BlackBerry Java SDK, then take a look at TreeField class.
UPDATE:
In this case the ListField would be the most suitable choice. Implement ListFieldCallback according to your needs and attach it to the ListField instance. When user clicks on an "expandable" list item, then just process this event in ListFieldCallback and repaint your list instance. Here is the tutorial on working with ListField classes.
It's my first question here, and i'm not an english native speaker, so i apologize in advance, if that makes my explainations difficult to understand.
CONTEXT
I'm in charge of the developpement of a small application which manipulate vocabulary sets.
The application is built on GWT, added by GWT-Bootstrap and some other libraries, that have nothing to do with the ui part of the application.
To expose to the user the terms of this vocabulary, i use a tree stucture, visually speaking.
STORY
The tree has few requirements, it has to allow drag&drop features for his items and show connectors between them.
I started by using the Tree ui class from the native GWT components. It turned out that with a lot of terms loaded in the tree, the performances felt down, even in production mode.
I decided so to try the CellTree implementation, but it didn't fit for me since make disappear the "showmore" button is not an easy task, and styling the tree too.
I finally ends up with my own implementation of a tree, from scratch.
This implementation relies essentially on a simple html list structure (ul-li), and benefits at maximum of css capabilities. Indeed, expanding a tree node is done with css, using a trick known as "checkbox hack".
At this point the custom implementation of the tree is fast (better than tree or celltree), even populated with thousands items, and it met the requirements, but...
THE ISSUE
When an item is being dragged over other items, the style of those items change depending on dropping possibilities.
1st Solution
The first idea was to benefit of the css, and use the :hover selector to change the style of the items, depending on their classes.
But there is a major issue in current browsers (specifically Chrome), which make the css :hover not triggered, if the mouse left button is down, which it's the case when you drag something (chromium issue 122746)
It seems that i have to forgot an exculsive css solution, until the :hover triggering issue will be closed.
2nd solution
The only other solution to which i came by is to change the style of the item programmatically.
Code of the handler
#Override
public void onDragEnter(DragEnterEvent event)
{
if (event.getSource() instanceof Word)
{
event.stopPropagation();
event.preventDefault();
Word word = (Word) event.getSource();
word.addStyleDependentName("over");
}
}
#Override
public void onDragLeave(DragLeaveEvent event)
{
if (event.getSource() instanceof Word)
{
event.stopPropagation();
event.preventDefault();
Word word = (Word) event.getSource();
word.removeStyleDependentName("over");
}
}
It works fine with a few items, but when dealing with thousands it make the application freezing, and the rendering is somehow random.
PRECISIONS
The issue appears when dealing with 5000 items in the tree (the application must handle such dataset).
I'm aware of efficient events handling concerns, as event bubbling, and the handler is unique as it is recommanded when the number of potential handlers, if made specific for each item, is a factor of lack of performance as the number of items increase.
Secondary i've used the speed tracer to analyse the source of the problem, and it turned out something i don't understand:
Events are incredibly slow on top elements of the tree, specifically the paint event which take 1 second to be fired after the style recalculation
Slow events Speed Tracer Screenshot
Events speed is fair enougth on bottom elements of the tree
Fair enougth speed events Speed Tracer Screenshot
QUESTION
I'm stuck with this issue since few days, and i wonder if someone could point out what i am missing.
Perhaps, the behaviour is totally normal, but maybe there is a workaround for a such issue ?
I'll be glad if someone could help me on this point.
Thanks you for any reply !
lilBrain
If you are using GWT-Dnd please have a look at that;
Slow drag performance when there are a lot of draggables on screen
It's mentioned that this performance issue is related to finding x, y coordinates of the widget on a drop event.
com.allen_sauer.gwt.dnd.client.DropControllerCollection.getIntersectDropController(int x, int y)
there is a block of code that loops through the DropController candidates with what appears it's only purpose being for debugging.
for (int i = sortedCandidates.length - 1; i >= 0; i--) {
Candidate candidate = sortedCandidates[i];
if (DOMUtil.DEBUG) {
DOMUtil.debugWidgetWithColor(candidate.getDropTarget(), "blue");
}
}
subsequent to that, the code then loops through and actually tries to
identify if the x and y coordinates are over a DropController.
Hope this will help you.
I am trying to do the standard - bind a list of data (including images) received from REST API calls in a very quick and smooth manner - a paradox in itself. I have 2 service calls that each take about 2 seconds to complete so I can async/await those, but based on the data returned, I then build other lists (observableCollection) in memory and bind them back to ListBox's in the page.
Problems:
This actual binding seems to lock up the UI thread, how can I asynchronously load my page - listBox by listBox (or even item by item) in a lazy fashion? I'd like to put a placeholder image in place and when finally bound, the placeholder is replaced by the bound image. Any ideas? Frameworks? Tools?
When binding the actual images, the other data in my DataTemplate, actually jumps around the screen while the Image is rendered. It looks terrible... I'd like to be able to, at the very least, bind the image first and then the other controls in the dataTemplate after? Anything that would make it appear a bit smoother would help.
Thanks in advance.
I suspect your problem in (2) will be solved with the placeholder image (assuming that it is the same size as the downloaded images).
I suspect that your "lock up" problem in (1) is that you are calling Wait or Result on a Task returned by an async method. In many cases, this results in a deadlock, as I explain in a recent MSDN article and on my blog.
I think what you really want is a way to start a Task and get a data-binding notification when it completes. I've developed a set of types (TaskCompletionNotifier) that helps out in this situation. Check out the end of my blog post on async properties for a sample. You may also be interested in my blog post on async constructors.
(1) If the list of items is large, binding them all at once will cause some stalling on the UI thread. One fix is to add the items a few at a time and pause so that the UI thread can get a new frame to the compositor before continuing.
public async void AddObjects(List<object> objects)
{
for(int i = 0; i < objects.Count; i++)
{
_myObservableCollection.Add(objects[i]);
if(i % 10 == 0) await Task.Delay(100);
}
}
(2) You should set a fixed width and height on the images in the DataTemplate, so that it does not change as the image is actually downloaded. Alternately, if you can fetch the width and height from your service in the API calls, bind the image width/height to those values before it gets downloaded.
I'm writing a simple dictionary app which gives suggestions for words as you type. The suggestions are displayed in a ListBox and each time the query changes, about 10 suggestions should appear.
Unfortunately, performance is low at the moment. It takes almost a second for the results to appear and I don't understand why. EQATEC Profiler shows that my methods are running smoothly. I've confirmed this by putting a Stopwatch around my code. I've also experimented with the number of suggestions, and performance does increase with fewer items.
This leads me to conclude that rendering the ListBox (which I presume happens outside of my methods) is to blame for the lack of performance.
Does rendering 10 items in a ListBox really take more than 250ms?
How can I quickly put a small number of words on the screen?
Edit:
The way I fill my ListBox is very straightforward. Is it the right way?
resultsListBox.Items.Clear();
foreach (string s in suggestions.Words)
{
resultsListBox.Items.Add(s);
}
resultsListBox.SelectedIndex = suggestions.MatchIndex;
What you see here is really it: default ListBox, String items, no templates. Do I violate one of these principals?
Ensure you have the item data template in a fixed sized container (grid).
Avoid/remove using complex converters, when the same information can be easily provided by the data object.
Avoid/remove nested structures, example listbox in a listbox item.
Strongly recommended to not use user control inside the data template.
Avoid/remove custom controls from the data template
The link below contains a demonstration of the ListBox performance in a simple project.
The project also shows an alternative (faster) way to display a list, using a Grid with Buttons. This list is not scrollable and therefore not a real solution.
http://www.mediafire.com/?jypcfm4cs3nvo5c
Remember to run the project on a device, because the emulator has very different performance. I've tested it on the Samsung Omnia 7.
It sounds like you're creating your own AutoCompleteBox. Is there a specific reason for not using the one in the Toolkit?
I would expect the time taken to update the listbox to be dependent upon: how you're updating it; the complexity of the listbox; and whatever-else is on the page.
In that you haven't provided details about any of these it could be possible that it will take this long.
Edit
As an alternative to the AutoCompleteBox (In theory you shouldn't need to scroll the results of this--just enter more characters to filter further.) I've done some experimentation and the following seems to work best. It uses a StackPanel inside a ScrollViewer and reuses the existing items, rather than creating new ones.
<ScrollViewer Height="629" Margin="0,139,0,0" Width="480">
<StackPanel Name="listBox1" />
</ScrollViewer>
cs:
private void InitializeResultsGrid()
{
...
for (int i = 0; i < 26; i++)
{
...
listBox1.Children.Add(new TextBlock());
and
private void SlowFill(string baseStr)
{
for (int i = 0; i < buttons.Count; i++)
{
(listBox1.Children[i] as TextBlock).Text = baseStr + (char)(i + 'a');
}
When I timed it, it was slightly slower than using the Grid but the performace seemed fine to me on an LG-E900