I am adding and removing elements dynamically in a flex application
When adding an removing items in flex component there is a flickering happening on the screen(Not all the Time only on first loading of the application). On research I understood that this is because of the time delay for two updates. One for removeAllElements and other for addElement. Is there any way to make it as one update to remove the flickering issue?
thanks
It's good practice to use DataGroup as a base class for list components. The huge benefit of it is that it has virtual layout. What means if you have 1000 items in your list, framework will create only items which can be fit in current screen ( for example 20 ). And than reuse them when user scroll list. So most likely using DataGroup will solve you problem.
Related
I'm developing a application which has a ListView which contains items which needs complex cell layouts. The cells are in variable heights and some of the cells tends to be larger than the view port height.
But when the ListView is filled with items the scroll thumb tends to resize its self while scrolling, which makes it hard to hold onto the thumb while scrolling. This happens mainly when passing through different size of cells.
This is not a problem in Swing if I create a same kind of a cell render to be used with the JList. This problem is there in JavaFX 2 and JavaFX8 both.
When looking at the VirtualFlow which is responsible for layout of the ListView and handle scrolling, it seems that the scrollbar thumb side (lenghtbar) is calculated based on the cell count and the visible cell count, which is actually a problem when it comes to lists which has variable heights of cells.
So is this the future of the scroll bar behavior for Java FX list views? or is there any solution available for this problem? Or should I try to hide the scrollbar and provide a different user interaction to scroll?
This problem is already reported under https://javafx-jira.kenai.com/browse/RT-25059 and fixed in Java8 upto some extend. So if this fix is needed on JavaFx2 we have to backport the changes under commit http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/81cc13fe6f96
To get this changes in JavaFX 2.2 you need to apply the required changes on to FX2.2 VirtualFlow.java class and load those changes before the jfxrt.jar is loaded. Another approach is if you don't like to mess up with the jfxrt classes is to have you own ListView which uses your own Skin and the patched VirtualFlow version may be with a different name. But this might require lot of customization compared to first solution.
More approaches are welcome :).
Whenever you resize a datagrid by hand (not via code), the last column seems to retain most of the width. What's worse, whenever you extend it and shrink it to a large degree, the other columns can get smushed. Here's a perfect example:
The ideal solution would distribute width equally or in proportion to the length of the text. In addition, if would avoid covering text when it's not necessary. Now, setting the width to 0.5 in the example above does seem to alleviate the issue, but not prevent it entirely.
What I'd also like to know if there are any well polished, custom datagrids out there that solve this. From trying to find a solution, I suspect the only solutions available are more ad-hoc.
I know two ways to avoid this problem.
1) Use List with special item renderer, which simulates columns (say HBox separated with rules), and header, which repeats the layout of item renderer. It's not very elegant solutions, but the resize is quite predictable. Also you can easily add sorting feature (by adding buttons to header), but I'm not sure if column resize is possible to implement here.
2) Use spark s:DataGrid from SDK 4.x. It hasn't got such resize problems AFAIK.
I'm working with a large flex applications and I have noticed that one of our largest components (with lots of child canvases) takes about 6 seconds between the initialize and creationComplete events. I've been doing some reading and have found that having lots of nested canvases can cause slowdowns, but i'm not sure if this is where the slowdowns would be? Anyone have any suggestions on speeding this up, or even diagnosing exactly where the slowdowns are coming from?
It's been my experience that nested containers with dynamic sizing are the most common cause of these types of lags. Some things to try:
Set explicit sizes/positions for your containers/components whenever possible. This reduces the incredible amount of measuring that goes on within the framework during the creation process.
Reduce the number of nested containers. Sounds obvious, but it's amazing how much you can cut away when you start looking critically at how your UI is set up. Specifically, are there HBox and VBox containers you can get rid of by simply setting explicit positions/sizes for the child components? Do you really need to use a Form container?
Switch your containers to the much lighter weight Spark Groups instead of using the heavier weight Canvas where possible.
Hope that helps. If not, post some code so we can dig in to your particular issue.
The biggest thing to consider is to use VBox's and/or HBox's in place of some dynamically generated x's and y's. VBox and HBox are much more efficient. Look into it!
Adding many display objects to the display list all at once can take a long time, especially if we're talking about Flex containers that have layout and scrolling logic in the mix. Since you say you're using many Canvas containers, that could certainly be the issue you're running into.
I know that a lot of developers abuse the creationPolicy property. Normally, it is set to "auto" which allows Flex to defer instantiation of a container's children until a very short time "later". Often, before the next frame, so you don't even see the difference. Do you happen to set creationPolicy to "all" anywhere in that hierarchy? This could be forcing the Canvases and their children to be created immediately.
I know there are a lot of questions about dynamic sizes for Flex components, but this one is quite specific and the other answers aren't a whole lot of help. Briefly, I need a List that resizes to exactly fit its content, unless that height exceeds its (dynamically sized) parent container. My requirements are as follows:
The component extends List, or at least acts similarly.
variableRowHeight and wordWrap both equal to true.
The height of the list cannot be less than minHeight (roughly 32px for scrollbar arrows).
The height of the list cannot be greater than the height of the parent container .
Note that the parent container can be resized dynamically.
The height of the list should be updated as the size of both the contents and parent container changes.
Live updating would be preferable but not necessary.
There should be no scrollbars if the content height is less than the parent container height (sounds obvious, but I've had trouble with this too).
The trouble is that with variableRowHeight and wordWrap, it's very hard to know the size of the content at any given time. If the parent container's width is reduced, a line wrap may occur in the list which will change the height of the content. I know I can measure the height of the list content using measureHeightOfItems() + viewMetrics.top + viewMetrics.bottom, but when should I calculate that? What events should I listen for? And the thing I've had the most trouble with - when should I calculate it to set the size initially (i.e. just as the content has finished populating)?
I've been tackling this for months now on and off, but can never find a solution (though I've come close with chunks of code of varying degrees of incomprehensibility). I'm not asking for someone to create a full component for me, I'm just hoping someone has the right pointers to let me know how I should go about determining and updating the size. I'm happy to do all the prototyping for you and discuss the results :).
Custom Flex components are definitely their own beast. You have a lot of dedication to spend months working on one!
If you haven't seen it already, you should certainly take a look at the Flex Component Lifecycle. This will answer your questions about where to execute code. I believe that measure() and commitProperties() are going to be important for your component.
I also find validateNow() to be a very useful function when managing components with dynamically sized children and/or parents. I have not yet figured out when the optimal times to call this function are but it seems to be necessary when calculating sizes of Flex components. There's an informative article about it at judah's blog.
Best of luck!
Update -- I stumbled upon a seemingly great article about Flex component lifecycle at DevelopmentArc that I'm adding to my own reading list.
Is it possible to get flex renderer recycling while using browser scrollbars?
I have a flex tree control with custom item renderers for rich editing of a server-side data structure which may have any number of child nodes. If at all possible, I'd like to avoid using a flex scrollbar if the content exceeds the viewable range, instead preferring to scroll with the browser's scrollbar. I could use javascript and ExternalInterface to resize the application when the tree's size changes, but my understanding is that this would cause renderers to be created for every row in the tree, which I would like to avoid for performance reasons.
The Flex Tree component doesn't support something like that out of the box. It will create enough renderers to fill it's entire height, assuming the data provider is that large. Since you want it to be larger than the browser window, it will create more renderers than those bounds.
If you were willing to subclass or patch the existing Tree, you could probably add new properties to override the starting value and the height used for the calculation of the number of renderers needed. I'm not sure how much work this would be, but it could be as simple as overriding a single function where this calculation happens.
Obviously, when the browser scrolls, you'd need to pass new values for the start and end values of what's displayed in your Tree.