Hi guys, This is my client design. Feel free to comment on any part of them. Note: Please do see the threads "database design" & "server design". CLIENT DESIGN ------------- 1. Used a connect dialog box to allow user to specify the location of database and to choose between local/remote mode operation. 2. The DataClient part of my client constructs an instance of Data class for local operation and RemoteData class for remote operation. 3. The client gui contains a menubar and a tool bar. The booking panel is displayed as an internal frame within the JFrame. 4. FlightBooking class is responsible for flight booking and displaying of the the Booking panel. 5. Used threads to prevent my client gui from hanging. I did this by starting a new thread for booking operation after the user specified the total number of seats to book and pressed OK. 6. No client information is stored. Only the total number of seats booked, thats it. 7. No support for booking cancellation. 8. No support for flight booking status listing. When the user clicks on book button a dialog box displays the total number of vacant seats in the flight. 9. Implemented search by providing four combo boxes: Flight Number, Flight Date, Origin Airport, Destination Airport and a Query button. 10. Implemented online help which can be activated by pressing F1. 11. Hardcoded the flight numbers, origin & destination airport names into the client. Any suggetios are always welcome.
When you create custom threads in GUI, how do you make sure you avoid the user making double booking for the same flight? For example, an impatient user can click the "Reserve" button, 5 times to reserve 2 seats. How do you make sure you don't reserve 10 seats?
hi vishal, i think you should give some more thought into teh design that u have made. Ona bigger picture its okay. but there are some fine intricacies that need some reasoning. like showing the number of seats that are available when the book button is pressed. I think it would be more feasable if the user knows if the flight which he is booking tickets on has the number of seats before he does.
next what si the advantage of using threading on your GUI. Hard coding of the data that is there in the database is an absolute no no. What if the data changes in future, you plan to recode your apliacation again.
Well guys, Its a great experience to get so many responses within 24 hours of my posting this topic. Let me clear up all the parts of the client which received criticism. Threading for booking process ----------------------------- As I said above I create a custom thread that handles the booking process comprising of lock, modify, unlock operation. Previously if the lock operation blocks on the server side for any reason then the client gui seems to hang for a while, So I create a separate thread for this process. In this way even if the lock method blocks on the server side my gui never hangs. The moment the user presses the book button I block the input to the main frame by displaying a JDialog which gets cleared only when the booking process is over. Hardcoded the flight number and origin/destination. --------------------------------------------------- I had contemlated about reading the whole database each time the client gui started up, to get a list of flight number and origin/destination airports. But just imagine, each time a client startsup it has to scan more than say 20 records now, in future this may increase to 1000 records. The clients startup will suffer and the user would definately get frustated. So I hardcoded this thing into the client. If it is so necessary to provide online help with regard to origin/destinaton airport I would design a button called "show origin airports" which scanned and returned the same only when the user requested so.
Showing current status of seats on the flight --------------------------------------------- I never modify the main db.db file in my implementation. Reservation details are kept in another file. So i don't want to increase the overhead of reading each flights status by scanning the whole reservation database each time the user clicks on search button. This are the reasons for the main topics which were highlighted in the previous discussion. Please do point out any deficiency in my reasoning and design. Any suggetions are always welcome.
Having a modal dialog to prevent the user from doing anything to the reservation is as good as not spawning threads at the client side during flight booking. In my experience, duplicating database values in any place is a recipe for disaster. I wouldn't hard code the flight/origin/destination at the client. [ May 12, 2002: Message edited by: Sai Prasad ]
Hi, I start a thread for time consuming operation to prevent the gui from hanging and the dialog box to prevent the impatient user problem. This solution is working perfectly and I would really like to know approach that is better than the one I have implemented. Any suggetions are welcome.
Threading for booking process ----------------------------- As I said above I create a custom thread that handles the booking process comprising of lock, modify, unlock operation. Previously if the lock operation blocks on the server side for any reason then the client gui seems to hang for a while, So I create a separate thread for this process. In this way even if the lock method blocks on the server side my gui never hangs. The moment the user presses the book button I block the input to the main frame by displaying a JDialog which gets cleared only when the booking process is over.
Hi visal, Instred spaning a new thread why dont u use SwingUtils.invokeLater(Runnable run) which intern does the same. Please get back to me if u have any problem in implementing this.
Hi all, this is my first post to the group. Personally I find Vishal's solution to avoid GUI 'hangs' great and thinking of doing the same. Only one problem: I've been able to click one or more buttons before the Dialog appears. This is easy to do if you have a slow machine. So if you are not careful, you may end up with two or more threads spawned and colliding in spite of having a modal dialog. Don't think a call to invokeLater is the solution, because the EventDispatchThread will hang till server replys Ed