added 5 functional errors in Readme.md

README.md

@@ -4,10 +4,44 @@ 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.
+###2.
+###3.
+###4.
+###5.
 
 
 # Description of our solution