A number of years back I had written a desktop software package for tracking and managing the maintenance of vehicles and it was called Love My Vehicle. The software was well received and it managed to attract a rather large & loyal following of paid customers and had won numerous awards from various software rating groups as well as user groups. The application was written for Windows using Microsoft C++ and the MFC framework.
Many things have changed since I originally wrote that package. Most noticeably, the Web has become the preferred target for delivering services and value to customers. The Web's influence can be said to have changed the landscape of application development and delivery. Cloud based Web services have also contributed to the changing landscape by offering software developers the opportunity to deliver services to their customers without the need to invest in infrastructure and by also providing solutions for wide scalability and resiliency. Numerous cloud options now exist including Amazon's EC2 and Google's App Engine for which I have written numerous applications .
About six months ago one of my customers contacted me about migrating her licenses for Love My Vehicle to new computers her company had purchased. Unfortunately, I wasn't able to offer her any assistance because I had lost the source code to the application a few years back (which could serve as the subject for its own article). As a result I decided to create a modern version of the software targeting, of course, the Web and the cloud and as I already had practical hands on experience with App Engine I opted to target Google's cloud.
One of the early lesson I learned about targeting App Engine is that Google's limit on the amount of time allotted to each HTTP request severely limits what I can and cannot do on their servers. I learned that the best approach was to limit each request to retrieving and updating data only and to do all HTML rendering on the browser using Ajax and DOM manipulation. The added benefit of this approach is the RIA experience for the user.
The applications I already have written for App Engine all use Java and Groovy on the servers for processing Ajax requests and jQuery on the browser for DOM manipulation. The shortcoming to this approach is that client side development tends to be tedious and you lose the benefits provided by compilers and IDEs, especially catching coding errors early and code refactoring. I wondered what other options I had that would offer the same set of resources on the client that I had become accustomed to having on the server side of development. Enter Google's GWT.
GWT is Google's pure Java approach for developing rich internet applications (RIA) and it uses a novel approach of compiling Swing like Java code to native Javascript targeting IE, FF, Chrome and the Safari browsers. Using GWT lets you develop both your servlets and client side code in Java without having to give up your favorite IDE which in my case is Eclipse.
In the course of two months and coding in my spare time I have manged to be very productive using GWT. After studying and learning its "ins and outs" I have already managed to put together a nice little prototype of Love My Vehicle running on Google's App Engine cloud. This isn't a clone of the older application but rather a complete rewrite with new features and of course, Web based. Here's the link:
http://lovemyvehicle.appspot.com/. Though early in its life cycle and sans source code for the original product, I am applying my knowledge of the original software's functionality to build out the new product which will support the popular 'freemium' subscription model.
As I progress in adding and refining functionality I will post updates here. I also intend to write new articles specifically relating to its development that will also include GWT and App Engine.
Screen shots of early prototype
Updated 11/27/2010
Since posting the original article I've made numerous changes to some of the views and I've also implemented a couple of new views, all of which are included below. But first, allow me to make a few obvious but none the less important observations about application development in general.
One of the keys to successful development IMHO is the constant refinement of concepts and ideas. No matter how good a first implementation is there is always room for improvement. As concepts and ideas materialize and as the complexity of the application increases it is very important to review your implementations frequently, looking for ways to improve them. In addition, as development progresses you can sometimes find that you need to reuse an implementation but in its current state it is tightly bound to a single point of use.
IDE refactoring support makes this repetitive cycle of coding and refinement manageable and Eclipse, my preferred choice of IDE, shines in this area saving me literally hours compared to what it would have taken me to manually make all the modifications up to this point.
So, if your current IDE doesn't shine in its refactoring support look to upgrade to a better IDE. JetBrains, Eclipse and Netbeans all provide excellent support for refactoring code and of the 3 only JetBrains requires a paid license for non open source projects.
With that little tidbit out of the way here are the screen shots I promised:
Screen shots of modified views from early prototype
Screen shots of recently added views from early prototype
Updated 12/5/2010
Since my last update I've done a lot more refactoring, made some improvements and changes to the the existing views, implemented the Parts, Fluids and Suppliers views and I've added one new view, Notifications, to the Manage sub menu. The data displayed in the following screen shots is bogus of course and is for testing purposes only, mainly to verify that my sorting routines are working correctly. Screen shots follow:
Updated 12/19/2010
Complex Web 2.0 pages are highly dynamic and require a lot of DOM manipulation for adding, removing, hiding and showing page elements in response to the user's actions; that's how they mimic desktop applications providing a similar rich user experience.
Love My Vehicle's Misc. Purchases View is one such example of a complex, highly dynamic page that responds to the user's actions by manipulating the DOM accordingly. The view supports the display of a document non editing view of a purchase which has numerous areas on which the user can click on to manipulate such purchase related items as purchase line items and sales tax.
For example, when the user clicks the Add Purchase Item button DOM manipulation is used to display an editor that allows the input of a purchase item. The user can save their input by clicking the editor's Save Purchase Item button or they can cancel the operation by clicking the editor's Cancel button. If they click the Save Purchase Item button the information they entered is first validated and if it is valid the DOM is again manipulated to display a document non editing view of the line item entry. If the information fails validation then the line item editor displays an error message which provides feedback to the user prompting them to correct the data.
The same line item editor also supports editing of an existing purchase line item which would be the case if the user is editing an existing purchase or a line item they previously entered in a new purchase.
Sales tax works similarly to the purchase line item editor supporting both a document non editing view and an editing view.
Whenever the users saves their data in either the line item editor or the sales tax editor the page recalculates the net and gross amounts for the purchase.
In the coming weeks I intend to publish an article dedicated to my approach to developing these types of highly dynamic pages and of course I will focus on using GWT to implement them. It is possible that this will be a multi part article as the topic requires a lot of detail and I think would be easier to consume if it wasn't all tossed out at you at one time.
I have added some screen shots below of the views that I described above as well as a screen shot of the Purchase view which shows a list of all purchases as well as showing a document view of the selected purchase.
I hope you have found this latest update interesting and as always, feel free to provide your feedback.
Have a very happy holiday and new year.
Updated 12/19/2010
In real life one rarely gets the opportunity to do things over but software development is an exception. After implementing the Purchase views I realized that I had failed to provide the user with a report view of a purchase. What do I mean when I say a report view? A report view is any view of data that when viewed looks like a well laid out report and as close to the real life document that it is supposed to represent. An invoice is an example of a report view with a header, line items, and a summary. A
purchase is also an example and is very similar to an invoice in that it also has a header, line items and a summary.
Business applications, which Love My Vehicle really is when you get down to it, usually have to provide a lot of report views and implementing them is often time consuming because of the detail required to get the views to look like real documents. I made two passes at implementing the Purchase report view, one using a div only approach and one using tables. In the end I chose the tables approach because it was more straight forward and it allowed me to use GWT's excellent support for table row and cell generation.
The following is a screen shot of a Purchase report view. Besides providing the user with a report view of what a Purchase document should look like, it also provides the user with the ability to edit and delete the backing purchase data:
Posts
