This question has been bugging me for some time. I've already developed a couple of apps on the Android platform and somehow always find myself resorting to Java code in order to construct the layouts. In a professional development environment, is this acceptable? Or should XML files be the go-to approach? I usually find XML a more tedious approach and often, these layouts don't look the same on all devices. I just don't get it. From a professional viewpoint, has anyone really been able to develop apps with complex views purely using XML files? This question is killing me because Google recommends using XML but the UI never looks the same on all devices unless done programmatically. Or am I doing something wrong?
Note that I'm referring to Android 2.2 and 2.3, which majority of the users use.
I use XML layouts on pretty much every fragment and activity of every app I write. I very rarely see any need to create Views dynamically, tho configuration of ListViews, showing/hiding views, etc needs doing in code. For me the advantages of XML are:
Ability to use layout editors (Eclipse)
Easier to preview layouts
Possible to benefit from auto-localisation of layouts
Easily maintain different parallel layouts for difference devices (screens)
Can get a sense of the layout by looking at it (easier than code)
Easy to break layouts down into pieces (fragments, includes, etc) to remove duplication
Keeps a separation between the visual design, and the functionality behind it
I can't think of any good reasons to put all my layouts into code - that sounds like hell.
I expect the reason your layouts don't look the same is because your XML is not defining the layouts correctly. Bear in mind the Android tools convert XML layouts into code, so there's no inherent problem with using XML layouts versus dynamic - both end up as code.
OckhamsRazor,
The answer very much depends on your needs, flexibility, and knowledge. The first thing to understand is that every Layout, whether created via XML or programmatically can be tweaked specifically or made to conform to many screens via properties.
... and somehow always find myself resorting to Java code in order to construct the layouts. In a professional development environment, is this acceptable?
Yes, it is. Android makes those available so you can do just that. However, the benefits of managing layouts via XML include standard MVC segregation, simpler debugging, and an easier time modifying the resource, if needed. Additionally, you may maintain multiple copies of Layouts depending on device configuration easily.
... has anyone really been able to develop apps with complex views purely using XML files?
Absolutely! There are some amazing programs that fully utilize XML rather than programmatic views. The key to them is how much information (that is non-standard view properties) is required from parental Views. Even in those cases there are ways to pass that information provided you know where and how to do so.
Or am I doing something wrong?
I don't think so. Honestly, I've run both ways depending on need. I'd say it really comes down to your lack of knowledge of the quirks. But the job is to get the job done. Here's an example: There are some times when I don't know how big everything needs to be until its run on the device, and there are times that I make the device conform to my layout's needs. Ultimately, I use the following chart to make my determinations.
Do I need information from parental Layouts that is aside from view properties
Do I need to dynamically size more than one element independently.
Is the View type pre-determined or will it change as well?
If the answer to 2 out of 3 of those is "yes", I will use some level of programmatic layout. If not, I will go pure XML. That being said, programming is one of those professions that encourages ingenuity (provided it is safe) and nearly anything can be accomplished in any number of ways. Ultimately, I'd say do whatever makes your job making quality apps easier.
Google makes its recommendations based on their own knowledge of software programmers and their general practices. They also created the platform, so they know which things are optimized in which ways. Its all about experience and we all have our own. If you have trouble utilizing XML, its worth taking the time to figure out the quirks simply so that it is another tool to utilize. Also, it will give you the information you need to answer this question for yourself.
To sum things up: I could say chocolate is better, but if you like vanilla, you'll disagree. Be aware of the drawbacks and benefits of each and take the time to learn how to accomplish the same tasks with both methods. It will make you a better programmer and give you a better sense of when to use which technique.
Hope this helps,
FuzzicalLogic
I typically do a lot of work with highly customizable UIs, where large portions of it need to be done in code. That being said, wherever possible I try to use layout fragments and inflate them, so as UI sections are added, removed, or rearranged I'm still just doing some of the layout, not all of it.
That being said, it's not that hard doing layout via code. The big advantage to it is compile-time checking. I'll find issues that way faster than using the preview pane. The preview pane can be nice for initial layout, but I use the Hierarchy Viewer for figuring out why my layouts don't look right.
It really depends on what type of project it is, or piece of a project, and what type of programmer you are. Some people just prefer pure code, while others like leaning as much on other tools for design as possible.
XML definitely has some benefits, like being able to switch between interface designs quickly. For specific design themes that are repetitive, is definitely useful for most programmers.
I personally prefer doing everything programmatically, and it is quicker for me to develop than writing XML, with the libraries and classes I have created. XML is quicker straight out of the box.
As for performance, there really isn't a difference worth mentioning unless you are using the same view so repetitively, at the same time, to the point that it no longer fits on the screen many fold. I did a test of how many text views Android could render on a Moto X - Android 4.4, and it couldn't get much over 5000, but there is never a purpose for that. If you are at that point, you are either need to dynamically load and unload data or are just doing something very wrong to begin with.
So learn both sides of it, definitely get to know the pros and cons with your style of programming, because there is no right answer for everyone, and let loose and have fun.
It is much better to separate the layout and put it in the xml file. I occasionally have to adjust the layout in code, but it is always an exception and only when I determine that it cannot be done in the layout .xml. If you use the layout views correctly, the application should look very similar on all devices.
Related
Are there any advantages to hand-coding your Java Swing GUI rather than using the Netbeans Drag n Drop editor? Maybe such as run-time? It seems to me that the Editor auto-creates quite a bit of extra code but I don't know if that has much impact on the runtime of loading the views. The only reason I'm currently using the editor is because it makes the GUI building quick and simple. But are there things you can do only by hand-coding that isn't possible through the editor?
Also is there a better GUI Framework? I've peeked at Java FX, but I really want the kind of effect that the Github desktop software has. It looks so slick and clean, almost like a webapp. Although I'm sure they did that in C++. It just seems to me like there isn't much for Java when it comes to graphics. One of my friends commented that all Java programs look the same and so far it seems true.
I know there are similar posts, but quite frankly they aren't very recent, such as Write gui programatically, or using an advanced gui editor (Java Swing)? which was posted in 2010 or Learning Java Swing (GUI builder or not?) which was also in 2010. If there's nothing new, sorry to bother you.
Are there any advantages to hand-coding your Java Swing GUI rather than using the Netbeans Drag n Drop editor?
There are lots, but lets start with the obvious...
Doesn't lock you into a single development environment. This means your code is sharable to others who may not be using Netbeans. This is of particular importantance when you are using things like Maven based projects
Encourages you to learn the API. You get a good understanding of how the API actually works and learn plenty of tricks to make fluent and flexible interfaces.
Encourages greater separation of respobsibilty. It's all to easy to simply keep dragging components onto a form, which does nothing for encapsulation or management. By dividing your UI into areas of responsibility it makes it easier to mange the distinct states and relations between your components. It also makes the code generally easier to read, as you don't need to keep discarding content which is not relevant to what you are trying to figure out.
Better extendability. Extending components is not easy at the best of times, but is made next to near impossible with form based components (or at least an order of magnitude more difficult)
Netbeans form editor code is...a mess...
Don't get me wrong, I use the form editor, but I've been hand coding Swing GUI's for ten years before I picked up the form editor. I like the form editor for laying out final screens and tend to use hand coded UIs for every step up to that point, putting the pegs in the hole so to speak.
The short answer is - until you can make a multi-level GUI by hand, stay away from the form designers - IMHO.
I know some people think they make great learning tools, I think the opposite, I think they allow you to develope lazy and bad habits which will affect everything you do into the future.
While the development enviroment shouldn't make a difference, not everyone will want to use Netbeans, best to learn to do without
Also is there a better GUI Framework?
That's rather a matter of opinion. Swing brings a concept of skinning through the use of the look and feel architecture, which provides you with the ability to change the way that components look and feel.
JavaFX provides similar functionality through the use of CSS
Swing is also highly customisable, it's very easy to get into the "paint" level of the components and even generate your own should you want to.
The ability to make a "slick" UI isn't about the toolkit but down to the developer. It's easy to just drop fields and other components onto a container, but it will take a developer with a good understanding of the underlying API and some talent for what actually looks good to make it look "slick".
Pretty doesn't always equal functional. The best UI's are ones you don't have to think about, that don't get in your way and just work. When you've been working with a program for hours, days, weeks, you're not going to be looking at how pretty the UI looks but how well it lets you get what you want done - IMHO
The #1 thing that hand-coding accomplishes that the GUI Builder cannot is: dynamically changing interfaces.
For example:
If you wanted to build a form that involves several JTextFields, but you aren't sure how many there will be when you build your GUI. The program will need to populate the JTextFields dynamically. This is impossible with a GUI Builder.
Also, when you have complex interfaces, the resizing behavior of GroupLayout can be cumbersome and confusing. On the flip side, hand-coded layouts are a lot of work when you are writing a complex interface (but, at least their resize behavior is predictable).
A classic GUI builder should be used for prototyping your GUI. Once you know exactly what you want, you should get rid of it and clean the code (factorize it, document it, ... in short make it simple & readable).
One of my friends commented that all Java programs look the same and so far it seems true.
Not absolutely true: JavaFX look is customizable through css. Swing is also fully customizable through the LAF system or by overriding the paint* methods (more time-consuming I admit).
If you look for something easy without the drawbacks of generated code I recommend you have a look at ReflectionUI: easy appearance customization (and that's not the only benefit):.
I've worked my way through the tutorial series of jme and feel like I've understood the basics. Now I would like to create a first very simple game. Nothing fancy just a simple test scenario: The player should be able to move an object. Then I would like to expand it. However I don't know how to start. It's hard to explain but I just don't know where to put my code. The manual says that there are "controls" (implemented as interfaces) that let you hook your code up to frequent update calls or other events (that's what I understood) but I can't grasp how to use them.
More detailed description. You could skip this:
To get the point clear - I'm coming from the engine Unity3d. The usage was quite pleasant, the community helpful and the documentation great. But you have to spend about 1000$ to get the full version and be allowed to use pro features (shadows, custom shaders, some advanced tools,...). After a while the temptation of open-source was simply to big. In unity3d you basically have an advanced 3d editor and a scene graph. You can place objects in the scene and access and modify them over the scene graph. You can use predefined objects such as lights or particle systems and change them to suit your needs but most things you use are custom made and puzzled together by different components: a mesh, a collider, a few scripts. And this is where your code comes to work. In unity3d your program is split into small scripts and these are added to the objects of each scene. The scripts have access to the underlying engine, the properties of their object and can use a special framework for math, networking,... Each script can also define functions to be called in certain events: update(), onCollisionEnter(Collider other), onTriggerEnter(Collision other), ...
This was extremely easy to use. Admittedly huge architectures can be difficult to implement but this setback was complemented by very high productivity.
Frankly: I need advice how to structure a simple game with JME.
What architecture do you recommend ?
How are controls used ?
I would appreciate a link to a tutorial (I already read the flagrush series) or any other resource.
Thank you for your help
I'm not sure how well you read the tutorials but they quite literally explain the things you asked for.
Anyway, you code everything so you don't add an object and put code in it you instance an object trough code.
Input is handled by the InputManager, as long as you still use SimpleApplication as foundation you don't have to think about it and use it the way you learned in this tutorial
I'm working on software specifications at the moment and just want to get an idea if this would be an easy/hard thing to implement.
What I'd like to do is to be able to move items(rows?) between two listbox(grid?) type controls on the same dialog; no external drag/drop support is needed. In .net apps drag/drop implementation tended to be messy and painful, and I remember MFC being even worse. Is the situation any better in java?
It is not bad at all. Have a look at the tutorial. To start with, see the code for Basic DnD demo, which basically covers what you are looking for. The only thing you have to figure out is exactly what data is packaged for the drag-drop. The right choice will depend on whether you plan to support data from outside your form to be dropped in.
I'm not sure how it is using other frameworks but this questions is strictly regarding Java swing.
Is it better to use a Visual Editor to place objects or to manually code the placement of the objects onto the frame (Layout managers or null layouts)?
From my experience I've had a lot of trouble using Visual editors when it comes to different screen resolutions or changing the window size. Using manual code to place objects I've found that my GUIs behave a lot better with regard to the screen size issue. However when I want to change a small part of my GUI it takes a lot more work compared to using a visual editor
Just wondering what people's thoughts were on this?
I never use a visual builder for my Swing UIs.
The ease to build a new UI generally becomes a pain point during software maintenance: some builders can't easily modify existing screens (in particular if they have been manually modified for some good reason); imposing a GUI builder to the people in charge of maintaining your software generally also means imposing their IDE as well, people may lack productivity if they have to use an IDE they are not used to or, worse, that they don't like.
Of course, manually building UIs comes at a cost: understanding the complexity of various LayoutManagers. However, there is a broad range of Swing LayoutManagers out there (mostly open source), some being both easy to use (and maintain) and powerful.
Two examples:
DesignGridLayout will work for
all forms-like windows and is not
only easy to use (less than 1h to
understand and use) but also enforces
good looking UIs and is the only one
(that I am aware of) where you can
"visualize" the shape of your UIs by
just reading the java code.
MigLayout is more powerful, but
a bit more complex to use and it
won't prevent you to design ugly UIs
;-)
One additional point: NEVER use absolute position/size in your UIs, this is looking for problems (your UIs may be truncated on some monitors/systems...)
You need to develop skill with both: one will always be faster than the other for some particular task. Having said that, without some manual skill, a designer will slow you down.
Personally i use layout managers over visual editors, the result is more readable, maintainable code. Also, you're not tied to any specific visual editor which may change (or stop being supported).
I personally have used over the years a lot of GUI designer - in Eclipse, NetBeans, IntelliJ. And I was never happy with the restrictions that they imposed and the code that they generated. In the end I had so much custom tweaks that using the designers hindered my work instead of assisting it. And then I found MigLayout - for me this piece of software is Godsend. It managed to take out the unneeded complexity out of my Swing labs and let me design superb layouts with minimum efforts. I don't think that MigLayout is harder to use(as someone above mentioned) - it's certainly to harder to use than CSS.
Even if you don't like MigLayout, my advice is to stay away from GUI designers. A simpler alternative of MigLayout is JGoodies Forms Layout(which MiG supercedes), jide-oss features some nice simple layouts as well. If you want to use a designer, however, my advice would be - IntelliJ IDEA Forms designer + JGoodies Forms - imo it generates much more maintainable code then say NetBeans Matisse.
We have a dilemma; developing desktop application using Matisse or Jigloo..
Matisse has this XML form files which we are afraid of maintaining later, we don't even know should MyEclipse further support Matisse, even Netbeans - do you think they will give up OS support of Matisse?
More or less Jigloo and Matisse have similar behaviour, although Jigloo obeys more designers wish, Matisse has this strange alignment behaviour from time to time.
Jigloo generates Java code which can be edited and which in turn can cause visual editor not being able to draw form. That is probably the reason why Matisse wants to have definition of elements in more stable XML form from which it generates java code.
Matisse would not help much if there is an error in instantiating a GUI element, so putting custom elements can be also nightmare.
When typing code in Jigloo, the visual editor likes to erase picture so you have to wait for picture to show up after editing code. In Matisse you can have errors in class and still editing GUI.
Please help us by voting, what do you prefer more and why.
Please don't use either! As with this answer, it's my strong opinion (after writing Swing GUIs for 10 years), that using GUI builders is, in all but the most edge-cases, a bad idea. HAND CODE YOUR GUI!
Whether you choose Matisse or Jigloo, it is not a standard, will fall out of favour and a better tool will come along. At that point, you will have legacy code that is nigh on impossible to maintain. This has already happened several times in the history of Java GUI builders.
You should avoid forcing your developers to use one IDE and it is a huge overhead to expect devs to switch to a particular IDE when looking at the GUI code. They'll be frustrated as they can't remember key bindings, project setup is out-of-date, they have the wrong version installed etc. People will make quick-fixes without the builder. At this point your code is unmaintainable in both your IDE of choice, and in the GUI builder istelf! The whole thing is a mess.
Designing a GUI is not, in my experience, a particularly onerous task and probably accounts for no more than 5-10% of the total development time of an application. Even if initially using Matisse or Jigloo provides you with a 50% time advantage over hand-coding the GUI, this is insignificant in the grand scheme of things. It is certainly not worth the hidden costs and impending maintenance disasters that lie ahead.
GridBagLayout is not hard. It just isn't! It's really simple, in fact. It will take you a few minutes to learn and after that you'll never look back. Your GUIs will look like how you want them to look and your code will be more maintainable as a result. Use GridBagLayout!
I have spent a good deal of time warning people about this before and been proven correct.
I have personally had a handful of occasions where the XML file backing a Matisse form somehow became out of sync with the code and had to resort to a backup to get it working again. This was enough to scare me away. I have no experience with Jigloo, though.
My current projects use TableLayout, extensively. It is easy to understand and (of all the layout managers I've tried) maintain. I have not found any other solution in GUI design for Java that I feel more comfortable with than coding the GUIs by hand. Moving forward, it seems like the best "future-proof" way of coding my GUIs.
I agree with Chintan on using Matisse or similar to mock up your design and then convert the layout to another layout (like TableLayout). Personally, I like using pencil and paper to do most of it. Not exactly high-tech, but it gets the job done.
I wouldn't go with either. The best thing I've found so far is Instantiations Swing Designer. It is not free, but not expensive either. It supports all major Swing layouts and DOES NOT create any additional artifacts except pure Java code.
Here is the link, if your are interested.
I would prefer Matisse since Netbeans is backed by Sun Microsystems and the possibility of the project being scrapped in the near futures seems blissfully low.
Also, I do not know the size of your project but I have developed some small ones and I personally use matisse to see how the layout would look and then go ahead and code everything using the Miglayout library. It increases the amount of coding a lot but gives good control and flexibility. And there is a possibility this library might be included in Java 7, consequently embedded into Matisse.
I prefer Netbeans Matise. Even if it is impossible to edit generated code, it's much more easier to design complex screens with Mattise(because of FreeForm layout).
I haven't tried Jigloo, but I would throw a fourth one in the mix.
JFormDesigner is the best Swing UI designer that I have ever used.
Like Matisse, it does create XML form files, but that is the only negative about this tool.
It supports all standard layout managers, plus some popular ones (such as JGoodies FormLayout). It has plugins for IntelliJ and eclipse and can also run as a standalone tool.
Here is the link
hth
Koen
What you can expect when you mess a file generated by a tool? Mess, isn't it?
This is a very very important always forgotten by developers.
Take Matisse as an example. It generates a XML file for you and a .java file for you.
Why on Earth developers start changing these classes?
Later they complain that everything is messed and they point out to Matisse as the guilt of it, because Matisse doesn't do A or doesn't do B. The only thing Matisse is guilty is not being able to fix the mess promoted by developers. This is problem in the domain of Artificial Inteligence and I personally do not expect any solution soon.
There's a more or less simple solution for it: OOP.
I explain: one of the most important concepts of OOP is 'responsibility', which means that a certain class has a limited and well defined responsibility in a broader and more complex problem domain.
So, Matisse generated the UI for you, which basically consists on UI elements, event handlers, etc.
Then you say: well... I need to add some logic to it otherwise the UI is innoperative. True. This is another responsibility, which cannot never be implemented in the same class generated by Matisse. Because either people is lazy or do not understand what 'responsibility' means in OOP, people implement whateber they need, add lots of variables and promote all sort of madness in a class which is definitely not responsible for business logic.
By a very simple thing like inheritance you can separate business logic in a extended class. The base class is the one produced by Matisse. The extended one is your class implemented by hand which contain implementation of event handlers, initialization of UI elements, etc.
Many developers are tempted to edit by hand the .java file produced by Matisse.
The golden rule is: never, never edit the .java file by hand. Matisse provides you means of defining whatever you need and call whatever you need. Never editing resources (both .xml and .java) produced by Matisse, you guarantee that it (Matisse) will be able to load it again in case you need to change the GUI in future. Probably you will find yourself tempted to edit the .java or even the .xml file directly. Please resist this temptation and educate yourself; you will thank yourself in future.
So... you can use whatever tool you wish or whatever provides the sexiest UI elements.
All tools will fail if you fail to separate UI from business logic.
All tools will succeed if you succeed in your main task as programmer which is: produce decent code.
Use WindowBuilder and be happy.
https://projects.eclipse.org/projects/tools.windowbuilder
Eclipse WindowBuilder is composed of Eclipse SWT Designer and Eclipse Swing Designer and makes it very easy to create Java GUI applications without spending a lot of time writing code. Use the WYSIWYG visual designer and layout tools to create simple forms to complex windows; the Java code will be generated for you. Easily add controls using drag-and-drop, add event handlers to your controls, change various properties of controls using a property editor, internationalize your app and much more.
Generated code doesn't require any additional custom libraries to compile and run: all of the generated code can be used without having WindowBuilder installed. WindowBuilder can read and write almost any format and reverse-engineer most hand-written Java GUI code. It also supports free-form code editing (make changes anywhere, not just in special areas) and most user refactorings (you can move, rename and subdivide methods without a problem).