Do we have to deal with data sync if multiple clients are using the program in standalone mode? To me, if this would be a real software, this "standalone mode" requirement would not make much sense. If we let different CSR's have their own local database, how can information be the same for all of them?
Am I missing something?
Champ, you can assume that, in standalone mode, only one CSR will be using the program at a given time. So, only one instance of the program will be running. However, the locking mechanism must still be used, even in standalone mode. So, when booking a room, the logic of the method must still lock the record, update it and unlock it.
Roel De Nijs wrote:Even in networked mode it is not necessary to push changes to all connected clients.
Your post got me thinking... Never crossed my mind to push changes to clients in networked mode, since they're all connected to the "same synchronized data". Are there any hints in the instructions that this might be necessary?
Rodrigo Uchoa wrote:Are there any hints in the instructions that this might be necessary?
No, there are not, that's why I mentioned it was not necessary In this forum you can find a few topics were people ask if this one is necessary, so I just wanted to already answer a possible question.
pushing data changes would be required. Even though the EarlyBird
requirements don't ask for it, I am doing the client updates through
RMI. I have also expanded quite a few other features.
I hope making the system more realistic doesn't earn demerits for
too much complexity. Has anyone heard about penalties for this?
Jim Hoglund wrote:In the real world, multiple clients would need to see current data. So pushing data changes would be required.
I agree the multiple clients should see current data, but I don't agree that you should push the changes to all connected clients. We have a real world application with 100s of clients, but we are not pushing changes to all these clients. That's simply generating unnecessary network traffic. And users may be confused because the data on the screen changes while they have done nothing.
Jim Hoglund wrote:Has anyone heard about penalties for this?
There are 2 guarantees:
1/ for doing extra things you won't receive extra credit, but you might lose points because the extras are not bug-free
2/ if these extras make your solution too complex, you might lose points because a simple understandable solution by a junior developer is preferred. If you add some unneeded extras, don't forget to mention it in your choices.txt. I also added something which was not required, but I justified it in choices.txt, because in my opinion the extra code would make the program easier to extend and maintain (and as you can see I passed, even with a maximum score). So you can add extra functionality without losing points if it's applicable and correctly justified.
I am afraid of over-doing it but I like a very user-friendly feel.
I intend that it be bug-free and intuitive in the code too, but I
may need to pull out some of the funkiest bits. I'm using some
1.6 stuff like SwingWorker and GroupLayout plus generics and
lots of boxing.
Jim Hoglund wrote:I am afraid of over-doing it but I like a very user-friendly feel.
My GUI was just what was required, nothing more nothing less and I may say it was very user-friendly with a very restrictive look-and-feel. The code was also bug-free and intuitive: no SwingWorker, GroupLayout,... just good ol' plain Swing. So you can have a simple intuitive gui without overdoing it