Part 3 of ?: Swing Application Best Practices
The Application and Where to Start
If you haven't seen Part 1 and Part 2 of this series I invite you to read those. I'm really excited about the amount of response I have received on these posts and I really think something good can come out of this. The only problem thus far is I have received an email from 1 person wanting to join the project. I can't do this alone and I can't do it with 2 people. For this to work I really need more participation on the actual project so if you would like to help in any way please send me a gmail address to gdboling AT you know the rest.
We should start talking about what kind of application we can build that will provide a good foundation for everything we want to try and accomplish. Here are a few points to think about as we try and come up with ideas:
- It has to be simple yet interesting
- It needs to support multiple forms
- It should try and use as many components as makes sense. It doesn't need to a be SwingSet demo but at the same time, if a concept can't cary over to multiple components we need to provide good examples.
- It doesn't have to be RIA. I believe the things we are trying show and learn can apply to any type of Swing application. There are just some things that RIA's require that aren't what we care about right now and I don't want to get hung up on something.
- Persistence shouldn't matter. We should begin by mocking it if we need to in order to keep things simple. If later we want to supply different persistence layers then fine. But that is not our goal.
So let's hear some wonderful ideas. After I get a few I'll chime in with the ones I have in mind.
Re: Part 3 of ?: Swing Application Best Practices
By the way, Gregg, although I cannot promise much of my time to it (I have 4 OSS projects currently, 2 of them in a very active state), I would be glad to participate to the Maddie project.
Re: Part 3 of ?: Swing Application Best Practices
Second, you may define "groups" of contacts, That will give the possibility to use more lists or even a tree.
Third you may want to add agenda facilities to your address book, where you can plan meeting/calling some of your contacts. That could be using drag & drop (I've seen in another post that you seem to love drag & drop with Swing ;-))
Fourth, you may add search capabilities (if your address book is big), which gives rise to interesting GUI problems such as: if I open the detail info of contact A in a window (that was open from a search window), then how will the search window reflect the change (this can help show usefulness -and related problems- of binding, including dirty forms; or we can use an event bus for this kind of "view synchronization".
Fifth, you may decide to add some docking capabilities (due the fact that users like to forge their own address book layout), and here you definitely would need an event bus.
I stop here, but you see the idea.
Re: Part 3 of ?: Swing Application Best Practices
Re: Part 3 of ?: Swing Application Best Practices
Re: Part 3 of ?: Swing Application Best Practices
Despite the case that i find the finance solution interesting, i would rather prefer something that has to keep the performance issue in mind (something like how do I deal with many events, simultaneous animations, binding to a control instance). I would suggest something like: Desktop Tower Defense
But I have to admit that it focuses perhaps too much the "gaming aspect" for this project. But it could be a hint towards an interesting project... I'm open for comments!!!!!! cheers michael
Re: Part 3 of ?: Swing Application Best Practices
Thanks for the suggestions. If interested lets move this discussion to the
maddie dev mailing list.