Your code is already on-line waiting for you to use. Try running the sample pages here. The page shows screen shots of each tool and provides you a link to run the code you are being given. Then, grab a copy of your project code off of our class server, sambucus.cev.washington.edu. Use your favorite SSH 2 capable Internet tool to login with the inde498a userid and the password I gave you in class (The UWick package from the University of Washington Web site comes with an SSH Communications Tool).
Upon login, you will arrive at the home directory for the inde498a account. There, you will find four directories that map to the four projects illustrated on the OWorld project page. The directories are named 3d, board, chat, and meet. 3d contains the code for the Meetspaces project. board contains the code for the Drawspaces project (a shared, enhanced whiteboard). meet contains the code for the MeetingPages project.
I will grade you on thoroughness, design, and functionality. The goal is for you to learn by doing. So, try making changes to the code that confirm any assumptions you make. Make changes for the sake of seeing the result. You don't have to turn in all the changes you make, just the changes you think add value. As you work, always think in terms of the components of collaborative software. They are:
Chatter.java is where you store all the attributes you need to know about each participant in the collaborative session. So far, you will see a name and unique ID for each participant. Consider adding to this class to include other important information pieces to store on each participant.
UserList.java provides a visual scrollable list of all the current participants in a collaborative session (i.e. all the names of people currently on-line sharing the same application). UserList keeps an internal hashtable (a hashtable is a very popular programming data structure that stores values based on keys (usually short text values) and can search to find the stored details when requested to do so).
UserListObserver.java provides an interface (we'll discuss interfaces a lot in class over the next few weeks) for all your classes to use when they want to be notified of events that occur within the UserList. Observers and Listeners are important programming concepts inate to the Java programming language. For now, just think of UserListObserver as a way to standardize events within your project.
ClientThreadObserver.java lets other classes know when events have occurred within the ClientThread. Try to see all the similarities to the UserListObserver class.
Dispatcher.java is the only class within the vnet networking package that knows about the other packages in your project. So, if a message is to come from or go to the network within Project 1, it has to be directed to do so from the Dispatcher class. Think of a taxi dispatcher and the job he or she does. Only the Dispatcher can add new message types or change existing message types within Project 1. I am making that a requirement.
makes it easier for you to interpret the bits coming in from the network by parsing them into fields. We won't really be using the fields much for Project 1 but you will need to understand the idea for Project 2.
forces you to package your bits into fields so they can be more easily interpreted by the application receiving them. We won't really be using many field types much for Project 1 but you will need to understand the idea for Project 2.
The other four classes from the vnet package define the fields you will have access to for VField input and output streams: