Related
I'd like to have a GWT app with a UI that is configuration-driven, meaning that if I make certain database changes, or deploy a different XML descriptor (outside the WAR), then I can change the look, feel and behavior of the UI without deploying any code changes. My reasons for wanting this lay outside the context of this question and I would need to provide way-too-big of an irrelevant backstory to justify placing it all in this question.
For instance, say with one particular configuration, the UI (a place in GWT verbiage, or page/screen) might just consist of a simple button in the center of the screen. Then, I make some database changes, and now, the same place renders with 4 buttons in each corner of the screen, and a "Hello, GWT" label in the center. Same code, but different DB values (or XML) cause the UI to look/feel/behave differently.
I'm trying to figure out how to design such a system, but am struggling and not sure if it's even possible. If it is possible, I'd appreciate a good explanation on how it might work, and maybe even some pseudo-code to get the creative juices flowing.
If it's not possible, then I'd like a concrete (definitive) answer as to why. As I've found on StackOverflow so many times now, when someone says "this is impossible!" it's usually just an advanced topic that is beyond their level of understanding :-), and what I'm asking isn't impossible, it's just hard! Thanks in advance!
Yes, this is definetely possible. I've went once through that.
But it's not a standard way of doing, so don't expect to find much in internet. You must invent the solution yourself.
Simply, you must create a channel/service/JSON service from which the GWT application will read your configuration, and build the UI according to it. You can invent your own description language, or use some existing format, for example XUL, to describe the UI. It's however a hard way, but giving a lot of satisfaction once you accomplish it.
I've been writing Java web (JSF, Struts, JSR168) apps for a number of years. With the recent departure of a colleague, it looks like I'm going to be building more client applications. I've used Eclipse since the beginning and I'm really comfortable with it. It feels as though SWT is waning (just an opinion based on literature I can find) and Swing is surging.
My question:
Is there value in learning Swing through writing apps by hand in Eclipse (as opposed to using Matisse in Netbeans)?
Yes, it is very valuable to learn coding Swing apps by hand. One reason for this is that no GUI-Designer I know always does the things you want them to do. The other - and in my opinion more important reason - is that most GUI builders (especially NetBeans') generate all and everything into one single class. This can be very annoying because the maintainability is reduced a lot (separation of concerns). Also many GUI builders have blocked regions, i.e. you cannot modify the generated code by hand. Or if you do the GUI builder will overwrite it the next time you use it.
However that standard LayoutManagers coming with Swing are very complicated. This is why I suggest that you give MigLayout or JGoodies FormLayout a try. On the JGoodies site you also find other libs for alternative Look&Feels, Binding and Validation, which can be very useful.
I would also suggest that you have a look at the Presentation Model pattern (Martin Fowler), which helps a lot if you want to unit-test your GUI-behaviour.
If you then are motivated to improve the design and add some very cool effects to your application check out the book Filthy Rich Clients.
Hope it helps.
Yes, definitely - even if you plan on using Matisse most of the time, you will benefit from having at least a reasonable understanding of the Swing code under the hood.
It sure will help. Maybe you'll reach the end of what Matisse can do, and want to tweak some of the code by hand. At this point it will be better to know what happens under the hood.
Note that using Matisse and writing Swing by hand are not mutually exclusive at all. Matisse just produces Swing code, and you can customize it. You can make part of your GUI with Matisse, and the part next to it by hand, for instance. Get the best of both worlds - that's how I do it, at least.
Fast way to learn how to do something in Swing is to do it in Matisse, and then see the code it produced.
You definitively need to know how Swing works since you will most likely have to adapt and change things which the GUI prgram expects you to know how works and what it is called.
The Java Tutorial has a good Swing trail: http://java.sun.com/docs/books/tutorial/uiswing/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What mechanism do you prefer for building a GUI: from scratch or using GUI-building software?
If the question is about GUI development using Swing then IMO it is best to code everything manually without a WYSIWIG tool.
In order for a manual UI design/coding to be efficient a really good layout manager should be used. MigLayout is one of such layout managers. Since I've started using it I have never looked back at WYSIWIG tools -- a sheet of paper, a pencil, MigLayout and you get a full control over your design and code.
Also tools like Balsamiq simplify making GUI mock ups for quick prototyping if the paper and pencil approach is not suitable.
My personal opinion is never use visual editors. Until there is a single standard for GUI-building in Java you will find yourself tied to an IDE. The best IDE for building Java GUI has switched around quite a bit in the last 10 years (I wonder how many projects were hit by a massive maintenance overhead from switching away from JBuilder for example).
For most applications, the actual layout of GUI code is probably something like 5-10% of the total amount of time you are likely to spend writing the app as a whole. Therefore even halving this by using a designer is not really saving you very much in the grand scheme of things.
Taking this together with the lack of flexibility and more complicated maintenance, it's almost always better just to write the GUI by hand.
I actually enjoy building GUIs with the NetBeans GUI Builder; the thing is, it is fairly customizable - it allows you to change the code used for auto-generation and the auto-generated code [no pun intended] (which is necessary for custom components), it also allows "easy" event-handling and binding. And NetBeans GUI Builder is not restricted to GroupLayout but rather allows you to choose which LayoutManager to use (a somewhat hidden setting in the form's properties dialog).
But it is not always the best choice; as others already said: MiG Layout is a good choice when you need to have full control of your application, knowing every single JLabel, every JButton etc.
I must confess I prefer Netbeans' GUI builder for the ease of use and WYSIWYG view.
But I also think that it does not even matter if you have created the GUI-Code by hand or with a GUI-Designer; adding Controls / custom Components dynamically works with both, doing this and that works with both etc.. The only thing that matters is that it works.
(From my point of view I do not see a point in coding a GUI manually if it can be done faster with a GUI-Builder, as I do not see why one should bother coding it by hand without some kind of benefit)
I use GUI builders to rapidly prototype designs and stuff like that. But when it comes down to building the actual production GUI, I code it from scratch. I'm not morally opposed to GUI builders, but I prefer the greater control over my code I get from writing it by hand.
Like any code generator tool, IMHO, you shouldn't use a GUI builder until you at least understand the concept - in this case, the Swing layout managers are particularly tricky.
If you give me the choice between NetBeans and by-Hand I'd definitely choose by-Hand. I was never really convinced by the NetBeans GUI builder's approach. At least the last time I used it, it relied on some proprietary sidecar files...
Look at Visual Editor for for Eclipse
You will still want to understand what the editor is doing for you.
You need to know how Swing works to be able to make things work properly. Nothing like building by hand to learn that :)
THEN the Netbeans GUI builder is rather nice.
Edit: I would strongly recommend going through the Java Tutorial Swing Trail - http://java.sun.com/docs/books/tutorial/ui/index.html
Both - use a WYSIWYG editor to get the ball rolling, but at the end of the day you'll need to manipulate your controls and in some cases create them programmatically at run time. Eclipse has a variety of free editors as plugins. Go to eclipse.org and look through the plugins listing.
Depends on your requirements. Some GUI building software work really well with simple applications, however, if your client requires many custom components the third party GUI builders may not work.
Also, it depends on the amount of forms and the complexity of them. If you need to build a form for each table in the database, for example, a third party GUI builder may be faster and cheaper.
In my experience, it really varies from project to project.
If you want a complex gui, then use something like netbeans to build it and create all of the events. If you're looking for a fairly simplistic gui, then building one by hand is still an option.
My company uses Netbeans for GUIs and eclipse for the regular programming.
We have looked but we haven't found any other (free or at least cheap) tool that does GUIs as good as NetBeans.
I used to write them from scratch with a plain text editor...
That depends what the reasons you're making the UI for,
I found that there are two reasons to make UI:
First is for clients, in these cases you want to UI to be polished and to handle really well in projects like this the core or essence of the project is the UI itself.In these cases it's usually the best to hand-craft the code for your UI because it's probably non-trivial code.
Second reason is usually quick & dirty UI where the core of the program is something else and the UI is created usually for Control aspects on your main application and you are the main client. In these cases the best thing to do is make the UI as quickly as possible as you don't want to "waste" time working on it and its more legitimate to use WYSIWYG editors.
I always find a GUI builder to be a good idea to begin with and then I end up in a situation where I am wasting my time fixing things to my own ways rather than that of the IDE and making them actually suit. And don't get me started on the messy code that GUI builders generate! Hence, it's often more efficient to build from scratch; at least for me...
I prefer hand coding the GUI myself so I can have complete control. For complex layouts I will use JGoodies Form Layout. Their syntax for specifying the layout makes it easy to draw the GUI on paper then transfer this to code.
I tried the Netbeans GUI builder and was impressed by how easy it was to use. Then I looked at the code it generated using GroupLayout and decided that by going that way you were basically locking yourself into Netbeans which was something I did not want to do.
I started by coding it manually using Swing. Now I use WYSIWYG editors, but I think it's important to know what's behind the editor. Also you might need to update the code manually, WYSIWYG editors often can't do exactly what you want.
Having created Java GUI's extensively, I can assure you the process is quite often painful. I'm well aware that Java's strength does not lie in it's GUI, but I'm surprised that a decent free interface builder tool hasn't been released.
Sometimes I'll use Eclipse's Visual Builder tool for quick and dirty mock-ups. It's code generation is a bit scary IMHO. I believe Netbean's Visual Editor is the best available at the moment (for free anyway); however, I find myself hand rolling GUI code for consistent cross-platform layouts. If your disapointed with these free GUI editors (like me), quite honestly, just use a layout library (like MIG) and just do it yourself. It'll be slow at first, but you'll have a lot more control and less editor newonses.
It really does depend on what you are trying to accomplish with the GUI. When I was tossing together ideas for a Computer Science class and testing functionality, the Netbeans WYSIWYG editor was great since it automatically generates a lot of the code for you. However, I found you tend to get better control with doing it by hand (in Java) than learning Netbeans.
I tried to use Eclipse's Visual Swing plugin, but on some occasions, the code it generated just disappeared, and I was left with a screen full of errors. In all the GUI apps I write, I use Netbeans, even though I hate the code generated when using GroupLayout. However, if layout code is not your concern, I think you'll be very pleased with the development speed it offers you. The only thing you'll have to do is implement the event logic and other logic you may require.
Eclipse's Visual Editor is a great choice, because the code that it generates is very straightforward and there's no hidden magic. Plus, you can make changes by hand and the editor will reflect them.
I test-drive the model of the UI, so that I have the functionality of the UI enclosed in a class that is completely decoupled from the GUI library and can be easily tested in isolation. Then I create a thin wrapper layer on top of the model, so that the GUI's event handlers are mostly one-liners that delegate to the UI model.
I've been using mostly IntelliJ IDEA's GUI builder (using the JGoodies Forms layout manager). It has been quite handly for laying out components in a static layout. But I think that for example with MiGLayout it's quite easy to write the GUI layout code by hand, so a GUI builder is not necessarily needed, and it helps to avoid tool lock-in. And dynamic layouts will anyways need to be written by hand.
But before writing any code, I first design and test a paper prototype of the UI, so as to have a clear vision of what needs to be done.
If you aim to create the final Java GUI, I recommand the Eclipse plugin named "Jigloo GUI Builder", which can generate clean and maintainable Java code.
If you just want to create the GUI quickly for review, you can try the UI prototyping tool like "ForeUI".
There's nothing wrong with using a GUI Designer when :
You understand what the IDE does and what it generates, how to customize the IDE output
You understand the code actually generated by IDE
Understanding at least the basics of Swing is important. Imagine the following scenario which happens just too often.
Q:"I have 10 years of experience writing swing applications"
A:ok
Q:How would you debug this code
A:Oh wait, there's no Netbeans form file??? You guys are not high tech!
Q:Hum.. you don't understand it?
A:Of course not, it's like machine code, you need to refractor it all and use an IDE!
I find that GUI builders can often complicate things and I'd rather know what was going on when the GUI was built than just use the variables created. I think because I don't know everything about Swing and layout managers as well, I am afraid to generate code that I have no conception of or don't know truly how it works.
When I was doing simple scripting using AutoIt that I knew would only be used on machines that had big enough screens I would use the GUI form editor. However, with commercial applications and those which may run on machines with any specifications I would generally shy away from GUI builders.
That said I think my decision may be influenced by my lack of knowledge regarding layout managers and maybe in the future I will start to embrace them more, as I can see nothing wrong with using them when you have a full understanding. Unlike some programmers may state, it is only a lazy way of building a GUI if you use the software with lazy intentions, and not for efficiently as the applications were written for.
To answer the original question directly, 99.5% of the time I will write the GUI from scratch!
I've played around with the netbeans visual editor for java and it seems very intuitive and simple to use but I can't help but think: is this detrimental to my learning? Should I be getting my hands dirty and doing everything manually? How do professionals in the field handle user interface design?
What would you guys recommend I do?
The main drawback of GUI builders is that they make it easy to do simple things and very difficult to do complicated things. It's the same as building a website with a real design tool vs. using a simple website builder like iWeb or FrontPage.
The three most important topics in GUI framework are learning the event model, the layout model, and the intricacies of each widget. GUI builders isolate you from the latter two and kind of restrict your exposure to your first.
In the long run, it's detrimental to the things you can achieve, and therefore detrimental to your mastering of GUI creation.
In addition, maybe behaviors that are very important to the users (e.g., blanking out one widget in response to change in another) are quite tricky to write, especially with automatically generated code. Complex GUIs often rely on models, and GUI builders often through everything together, so it's much easier to end up with horrible unmaintainable code.
For learning design I think a visual GUI editor is fine. Design has nothing to do with what tools you use to create the design. If your goal is to learn how to create a pleasing user experience a visual editor might be very helpful.
For learning how to create an application with a graphical user interface I think it may be detrimental, though that really depends on the individual. At some point I do think you need to "get your hands dirty" so you can learn exactly how widgets interact with business objects and with the user.
I would recommend that for every new component you use, you first handcode it at least once just to make sure you understand.
But theres no need to get redundant and just spend all your time coding locations and sizes when the visual editor does it for you.
What I would do is just make sure you understand child forms and parent forms and leave the repetitive technical things to the editor.
Understand the underlying code. If that means practice by writing a form window so be it.
However, don't waste time on it or pain yourself. It is hardly ever required to actually go in and play with the underlying generated code.
I would definitely not recommend getting too far consumed by it. It is simple and repetitive code that is generally quite simple to figure out when the time actually shows it self.
I recommend getting your hands dirty with the underlying parts of the code. The problem I find with Visual Editors is that they can often generate unclean code, or code that is difficult to understand when someone else needs to make changes.
Once you have a clear understanding of JComponents then you can play around with the visual editor to understand the code that the editor generates. I recommend playing around with the examples provided by the Sun Website for Java GUI programming.
i use GUI editors just to make the template/repetitive tasks through applications, and make the dynamic elements by hand
I'm starting a fairly complex Swing application that heavily graphics-oriented with about 1000 separate jpegs, 30+ different forms, and timers keeping track of the rate of user-interactions throughout.
My question is from a practical programming perspective, after I've already written a storyboard for the entire project and got it approved by the client, where's the best place (code-wise) to begin programming this massive project and in what order should I program the elements?
(Example Answer: first begin coding the declare and init statements of all the necessary pieces, then write skeleton versions of all the methods, then deal with swing design and layout manager (gridbag), and then deal with Events and Listeners)
Thanks for the advice everyone, oh and btw I really love StackOverflow!
You're describing a "waterfall" development approach - completing some level of the program first, then completing the next level etc. It's indeed one possible approach, but many people find it so called tracer bullet approach better; first make something functional, then learn from it, adjust what's needed and proceed. It's especially useful if you're working with a client, because by showing prototypes you can get feedback and avoid misunderstandings.
I'd pick up a book on TDD and even if you're not going to write automated tests, it will be full of good advice on how to approach your project.
After that I'd pick a single piece of functionality that slices all the way through your application vertically and implement that end-to-end. This should allow you to get any infrastructure/frameworks in place and spot any gotcha's that may get thrown up out of your design.
If your client has the time free, show them each piece of functionality along the way and make sure that every piece you do adds some value to the product.
--EDIT
In addition I'd take a look at using a graphical designer for your screens instead of using the GridBagLayout. That will just waste time and can quickly become a maintainence nightmare when changing screens. I personally prefer the ones that work in a resource file type way, where the screen is essentially "compiled" and you just load it into your code
I prefer writing the UI so, that first I write (using TDD) the backend classes which implement the behaviour of the UI, without any dependencies to the presentation of the UI (i.e. without Swing or any other UI library). After that I write a thin presentation layer with an UI library, where all the event handlers etc. delegate to the UI backend (they should be just one-liners without any logic). The benefit of this is that you can easily write tests for the UI, which in turn makes it easier to change and maintain the UI. See the links at http://martinfowler.com/eaaDev/ModelViewPresenter.html for more details.
At a higher level, first implement the features which will produce the most value to the users. Try to get something to show as early as possible, so that you can get feedback from the users and improve any deficiencies in the UI. You can fake most of the background services (for example the database and business rules), so that the UI can be used, even though it does not yet really do anything.
I think mad-j has the words of wisdom.
Don't concentrate on the 'all'... identify sections/components/modules and deliver those. Then move on to the next and the next. This is called Iterative and Incremental Development (a response to the weaknesses of the waterfall model)!
This will also allow you to create tools and frameworks which should make your development easier and faster as you move along.
This will allow you to show your clients functional parts early. But a word of advice! Your client will more than likely keep changing its requirements, changing the GUI, changing its mind, etc. I've seen entire projects fail due to these continuous changes. It is out of the scope of this question to mention any more on this, but please be aware that it more than likely will happen and be prepared to deal with it!
If you and the client have functional parts, they can be tested immediately rather than testing one huge system.
By completing functional parts iteratively will probably allow you to work at every layer, on most API's using most tools and technologies. The advantage of this is that it will allow you to identify the complexities early. It is those complex areas that render this following statement true:
The first 90% of the code accounts for
the first 90% of the development time.
The remaining 10% of the code accounts
for the other 90% of the development
time. --Tom Cargil
Identifying, acknowledging and understanding those complex areas will allow you to manage your risks and alter your efforts and resources more effectively.
Good Luck,
Jeach!
As mentioned by MrWiggles, you may want to look into using a UI builder.
If you're looking at writing many forms, and it looks like the form data can match nicely to some javabeans, you may want to think about creating some framework panels first.
If you can create some simple base classes that take care of the wiring (syncing the fields to the beans and vice-versa), it'll save you a lot of work.
You may even want to set up some panels that will "auto create" fields based on beans. Just pass in a bean and the panel creates itself. The trick there is specifying layout for the fields, and dealing with fields that have fixed values, validation, etc. (Fixed values can be dealt with using javabean property editors - see http://javadude.com/articles/propedit/index.html.
If you're set on using Swing (eclipse RCP is nice, btw), you might want to look at the Swing Application Framework (https://appframework.dev.java.net/). If not using it directly, it may give you some ideas on how to set up bindings.
Hope this helps a bit
Are you really sure of Swing? Eclipse RCP is much better and flexible starting from EMF and going on
Anyway with Swing, first I'll prepare an XSLT template of all: common code routine and other common pieces of common to bring then them in abstract and interface classes, ORM patterns you use.
Then I'll design a common UI scheme, this "xslize" too.
After all with ANT XSLT processor I'll prepare a complete build procedure upon your specs.
P.S.
I made similar projects for simple web and swing cruds just before 2001, and if you use some peculiar UI designer you can also nest or write with xslt every specs without putting dirty code in your ui raw concepts, so when I make/add remove features on all or singular piece of code, 30 seconds maximum for full rebuild of ALL, of course you must "XSLIZE" all using also many xslt overrider/import.