Übung – Multichat

Uebung-hk1-Schrom01-Fassband-Brandleo

Most important Problems

Our 5 most important functional Errors

1. Multiple Server Connections not possible (Issue #4)

If a client was connected to the server, it was not possible to connect another client. The Server created a new instance of ServerConnectionHandler which was in a endless loop to receive data.
Now we changed the ServerConnectionHandler to implement Interface runnable. If a new client connects to the Server a new Instance of ServerConnectionHandler is created and Method start is called in a new Thread. This makes it possible to connect multiple Clients to the server. The new Thread is alive as long as the client is connected.

2. Private Message not visible for Sender (Issue #28)

If a Client had sent a Message it was only sent to the server but not displayed directly in the chat window. So only if the message was sent to all clients or if the sender was also the receiver, the message was visible for the sender.
We discussed two different solutions:

• Send Messages also to the sender if it's not sent to all clients and if the sender is not the receiver.
• Client checks if a private message is sent and when yes the client adds the message to it's message List. Both solutions would have the same result. The message would be in the Message List of the sender. We decided to realise the first solution, because in case of saving the message Lists on server side (as possible extension to restore messages of a user after reconnecting) the messages which are sent by a user have to be added also to the message list of the sender. So it keeps easy to implement this extension by adding those messages to the list, which are sent to a client.

3. Empty Messages can be sent(Issue #7)

It was possible for a Client to send empty messages and they were also delivered and displayed.
We discussed two different solutions:

• If method message in chat window controller is called, only call method message of connection handler if message field is not empty.
• If method message in connection handler is called check if message is empty and return false as boolean like it's already implemented if format isn't correct.
• Do not forward empty messages on server site. We decided to realise the second solution, because if a Client could have multiple different windows (as possible extension) it would be necessary to implement this check in each window controller with the first solution. With the third solution the server has to process invalid messages and uses resources for that. Also if a user only hets the enter button by mistake. With the second solution the connection handler returns false as feedback if the format of the message was invalid and the user sees that he did a unwanted action.

4. Direct Messages not possible when username has special characters (Issues #19, #29)

If a user wants to send a private message to a user with special characters or spaces in the username, it's not delivered because the user is not found. We were able to solve this problem by changing the regex of the "messagePattern". Instead of using "\w" as characters (contains only letters, numbers and underscores) for the username we used "\S" (contains all characters excepting spaces). During the registration process we check if a username contains any spaces don't accept it in this case. Accepting spaces in a Username would not be possible becuase it's used to separate the username and the message when a user types a private message.

5. Message stays in input field after being sent (Issue #8)

If a User had sent a message, the Message wasn't removed from the message field. We decided to remove the message only if the message was sent sucessfully. So if there is a typing mistake in the username of the receiver, the user can do a correction without having to rewrite the whole message. The message field is cleared if the method message of the connection handler returns true.

Our 5 most important structural problems

1. Data Class Message (Issues #14, #49)

The class MessageList had multiple List objects to save the different informations about a message. We created a Message Class which will be stored in a Array List in the MessageList instance and can also be sent from the server to a client and from a client to the server.
The new class message contains the datafields type, sender, receiver, text and also the enum with the different data types. We also added a method to check if a message matches a filter, which can be used in the method getFilteredMessages in MessageList.

2. ClientConnectionHandler and ServerConnectionHandler have a lot in common (Issue #11)

We created a superclass Connectionhandler to remove code dupplication. Common datafields and method "sendData" are now in superclass and can be used in ServerConnectionHandler and ClientConnectionHandler.

3. Creation of instances of ClientMessageList and ClientConnectionHandler (Issues #18#24), #24)

The instances of ClientMessageList and ClientConnectionHandler had been created and stored only in ChatwindowController. Those Classes are acting as model in our application. The should not be created in a window controller. So we created methods to set those objects in chat window controller and call those methods from clientUI Class.

4. ClientConnectionHandler calls Methods on ChatWindowController to add new Messages (Issue #23)

A Object of ChatWindowController was saved in ClientConnectionHandler and methods of window controller were called to add messages in the window. A Model should not call any methods of a window controller and should work without any controller object. We removed those method calls and added listeners to those properties in ChatWindowController to update the view if there are any changes in the models.

5. ChatWindowController MessagePattern and method message (Issue #17)

The Method "message" in ChatWindowController had a lot of logic in it and a MessagePattern object was saved in this class for that. We moved the logic to get the receiver and the message text into class ConnectionHandler, because the ConnectionHandler has to send the message to the server and it returns a boolean to give feedback if it was successful.

Description of our solution

Classdiagram of our new structure

Structure of Client:

The instances of ClientConnectionHandler and ClientMessageList are not created in the ChatWindowControllerClass anymore. It's created in the ClientUI Class and the ChatWindowController Class has access to them. This makes it possible for a client to have multiple windows open or close all windows without losing the message list or closing the connection. The ClientConnectionHandlder does't need a ChatWindowController Object now. Received Messages are added directly into the message list. This makes it possible to receive and store new messages without having a Window open. The ChatWindowController adds listeners in the clientConnectionHandler and in ClientMessageList to refresh the view if there are new Messages or if there are any changes in the connection handler.

Structure of protocol:

Datatype:

A new Class Message represents a Message which can be sent from a Client to the Server and from the Server to a Client and can also directly be stored in ClientMessageList. This makes it much easier to process the received data and to send a message because no String parsing and String building is needed.

Class ConnectionHandler

A new Abstract Class ConnectionHandler contains Code which is used in ClientConnectionHandler and ServerConnectionHandler. For Example Method send Data. This removes a lot of duplicated methods and data fields.

Ideas to extend the application:

• It would be easyer to use for a User if it was possible to open a separate Window for a private Chat with a specific user.
• Users could be divided into groups, and it would be nice if a group name could be used as receiver.
• registration and login with username and password and store credentials in a Database in Server.