Server applicatie

De server applicatie heb ik ontwikkeld in de programmeertaal C#. Aan deze applicatie kon ik vrij gemakkelijk al een begin maken, aangezien ik al tijdens mijn studie ervaring had opgedaan met C#. Ik hoefde geen ervaring meer op te doen met Visual Studio, aangezien ik deze IDE al kende.

Ik heb dan ook de requirements erbij gepakt die ik had opgesteld aan de cliënt/server applicatie en ben begonnen met een design form (GUI) waar ik de volgende functionaliteiten aan

toevoegde:

Functionaliteit Informatie

Port number textbox: Een textbox waar het poortnummer kan

worden ingevoerd.

Start Listening button Om verbinding open te zetten voor simulaties

en iPad.

Data Received textfield Tekstveld met daarin de data die wordt

ontvangen van zowel de simulaties en de iPad..

Client Informatie [Devicename]

De naam van de simulatie die is verbonden met de server

[Usage]

Het verbruik van de simulatie die is verbonden met de server

[Status]

Status van de simulatie (aan of uit)

[Switch]

Een knop om de simulatie aan of uit te kunnen zetten.

Zoals uit afbeelding 6-1 op te maken is heb ik een aantal labels toegevoegd aan de server puur voor het debuggen. In het eindproduct is het namelijk helemaal niet nodig dat de server de informatie laat zien over de simulaties, dit is de taak van de iPad. Omdat ik echter de iPad app pas later ging ontwikkelen moest ik een plek hebben om de data te kunnen laten zien die de simulatie doorgeeft aan de server. Dit was nodig voor het debuggen, ik moest natuurlijk wel weten of de data goed verzonden en ontvangen werd. Dit heb ik opgelost met behulp van deze labels. Voor de aan/uit switches naast de labels geld dezelfde redenering.

De hoofdtaak van de server was om de messages te verwerken die werden verstuurd van simulatie naar iPad en vice versa. Hiervoor moest dus verbinding worden gelegd met zowel de simulaties als met de iPad. Het was de bedoeling dat er meerdere simulaties verbonden konden worden met de server, omdat iedere simulatie een apparaat voorstelde.

Een verbinding opzetten met de simulaties was relatief eenvoudig. Beide applicaties schreef ik in C#, wat betekent dat de messages die over een weer werden gestuurd met behulp van het message systeem werden geencodeerd en gedecodeerd met de UTF8 encodering die C# standaard gebruikt. Met de labels die ik had toegevoegd aan de server kon ik zien of de message die ontvangen werd ook goed werd uitgelezen.

Op het moment dat een simulatie met de server wilde verbinden stuurde deze een connect message naar de server, waarmee hij aangaf te willen verbinden. Zoals in paragraaf 6.2 wordt uitgelegd bevat een connect message de volgende data:

ID|CONNECT|NAAM APPARAAT|

Omdat de server moest weten naar wie de messages verstuurd moesten worden was het de bedoeling dat deze zelf de ID's uit ging delen aan de simulaties die willen verbinden. Als iedere simulatie namelijk een uniek ID had dan kon de server aan de hand van het ID uit een message bepalen naar welke simulatie het bericht verstuurd moest worden. Bij het aanmelden bij de server moest de simulatie echter wel een ID meegeven, omdat anders het bericht niet goed was opgesteld en de server deze niet goed zou decoderen. Door de simulatie het ID "-1" mee te geven, ziet de server dat dit een ongeldig ID is (negatieve getallen kunnen niet voorkomen in ID's) en deelt hij zelf een geldig ID uit aan de cliënt.

Voorbeeld uitdelen ID

Een message die de server binnenkreeg moest eerst gedecodeerd worden met behulp van de decoding functie die toegelicht is in paragraaf 6.3. Als het type bericht was vastgesteld (wat in de decoding functie werd gedaan) werd er een switch toegepast:

Voorbeeld switch functie

In dit voorbeeld is de case weergegeven voor het message type CONNECT. In het geval van een connect message moest de server de data uitlezen uit het bericht, dat dus de naam bevatte van de simulatie die wilde verbinden, en deze weergeven in het label dat ik had toegevoegd voor het debuggen. Dit ging allemaal relatief eenvoudig en dit heeft dan ook geen noemenswaardige problemen opgeleverd. De messages kwamen goed aan en werden in het desbetreffende label weergegeven. switch (receivedMessage.Type) { case MessageType.CONNECT: { if (idMessage.Data.Equals("1")) lblDevice1.Text = receivedMessage.Data; if (idMessage.Data.Equals("2")) lblDevice2.Text = receivedMessage.Data; } }

Message idMessage = new Message(); if (receivedMessage.ID == -1) {

idMessage.Create(-1, MessageType.CONNECT, Convert.ToString(conns - 1));

Bij het ontwikkelen van de iPad verbinding met de server zijn echter wel een aantal moeilijkheden naar voren gekomen.

Het lastigste punt was dat de server zowel verbinding moest hebben met de iPad als de simulaties. De connectie met de cliënt applicaties was relatief eenvoudig zoals hierboven beschreven is. De iPad verbinding was echter lastiger. Bij het ontwikkelen van deze verbinding heb ik de iPad zichzelf laten gedragen als simulatie, zodat deze gegevens zou verzenden naar de server, welke ik dan weer in labels kon laten weergeven. Dit heb ik gedaan omdat het makkelijker was om de server de gegevens te laten zien die werden verzonden door de iPad. In Visual Studio wist ik namelijk nog steeds makkelijker alle functies te vinden dan in XCode. Als er eenmaal gegevens werden verzonden vanaf de iPad, dan moest het ook mogelijk zijn om ze te kunnen ontvangen op de iPad.

Om redenen die ik toen nog niet begreep, kreeg de server geen goede message binnen van de iPad en werden de labels dus niet gevuld met de data die ik verwachtte.

Hierdoor begon ik met debuggen door breakpoints toe te voegen aan de server en wel bij de decoding en encoding functies, omdat daar de data als eerste binnenkomt en verzonden wordt. Na de hele sequentie te zijn doorlopen bleek dat de messages niet goed werden gedecodeerd. De iPad verstuurde keurig een complete message, maar eenmaal aangekomen bij de server

werd er verkeerd gedecodeerd. Dit kwam omdat C# decodeerd in UTF8. De messages die de iPad verstuurd zijn echter geëncodeerd in ASCII, dit is de standaard encodering van Objective- C. Hierdoor las de server de berichten niet goed uit en werd de data verkeerd geïnterpreteerd, waardoor deze niet in de labels verscheen. De encoding- en decoderingsfuncties van C# kunnen echter wel gewijzigd worden in ASCII. Door dit te hebben gedaan werd de message goed uitgelezen en gaven de labels de data aan die ik verwachtte.

Dit is een voorbeeld wat aantoont dat het programmeren voor de iPad toch erg anders is dan het programmeren van een C# applicatie. Het heeft lang geduurd voordat ik erachter kwam dat het een relatief eenvoudig probleem was. Het feit dat Objective-C met ASCII encodeerd was iets dat ik niet wist, maar waar ik achter kwam doordat de server geen goede data doorkreeg na het decoderen van het bericht.

Nadat de message werd gedecodeerd aan de hand van de ASCII standaard kwam de message wel goed aan en werd de data goed weergegeven in het label dat ik had gemaakt.

Later, tijdens het ontwikkelen van de iPad app, besefte ik dat het message systeem geen afzender bevatte. Standaard werden messages vanaf de simulatie doorgestuurd naar de iPad. Omdat de server de messages van de iPad niet kon onderscheiden van de messages van de cliënt werden ook deze messages weer naar de iPad teruggestuurd. Door een uitroepteken aan de data van de messages van de iPad toe te voegen kon de server deze herkennen en werden deze niet meer doorgestuurd naar de iPad maar naar de simulaties.