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!
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.
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.
Related
I read that the window that appears using the JFrame class is a Container with the predefined features (minimize, closing), but I found people who were not using the JFrame class but other classes (one of them the Container) which was far more hard.
Why do they do it that way? Is it because the JFrame class always has a predefined window that you can manipulate some aspects of it but the Container and the other classes give you more freedom of how you can create a window?
For an example to my question (I don't know if its real or not) in the JFrame class the close button always go to right to corner of the window but if I do it the other way you can put it everywhere you like. (If it can be answered with a yes or no).
So my qusetion is why they do it that way
There are two "main" reasons why. First is about overall good programming.
We tend to recommend avoiding extending from classes to which we are not adding any new functionality or repeatable features. If the whole reason for extending from JFrame is just so you can display some components, then it's really not a good choice or starting point.
JFrame is also a complex, compound component. That is, it's actually made up of a number of other layered components which work together to provide an overall experience.
*From How to Use Root Panes
This means that there is a lot of added complexity you'd have to be willing to manage if you extended from this class, a lot of overhead just to display a few components.
In principle, it's better to use composition over inheritance, which leads into the second point.
Extending from any class locks you into that classes use case. In the case of JFrame, you can only ever display what ever is managed by the class via a JFrame, there is no flexibility or entry point for re-usablility.
If, instead, you started with a base class of, say JPanel, you can add that to what ever container you want when ever you want, it increases the flexibility and re-usability of the class over all.
For an exaple to my question(i dont know if its real or not) in the JFrame class the close button always go to right to corner of the window but if i do it the other way you can put it everywhere you like.(If it can be answered with a yes or no)
Yes and no. The frame border is defined by the look and feel delegate, so you're not actually starting at the right place to begin with anyway.
Most look and feel delegates delegate the frame border to the native platform, in the case of Windows, yes, the close button is on the right, on Mac it's on the left.
In any case, it's better to support user expectations, placing the close button in an unusual place might make the UI "pretty", but diminishes the user experience - as a general guide line, don't diminish the user experience, no matter how awesome your program or UI, user's won't like you for it - but that is a (very broad) question for another day
Both the Book of Vaadin and the Vaadin training course recommend using acom.vaadin.ui.CustomComponent to contain a Layout.
I can understand this in pure theory, to encapsulate the contents without needlessly exposing a specific layout such as GridLayout or HorizontalLayout. Encapsulating has benefits of:
Encouraging de-coupling between classes
Makes it easier to change the layout without having to change the declarations in the outer class.
But in terms of practicality, I assume the rendering of a CustomComponent means extra HTML/CSS layout instructions such as perhaps an another div. The last thing Vaadin rendering needs is yet another layering of HTML structure.
I wonder if this might be old folklore. Perhaps using the visual composing tool in Eclipse accepts only CustomComponent objects rather than Layout objects? (Just a wild guess, I have no knowledge)
➤ Alternatively, why not just declare in the outer class a reference variable of type com.vaadin.ui.Layout to get the same encapsulation?
➤ Am I exaggerating the impact of adding a CustomComponent to Vaadin rendering?
➤ Is there some other benefit of CustomComponent which I’ve failed to perceive?
You can compose the content of a CustomComponent with the Visual Designer. This saves a lot of time in the development process
The main advantage of the CustomLayout is, that you can place your components inside HTML code which you otherwise can't generate via vaadin means.
If this adds more div/html as with native Layouts depends on the specific case.
We ususally use it only when a clean Vaadin only solution would introduce more components/div's or is not possible to implement.
The second idea is the separation of layout and logic, which can be implemented partially with this Layout. You just specify which components you have and then a UI designer (in theorie) could make your HTML code, with the correct blocks where your components will be placed.
In real life I do not find this a real advantage, since the whole CSS, sizing etc. is anyway done with vaadin.
I'm developing a new application where I'll have some windows opened at the same time.
I'm currently trying to design the GUI and I'm struggling with two choices:
I could use a side navigation panel and using the center of the page to display the content of each panel. These panels would be stored according flyweight pattern and I would just hide/show them when navigation buttons are clicked (in order to save the content as is was when hidden, for example a user registration form).
I could use a front page displaying the menu all over it and use popups/new windows to show the content. These could be closed/minimized etc).
My problem is: What if all the panels are stored in my flyweight pattern? will it have a huge performance hit or will it still run smoothly with like 15 JPanels stored? (of course those JPanels will have sometimes lots of content in it such as forms etc).
What do you think would be the best easy-to-use/performance choice ?
Thank you :)
JTable rendering already uses the flyweight pattern, so a one column table is ideal for selection. A custom renderer can display an arbitrary thumbnail representation, while a ListSelectionListener can display arbitrary detail in an adjacent container. In the TableModel, consider an LRU cache if the individual data records are consuming too much memory.
As always with performance questions, prototype and profile.
As long as you don't attempt to hold more data than fits the heap reasonably, performance will be a non-issue nowadays (unless you do something exceptionally bad you will not notice any performance difference from the user perspective).
That said, unless you have pressing reason to hold on to GUI's you currently don't need - just let them get GC'd and recreate them as needed. The create-throw-away after one use approach is more flexible when the application needs to be modified and bears less opportunities for memory leaks.
As for the GUI design aspect, many people absolutely hate popups. They can also interfere with focus management/keyboard usage. But it still depends on which kind of control flow you need. Side menu bar is fine for many purposes.
I'd like to point out that the side menu is just a fancy reinvention of Tabbed Pane (which is a standard component you wouldn't need to implement yourself). Also, if things need to be done in a specific order - a Wizard like approach can also be a good choice (one Window that changes contents with each step completed).
I have designed an html document editor and I wanted some help in resolving a design problem in it. The problem is as follows -
The document editor consists of a surface (JFrame) and a menu bar. Inside the surface I have three panels - a tool panel, text panel and status panel (which are all extensions of JPanel). The text panel has the customized text pane (extension of JTextPane). Now the problem is that - there are lots of scenarios where the menus and the widgets items on the tool panel need access to the underlying document model of the JTextPane. E.g. to implement list/paragraph dragging functionality, the ruler needs to know the position of the caret inside the document model, so that I can mark the paragraph whose left inset I need to increase.
The way I have organized my design right now is that - surface is a singleton, so to access the html document model inside the JTextPane you need to code your way through the following maze -
Give me surface -> go to text panel -> go to text pane -> go to document of the text pane
Another alternative to make the reference of the document inside the text pane static, so that it can be accessed directly.
TextPane.getTextDocument ()
Also the html document inside the Text Pane I am using is not customized right now. So I am just using the default HTMLDocument returned by the text pane. Though in future I may have to replace it with a more customized extension of HTMLDocument (e.g. to implement cusom tags)
I am somewhat of a design novice. Can some design guru throw some light/insight into this?
I think if you get 10 responses you'll get 11 answers. :-)
First, there is no need for a Singleton. In this scenario, it's just a way of cheating with a global variable. And what happens when you want to have two or three text documents open?
Do your menus have ready access to the tool panel? Since toolpanel is a sibling of the textpanel, and in a 1-1 relationship (I think?) it is somewhat "reasonable" for toolpanel to know about textdocument (have a link it) and a convenience method, getTextDocument(). And it seems reasonable for your widgets to know about their immediate parent, the tool panel.
That would be my way of approaching the problem - what links between objects "make sense". You want as little coupling as possible, but there are places where you do need coupling. Maybe I have misunderstood your problem, or maybe you think a lot differently than me, in which case you should do it another way. Also, you are making a best guess as to how your code might evolve in the future. Good luck with that! :-)
One big question for any solution - does the text document change? (e.g., is there a File->New menu or a File->Open menu?). If so, that needs to be considered. In my proposal, the JFrame, on a File->Open, would create the text document and then change the link to it in the ToolBar.
p.s. MVC purists - please add appropriate models and controllers! I just talked about the graphical components to keep things simpler...
p.p.s. Examples of "thinking ahead" for reasonable enhancements
Would this handle multiple JFrames open at once? Yes.
Would this handle a single JFrame, but with multiple documents (say, a tabbed interface for the text document)? Almost. The method has to be a little smarter to know which of the many documents is active, but you can easily imagine doing that.
How about when I need to hold a lot more info about the dicument, like the name (so Save gives a good default), last time saved, is it "dirty", is it HTML or XHTML or whatever... At this point, you'll probably want to add one more model layer. But you can sortof imagine, with one more layer of indirection (one more link) this being o.k. So it depends on how close you are to implementing #3 how you want to design.
I'm creating a standalone SWT desktop application that has around 10 different screens (few wizards, help, forms, etc). Some elements on screen don't change at all (like header, background, etc) and there is a working area that changes depending on what is clicked, etc.
What is the best way to manage application screens? Do I need to create all screen at startup and then show/hide them depending on what is clicked? Or do I need to create those screens dynamically?
Also, I couldn't find any way to show/hide a Composite, do I need to dispose it and then create again?
What is the best practice? I'm new to SWT developing outside of Eclipse so any help would be beneficial.
Deciding whether to create screens up front or creating them the first time they need to be displayed is a decision that needs to be made on a per application basis. If there is a good chance that all the screens are going to need to be used on a particular application run and the number of screens is low (10 screens is relatively low) then you may want to create them at application startup so the UI is snappier once the application loads.
If you use bindings then you may need to come up with a dispose strategy (even if you only dispose the bindings) so you don't have too many events flying around.
Control has a setVisible(boolean) method (and Composite inherits from Control) which you can use to show and hide a component. Note this will only prevent the composite from being shown on the screen, the layout manager will still allocate a blank space for it. Many SWT layouts have a way to exclude a control from the layout which will get rid of the blank space. For example if you are using GridLayout then you would set the exclude variable on you GridData object to true when you hide that control.
Another option is to use StackLayout. This lets you stack a bunch of Composites on top of each other and then choose which on is on top. This might be a good fit for you if you have static areas plus a working area like you described. I would put the header, footer, and an empty composite with a StackLayout in a class file. I would then put each screen that will be displayed in the working area in their own classes. You can either have these screen classes extend Composite and then set up themselves in the constructor or you can use a factory method to setup the screen. Either one is a common and acceptable practice and comes down to a matter of taste.