views:

49

answers:

2

I have used the Eclipse plugin Visual Editor to construct Java Swing interfaces. As I'm not a big fan of the code WYSIWYG (UI) editors generate, I wanted to optimize it, when I noticed, that the editor implemented all elements using lazy loading like this:

private JPanel getSomePanel ()
{
    if ( somePanel == null )
    {
        somePanel = new JPanel();
        // construct the panel
    }
    return somePanel;
}

I know that lazy loading is used to get better performance, when the objects in question are not used immediately. However for most user interfaces this makes less sense, as a window for example should usually show all components on it right from the beginning. This is also the case in my situation where I have a rather simple clear layout, where all components are expected to exist when the window is displayed.

Visual Editor added an initialize call in the root container's constructor in which the root panel is constructed and all the other elements are added (via lazy loading). So actually all components are created right when the root container is constructed, just nested into multiple methods.

Is there actually any use for lazy loading in this case? In which UI cases should I use lazy loading? And when using lazy loading, am I actually even allowed to access the member variables directly - or should I call the getter each time?

Thanks!

+3  A: 

I'm not a big fan of the code WYSIWYG (UI) editors generate

Me either.

Is there actually any use for lazy loading in this case?

I don't think so, the creation of the component takes no time so all components should be visible when the GUI is displayed.

To me the bigger concern is the data. If your data for components like combo boxes and tables comes from a database you may not want to load it all up front.

camickr
You mean that I should rather lazily fill the elements with data? How exactly would I do that?
poke
No. He's saying that if you need to load data from a database and use it to fill a table or a drop-down, you should make that run in a separate thread so that it doesn't block the EDT while it's loading. It doesn't apply to any sort of default data, only data that needs to come from an alternate source that may take some time to load, and you don't want to block the UI while it loads.
Erick Robertson
Ah, okay, that makes sense, thanks :)
poke
Good starting point of "lazy loading" data can be AncestorListener.ancestorAdded event. Here is where you can start executing your long running data retrieval process on separate thread.
eugener
+3  A: 

When you use lazy loading, you should always use the getter each time you access the member variables. This is a fundamental part of lazy loading.

However, in this case you described, there is no reason to use lazy loading. I have to wonder if the author of Visual Editor didn't just have some thing for lazy loading where he felt it always needed to be used, or just decided that he wanted to use it in the tool for some arbitrary reason.

You are exactly right about UI's where components are generally all loaded when the panel is constructed because they're all visible. There are some cases where parts of a panel may appear and disappear based on other choices on the panel, and it's conceivable that you could use lazy loading in these cases. My point of view, however, is that people are likely to click around an interface anyways and use all the different tabs and options, so you might as well load everything to begin with.

Obviously, there's something different going on when you're talking about loading data. If you have a drop-down that's hidden when the panel comes up and has a lot of information if loaded, you may want to not load the drop-down until it becomes visible. I still see no reason not to instantiate the drop-down right away, though, even though it's hidden.

I would not consider lazy loading to be the norm behavior for a panel at all. I could not offer a reason why Visual Editor chose to generate code in this manner.

Erick Robertson