Hey,
i've a simple question.
Task:
Program a backup system which can be used by server-, or desktop-systems. The backup system should include a graphical configuration and status view. The programming language should be Java.
Question:
Would you use a web interface, which will solve these jobs or would you create a GUI in Swing?
My thoughts:
- The web interface has the advantage that is is accessible from everywhere (server - configuration made easy without any additional software on the client side).
- The GUI has the advantage that it is more responsive than a web interface and will maybe look more professional on a desktop-system than, the web interface version.
Which solution whould you choose?
Thanks!
The desktop vs. web app discussion usually depends on who would use the application, and from where. If it's always going to be used by the person sitting at their desk (or at the desk of the server), a desktop application is a good choice. If the user may be remote a web application is the way to go.
Another consideration is deployment. Is this going to be deployed on one or two machines, or does it need to be installed / available to 10's, 100's or 1000's of users? Deployment and updates across hundreds of machines can be onerous for desktop applications, but a non-issue with web-based apps.
Generally speaking, you can give a much richer experience with a desktop app. In this case, however, "rich" isn't really a requirement. You're going to have a few buttons, perhaps a window showing a log of some sort, and that's about it. So from a usability perspective you can probably create a compelling UI using either method.
If deployment and a rich UI don't really factor in, pick the one that either a) you know well, so you can do a good job, or b) want to learn assuming you have the time.
Since the actual question you asked was "which would you choose", personally I'd choose a desktop GUI based on the little information provided in your question.
Yeah Bryan is totally right. Choose the solution you prefer, since you are the developer :)
I'd prefer the web solution, because I love to play around with these nice Web 2.0 AJAX/JS things. Also there are at the moment a few new Browser Developments, which will make it possible to use an webapp as desktop app.
Basically, it's really no matter which variation you choose.
I did serious Swing work in the past but I see less and less the incentive to use "fat client" technologies with today's web based UI (Ajax, JQuery, HTML5 and efforts like html5boilerplate.com to make them work on older browsers). The browser is the present and future of rich UI, specially as more software makes the move to the cloud.
Related
I saw some other similar questions on this topic here but they were not very helpful so I a posing this question.
What is the fastest way to convert a reasonably sized, simple web app to a Java desk top based client targeted for pc and mac? Unfortunately I can not share a whole lot of details about the app here due to various reasons. The most complicated UI in the app though is a page that contains a multi level threaded discussions (please see here for an illustrative example of what I am talking about.) The current web app is based on python so I can not re use anything from the server side code (dont think this is an issue)
I have never done any swing or awt or any other Java based thick client GUI work. My thinking is more or less defined by web based applications. I am capable of doing end to end web app development (including backend and decent UI using HTML, CSS and JS) using Java or python. For your answers please focus on Java solutions only.
So here are my questions
What is the best framework or tool I should use? I found some of the following tools on the web as part of my research.
Awt - does not look like this is a good choice.
Swing which I believe is bundled with regular Java SDK/JRE. - This may be my best
bet.
SWT which seems to compliment Swing in some fashion.
Griffon based on an article here. This framework uses Groovy ( I
have no clue about Groovy, btw) Adobe Air flex. Any open source
frameworks?
What are some of the other issues that I need to keep in mind? Some that I would like your comments on are:
How does the fact that it needs to be deployed on the client complicates things? Since we are using Java, I believe this to be a non issue. I am aware of the usual trade offs between a web based app and a desktop app (e.g. ease of deployment and upgrades etc etc.)
How easy is it to create a one click installer and bundle the app and the environment needed - eg. JRE etc?
The product needs to work on Mac and Windows. Does that complicate things in any way (Again, since it is Java I am assuming there are no gotchas but would like to be forewarned if there are any)
What is the framework or technology that may be good to have on the resume as a skill set?
My deadline is a max of 2 months - would that be enough for a reasonably simple web app given that I need to learn all of these technologies? I am just trying to get a sense here - I know it is most likely impossible to give an accurate answer - just assume I am smart enough and can pick up any unfamiliar tech stack fast enough.
Thank you!
GUI toolkit
Given "Mac and Windows", I'd say that settles my recommendation as "Swing" (perhaps with SwingX1).
I agree with your assessment of AWT. It does not support formatted text in any component out-of-the-box. It also lacks trees, tables (and other components) & people with recent experience using it. Note though, that it is also "bundled with regular Java SDK/JRE" just like Swing, it is just that it is older and less enabled than Swing generally.
If anything complements Swing it would be SwingX. SwingX is built on Swing and provides advanced controls that are not available 'out of the box' in the J2SE.
Swing and SWT are mutually incompatible - use one or the other.
I have no experience with Griffon.
Swing is the most used of the options outlined, so for getting help (ignoring other potentially important factors in the decision), it would be a good choice.
Note 1) Add SwingX if they have any groovy components that present threaded conversations easily, but I suspect a JTextPane would suffice.
Deployment
As far as deployment goes, that is a little more tricky than it seems. Many desktop computers do not come with Java as standard. Those that already have it, might have an old version.
To ensure a JRE of the right minimum version to run the app. is available, use the deployJava.js (mentioned, with links, in the JWS page below).
To provide a 'one click' launch experience for the user, look to Java Web Start.
Cross-platform gotcha's
Unfortunately, though Java is x-plat, there are plenty of things that programmers can do that stuff that up. E.G.
Not accounting for the platform default:
File encoding (file.encoding2)
Line break (line.separator2)
File separator (file.separator2)
Coding fixed size ('absolute layout') apps. that will be shown as different sized apps. on other OS.
...
Note 2. That is showing the property to use for each.
Timetable
Obviously I cannot speak for you, but I can tell you that I would have had no chance of going from 'which technology' to a 'deployable app' within two months.
Hope you're more capable than me! ;)
You said that you wanted a Java solution, but be aware that there are plenty of Gui options in Python, and you already have your web application written in Python.
Groovy is a different programming language than Java, but Groovy runs on the JVM. Do you want a Java solution or a JVM solution? I ask because you mention Griffon.
Assuming you want Java, I think your main options are Swing, SWT, JavaFX 2, and Apache Pivot. Oracle has said that they intend for JavaFX to replace Swing as the GUI platform of choice. That said, JavaFX 2 is in its infancy, and only a preview release is available for Mac right now. The upshot of JavaFX and Apache Pivot is that you could use the same code for your web application as your desktop application.
You can try doing so in small steps:
* As a first step you can create an applications with SWT and embed your application in a browser control.
* Then you should move pages and some controls from the web app to the desktop one by one.
In this way you can get a minimal application in hours :)
P.S. If you want an iOS app with this approach it's worth looking at this open source project: http://en.wikipedia.org/wiki/PhoneGap
I'm about to start developing a large-scale system and I'm struggling with which direction to proceed. I've done plenty of Java web apps before and I have plenty of experience with servlet containers and GWT and some experience with Spring. The problem is most of my webapps have been thrown together just to be a proof of concept and what I'm struggling with is what set of frameworks to use. I need to have both a browser based application as well as a web service designed to support access from mobile devices (Android and iPhone for now). Ideally, I'd like to design this system in such a way that I don't end up rewriting all of my servlets for each client (browser and phone) although I don't mind having some small checks in there to properly format the data.
In addition, although I'm the only developer now, that won't necessarily be the case down the road and I'd like to design something that scales well both with regards to traffic and number of developers (isn't just a nightmare to maintain).
So where I am now is planning on using GWT to design the browser-based interface but I'm struggling with how to reuse that code with to present the interface (most likely xml) for the mobile devices. Using GWT RPC would, I think, make it relatively easy to do all of the AJAX in the browser, but might make generating xml for the mobile phones difficult. In addition, I like the idea of using something like Hibernate for persistence and Spring Security to secure the whole thing. Again, I'm not sure how well those will cooperate with GWT (I think Hibernate should be fine...)
There's obviously a lot more to this than I've presented here, but I've tried to give you the 5-minute overview. I'm a bit stumped and was wondering if anybody in the community had any experience starting from this place. Does what I'm trying to do make sense? Is it realistic? I have no doubt I can make all of these frameworks speak the same language, I'm just wondering if it's worth my time to fight with them. Also, am I missing a framework that would be really beneficial?
Thanks in advance and sorry for the relatively broad question...
Chris
I'll be pretty specific here since I have some related experience. Not all of what I'll write will apply, but I'm hoping something does.
My 1. advice would be to keep any code that's directly dependent on any framework as "stupid" as possible. If you can, consider such code more or less disposable (implementation wise, API contracts exposed to clients needs to be stable of course).
Focus on what makes your application unique, and try to make that independent of GWT etc. The facade pattern is something I can recommend - keeping the app-specific logic behind one and exposing it by wiring the presentation layer with it has served us well. If your back-end depends on third party infrastructure (via web services etc), decouple those dependencies from your code with the adapter pattern.
I have spent most of my working time during the past 5 years on building something that matches what you described in many ways. Today it's more an app framework then an app - it has a few different browser interfaces (WAP/standard web+ajax/Facebook app), an interface for 2-way SMS usage, and a REST/XML interface for thick mobile clients - BREW, iPhone, Android and Blackberry.
When it comes to frameworks, for persistence, we have used Hibernate. All the different pieces of code are tied together with Spring. The browser interfaces have been ported from Struts (1.x) to Wicket. The SMS and mobile client interfaces are built on top of Restlet.
Using multiple different presentation layer frameworks (such as Wicket and Restlet in our case) has not been a problem, as long as that code is kept lean and business rules are kept out of it (to the extent possible). There is nothing that says that your browser interface has to be packaged into the same WAR as your mobile client interface - with Spring you can easily wire several web applications with the same facade. This has been helpful to us especially in allowing multiple developers to work on well isolated pieces of the application.
In my opinion, trying to achieve maximal reuse of code in the presentation layer has caused more harm than good. That has always been the most volatile part of our application, beyond what we have been able to expect.
Is it possible to develop an application easily available on the web that also can be distributed on DVD (installer or started from the dvd)?
For the moment, we use static html (frameset!) pages (generated by xml files), with one difference: pdf's are only on the DVD version, the web version only shows a preview of these files.
Can this be done with JavaFX, OpenLaszlo or are there better options?
(for example: turbogears, and using tg2exe for DVD version)
I think if you design it correctly to begin with, a JavaFX app can be interchanged between web-app and desktop-app relatively easily. However, I've only done this with very simple apps (specifically, Tic-Tac-Toe!), so I'm sure there might exist some caveats that I am unaware of (thus the "design it correctly" catch-all). ;)
Why don't you just provide the PDFs in your current web version, rather than redeveloping everything? I'm not aware of any browsers that don't support in-browser PDF reading anymore.
Yes JavaFX or Flash applications can be used to develop applications that run in different contexts.
However, it's not clear from your question why these would be preferable over your current solution.
If the information your sharing is primarily text and you're using DVD because your audience is primarily located in area with bad Internet connectivity, then you're current approach probably makes more sense. JavaFX or Flash might be more fun to write for developers but maybe doesn't serve your audience.
I would suggest that if you are shipping DVD and are looking for ways to make the DVD more useful than as a PDF delivery system would be to add video to the DVDs. And then maybe it would make more sense to use JavaFX or Flash to drive the UI.
Yes, it is possible. If you use JavaFX you will be allowed use multiple deployments. For example, NetBeans 6.7.1 with JavaFX creates several possible deployments from one project. Then you can publish this application on web, DVD, etc. You will need to slightly customize standalone deployment for DVD to be able e.g. start it as autorun if necessary. JavaFX is good choice.
This seems like a job for flex, however I know better little about it to give a better answer.
I've got an application here that I wrote many years ago that consists of a heavy-weight front end that directly queries a database server. This application runs on about 7 dedicated workstations. There is also a web-based front-end that I whipped up that shares the same feature set, and a web-based administration too for managing and reporting on the data -- they all just hit the database directly.
The application is quite simple and I understand the problem it solves very well. It could use an update, and I don't even have access to the tools necessary to work on the GUI anymore. I've been getting into Java lately, and it seems like a rewrite of this app would be a good project to get started with.
So my question then is this:
The application will require a non-web GUI, I suppose in Swing. This is necessary for very particular reasons. The application will also require a web-based GUI with the same exact features as the Swing front that will probably be deployed as a JSR-168 portlet, and a web-based administration tool (portlet also). With my previous design I ended up with a lot of duplicate code because each component had its own code base, and I foolishly used stored procedures to help to ensure that critical calculations were at least consistent.
Where should I start? I'm having such a hard time wrapping my mind around how this should all work in the Java world. I guess what I'm having the hardest time with is how do I create an application that can have both a Swing (or whatever) front-end and a web-based front end with as little duplication as possible?
Edit: I know conceptually how this can work. What I'm asking is for advice specifically related to Java technologies. Which frameworks to consider, etc.
Build a Core that contains the business logic. Use JDepend or a similar tool to ensure that it nowhere references anything swing or anything web/jsp/servlet.
Build the two UIs: For the web version pick a webframework of your choice and call your business logic from there.
For the Swing framework you have two options: access the businesslogic through webservices (you could use RMI or whatever, but I wouldn't), i.e. the logic is on the same webserver that serves the webapp (I'd probably prefer that). The alternative is to ship the weblogic with a swing GUI. Makes the coding and debugging easier, but now you have multiple points that access the db which causes headaches when you want to use caching
In any case you should only duplicate the gui stuff, once in html/css/javascript and once in swing.
Congrats on that project it will teach you tons about design and software architecture
You should have a project with all business logic.
Then, 2 separated projects, 1 for the web access, and 1 for the Swing application. those projects both calling the business logic API.
in these 2 projects, have only presentation code
Use a middle tier server.
Swing Client -> middle-server with spring-remoting -> database
Web Client -> middle-server with spring-remoting -> database
Web Client write once any MVC framework will work stripes, struts, even grails if you are brave rememder to keep it thin....
Swing Client write once using miglayout, and glazelist.
http://www.miglayout.com/
http://publicobject.com/glazedlists/glazedlists-1.8.0/
take a look at this posting.....
Java Swing: Libraries, Tools, Layout Managers
Middle-server write once using jdbc cause you have the db already..
http://www.springsource.org/
database write once using whatever you like. It seems already have this....
Obviously start with a unified code base. You might also want to consider whether you really do need multiple interfaces.
You want to make sure that your code does not have unnecessary dependencies. For instance, make you UI as shallow as possible, rather than the usual ball of mud. Avoid singletons, as they cause dependency hell.
It may seem very enterprisey to have a middle tier, but it also adds a lot of work. For a small group it is entirely pointless.
I've been experimenting with Adobe Flex recently. Being a long-time server-side web app developer, I'm faced with difficulties that I last experienced when I dabbled in Java Swing development a long time ago. It mainly revolves around the flow of control between my code and the framework's code. Most things are asynchronous as to not freeze the UI.
So, I'm looking for all the seasoned developers out there who have seen it all to put into words the shifts in thinking required to make the transition from traditional web apps to RIAs.
Update: Moved the distracting parts to another question.
There's two models I'm seeing in the market right now:
Blended UI. The server is still involved in the UI construction effort, but a lot of it is offloaded to javascript. This is how a lot of the javascript toolkits work (except dojo, extjs, ...).
Separated concerns. The server is treated as a data storage and synchronization method only. The app runs entirely client-side, possibly even with local storage. This is how flex works.
I think we're going to be migrating towards the second model, because it means that you don't have to track UI state on the server, which dramatically simplifies the architecture. I've been toying with ExtJS and Flex, and the development experience is a lot like building a desktop app, only without the fancy drag-and-drop IDE's. It's hard to think of large differences between a three-tier desktop app and a web app in this fashion.
So my advice would be: stop thinking you're building web apps, always put into doubt whether something belongs on the server, because in the new model it often won't. Also, use gears or the browser cache effectively, because if your app is client-side, downloading all that code every time will be too slow.
Two pieces of advice:
Your server should never ever trust anything given to it by the client. Like any web app, data originating on the client can be compromised.
Visualise. That's the real (perhaps only) benefit of RIA: the ability to give rich interactive visualisations of data, that can be mixed in interesting ways. Make the most of it.