This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes My ui config dialog strategy + open ui questions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "My ui config dialog strategy + open ui questions" Watch "My ui config dialog strategy + open ui questions" New topic
Author

My ui config dialog strategy + open ui questions

Norbert Lebenthal
Ranch Hand

Joined: Sep 23, 2010
Posts: 74
hi

Being a total newbie, looking at the swing part was quite intimidating. On top of that, I found SCJD 5 chapter on swing to be a bit confuse, or, rather, the implementation they offer.

As such, I went for the following impl:
- a LaunchMode enum, with CLIENT, STAND ALONE and SERVER as its values.
- the LaunchMode is built from the arguments, then a start method is called. This start method in turn does:
- create a ConfigurationEditPanel instance
- add in it the various elements (file location, port, hostname) as needed, through method calls,
- triggers the display
- then, when the configuration edit panel returns, grab the configuration object from it and uses it. The configurationEditPanel won't return as long as the input aren't valid (errors shown through a JOptionPane ErrorMessage).

Does it sound like ok ?

Then, I've a few open questions:
- in the book, they do synchronizing on the config file. Why is that ? I check this in the configurationEditPanel, after user input:
. Isn't it sufficient ?
- how to handle ioexception on close when reading the property file ? In my Configuration object readProperties method I currently do:

is it ok or a bit overdone ? if so, what would you suggest ?
- on server and stand alone modes, the FileDatabaseManager is instantiated, which starts by reading the whole data file to cache the records. currently, with few records, it's blazing fast, but it could increase. Shall I do some kind of splash screen, launching the FileDatabaseManager in another thread and grabbing it back when its creation is over? It feels a bit overblown to me actually: the day there'll be enough data in the file to cause this other issues will have popped up before I think... What's your opinion ?

thanks in advance
best
Norbert
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

Hi Norbert,

1/ Your approach sounds ok to me, I used a similar one.

2/ The only reason I can think of for sync'ing on the properties file, is to make you think about it and not just copy/paste that part from the book

3/ About closing the config file: your code is Agreed it is a bit overkill, but that's the only way you close your files correctly. I just checked my code and it has a resource leak (when something goes wrong when saving/reading file) (as a side note: I believe in Java 7 they will introduce automatic resource management, which will remove this clutter for you, you can click here for more info)

4/ I didn't add a splash screen or some other alternative (because not required in the specs)

Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Norbert Lebenthal
Ranch Hand

Joined: Sep 23, 2010
Posts: 74
thanks for the reply

For the splash screen, the issue is that, in my solution, loading the whole file could take time. I remember having read you went for some other solution, so maybe this wasn't the case for you.

In the end, I'll just speak of it in the justification doc I guess. Server side it's not of too much use anyway. Stand alone it would be surprising to give it such a big file. And over all other issues would pop up sooner I guess (and workaround is easy). :$

A side note by the way, for localisation, I went for a Message class with public static inner classes for each class containing message. For example if my Foo class requires a Bar message, it ends up this way:


Eventually I do as well call some constant on the parent class, which then requires the proper path:



do you think it's already bloated ?

thanks again
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

1/ I have to read/load the complete file at startup (for my record cache), but still I didn't implement a splash screen, because it's simply not required.

2/ What's the benefit of this (weird) messages with static inner classes approach? I just have 1 class containing all constants. It will be easy to apply i18n on this class in a future version
Norbert Lebenthal
Ranch Hand

Joined: Sep 23, 2010
Posts: 74
Roel De Nijs wrote:1/ I have to read/load the complete file at startup (for my record cache), but still I didn't implement a splash screen, because it's simply not required.

ok thanks

Roel De Nijs wrote:
2/ What's the benefit of this (weird) messages with static inner classes approach? I just have 1 class containing all constants. It will be easy to apply i18n on this class in a future version


lol

well, it's due to the fact that messages are a bit "class dependent": knowing which class they come from can/is/could be helpful... But then again it's most probably overdone. Maybe just putting the calling class name at the beginning of the message keys would be enough.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

Norbert Lebenthal wrote:well, it's due to the fact that messages are a bit "class dependent": knowing which class they come from can/is/could be helpful... But then again it's most probably overdone.

Have a look at this scenario: you have the ServerWindow with the necessary input boxes, labels and buttons. So you will have in the Messages class a static inner class ServerWindowMessages with the necessary constants. Then you start at the configuration settings dialog for the client. You notice that it's almost the same as the one you used in the ServerWindow class and you decide to create a seperate class (e.g. ConfigSettingsPanel) and use it in both ServerWindow and client. And then you may not forget to refactor your Messages class....
This approach is a burden when you refactor your code and offers no added value at all. I would advice not to follow this approach, because it's simply not good at all!

I'm developing in Eclipse and they have a project called Babel to translate all captions, labels, messages,... by the community in a wide variety of languages. And they often have just 1 class per plugin (and a plugin contains several packages and classes).


Note: it took a bit longer than normally to reply, but I've a good excuse: I was on holiday for a week, enjoying the sun
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: My ui config dialog strategy + open ui questions
 
Similar Threads
Route Finder Front End
opening serial port
Weird actionPerformed method.
unble to write the data into file
Execution dir (in Eclipse)