Hi, I don't have any experience working with Swing. My Swing Client is already done, but I am worried if it is done as it should be. In my main GUI Client class my Handler runs a thread which calls the DB approprate methods in DB Interface and then(this Thread updates) my View. I guess in MVC this thread servers as a Controller and should not itself change the view, the thread cannot deliver a Model for the View to update the view, since the Thread has void run(). I can try to apply observer pattern or use events, but should I? Here is part of my main GUI Client class:
Here is a prt of the thread:
So, the thread instead of return a model, updates the view by its own. Is it Ok? Thanx, Vlad
Joined: Jul 07, 2003
Hi, One more question: Do I need to make the GUI Client multithreaded at all? Vlad
Hello Vlad, To answer your second question -- so far in my client UI code I did not need to start any additional threads myself but I do use SwingUtilities static methods (ex. invokeLater()) to help me avoid frozen client, especially when considering remote calls and network latency. But this is only my personal opinion and there are different implementations around. Regards, +Seid
Hi Vlad, I do not understand your reference to MVC, since the way you have implemented this does not fall into any variation of MVC that I know of. If you did want to have an MVC, and you wanted to have a thread to handle the database access, then the model would create the thread to do the work. Having a thread to handle the database access is a great idea. Without this your application can become completely unresponsive to user actions. So I like the fact that you are using it. Having said that though - I did not have separate threads in my GUI Didn't cost me any marks missing this.
I can try to apply observer pattern or use events, but should I?
I can't see any value for the way you are using the thread here - since your thread is short lived, and is custom made to do some work for you, I think the overhead in fitting the Observer / Observable pattern is unwarranted.
So, the thread instead of return a model, updates the view by its own. Is it Ok?
As long as you are not using MVC. If you tried to do this, and use MVC, then I think you are likely to confuse the examiner (not to mention the poor junior programmer). I have heard some people say that you have to use MVC in your design. This was not specified in the instructions I have seen, so as long as it is not implicit in yours, then you should be OK. I assume you have some way of ensuring that a client does not attempt to make a second booking while the first one is being processed?
Do I need to make the GUI Client multithreaded at all?
You mean more than you have already? I don't think so. If you application is already using separate thread(s) for all data access, then you should be OK. As I said: I didn't even bother with that. Regards, Andrew [ July 25, 2003: Message edited by: Andrew Monkhouse ]
Hi Andrew, [Andrew]I do not understand your reference to MVC, since the way you have implemented this does not fall into any variation of MVC that I know of Exactly. By using this Thread (to access database) on the client I break MVC. That is exactly what I am worried above. The Thread is "interface beetwen" view and model, which normally is controller, but in my case not because instead of delivering model to view and letting view make itself appropriate changes and make changes in view directly. The thread is short-lived, but it makes the most function : data access.
[Andrew] If you application is already using separate thread(s) for all data access, then you should be OK. You mean that it is Ok not using MVC for the Client? You also said that you have not used threads at all. It means if the data access blocks you have no way at least to close your client window... Is it correct? And you was graded at max for the client. U guess then that instead of having extras, but not havi ng MVC design, it be better to hold on MVC and rehect from Threads idea as you did.
Joined: Jul 07, 2003
Hi Seid, I use also invokeLater, but it makes sense to use only if you have your own thread. By having only one thread, the client will always be block while waiting for the server response!? Vlad
author and jackaroo
You mean that it is Ok not using MVC for the Client?
I know that there have been people in the past who have passed with high scores who did not knowingly use any design patterns at all. I think as long as your design is easy to follow, easy to maintain and upgrade, and works, then you should not loose points for not using a pattern that was not specified. But - if you are using MVC, then I would strongly suggest that you not break it in this way. There is too much danger of it causing confusion.
You also said that you have not used threads at all. It means if the data access blocks you have no way at least to close your client window... Is it correct?
Yep. I don't recomend this. But I got away with it.
U guess then that instead of having extras, but not havi ng MVC design, it be better to hold on MVC and rehect from Threads idea as you did.
Not necessarily. The main reason I didnt create extra threads for my GUI is because I just didnt think of it while I was building my GUI - for the last 6 years I have been developing middleware, and for the 8 years before that it was CUI. Since you already have your MVC design, and you are thinking about creating threads to save your user from a dead screen, why not just refactor your code to put the extra threads into the model? Regards, Andrew
Joined: Jul 07, 2003
Hi Andrew, That is what I have, except that Controller(Thread) and View (Main window) are not really good separated as they should be in MVC. So will leave it now as it is and explain it by not willing to get in complexity to follow exact MVC pattern. Thanx, Vlad
I'm no expert in multi-threading with Swing but I was told by someone who is an expert that you have to ensure that all swing components are accessed in the AWT event dispatching thread. So you'd have to do something along the lines of start a new thread to get the data from the server and then use SwingUtilities.invokelater() to update the ui once the thread is done. That's what I've done. In my assignment, however, there was no mention at all about multi-threading the ui. ms