Personal Project: Event App
Laat ik me eerst even voorstellen. Ik ben Kanzi Louagie, 20 jaar oud en ben reeds derdejaars student in DEVINE (Kask), Kortrijk. Dit wil zeggen dat ik zelf al een goeie twee jaar en een half ‘geniet’ van het studentenleven. Dit omvat natuurlijk het gebruikelijke: ik zit op kot, ik ga naar school, ik studeer na school, maar even belangrijk: Ik ga ook wel eens uit doorheen het jaar.
Tijdens het uitgaan, hier in Kortrijk dus, ben ik 3 mensen tegengekomen die een app hadden ontwikkeld voor de omgeving Kortrijk o.v.v het uitgaansleven. Ik was er onmiddellijk mee verkocht en vroeg hoe de app noemt: Gank Kortrijk.

Toen ik de app opende zag ik dat het redelijk amateuristisch in elkaar zat. De interface was laggy, de buttons leken niet op buttons, als je doorklikte op een button laadden de foto’s en evenementen niet onmiddelijk in en ik vond de algemene stijl van de app ook niet zo mooi.
Maar buiten al deze ‘minor’ (schoonheids)foutjes, hebben ze een concept die werkt en die mensen/studenten in de buurt kunnen gebruiken, om snel uit te vissen wat er te doen is in de avond.
Voor mijn persoonlijk project wil ik dit project nemen, in het geheel dat bestaat en wil ik er mijn eigen twist qua development/uitwerking en design aan geven. Ik weet zeker dat de app potentieel heeft. Maar waarom enkel in Kortrijk?
… En niet voor alle studentenbuurten in België? :)
Week 2: Research
Even kort briefen waar ik momenteel nu sta in mijn project:
Na mijn pitch ben ik op gesprek geweest bij een leerkracht uit mijn richting (Digital Design and Development, Kortrijk) en heb ik met hem besproken wat ik nu het beste doe de komende weken. Ik besprak onder andere of React-Native nu de ‘way to go’ was of als dit me in een verder stadium in het uitwerken mij problemen zou geven.
Zelf, voor ik op gesprek ging bij hem, had ik al wat test-fases gedaan met React-Native om te weten of dit doenbaar was of niet voor mijn project en vond ik dat dit wel zou lukken. (meer hierover bij de volgende titel…)

Alhoewel, mijn project was sinds toen al wat veranderd. De bedoeling nu is om ook, buiten de oplijsting van de verschillende studentenbuurten en café’s ook te werken met AR.
Extra concept bij idee
Zoals iedereen waarschijnlijk weet heeft elk evenement op facebook een passende banner.

Wat als we werken met een soort van leaderboard systeem, waarbij elke user op eender welk moment van de dag, van een evenement de banner foto kan nemen en kleven op een random gebouw, muur of zelf op een tshirt van een persoon, etc. Na het nemen van de foto kan men hiervan een foto nemen en delen via instagram stories, facebook stories, opslaan in zijn gallerij, etc.
Men kan de poster zoveel keer ophangen als hij wil, maar per keer dat hij dit gedaan heeft, krijgt hij een punt en kan hij dus hoger geraken in de leaderboard.
Laten we nu even terugkeren naar het verhaal van mijn programmeertaal…
Is React-Native nu de way to go?
Hét sterke punt van React-Native is, dat je dezelfde app, op beide platformen (Apple en Android), simultaan kan gaan uitwerken. Dit kan aan de hand van simulators of aan de hand van Expo. (een app op je gsm, waarmee je onmiddellijk je code kan builden en bekijken op je smartphone).
Alhoewel dit een heel sterk punt is bij React-Native heb je ook zaken die niet voor beide platformen kunnen worden uitgewerkt. Een goed voorbeeld hiervan is dus AR.
Apple werkt met ARKit 3 ondertussen, terwijl Android werkt met ARCore.
2 verschillende Libraries die ongeveer evenveel aankunnen dan de andere, maar die dus nog niet voor beide platformen dezelfde zijn. Als men in React-Native met deze 2 frameworks wil werken, dan zal je moeten werken met bridges in je code en Swift-code moeten schrijven voor bepaalde zaken voor Apple en werken met Java voor de Android-code. Wat na een bepaalde tijd zeer onoverzichtelijk zal zijn.
Dus:
Is React-Native de way to go?
Nee.
Voor dit project, kies ik ervoor om de eerste versie van mijn app uit te werken in Swift, om deze dan erna om te zetten naar Android Studio.
Research
De volgende logische stap in mijn proces, valt nu volledig buiten het programmeren en welke taal ik gebruik en alle technische zaken.
Ik moet nu een lijst zien te maken van alle studentencafé’s /-buurten in België, meer specifiek Vlaanderen.
Ik maakte een enquête op via Google Forms met 2 simpele vragen:
- In welke stad kent u een uitgaansbuurt?
- Hoe noemt het café/uitgaansbuurt (bv. Pallieter — Gent), u kunt ook meerdere café’s opgeven.
Hierop kreeg ik in een snelle tijd al een goed overzicht van welke café’s er zijn in België: meer specifiek in deze regio’s: Gent, Antwerpen, Leuven, Brugge, Kortrijk, Brussel, Mechelen en Torhout
Nu ik deze informatie heb, kan ik beginnen programmeren. (Ondertussen wordt de enquête verder ingevuld en kan ik mijn lijst later aanvullen.
Wat is het doel van deze lijst?
Ik neem deze lijst bij me en zoek de specifieke Facebookpagina's op van elk café in elke buurt. De links van deze Facebookpagina's steek in daarna in een variabele. En deze variabelen gebruik ik dan in een Array, om zo met de Facebook Graph API alle data - per buurt - op te halen.
Design
Ondertussen kunnen we de app beginnen wireframen en designen. Het logo is al tot stand gekomen en de beginnende layout krijgt ook vorm.


Eerste problemen… Of toch niet?
De meeste API’s de dag van vandaag werken met Access Tokens. The Facebook Graph API niettemin. Je hebt de User Access Token, App Token en de Page Access Token. Lang heb ik de User Access Token gebruikt met het idee dat dit allemaal goed werkte: ik kreeg data uit de API, ik probeerde verschillende andere café’s “die ik kende” en stak ze in de Graph Explorer van Facebook.
Vandaag maakte ik een Facebookpagina aan voor mijn app (Bash) en probeerde het opnieuw, deze keer met de Page Access Token.
‘Dit lukte niet.’
Na even kijken op google op Stack Overflow en de documentatie van de api zag ik dat ik een heel belangrijk feit over het hoofd had gezien. Namelijk:
Only Events for which the requesting User is listed as a Host or Guest will be returned.
Ik kreeg namelijk alleen maar evenementen te zien, waarop ik zelf op geïnteresseerd stond. (Wat ik nogal vaak was).
Waarom ik dit nu achteraf gezien geen probleem vond:
Dit kan je in eerste instantie zien als obstakel. Mààr ook als groeimiddel!
1. “Je app wordt exclusiever.”
Stel dat de app heel populair wordt. Dan wil jij, als cafébaas toch zeker ook gefeatured worden op de app met je events.
Het enige wat er moet gebeuren, is de start: Éen café moet ooit als eerste worden toegevoegd op de app.
2. “Goeie reclame voor Bash”
Hoe meer café’s je medeorganisator maken van events, hoe meer reclame je krijgt (aangezien dit altijd op facebook staat in de heading bij info).
3. “Minder werk (voor mij dan)”
De café’s zelf hoeven niet veel meer te doen dan enkel ‘Bash’ in te vullen bij medeorganisatoren wanneer ze een evenement maken via Facebook, dit duurt nog geen vijf seconden extra.
7 dagen later: waar staan we nu met het project?
De problemen die ik vorige keer had heb ik besproken met een leerkracht. Na het vertellen van mijn oplossingen, had hij mij verteld dat “cafés je laten medeorganisator maken van evenementen een heel werk is om die mensen te gaan overtuigen om dit te doen, zeker in het begin”: Hij zag de tweede oplossing (overal op geïnteresseerd zetten met ‘een bepaald profiel’ een betere oplossing. En achteraf gezien heb ik ook dit gevoel.
Hoe kan ik deze oplossing nu gaan verbeteren, en hoever ben ik al tot deze oplossing gekomen… Dat vertel ik in het volgende hoofdstuk.
waar staan we nu met het project?
In de afgelopen zeven dagen heb ik de meeste core-functionaliteiten van mijn app kunnen toevoegen, echter wel niet zonder veel opzoekwerk en bugfixing.
Lijstweergave van de evenementen die uit de Facebook graph API komen:
Het weergeven van de lijstweergave van de evenementen heb ik kunnen fixen aan de hand van SwiftyJSON, Alamofire en Firebase.
Om te beginnen heb ik in Firebase een CloudStore of FireStore tabel aangemaakt: in deze tabel sla ik de facebooknaam van het evenement op,
De link ziet er als volgt uit:
https://www.facebook.com/pg/cafetkanon/events/
Hiervan heb ik ‘cafetkanon’ nodig. Deze sla ik op in de database, samen met de plaatsnaam van het cafe, in dit geval ‘Kortrijk’. Dit heb ik herhaald voor verschillende cafes in Kortrijk en ondertussen al 1 café in Gent als testwaarde.
De waarden van alle cafe’s heb ik dan uiteindelijk opgehaald en in een array ‘Arraycafes’ gestoken. Deze haalde ik eruit met een FireBase commando.
Met AlamoFire heb ik uiteindelijk een api call kunnen doen om de data uiteindelijk van de Facebook Graph API te halen. Deze sla ik dan uiteindelijk ook weer op in een andere variabele array.
Met dit commando haal ik de database uit de tabel afhankelijk van de ‘selectedcafe’ en als selectedcafe = ‘alle buurten’ dan moet hij alle cafe’s uit de database halen.
Daarna kon ik deze inlezen in m’n tabelview en wordt de data teruggegeven.
Het volgende dat ik afgelopen dagen geprogrammeerd heb, was een soort van inlog-systeem.
Met dit inlog-systeem kan je het volgende doen op mijn app:
- vrienden opzoeken en een vriendschapsverzoek versturen.
- vrienden toevoegen wanneer je een vriendschapsverzoek gekregen hebt.
- zien waar je vrienden zich momenteel bevinden door een incheck-systeem.
Dit klinkt heel evident en simpel, maar was 3x ingewikkelder te realiseren i.v.m de lijstweergave.
Ten eerste moet je ervoor zorgen, dat mensen die niet ingelogd zijn:
- Geen check-ins kunnen bekijken
- Niet naar de settings weergave kunnen gaan om vrienden toe te voegen en te zien
Wanneer ze dit wel proberen, moet er een pop-up venster verschijnen om je dan toch weer in te loggen.
Wanneer je uiteindelijk wel ingelogd bent, moet je de vorige zaken dus wel kunnen bereiken.
Het inloggen gebeurd via FireBase en Facebook Authentication:
Het eerste wat ik moest doen was in FireBase aanduiden dat ik via facebook wil kunnen aanmelden. Daarna moest ik in de Facebook Developer Tools een bepaalde referentie kopiëren om dit mogelijk te maken + aanduiden dat ik Facebook Login wil gebruiken in m’n app.
Wanneer deze koppeling gemaakt is, heb ik de FireBase AuthUI gebruikt als overlay met als provider de Facebook Authenticatie. De rest ging ongeveer vanzelf. Na het inloggen kreeg ik bepaalde waarden terug. Deze heb ik als testwaarden afgeprint: DisplayName, PhotoURL en UID.
Deze waarden heb ik dan ook opgeslagen in een collectie ‘users’ in mijn FireStore Database. Dit had ik nodig om dan uiteindelijk mijn sociaal netwerk aan te maken.
Nu deze users in mijn database komen, kon ik beginnen aan het vrienden toevoegen systeem. Hierbij moet je eens goed nadenken. Hoe voegen wij vrienden toe?
- Je vriend moet in de database zitten.
- Als je vriend in de database zit, dan kan je hem opzoeken in de database.
- Als je je vriend gevonden hebt, moet je hem kunnen toevoegen.
- Als je hem hebt toegevoegd, dan moet je in de lijst van vriendschapsverzoeken komen bij de andere partij.
- Wanneer deze vriend dan naar zijn lijst gaat, moet hij/zij je kunnen toevoegen.
- Wanneer hij je heeft toegevoegd, dan ben je uiteindelijk ‘gemeenschappelijke vrienden’
De code is op dit moment ongeveer goed op stand gekomen. Het enige wat nu nog toegevoegd moet worden in de ‘pending’ status wanneer jij iemand toevoegd. Maar daar zal ik tegen het einde van dit project waarschijnlijk niet meer geraken.
De Core Functies van de App zijn nu bijna allemaal op zijn plaats. Dus what’s next?
In het begin van het project wou ik zeker iets met AR doen. Een feature in de app steken die mensen niet verwachten, en misschien wel leuk kan zijn.
Dit is dan ook de hele reden dat ik in Swift ben begonnen coderen en niet in React-Native of Flutter. Het gebruik van AR ligt heel zwaar op de CPU en grafische kaart van de applicatie en iedere OS heeft zijn eigen AR Systeem.
Bij Swift is dit dus ARKIT. En uiteindelijk ARKIT3.
Dus wat heb ik uiteindelijk verzonnen?
Een scherm in m’n app na de detailweergave, waarvan jij de poster in ‘real-life’ kan ophangen.
Dus daar ben ik dan eens aan begonnen. Na veel opzoekwerk naar ARKIT3 en documentatie van Apple over ARKIT3, moet ik zeggen dat het een heel grote tegenvaller geweest is. Ook de documentatie en tutorials over Reality Composer zijn zo miniem uitgebracht dat het voor mij ‘als beginner’ bijna onmogelijk was om hier nog aan te beginnen zo last minute.
Hetgeen dat mij het meeste aansprak bij ARKIT3 en wat ik dus ook wou gebruiken was Collaborative Sessions. Met meerde personen op eenzelfde moment met verschillende Iphones kunnen zien wat een persoon heeft veranderd aan de scene. Maar jammergenoeg (voor dit project) nog niet genoeg gevonden daarover.
Nu ben ik op andere platformen beginnen zoeken en ik heb een SkillShare course gevonden die ARKIT en RealityKit goed uitlegde. Hierbij heb ik de functionaliteit die ik heb willen aanbrengen in mijn app toch nog uiteindelijk kunnen waarmaken in een tijdsspanne van ongeveer 2 dagen.
Het belangrijkste aan de implementatie van AR vondt ik dat je met een indicator kon zien wat je uiteindelijk aan het doen was. In eerste instantie zag het er niet zo moeilijk uit. Apple had een FocusSquare klasse aangemaakt. Met een FocusSquare Segments file apart. Deze probeerde ik in mijn project te importeren en ik kreeg een foutmelding. Vele variabelen in deze swift files waren ongekend in mijn project. Dus begon ik deze toe te voegen vanaf het voorbeeldproject… Na het toevoegen van die bestanden, moest ik onnodige code verwijderen van die bestanden, code toevoegen die ik mistte enzovoort enzovoort.
Na de vele pogingen (en het te weinig testen van de applicatie met de Ipad zelf) heb ik alle foutmeldingen eruit kunnen krijgen. Ik startte de applicatie op en… CRASH! SGBRT error 5353672jdsbqjh… enzovoort.
Ik mocht opnieuw beginnen dus.
Terug naar SkillShare dus. Hier was er een basic model van de FocusSquare die van scratch werd geschreven. Het enige dat ik dus moest doen was de focus square omzetten van een horizontal plane, naar een vertical plane.
Waar ik dacht dat het gewoon .horizontal veranderen was naar .vertical in een variabele was het veel meer dan dat.
Ik moest dus ten eerste aanduiden in mijn code dat ik een verticale muur zoek.
Ook de Focus Square zelf aanmaken:
De juiste delegate methodes gebruiken om de square up te daten en de positie ervan juist te zetten t.o.v het ancherpunt dat initieel werd aangemaakt:
Checken wanneer de focus square echt een vlakte raakt of niet:
En dan uiteindelijk de afbeelding plaatsen die ik via de navigatiecontroller van de detailpagina heb overgebracht naar de ARViewController.swift klasse:
Wat was mijn oplossing nu om de evenementen makkelijk van Facebook te halen?
De bedoeling is nu nog om een klein Python script aan te maken die zich inlogt op mijn Facebook, surft naar de links van de cafes en dan overal zich op geïnteresseerd zet. Geen idee of ik zover nog geraak voor dit project, maar misschien in de nabije toekomst wel.
Wat moet er nog gebeuren tegen het einde van dit project:
Kort gezegd. We zijn er bijna buiten enkele schoonheidsfoutjes:
- Er moet nog een label komen op de homepagina die de evenementen scheid van datum van het evenement. Bv. Eerst een label 15 december, daarna alle evenementen voor 15 december, hetzelfde voor 16 december enzovoort…
- De evenementen zijn nu gesorteerd volgens datum (dit klopt), maar na deze filter zouden ze gesorteerd moeten zijn op aantal geïnteresseerde personen.
- Als er geen internetconnectie is, moet je een melding krijgen dat je moet verbinden met het internet voor je de applicatie verder kan gebruiken.
- Users kunnen vrienden toevoegen, maar ze moeten bestaande vrienden ook weer kunnen verwijderen.
Tot daar zal het wel genoeg zijn (voor dit project)… Maar er komen nog updates… dus stay tuned komende weken!