Eat App ios. jacga987. Oktober 2016

Eat App ios jacga987 Oktober 2016 1 Inledning Syftet med Eat App är att få människor som inte tidigare mött varandra att få utbyta middagar. För en ensam person kan det betyda otroligt mycket om man kan bjuda över någon på middag. För människor som inte gillar att laga mat eller är på resande fot, så är det ett perfekt sätt att få äta billig hemmalagad och förhoppningsvis god mat. Samtidigt som alla får träffa nya vänner, kanske är det bara grannen som kommer över på ditt middagsevent eller några nya människor att lära känna. Figure 1: Logo Varje användare har en egen profilsida där man kan se användarens profilbild, namn, ålder och de eventen som användaren har skapat. Användare kan själva skapa nya event som är geotaggade på ett visst ställe. Alla som sedan befinner sig i närheten kan se det eventet. Man kan anmäla sig till vilket event som helst och det gäller då för användaren att faktiskt gå på eventet då värden/värdinnan räknar med att alla som anmält sig kommer. Detta skall ske som en förfrågan så att när användaren frågar om hen kan komma så kommer en notifikation till den användaren som arrangerar eventet där den användaren kan acceptera eller inte. 2 Problemanalys För att hantera och lagra data om event, användare och så vidare behöver jag en API som jag tog fram med hjälp utav Django Rest Framework. All data skickas från och till APIn. Svårigheter kommer först och främst att sköta överföringen 1

av datan på en annan thread än mainthread för att inte låsa UIn. En annan svårighet är att hålla datan i rätt synk mellan APIn och applikationen. För att göra detta behöver jag ha separata klasser för Event och User som kan lagra datan samt get/set den datan som behövs. Utöver det behöver jag två managers, en för Event och en för User, som har hand om API requesten samt lagrar alla events/users. De två managerna ska kunna kolla ifall en användare eller ett event redan finns sparat i managern och beroende på utfallet där även hämta eller uppdatera en instans. User Managern måste också sköta auktorisering mot APIn så jag vet att användaren har tillåtelse att hämta/ladda upp viss data samt validera inloggning. Så som jag vill ha UIn tror jag är relativt enkelt men vad jag lärt mig från labbarna så ser det enklare ut än vad det är. Det kan vara klurigt med att få alla constraints att samspela med varandra samt att det skall se bra ut på alla olika enheter. Kan bli lite utmanande att få formulären för registrering och inläggning av nytt event att bli som jag vill ha dem. Det är många lösa delar som skall samspela, t ex olika DatePickers och MapKit som ska kännas bra och enkelt att använda. 3 UI Här beskrivs lite om skissandet för applikationen samt förklaringar för alla skärmar. Vilka element som är i skärmarna och lite om hur dem fungerar på layoutnivå. Jag skissade fram en layout för hur jag ville att TableViewn skulle se ut där man ser alla närliggande event samt hur profilsidan skulle se ut. Registrering och lägga in nytt event är bara 2 formulär rakt upp och ner helt enkelt där jag försökt följa Apples guidelinjer för hur man gör. Valde att göra de som TableViews så att man kan dela in i sektioner plus att det är vad Apple rekommenderar för större formulär. Jag följde mina skisser till stor del men valde att göra några förändringar. Jag kollade en del på liknande applikationer och tog efter designvalen som de har gjort i viss mån. I figur 3a ser man den första skärmen som användaren ser, här kan man välja att logga in med sina användaruppgifter eller att skapa sig ett konto. Detta är en simpel View som är inbakad i en NavigationController så att när man klickar på Don t have an Account? Sign up now! så får man också upp en NavigationBar längst upp så att man kan gå tillbaka. På figur 3b ser man registreringsskärmen. När man skapar ett konto så måste allt fyllas i. Registreringsformuläret är en statisk tableview där vardera cell innehåller ett UITextField, UIButton eller UIDatePicker beroende på vilken data jag vill ha från den som registrerar sig. I figur 4a så ser man alla närliggande event med information om datum och 2

Figure 2: Skiss av eventtabellen samt profilsidan antal deltagare på vänster sidan, mittendelen av cellen är rubrik och beskrivning, på högersidan ser man avstånd till eventet från den positionen man har samt priset för eventet. I figur 4b ser man mer detaljer om eventet. Överst är profilbilden för den som skapat eventet och i detta fall är det den som är default om man väljer att inte ladda upp en profilbild. Under den är det UILabels med samma information som man ser på tableviewn över alla event. Under det har jag placerat en UIControl samt två containerviews som man byter mellan beroende på om man klickar på About och Participant. Hela UIControlen samt de två embeddade containerna ligger själva i en containerview. Här har jag haft lite problem med att få texten som visas att göra radbryt. Det är en UI- TextView som skall göra radbryt automatiskt men jag tror att det blir konstigt (a) Inloggningsskärm (b) Registreringsskärm Figure 3: De första skärmarna 3

(a) Listar alla events i närheten (b) Detaljerad information om eventet Figure 4: Lista event och detaljerad information om event (a) Skapa ett event (b) Man kan söka eller välja på kartan vart eventet skall vara Figure 5: Hur man skapar ett event med alla containerna just där. En bättre lösning hade kunnat vara att ha About och Participants controllern direkt i huvudviewn för skärmen och sen byta två containrar under den. Figur 5a är den skärmen som man skapar ett nytt event på. Det är en Table- View där vardera rad är antingen UITextField, UITextView, UIButton eller en UIDatePicker. När man klickar på Starting och Ending så ritas TableViewn om och inkluderar en UIDatePicker för användaren att enkelt kunna välja start och slutdatum. När man klickar på Place så kommer man till en MapView som kan ses på figur 5b. Där kommer det ett förstoringsglas uppe på navigationsbaren som tar fram en sökruta i navigationsbaren. Där kan användaren söka upp adressen där eventet skall vara. När man har hittat rätt ställe så kan man gå tillbaka till eventskaparskärmen och slutföra skapandet av ett nytt event. I figur 6a kan man se sin profilsida, det går även att se andras profiler om man 4

(a) Profilsida (b) Här kan man se alla event som en användare har arrangerat Figure 6: Profilsidorna klickar på dem under Participating i figur 4b. Överst ser man användarens profilbild och undertill namn, ålder samt events som användaren har arrangerat. Hela viewn är en statiskt TableView med där vardera cell är utformad efter att passa till innehållet. 4 Implementation Här beskrivs den bakomliggande implementationen för vardera skärm och de övriga klasserna jag använder i applikationen för att t ex hämta och skicka data. 4.1 Användare Till att börja med så finns det en klass som heter AppManager som är en singelton som sköter själva inloggningen av en användare. När användaren är inloggad så har APIn skapat en access token som gör att användaren har tillåtelse att hämta och skicka data. När inloggningen lyckats så används klassen SessionUser som ärver av User. User-klassen innehåller alla properties som en användare kan ha samt ett par funktioner som t ex getage som returnerar åldern på personen utifrån födelsedatumet. För att hantera alla användaren används en klass som heter UserManager. Den lagrar alla hämtade användare i en lista. En användare hämtas t ex när användaren väljer att besöka någon annans profil. Den här klassen har även ett par funktioner för att bland annat hämta användardata. Det uppstod en massa problem när jag skulle implementera en funktion för att registrera användare eftersom att jag också var tvungen att skicka en bild. För detta använde jag mig utav ett litet bibliotek som heter SRWebClient [1] och gjorts tillgängligt på GitHub för att sköta GET och POST requester med Swift. När man registrerar sig så utförs ett par tester på de inmatade fälten för att se så att de uppfyller vissa kriterier. Om allt är godkänt 5

så skickas det som en POST request till APIn. 4.2 Events Eventen fungerar ungefär som användare. Det finns en Event-klass och en EventManager-klass. EventManagern är en singelton så att man vet att det bara finns en. Event-klassen innehåller alla properties för event samt några funktioner. En funktion konverterar datum mellan APIn och Swift så att det lagras och visas på rätt sätt. EventManagern innehåller en lista med alla hämtade event. Den har funktioner för att hämta och skicka data till APIn samt funktion för att parsa JSON data från apin till en instans av Event. Om eventet redan finns sparat i listan så uppdateras eventet med den informationen som kom från APIn. 4.3 UI 4.3.1 Startskärm Startskärmen består utav en loggo längst upp som är en UIImageView. Under den är två UITextFields, ett för email och ett för lösenord. Det finns även en Remember me checkruta som man kan kryssa i för att applikationen ska spara emailen och lösenordet i en KeyChain. 4.3.2 Registrera ny användare Den här skärmen består utav en UITableViewController som är statisk. De översta cellerna innehåller en UITextField där användaren skriver in mail och lösenord (två gånger), om lösenorden är lika blir båda TextFielden gröna annars är de röda. När användaren klickar på Select birthday så visas en UI- DatePicker i cellen under och användaren gör sitt val. UIDatePickern är inställd på att man inte ska kunna välja yngre datum än 18 år. 4.3.3 Eventlistan Detta är en UITableView som är embedded i en UIBarController så att man kan ändra läge mellan att se en lista på eventen och sin profil. Cellerna är specialanpassade och går under klassen EventCell som håller alla properties, det vill säga UILabels, som sätts när tableview funktionen itererar igenom listan av events. Det går även att uppdatera eventsen genom att dra neråt på skärmen. Då skickas en GET request till APIn som returnerar en lista med alla event på en radie av 100km. Tanken är att användaren själv skall kunna välja radie men jag valde att inte ta med en skärm för att redigera sina profilinställningar just nu. När eventen kommer tillbaka från requesten så kollar EventManagern om eventet redan finns sparat och om det gör det så uppdateras endast informationen som till exempel avstånd om användaren har rört på sig. 6

4.3.4 Event i detalj När man klickar på ett event i eventlistan så utförs en segue till den här skärmen som sätter variabeln event till det eventet som användaren klickade på. All information sätts i viewdidload() funktionen. Därifrån startar även en funktion från UserManagern som hämtar användaruppgifter baserat på vilket ID användaren har. Listan över vilka deltagarna är är nämligen bara en lista med IDs (Integers). När de har hämtats så sker ett callback som returnerar resultaten och sedan updaterar datan i den tableviewn som man ser deltagarna i. Om man klickar på en användare i deltagarlistan så kommer man till deras profilskärm. Även där skickas användaren över till profilviewcontrollern genom en segue. 4.3.5 Profil Man kan välja att se sin profilsida nere på BarControllern. När man går in på sin profil så startar en nerladdning av sin profilbild om man inte redan har den sparad. Det fungerar på samma sätt när man kollar på någon annans profil. När den här skärmen startar så kollar den i viewdidload ifall en användare är definierad eller nil. Om en användare inte har skickats till profilsidan med segue från t ex deltagartabellen så antar den att det är ens egna profilskärm man vill se och då tar den SessionUser. SessionUer är en singleton instance som ärver allt som User har. Den har dessutom access token som property. 4.3.6 Skapa event När ett event skapas så kör den en funktion som heter is valid som ligger i den här view controllern. Den testar all data och om något saknas eller är fel så visas en UIAlertController som säger vad det är som är fel. Om allt är ifyllt rätt kommer också en UIAlertController upp som frågar en gång extra om man är säker på att man vill skapa eventet. När användaren trycker OK där så skickas all data till APIn och när man får ett resultat tillbaka så skickas användaren till eventlistan. Användaren kan nu hitta sitt event under sin profil och event. 5 Slutsats Arbetet har gått bra men långsamt. Jag är nöjd över resultatet och kanske ska fortsätta att utveckla applikationen efteråt också eller göra något nytt men liknande. Det känns som att jag fått använda många olika delar av Xcode och Swift som gör att jag nu har en bra och bred grund i ios-utveckling. Det enda jag inte lyckades med var notifikationer. Det var väldigt mycket mer komplicerat än vad jag förväntade mig. Hade jag haft en backend som redan var konfigurerad för att använda det kanske det hade gått men det var väldigt krångligt att implementera i APIn. Det kändes som det låg utanför ramen för vad det här projektet skall vara med. Arbetet har gjort att jag lärt mig att utveckla egna applikationer i Xcode med Swift. I det här projektet handlade mycket om att utföra uppgifter i async, 7

alltså inte på main thread för att UI:t inte skall frysa medan data skickas eller hämtas. Det finns en del svårigheter med att arbeta med async metoder eftersom att man måste vara säker på att t ex en properties har blivit initialiserad innan main threaden kan hämta och använda sig utav den. Jag har programmerat så tidigare men aldrig i Swift eller Objective-C så det var en ny utmaning helt klart. References [1] Suman Raj Venkatesan. Swift-srwebclient. https://github.com/sraj/ Swift-SRWebClient, 2014. 8