Related
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.
I know this question is vague, but I'll try to make myself clear.
I am starting a Java project involving a Swing GUI. I want to follow the MVC pattern, and could use some help from a framework to organize the project's architecture. I was thinking of using Griffon, though I suppose others might do the trick.
So, is it a good idea to use a framework in terms of:
Programming efficiency: Of course, it will be improved... most of the time. More precisely, what if the project is a small one? Or a large one? What if I'm already very familiar with Java and Swing? What if I'm not? What if the project has to be maintained by someone who knows nothing about the framework I used?
Learning value: Will I merely "learn how to use the framework", instead of learning more about Java and Swing in a different environment?
Professional value: Would companies prefer a developer who knows "more" frameworks (even if they might not be the ones they intend to use) to a developer who knows the "traditional" approach better?
I found little information elsewhere, which is surprising, considering how big this question is. It might seem trivial, but I'm actually wondering about it.
Of course I'm biased when it comes to Griffon however I'll try to be as objective as possible:
Griffon is an MVC framework/platform for the JVM. It's true that the programming language of choice is Groovy, however many others can be used too, see this example from the Guide http://griffon.codehaus.org/guide/latest/guide/tips.html#nonGroovyArtifacts where it shows how a pure Java application can be written. Other options are possible if you install a specific plugin http://artifacts.griffon-framework.org/tags/plugin/polyglot
Griffon's philosophy is one of keeping your choices open. It's true that sometimes the framework will steer you to follow particular path however it has provides plenty of leg room, that is, you make it dance to your own tune. For example, writing Views is usually done following the Groovy SwingBuilder DSL (a subtle abstraction layer on to of Swing), but you can drop down to the Java layer and write in plain Java/Swing if you want; or pick NetBeans Matisse, Abeille Froms Designer, or any other Visual tool that supports Swing.
Plugins are key to Griffon's success. As you can see at http://artifacts.griffon-framework.org/category/all/plugins there are currently 211 plugins, and more are coming.
But in the end there's only one opinion that matters: yours. I'd recommend you to spend a few hours with Griffon, if you don't see the value added by it by then ... I'm afraid we'll have to work harder to make it better.
Cheers
As we know, Griffon is based on Groovy and Groovy has a beautiful Java style, probably you will avoid lots of code line, but always we need to consider some aspects like knowledge and schedule.
Knowledge: Your productivity is related with what you know and how to use what you know, if you feel confortble in Java, use the Java, because, seems that your goal is to use MVC and as Juned said, we can do this with Swing, too.
Schedule : If you have time to study and really want to learn a new framework now, this is the time, but you must to follow your schedule, don't forget that you need to finish this project in the time.
So, consider to use what you know, and study new things to another projects.
Avoid diving in the dark without your flashlight.
I was evaluating Griffon as a framework. I got the impression that this project is slowly dieing. IMHO Groovy is not a mainstream anymore (I wonder if it ever was a mainstream?). Now everybody fancies Scala.
Now back to your question:
Most frameworks expect that you follow the standard development path. Any changes / customizations will most probably introduce difficult to maintain solutions (they will call it architecture afterwards). Choose a framework that allows you to do 95% of the things you plan to do. And yeah, choose a mainstream framework.
Griffon is based on Groovy, so you have to master Groovy first. Ok, Groovy is a JVM language and if you're OK with Java it will greatly help, but still all those DSLs will require some time to settle in your head.
If you know any mainstream framework - this is a valuable asset. The sad fact is that frameworks tend to fade / die and you have to constantly look for new buzz things. You never stop learning (although key principles cannot be changed and remain constant from framework to framework)
Implementing the MVC pattern for an environment should be easy if you understand it. First a note on it: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Now coming to your environment which is Swing based, you can implement your code by dividing it Model-View-Controller. Views are your Swing classes where are you are actually creating the user interface. In such classes, you should simply capture the user actions through different listeners but should not implement any business logic.Controller should be doing the business logic and may use Model whenever desired.
For example, you are creating a Swing GUI for login. Create a LoginView class where you will create the frame, textfields, buttons etc. And also attach the listeners to different controls as desired. Now whenever a user submits the login, you should call controller to do the credentials validation. Credentials may be stored in a DB, which should be loaded and stored in Model(DAOs). Controller should get the user input from View, correct credentials from Model, and the compare logic should be implemented in Controller.
Hope it helps!
I know this question has come up in some form, one way or another. However, a lot of them are outdated, so I figured I'd ask again plus also ask the real reason for this question.
Both Android and BB development can be accomplished via Java, and while Android adds a lot of classes and functionality on top of the Java SDK, Blackberry seems to rely on Java's J2ME. If I write an application that targets both platforms, especially from a media playback perspective, how much code reuse can I expect between both platforms? For the record, a PhoneGap based app is not possible (esp due to BB's implementation of Webkit).
IMHO, don't expect to reuse tons of code. These are the areas where you probably can't share code: UI, network, security, regex, java 1.4+ classes.
Also, android doesn't need a self made eventing system. All activities can talk with each other, or you can use services... BlackBerry doesn't have any of this.
I've being working with these two platforms for a while, and I only share the idea... The implementation is almost specific for each one.
I work on a large app which shares common code across Android, BlackBerry, MIDP, and J2SE (i.e. Desktop Java). I would say that about 75% of the code on a given platform is common code.
Pros:
One lot of code to develop/test. This is a huge positive!
If you ever decide to port to other platforms, you've already done most of it.
Cons:
You're limited to java 1.3 compatibility in the common code (no annotations, collections, etc).
UI differences can be a pain, particularly with the different event models. MVC is your friend here - at least you can share the model!
You'll want to write wrapper classes for all the platform-dependent stuff which needs to interact with your common code. This is extra code which you wouldn't have to write if you weren't code sharing.
Whether it's going to be worth your while depends on a few things... I'd at least think about the following:
How large is the project? (Larger = more of a case for sharing code.)
How much of your core functionality is realistically going to be shareable? You mention media playback - if that's going to be 80% of your app's code then it's probably not worth the effort to set up shared code.
How familiar are you with the different platforms? (More familiar = more idea of the potential pitfalls = more likely to know which code should be shared and how to structure it.)
Android and Blackberry code can be reused. I have done it before and works beautifully. A few small differences do exist. I cant remember them all, but a few
Https / Http api calls are different. So you need to code them a bit differently for both.
Blackberry compiler does not like unused imports
Other than these, I think you will be ok. But yes, do give it a shot saves a lot of time.
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 need to write cross platform application (basically CRUD).
Is usage of Java Swing good idea? Or is it out-dated and you know better solution?
I dont want to use like 5 languages for various stuff, one or two should be enough.
Java and Swing will absolutely fit the requirement, and you will be able to make do with just the language runtime as downloaded from Oracle/Sun and nothing else. Java is one of few languages that comes with a complete and powerful GUI library of its own already included.
If I were to write a program like this these days, that's what I'd use.
Swing is complete, maintained, well documented, and implemented in Java, ensuring cross-platform portability. Most relevantly, it's part of the Java language so no other downloads for the user to manage / bloat your program.
Although the default look and feel is ugly, Java 7 is to update the default look and feel of Swing to Nimbus, which looks very glossy.
If your question relates to using the language itself, I'd say "yes". Java is, like Swing, well documented and highly developed. It may seem verbose but if there's a problem, you can sure tackle it in Java.
Personally, I've always much preferred the Standard Widget Toolkit in terms of GUI toolkits myself.
Some argument and discussion.
Java/Swing will definitely do what you want. There are other solutions such as .NET/Mono, Various cross platform GUI libraries and C++.
If I had to decide today which to use it would be Java/Swing. Java because it is better supported, Swing because it's built in and JDBC simply tips the balance away from the others.
Gavin's right +1 for the SWT. If I didn't already know Swing I'd consider SWT before making a final decision. However I do know that Swing does the job well.
Since both good java answers are already given, It should be possible to do the UI in c# as well (as long as you don't use anything Windows specific). System.Windows.Forms type applications can run on Windows, linux and Mac OS X (with mono). It does require a bit more work to get the packaging done for each platform you want to support, but it is possible.
(If you already know java you're still better off using that though as the support is better across platforms and it doesn't require your users to install mono or .net)
Java/Swing is fine. I would recommend getting a license for JFormsDesigner or one of the other UI layout tools that makes life much easier.
Also, check out SwingX which is people who work at Swing making custom controls and what not that look good and are very useful.
That's also a good place to look for best practices.
Maybe you can decouple the front end from the back by creating XML request/response streams and using web services. Then you can write the front end in whatever technology you want, as long as it uses an appropriate web client.