Best programming process for creating a graphically-complex Java Swing Application?

Question

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!

Answer 1

Are you really sure of Swing? Eclipse RCP framework is much better and flexible

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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

Answer 6

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!