73 lines
6.8 KiB
Markdown
73 lines
6.8 KiB
Markdown
# Übung – Multichat
|
||
Uebung-hk1-Schrom01-Fassband-Brandleo
|
||
|
||
|
||
#most important Problems
|
||
## Our 5 most important functional Errors
|
||
###1. Multiple Server Connections not possible (Issue [#4](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/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.
|
||
<br>
|
||
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](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/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.
|
||
<br>
|
||
We discussed two different solutions:
|
||
<br>
|
||
- 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](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/7))
|
||
It was possible for a Client to send empty messages and they were also delivered and displayed.
|
||
<br>
|
||
We discussed two different solutions:
|
||
<br>
|
||
- 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(Issue [#19](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/19))
|
||
|
||
###5. Message stays in input field after being sent [#8](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/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](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/14), [#49](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/49))
|
||
|
||
###2. ClientConnectionHandler and ServerConnectionHandler have a lot in common (Issue [#11](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/11))
|
||
|
||
###3. Creation of instances of ClientMessageList and ClientConnectionHandler (Issues [#18](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/18)[#24](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/24)), [#24](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/24))
|
||
|
||
###4. ClientConnectionHandler calls Methods on ChatWindowController to add new Messages (Issue [#23](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/23))
|
||
|
||
###5. ChatWindowController MessagePattern and method message (Issue [#17](https://github.zhaw.ch/PM2-IT21bWIN-ruiz-mach-krea/Uebung-hk1-Schrom01-Fassband-Brandleo/issues/17))
|
||
|
||
|
||
# Description of our solution
|
||
|
||
###Classdiagram of original handout
|
||
|
||
###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 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.
|