Programmeren Inhoudsopgave Beginpunt 2 Implementatie Karhoo 3 ETA & Prijs principe 4 Implementatie prijsberekening en gegevens database 4 Het versturen, ontvangen en beantwoorden van ritaanvragen. 7 Weergeven van alle taxi s op de kaart 9 Chauffeurs met meerdere auto s 11 1
Beginpunt Voor ik begon aan het semester was ik al aan de slag gegaan met mijn taxi app. Ik heb gelijk de keuze gemaakt om met 2 apps te werken. Zo hebben de gebruiker en de chauffeur een andere app, zo kan iedere app perfect aansluiten op de doelgroep. De chauffeurs app zag er na smart mobile, zo uit: Zoals te zien, is er nog weinig uitgewerkt en is er ook nog geen echt design toegepast. De chauffeurs app werd tot dit moment ook alleen gebruikt om te zorgen dat de chauffeur een rit request kon accepteren. Wel is er in het tweede scherm ruimte over gelaten onder aan voor nieuwe elementen. De gebruikersapp was na smart mobile ook niet zo top er moest nog veel gebeuren. Alhoewel ik op sommige punten de app wel al wat moderner heb gemaakt. Zo heb ik de inlog UI aangepast en kun je vanuit de app zo maar een willekeurige taxi bestellen als test van de functionaliteit. 2
Implementatie Karhoo Uit mijn onderzoek kwam naar voren dat ik en de app gebruikers erg onder de indruk waren van de manier waarop Karhoo de beschikbare taxi s liet zien. Nadat ik had getest of de gebruikers het ook in mijn app fijn vonden om te gebruiken, heb ik het op mijn eigen manier nagemaakt. Je ziet hier dat ik met de locatieservice van apple, de huidige locatie inclusief adres laat zien. Verder berekent de service hoe ver welke taxi van mijn locatie af is. Als je nu op de knop boek taxi zou drukken, kun je niet een taxi kiezen maar wordt er een willekeurige taxi aangeroepen, dit is nog omdat het een ouder prototype is. 3
ETA & Prijs principe De gebruiker van de app is meestal op zoek naar: 1. De taxi die het snelst op locatie is. 2. De goedkoopste taxi naar bestemming. Om mijn app ideaal te maken voor mijn doelgroep heb ik ervoor gekozen om net zoals Karhoo, een keuze tussen ETA (Estimated Time of Arrival) en prijs te maken. Hiernaast zie je hoe ik dit heb ingericht. Wanneer je op prijs drukt, komt er een pop-up die vertelt dat je voor een prijsindicatie ook een bestemming nodig hebt. Implementatie prijsberekening en gegevens database Wanneer je een bestemming invoert, wordt er netjes berekend hoeveel kilometer de reis is en hoeveel minuten het duurt tot je op de bestemming bent. Dit wordt voor de gebruiker en chauffeur omgerekend in een prijs en een route die hierlangs wordt getoond. De prijs wordt berekent vanuit een starttarief, tarief per kilometer en een tarief per minuut. Er staat ook netjes bij, wat voor type voertuig het is en wat de aankomsttijd van de taxi is op jou locatie. De technieken van de route en de locatie service maken gebruik van enkele softwarebibliotheken van Apple. Zo maakt de app veel gebruik van CLGeoCoder() en CLLocationManager(). Verder worden er FOR-loops gebruikt om voor iedere taxi locatie een ETA te kunnen berekenen. Omdat dergelijke request asynchroon zijn en dus soms later aankomen als dat een funtie is aangeroepen, wordt er ook veel gebruik gemaakt van zogenaamde Closures, die zorgen ervoor dat de data op het juiste moment bij de functie aankomen. 4
Dit is de functie die de berekening doet wat de ETA tijden zijn per chauffeur. Het mechanisme wat de route trekt over de map, is gemaakt met een overlay. (Z.o.z) 5
Zie hier de code met aantekeningen: 6
Het versturen, ontvangen en beantwoorden van ritaanvragen. Wanneer de gebruiker zijn keuze heeft gemaakt, gaat de app verder. Er wordt eerst nog een korte bevestiging gevraagd om zeker van de boeking te zijn. Wanneer de laatste bevestiging is gedaan komt er een melding bij de gebruiker die laat zien dat het proces in werking is gezet. Wanneer de ritaanvraag in de database wordt gezet, krijgt de chauffeur een melding. De chauffeur kan kiezen of hij deze rit wilt rijden en nadat hij deze accepteert wordt het gelijk in de database gezet. 7
Het enige wat nog niet lukt me de requests, is om de gebruiker hierna een alert terug te geven dat de rit ook is geaccepteerd. Indien de rit wordt afgewezen zou de gebruiker een alert moeten krijgen die vraagt om verder te zoeken. Door een softwarematig probleem kom ik hier nog even niet verder, maar een groot probleem is het niet. De techniek die achter de aanvraag listener wordt mij geleverd door Firebase zelf. Ze hebben in hun API een observeevent functie gebouwd. Je kunt zelf kiezen wat je wilt, ik ging in dit geval voor de.childadded functie bij het binnen krijgen van requests. Deze kijkt erna of er iets nieuws wordt toegevoegd bij de ritaanvragen. De.childchanged functie kijkt erna of de aanvraag is geaccepteerd of niet, er wordt namelijk een waarde veranderd(changed) onder de status parameter. Hieronder zie je de functie die, wanneer er iets wordt toegevoegd, de data inleest en omzet in een bericht. Dit bericht kan de chauffeur accepteren of afwijzen. Na het accepteren of afwijzen wordt de onderstaande functie gebruikt, om in de database aan te geven wat het antwoord van de chauffeur is. 8
Weergeven van alle taxi s op de kaart Om de gebruiker een mooi overzicht te geven was het mijn plan, om de locatie van de chauffeurs, die via de chauffeurs app wordt geüpdatet, op de kaart te zetten. Zo kun je gelijk goed zien waar er iemand in de buurt is. Dit is meer voor het type doelgroep die graag alles zelf uitzoekt. Het hoeft niet, maar ik wil deze manier wel openhouden. Eerst keek ik naar de database vol coördinaten van taxi s, die ziet er zo uit: Dit is een chauffeur, met ID 01. Deze informatie wordt uit de database gehaald met de volgende functie: 9
Hierna moet de informatie ook op de kaart worden gezet, dit gebeurt in de ViewController zelf door de functie: placeallcabplacemarks. Deze pakt uit de array alle locaties en zet deze neer op de map. Hieronder zie je het resultaat van alle taxi s in de buurt De plaatjes van de taxi zelf, worden in een functie van apple als taxi afbeelding gekoppeld aan een placemark. Normaal is het een rode pin die als afbeelding, maar nu heb ik dat dus verandert naar een taxi afbeelding. 10
Chauffeurs met meerdere auto s In eerste instantie was ik eigenlijk niet van plan om dit concept aan te pakken, of eerder gezegd ik had er nog niet aan gedacht. Maar door een video die ik had bekeken op youtube over een taxi app, besefte ik me dat dit een issue kon worden bij mijn app. Ik heb contact opgenomen met een bevriende groep chauffeurs en hen de vraag gesteld hoe ze tegen dit onderwerp aan keken. Het antwoord was dat het hun beter leek om een keuze in te bouwen indien je meerdere auto s hebt. Dit is aantrekkelijker voor de chauffeurs omdat de app hierdoor alles biedt wat ze nodig hebben. Nadat ik dit had onderzocht ben ik aan de slag gegaan om een dergelijk systeem in te bouwen. Ik begon bij de database, daar heb ik zelf wat nieuwe data ingebracht, wat in een later stadium ook door de chauffeur zelf gedaan kan worden. Zie database: Hier zie je 1 chauffeur, de eerste code is zijn persoonlijke ID dit is alleen voor het programmeren belangrijk verder niet. Bij Vehicles zie je 2 auto s, deze worden uiteindelijk door de chauffeur zelf ingevoerd, hierna kan hij in het overzicht kiezen welke auto hij wilt gebruiken. 11
Wanneer een vehicle wordt gekozen, komt de chauffeur op de map waar hij online kan gaan. In de toekomst komt hier een heatmap met drukke gebieden in de buurt waar de chauffeur veel werk kan krijgen. Hieronder is het overzicht, met de gekozen BMW te zien. De apps zijn erg recent pas gemaakt als hoe ze nu zijn, daarom zitten er ook nog geen menu s in. Het is puur de functionaliteit die ik op heb gezet i.c.m. een backend die de authenticatie en database managment op zich neemt. 12