The crucial interfaces and data definitions in the ChatApp system are the common Remote interfaces for communicating with remote ChatApp applications and the data definitions of the fully serializable data to be sent between ChatApp apps.
Some basic notions to consider:
- Minimal and Complete -- Strive for the minimum number
of methods that for a complete set, enabling all required operations to be
performed.
- Orthogonality -- All methods should be maximally
independent of each other and not perform operations that are also partially
performed by other methods.
- Implementation Independent -- The user of a
method or object should not be concerned with how it is implemented.
- Flexibility -- All possible operations must be able to
be accomplished with the defined set of operations and objects without the
need for special cases.
- Extensibility -- The addition of new operations and/or
capabilities should not require major reconfiguration of the system,
preferably no changes at all.
- Robustness -- The system should be designed to
gracefully handle user or other errors that may occur.
- Security -- The system should be gracefully
disallow deliberate attempts to circumvent proper operation.
In order to more accurately represent "real world"
API's, the ChatApp networking API should minimize the number of method calls on
remote objects.
Note that shared network API may encompass more than one
set of use cases for distinct sets of processes. This may mean that
the API may naturally separate into multiple decoupled parts!
Technical Details
Some details that need to be standardized:
- RMI bound name for initial connection entity in the Registry
- "Well-known" data types
- What well-known data types are required?
- What are the host ID's of the well-known data types?
Pitfalls:
-
Infinite loops or other problems when notifying existing chat room users
that one has joined the chat room: This can be caused by adding one's
self to the room before notifying the existing room occupants, causing one
to receive one's own join notification.
-
Attempting to serialize an anonymous inner class.
- Symptom: "Not Serializable" errors. -- Do NOT blithely select the Quick Fix of "Make Serializable"!!
- The fix is to stop using an anonymous inner class that is closing over too many things, e.g. everything in the model, its adapters and everything that those adapters are connected to.:
- Switch to using an instance of a named class
- Switch to using a factory to instantiate the anonymous inner class. The factory class will limit the range of what the anonymous inner class is closing over.
- Threading
Issues
- Locking up and/or "cross-thread invocation" errors: This could be caused by threading issues due to the fact that RMI method calls run on a diffferent thread than the GUI. We will be treating these issues on an "as needed" basis, so if you experience the problems, please let the staff know right away.
-
Cross-Thread Invocations onto the GUI Thread
© 2020 by Stephen Wong