I have a Windows Mobile application written in Java that uses AWT for the user interface. I am looking at porting the UI to SWT. I got a hold of the SWT libraries for windows mobile and I started looking at what work will be involved in actually porting it over. I think the first thing I have to decide is how to handle a large number of screens in the application.
In AWT the UI is basically a single java.awt.Frame with CardLayout. Each screen is then just an extension of java.awt.Panel, and is added to the Frame. Then whenever we need to change to a different screen we just set that panel to the top-most.
SWT doesn't have such a layout manager (and I'm not even sure if that is the best/most efficient way of doing it anyway, since the system resources associated with every screen in the application are always held). One way I thought of doing it was that each screen would be its own org.eclipse.swt.widgets.Shell. Switching from one screen to another would involve a display manager class creating the new screen (shell) and disposing of the old one (not sure of the performance hit here of creating the shell and all of the widgets every time the screen is shown?). I am not sure though if having multiple shells in one mobile application is a good idea??
Does anyone have any suggestions on the best way to handle multiple screens in a mobile application using SWT? Is there an equivalent to the method we are currently using in AWT, i.e. CardLayout? Or am I right in thinking that this is not really the best way of doing it, given the use of resources for every screen, even if they are not being displayed?
So the answer to my own question seems to be that there is in fact a StackLayout in SWT, which is pretty much identical to CardLayout in AWT. So I can use that and the job of porting from one to the other is pretty easy because they act in the same way.
Not sure how it would play out in Windows Mobile, but MigLayout is a great layout manager for SWT, which may support the kind of layout you describe.
Check out its demos.
Related
I'm writing a program that currently switches back and forth between different JPanels placed on a JFrame that also has a JMenuBar. (We're required to use Swing.)
I need to write a tutorial and right now I have it giving step-by-step instructions from a popup window. However, it doesn't seem to resonate well with test users and quite frankly it's annoying to switch back and forth between screens.
After checking out JDesktopPane and JInternalFrame it seems to make sense to place my entire program in a desktop pane and then create the tutorial using an internal frame. I'm worried that this will force me to place my different screens each in an internal frame which is NOT what I want to do. I just want the tutorial to be an internal popup(?) that can be minimized and moved around if necessary.
Am I going about this the correct way or is there a more efficient/practical way to implement the same tutorial popup feature?
I'm not 100% clear on your problem -- is it that your tutorial keeps popping up new windows for each step? I would assume that you wish both the main program and the tutorial to both be in view while the tutorial is running, and if this is so, perhaps the tutorial should reside in a non-modal JDialog, and then you swap tutorial screens via a CardLayout. ... unless I'm mis-reading your requirements and problem.
This question already has answers here:
Why is it frowned upon to use a null layout in Swing?
(4 answers)
Closed 8 years ago.
Bonjour.
Upon spending countless hours around this site looking for code to drag a component around the screen, I noticed an odd trend growing in the answers.
...being that everyone shudders at the sound of the null layout.
So I ask, what's the problem everyone has with it? I've been coding for no more than three months, using Swing for no more than one, and the layout has been a breeze to use with endless customisation possible. Why is it bad practice?
The major problem is the complexities involved in trying to make determination about individual platforms with regards to things like fonts and how pixels may be rendered
Even two systems, running the same OS can generate different output due to different hardware drivers and rendering pipelines.
Much of the API has been abstracted in such away that you should never care that one PC is using a DPI of 120 and using DirectX and another is using a DPI of 92 and using OpenGL.
Layout managers remove the developer from the responsibility of having to calculate the size a component (and its child components) at a particular moment in time as well as calculating the relationship between these components and does it in a standardised way.
The core Swing API has been designed to utilise this API, so when a component changes in some way that would represent a change in the size, all the required containers are notified automatically and the entire hierarchy of components can be adjusted as required.
The basic idea of a layout manager is to describe the relation between components on the same container as well as providing information about how much that container might like to have. This allows you to focus on the user-ability follow of the UI rather then trying to spend time trying to update the UI to meet all various possible combinations of hardware and software.
As a former VB developer (no, I'm not proud if it), I can assure you, the most frustrating part of working with it was trying to develop usable, dynamic UIs that didn't look crap on the next clients machine.
Of all the aspects of Swing, the layout management is one of the most welcomed - IMHO
Because it's not a layout. All you are doing is using a GUI editor to place your components in absolute locations. And resizing your window or running your code under a different monitor resolution will look terrible.
looking for code to drag a component around the screen
That is a different requirement. By definition when you drag a component around the screen you can't program the location.
Having said that a layout manager does more then just set the location of a component. Check out Drag Layout for a layout that you can still use in this situation.
For other situations a layout manager (or combination of nested layout managers) if the better solution for designing effective GUI's.
You will loose some points for GUI for using it, because it's hard to maintain, more code, less flexible,... Adding an extra button will lead to a lot of recalculation you have to do.
How i see it : http://leepoint.net/notes-java/GUI/layouts/nulllayout.html
Back in my, ahem, Visual Basic programming days, I remember it was very easy to create a multi-form program.
In the gui designer I could simply create as many forms as I wanted and then load them in my program where needed.
I'm having a very difficult time doing this in Java.
I started out using the Java FX Scene Builder but soon discovered there doesn't seem to be good MDI support. So, back to Swing. But, again, I don't see a simple way to design a multi form application.
I read somewhere that JDesktopPane was the way to go as it will allow you to have different internal frames, but there is no way, that I can see, to design multiple frames in the NetBeans gui designer.
You would think that you could hide an internal frame in the designer so you can layout another frame. While I can add multiple frames to my JDesktopPane, they all overlap each other making it impossible to design multiple frames.
Are there any tools available to do what I'm trying to do, or do I just need to bite the bullet and code the guis without the help of a designer?
In brief, I just want to create a simple application that displays three or four options on a home screen
Enter new customer
Search for existing customer
Quick estimate
And depending on which the user selects, opens the appropriate form. It would seem that this would be a basic requirement for almost any program and I don't understand why it seems like actually creating an application with multiple windows/forms was never thought of when developing the design/development tools. Thoughts? Suggestions?
If you're really keen on using the multi document interface (MDI) of the JDesktopPane, create each form in it's own class form. Don't drag them to the desktop. This will allow you to isolate them.
(You can double click a internal frame and it should enter "isolation" mode, basically making it the only thing you can see)
However, unless the windows are sharing information (ie you want to see the information in one window to change the information in another), I'd avoid it.
A better solution might be to use a CardLayout which will allow you to switch between each form as you need.
Again, I'd start by building your forms from something like a JPanel, individually, and when you're ready, add them to your main form.
I always encourage people who are coming into Swing anew to hand code their forms, it will give you a great appreciation for how to design forms and the power of the layout managers.
I just wanted to know if there are Java libraries that allow for smooth transitions between Java Swing Containers.
Suppose I have a Java GUI application with a single JFrame. Based upon user actions I would like to change the JPanel contained in my JFrame. Now, this I can do. However this change is instantaneous. What I would like to do is have a slow transition/animation so that it is not too hard on the users cognition.
Concrete Example:
Say the JFrame I have isframe having 2 buttons and I have two JPanel, panel1 and panel2. Depending on which button the user clicked, I would replace the frame with either panel1 or panel2. However I would like this change to be slow/animated (whatever you call it), a fade-in effect per se. So my question is
Is there some Java library that allows for such transitions?
If not, are there other desktop development language(s) that I can use for such transition. I already know of Javascript frameworks like JQuery that allow for this. But, I am looking for desktop development (if not Java then anything else is also fine).
Something like that?
I had the same need: smooth transitions and animations of components, panels and screens in my app, to create a fancy UI. Since I once made an animation engine (Universal Tween Engine) for java, I quickly setup a very small and easy-to-use library to create such animations in swing UIs, the SlidingLayout library.
If that's what you're looking for, there is a dedicated forum in case you need help to setup the lib in your project.
I can think of two animation libraries that would be capable of producing the effect you're after, but you'll have to do the work of getting the transition to actually work
TimingFramework
Trident
You should also check out:
http://weblogs.java.net/blog/kirillcool/archive/2007/04/who_doesnt_want.html
For a possible implementation
I'd also suggest checking out http://filthyrichclients.org/ for further insights
How do I create a J2ME app for cellphones with a GUI similar to the menus you see in Java games? I've tried MIDlets with Netbeans but they only show you one GUI element at a time. (textbox, choice, login, etc)
And which Java IDE would you typically design these GUIs in? Netbeans or Eclipse? and is IntelliJ IDEA usable for this aswell?
Do I have to write/get a library that draws GUI controls to screen via bitmap functions .. and keeps track of the keys pressed for focus?
Try to use LWUIT - nice UI toolkit for j2me:
https://lwuit.dev.java.net/
http://lwuit.blogspot.com/
You can also use minime: http://code.google.com/p/minime/
It's an open source GUI library for j2me. miniME works on canvas level (lowest level in j2me) to draw every control so your UI will look exactly the same whatever the handset it'll be running on. Other advantage are:
- miniME uses its own event loop to manage user controlled event (botton pressed, softbar, ..), so you Application will "behave" the same whatever the handset.
- miniME support the concept of Views and stack of view, in order to make navigation between different view/screens very easy.
Here is an example: A View is what you have on the screen at a given moment (for example the main menu screen), then to go to a sub menu, you create a new view, and by calling a simple API, you push it in the stack of Views. The previous view (the main menu) is still existing, but inactive. When the sub menu view complete his work (for example, user press back, or do a selection), you can just go back to the previous view by calling a pop api.
Your question is a bit vague to give a specific aswer, but you might want to check out LWUIT or Polish, you can develop both with either Eclipse or Netbeans.
As far as designing GUIs go, neither IDE will help from a visual perspective. J2ME UI development is all done in code, beyond creating any initial graphics in a proper graphics editor you don't get to see your output until you test.
Read up on the LCDUI package documentation which explains how the UI classes work and the differences between the 'High-level' and 'low-level' APIs.
I can't comment on which IDE to use - but I do know that to create custom UI (like the ones you see in J2ME games), you have to explicitly draw the GUI controls.
Beware that you may need to customize the GUI depending on the target phones. You have to cater for different screen sizes, key pad configurations, default theme etc. This would probably mean that you need different builds for things like different screen sizes which would drive up your Java Verified certification costs (if you need it).
You may be able to find a set of nice looking UI controls that you can buy online and use (try J2ME Polish). The easy way out of course, is to use default J2ME controls :)
Links to many j2me GUI libraries: link1, link2
I know that kuix is not bad and free - watch demo.
But i prefer to make my own gui elements - this is much more flexible (but takes some time).
As for IDE - you may want to make some kind of gui-editor tool, construct interface in it, save result to some file, and read it from your app.
It's way too cumbersome to write your own GUI, especially since there are so many available these days. If you're familiar with desktop development in VB.Net and C#, you might find "J2ME GUI" easy to use. You can download it from http://www.garcer.com/. It has a similar feel and makes it easy to learn. This is the kind of GUI that I expected to come standard with MIDP2 when I started mobile development. Would have solved a lot of issues.
If you are familiar with web stuffs then you can use KUIX (kalmeo.org/home/index) framework having xml and css supports. In place of It you can use also Polish framework (www.j2mepolish.org) it's also uses the xml in easy way rather than kalmeo kuix framework.