Tillbaka till lektionslistan

Mobila applikationer med Android: Inlämningsuppgift 5

• Nätverkskommunikation
• Grafik
• GPS
• Frivilligt: Kompass, Google Maps

Uppgift

Här är ett utkast till hur den skulle kunna se ut:

Den inloggade spelaren tompa syns i mitten. Två andra spelare, alpha och bravo är zombier. Spelaren charlie är människa.

De krav som klienten ska uppfylla finns beskrivna längre ner.

Spelet

Regler:

• En spelare kan vara antingen människa eller zombie.
• Alla spelare börjar som människor.
• Varje spelare har en position, som är en riktig position med latitud och longitud.
• Om minst två zombier befinner sig på samma plats (inom ca 20 meter) som en ensam människa, förvandlas den människan till zombie. Det beror på att medan människan försvarar sig mot den ena zombien, smiter den andra zombien runt och biter människan.
• Om minst två människor befinner sig på samma plats (inom ca 20 meter) som en ensam zombie, förvandlas den zombien till människa. Det beror på att den ena människan distraherar zombien, medan den andra injicerar motgiftet.
• Med en ensam människa och en ensam zombie på samma plats händer ingenting. De bara står och stirrar på varandra utan att kunna göra något.
• Med fler spelare på samma plats, till exempel två zombier och två människor, blir det också ett dödläge, och inget händer. (Men tänk på att positionerna bestäms med GPS, som alltid har ett visst fel i sina positionsangivelser. Dessutom kan det vara lite förvånande hur reglerna faller ut i komplicerade situationer med flera spelare.)

Kommunikationsprotokollet

Här är de kommandon som klienten kan skicka till servern, tillsammans med de svar som servern kan skicka. Alla data mellan klient och server skickas som strängar, med varje kommando och varje svar på en egen rad. (Undantaget är kommandot LIST-VISIBLE-PLAYERS, där svaret kan bestå av flera rader.)

Det nummer som skickas före varje kommando är bara ett löpnummer, som servern skickar tillbaka. Om servern har mycket att göra kan det hända att den inte hinner svara direkt på ett kommando, och då kan klienten använda löpnumret för att veta vilket kommando ett serversvar hör ihop med. Servern använder inte det löpnumret till något, förutom att skicka tillbaka det, och förmodligen behöver du inte använda det heller. Det får vara samma hela tiden, men det måste vara med.

(Observera att servern dessutom ibland skickar ut meddelanden till klienterna på eget bevåg, så kallade asynkrona meddelanden. Dessa meddelanden börjar med ordet ASYNC, och beskrivs i en annan tabell längre ner.)

Det flesta kommandona är ganska självförklarande, utom kanske TURN och LIST-VISIBLE-PLAYERS:

• TURN-kommandot är tänkt att användas vid testning. TURN ZOMBIE förvandlar spelaren till zombie, och TURN HUMAN förvandlar spelaren till människa. Om man försöker förvandla spelaren till något den redan är, svarar servern ERROR CANNOT-TURN.
• LIST-VISIBLE-PLAYERS kan man använda när man ska rita kartan, för att få reda på vilka spelare som finns inom synhåll och som därför ska ritas ut. Som svar från servern får man VISIBLE-PLAYERS, tillsammans med den synlighetsgräns som gäller, och antalet spelare som fanns inom synhåll. Därefter räknas dessa spelare upp av servern, en per rad. Den inloggade spelaren själv är med, och kommer först i listan. Om spelaren inte har en känd position, svarar servern ERROR UNKNOWN-POSITION.

Servern skickar ibland ut meddelanden till klienterna på eget bevåg, så kallade asynkrona meddelanden. Dessa meddelanden börjar med ordet ASYNC, och beskrivs i tabellen nedan. Klienten ska inte svara på dessa meddelanden.

När en spelare förvandlats till människa eller zombie, får den spelaren ett asynkront YOU-ARE-meddelande.

När en spelare förvandlats till människa eller zombie, eller flyttat på sig, skickas asynkrona PLAYER-meddelanden ut till alla spelare. GONE-varianten av PLAYER-meddelandet används när en spelare inte längre syns (för att hon loggat ut, eller kommit längre bort än synlighetsgränsen).

En dumhet: Observera att i protokollet skickas alltid latituden först, följt av longituden. Kommandot geo fix till emulatorn tar däremot longituden först, följt av latituden.

Ett tillägg i version 0.3 av serverprogrammet är kommandot LIST-ALL-PLAYERS, som främst är avsett för administration och felsökning av servern. Det listar alla registrerade spelare, oavsett om de är inloggade eller har någon position. Det kommandot kräver att man skickar med ett lösenord, som först ska ha angetts som argument när man startade servern.

Förslag på arbetsgång

1. Börja med att ladda hem och provköra servern: ZombieServer-0.3.2.zip
   Installera och kör servern på din egen maskin. Kör servern i ett separat fönster, och koppla upp dig mot den med först en och sen flera klienter.
2. Det finns en särskild desktop-klient (se nedan) för att koppla upp sig mot servern, och man kan också använda programmet telnet och skriva kommandon direkt. Undersök hur spelet fungerar, och hur protokollet mellan klient och server ser ut.
3. Jag kommer att köra en server på basen.oru.se. Under utvecklingen kan det vara praktiskt att provköra mot en egen, lokal server, men den färdiga klienten ska koppla upp sig mot basen-servern.
4. Skapa därefter en Android-app som kopplar upp sig mot servern.

Krav på klienten

1. Klienten ska kunna koppla upp sig mot servern och logga in.
2. Klienten ska rita upp en karta med spelarna, där man ser sig själv och de andra spelare som är inom synhåll. Det ska gå att se vilka av spelarna som är zombier och vilka som är människor.
3. Klienten ska hela tiden tydligt visa om spelaren är människa eller zombie.
4. Klienten ska uppdatera kartan när asynkrona meddelanden om positionsändringar och människa/zombie-ändringar tas emot.
5. För att det ska gå att rita kartan måste klienten kontinuerligt bestämma sin postion med GPS, och rapportera in postionen till servern.

1. Gör så att det går att ange namn och lösenord för den spelare man vill logga in som.
2. Gör så att det går att registrera nya spelare, och då ange namn och lösenord.
3. Rita ut en kartskala, så man ser hur långa avstånden är.
4. Skriv ut namnen på spelarna.
5. Undvik onödig kommunikation med servern. Man behöver inte begära en hel lista med kommandot LIST-VISIBLE-PLAYERS annat än första gången man ska rita kartan. Därefter använder servern asynkrona meddelanden för att skicka ut ändringar som man behöver ta hänsyn till.

1. Gör det möjligt att ändra gränsen för hur långt bort spelare ska synas (kommandot SET-VISIBILITY).
2. Anpassa den visade kartans storlek efter synlighetsgränsen, och de spelare som visas.
3. Visa en riktig karta, med hus och vägar! (Jag har hört att Google har kartor.)
4. Om telefonen har inbyggd kompass (med magnetiska sensorer eller GPS), så orientera kartan efter telefonens läge. Rita ut norr.
5. Vid inloggning skickas lösenordet i klartext. Laga detta allvarliga fel. (Det kräver naturligtvis också att man ändrar i servern.)

Desktop-klienten

Den här desktop-klienten körs alltså inte på Android, utan på en vanlig dator. Den har ett huvudfönster, där man bland annat kan logga in, och skriva in (simulerade) kartkoordinater:

Om man klickar på knappen Show map, visas en karta, som påminner om den karta som det ingår i uppgiften att skapa, men då alltså under Android:

Med knappen Show com log kan man få fram ett fönster där kommunikationen mellan klienten och servern visas:

Här kan vi se hur klienten skickat kommandot LIST-VISIBLE-PLAYERS, och fått ett svar med VISIBLE-PLAYERS om att det finns 4 spelare inom synhåll, som är 1000 meter. Sen listas de fyra spelarna, och den första av dem, tompa, är den inloggade spelaren själv.

Efter att vi fått detta svar från servern, har det kommit två asynkrona meddelanden från servern med nya positioner för spelaren bravo. Om en synlig spelare flyttar sig, eller förvandlas mellan zombie och människa, får man alltid asynkrona meddelanden om det. Om man låter klienten komma ihåg den mottagna informationen, slipper man därför skicka en ny VISIBLE-PLAYERS varje gång man ska rita upp kartan.

Tips

1. Man kan återanvända en del av koden från desktop-klienten.
2. Man kan hämta vissa Android-specifika lösningar från chat-klienten man gjorde i uppgift 4.
3. Man kan köra flera instanser av skrivbordsklienten samtidigt, så ser man kanske tydligare hur meddelanden från en klient påverkar de andra.
4. Bli inte förvånade om ni hittar buggar i servern eller i desktop-klienten. Rapportera dem.
5. Kända buggar i servern:
   • Om en klient kopplar ner utan att först logga ut, skickar servern inte GONE-meddelanden till de andra klienterna som den ska.

Redovisning

Det behövs ingen formell labbrapport, men om det är något som inte framgår direkt, till exempel hur man använder den inskickade appen eller vad utmatningen betyder, behövs det någon form av beskrivning. (Och underskatta inte min förmåga att inte begripa.)

Tillbaka till lektionslistan