Projectvereisten

Het project wordt in twee variaties aangeboden. Een variatie met minimale vereisten om te slagen en een variatie met zwaardere vereisten waarmee je een hogere score kan behalen. De puntenverdeling is als volgt:

• $85\%$ is te verdienen door te beantwoorden aan de functionele vereisten
  • Minimale vereisten: $65\%$
  • Uitgebreide vereisten: $20\%$
• $15\%$ is te verdienen door een kwalitatieve, complexe en/of grote app te schrijven

Toegestane hulpmiddelen

Je mag voor dit examen gebruik maken van bronnen zoals tutorials, voorbeelden en StackOverflow. Dit betekent echter niet dat je project hier volledig op gebaseerd is. We controleren je inzendingen en indien grote gelijkenissen met online bronnen gedetecteerd worden, dan is dit plagiaat en wordt een fraudeprocedure gestart.

Het is toegestaan om delen uit de lesvoorbeelden of opgeloste oefeningen te herbruiken. Als je dit doet, moet je dit op een innovatieve manier doen. Hieronder zijn enkele voorbeelden te vinden, als je toch nog een specifieke vraag hebt over het al dan niet herbruiken van bepaalde code, dan contacteer je jouw lector hierover.

• De login-component uit les 6 mag herbruikt worden, maar dit telt niet mee als een pagina tenzij je hier een uitbreiding aan doet. Bijvoorbeeld het toevoegen van een email/wachtwoord login en de bijhorende meldingen voor het succesvol aanmaken van een account of foutieve wachtwoorden of de optie om een wachtwoord te resetten.

• De login functionaliteit uit les 6 telt niet mee als online service tenzij je een extra provider configureert. Dit mag eender welke provider zijn, GitHub, Facebook, Twitter, Microsoft, ... Als je enkel Google en phone authentication voorziet zoals in de les, is dit niet voldoende.

• De PhotoService uit les 4 telt enkel mee voor de plug-in vereisten als je de foto's op een alternatieve manier verwerkt, zoals het uploaden naar Firebase (of soortgelijk), het versturen naar één of andere API voor image recognition of het implementeren van een crop functionaliteit of het toevoegen van filters.

Begeleiding

Tijdens het bouwen van de applicatie is het toegestaan raad te vragen aan de begeleidende lector.

Vragen over leerstof die gezien is tijdens de lessen worden zelden beantwoord, je wordt meestal doorverwezen naar het relevante lesmateriaal. Vragen over leerstof die enkel in de uitbreidingsoefening TVTracker gezien is of over features van Angular/Ionic/Capacitor die in geen enkele oefening gezien zijn worden wel beantwoord. Als je kan aantonen dat je het cursusmateriaal gebruikt heb en geprobeerd hebt om een feature zelf te implementeren, word je wel geholpen. Ook als dit gaat over leerstof die wel in de les behandeld is.

Met vragen over conceptuele problemen zoals het structureren van je app of dingen die je niet geprogrammeerd krijgt, maar die los staan van de (geziene) Angular/Ionic/Capacitor features kan je altijd terecht bij je begeleidende docent. Je wordt gecoacht in het vinden van een oplossing.

Indien er problemen ontstaan door bibliotheken die niet meer werken door updates, updates van de IDE, deprecated features … kan je ook hierover hulp vragen.

Vragen die buiten de les gestuurd worden moeten een link bevatten naar een GitHub repository met de code van je project, je geeft je lector ook schrijfrechten op dit repository.

Kwaliteit

De kwaliteit van je code wordt beoordeeld op basis van onderstaande, niet exhaustieve, lijst. Omdat je voor een functionerend project al veel punten kunt verdienen ($85\%$) wordt de kwaliteit en complexiteit van je code streng beoordeeld.

• Naamgeving van variabelen
  • Correct gebruik van enkelvoud/meervoud in de namen
  • Duidelijke namen
• Types
  • Types van variabelen
  • Types van functies
• Gebruik van enums waar toepasbaar
• Geen diep geneste callbacks
• Gebruik van klassen/interfaces in de plaats van objecten met het any type
• Consistentie in de code, geen mix van () => {} en function() {} (voor methode namen, callbacks kunnen natuurlijk wel als arrow function gedefinieerd worden als de rest de klassieke syntax gebruikt.)
• Volgen van de linting regels die door Ionic geconfigureerd worden in ESLint.
• Geen hard gecodeerde gegevens
• Voldoende gebruik van services
• Opsplitsen in componenten waar nuttig
• Leesbaarheid

Minimale vereisten

Als je project voldoet aan onderstaande vereisten, kan je, mits een minimum aan bugs en een bruikbare UI maximaal, een 13/20 halen voor de functionele eisen. Je kan natuurlijk nog steeds punten verdienen voor de kwaliteit van je code en zo maximaal een 16/20 scoren. Hoe meer van deze vereisten ontbreken en hoe meer bugs er zijn, hoe lager je zult scoren. Je eindresultaat is meer dan de som van je punten, je eindresultaat voor de minimale vereisten wordt vermenigvuldigd met één van onderstaande factoren, afhankelijk van het aantal ontbrekende features en het aantal bugs.

Figuur 1: Beoordelingstabel

Hier worden volgende definities gebruikt:

• Uitstekend: Na grondig testen geen enkele bug tegengekomen en een duidelijke UI waar alles in terug te vinden is zonder problemen en die steeds de juiste data weergeeft.
• Zeer goed: Na grondig testen een bug of twee gevonden en/of hier en daar een onduidelijke UI of een UI die niet goed bruikbaar is, maar die nog steeds de juiste data weergeeft.
• Goed: Meer dan de helft van de aanwezige functionaliteiten werken, maar vertonen bugs en/of een foute UI die niet altijd de juiste data bevat of UI elementen die onbruikbaar worden.
• Minimaal: Minder dan de helft van de aanwezige functionaliteiten werken volledig en de UI vertoont regelmatig foute data of onbruikbare onderdelen.
• Ondermaats: Minder dan $1/3$ van de functionaliteiten werken zonder bugs en/of de UI vertoont regelmatig foute data of onbruikbare onderdelen.
• Niet bruikbaar: Geen van de aanwezige functionaliteiten werken zonder bugs.

Pagina’s

Voeg minstens vier pagina’s toe aan je applicatie, waarvan er één enkel statische gegevens mag bevatten. Zorg dat je tussen deze pagina’s kan navigeren, hoe je dat doet (side-menu, tabs, nog iets anders) beslis je zelf. De pagina’s mogen een combinatie van statische en hard gecodeerde data bevatten, maar minstens drie pagina's moeten onderdelen bevatten die dynamisch opgebouwd zijn. Elke van deze drie pagina's moet dus property binding of 2-way data binding gebruiken, daarbovenop moet de data opgehaald worden via een service.

Dynamische data

Om te voldoen aan de minimumvereisten moet elke dynamische pagina minstens objecten bevatten met twee of meer attributen (id niet meegeteld). Daarnaast moet minstens één pagina objecten gebruiken met zes of meer attributen (id niet meegeteld).

Voor bovengenoemde objecten moeten alle CRUD operaties voorzien worden. Daarnaast moet er tijdens het invoegen van nieuwe data de nodige validatie uitgevoerd worden.

Plug-ins

Gebruik minstens twee plug-ins. Dit mogen Capacitor of Cordova plug-ins zijn. Twee plug-ins is niet veel. Network, storage, en notifications kunnen in zo goed als elke app gebruikt worden. Indien je een plug-in gebruikt die we niet gezien hebben of geziene plug-ins gebruikt op een nieuwe manier, zal dat de punten voor de kwaliteit en complexiteit van je project ten goede komen.

Gebruik de plug-ins op een zinvolle manier. Een controle op de netwerkverbinding, maar verder geen gebruik maken van deze verbinding zal je geen punten opleven, ook al werkt de code zonder fouten. Ook authentication wordt niet meegeteld tenzij je iets doet met de gebruikersinformatie.

Een plug-in is een library die geschreven is voor Capacitor of Cordova en een brug vormt tussen het operating system (Android/iOS) en de web-layer. Een JavaScript library die je installeert via pnpm is niet automatisch een plug-in, de library moet een brug vormen tussen JavaScript en swift/java. Onderstaande plug-ins tellen niet mee omdat Ionic hier al elementen voor bevat.

• @capacitor/action-sheet
• @capacitor/dialog
• @capacitor/toast

Verder telt @ionic/storage ook niet mee als plug-in omdat Capacitor een beter alternatief bevat, zoals in de les besproken is.

Voor inspiratie verwijzen we door naar:

• https://github.com/riderx/awesome-capacitor
• https://github.com/capacitor-community

Tenslotte tellen ook de plug-ins die standaard geïnstalleerd zijn niet mee, tenzij je hier iets zinvol mee doet dat niet automatisch gegenereerd wordt.

• @capacitor/app
• @capacitor/haptics
• @capacitor/keyboard
• @capacitor/status-bar

Online services

Je moet minstens één online service gebruiken. Dit kan een API zijn, Firestore, Firebase Authentication, Supabase, AppWrite, ... Natuurlijk moet dit opnieuw op een zinvolle manier gebeuren. User authentication heeft, als je verder geen gebruik maakt van de gebruikersnaam, het e-mailadres, het GSM nummer of andere user gegevens, geen zin. Een foto uploaden naar Firebase en vervolgens de foto enkel uit de locale storage lezen heeft ook geen zin.

Logo & Splash

Zorg dat je applicatie een gepast logo en splash screen heeft. Je wordt niet beoordeeld op de kwaliteit van je icoon en/of splash screen, enkel op de aanwezigheid. De enige voorwaarde is dat de gebruikte afbeeldingen moeten verschillen van diegene die gebruikt werden in de les.

Publicatie

Je bouwt een APK voor je applicatie (zie les 6) en je uploadt deze APK samen met de source code op Canvas als zip, verwijder de node_modules folder voordat je jouw code uploadt.

Bied je applicatie aan als een PWA via Firebase hosting of een andere hosting provider (telt niet mee voor de online services). De PWA app moet niet enkel bruikbaar zijn als web app maar moet ook geïnstalleerd kunnen worden via de website. Enkel het hosten is niet voldoende. De PWA moet werken. Maak gebruik van een tool zoals https://www.seoreviewtools.com/pwa-testing-tool/ om te controleren of je PWA volledig in orde is.

Voeg de URL van je PWA toe in een README.MD bestand in je zip.

Persistentie

Je app moet dynamische gegevens bevatten. Dit betekent dat de gebruiker wijzigingen moet kunnen aanbrengen en dat deze wijzigingen bewaard moeten kunnen worden. Zorg dat de acties van de gebruiker bewaard blijven nadat de app herstart wordt. Hoe je dit doet bepaal je zelf, je kan gebruiken maken van de Capacitor Storage plug-in, een embedded sqlite database, een document database op Firebase, een SQL database op Supabase, een eigen geschreven API, ...

Uitgebreide vereisten

Als je project voldoet aan onderstaande vereisten, kan je, mits een minimum aan bugs en een bruikbare UI maximaal een $17/17$ halen voor de functionele eisen. Je kan natuurlijk nog steeds extra punten verdienen voor de kwaliteit van je code en zo maximaal een $20/20$ scoren voor dit project.

Alle minimale vereisten blijven nog steeds gelden.

Pagina’s

Alle vier de pagina’s in je applicatie moeten dynamische gegevens bevatten.

Plug-ins

Gebruik minstens drie plug-ins.

Online services

Gebruik drie verschillende online services. Waarvan er minstens één geen deel uitmaakt van Firebase.

Publicatie

De PWA app moet bruikbaar zijn op een desktop computer. Je moet dus een responsieve lay-out voorzien. Je kan hiervoor gebruik maken van de <ion-split-pane>, <ion-grid>, <ion-row> en <ion-col> componenten.

Persistentie

Je app moet de gebruiker de optie bieden om de gegevens in de cloud te bewaren. Hiervoor moet user authenticatie voorzien worden, gegevens worden per gebruiker bewaart. Dit betekent niet dat de gebruiker noodzakelijk ingelogd moet zijn om de app te gebruiken. Je kan er ook voor kiezen de gebruiker pas te laten inloggen als hij aangeeft dat de gegevens in de cloud bewaard moeten worden.

De user authentication en cloud opslag tellen mee als twee van de drie cloud services.

Deadline & verdediging

De deadline voor het project is op Canvas te vinden. De uploadzone blijft tot twee uur na deze deadline open staan. Voor elke minuut dat je te laat indient verlies je (ongeveer) $0.8\%$ van je score. Als je $N$ minuten te laat indient, wordt je eindtotaal berekend als

$\frac{120 - N}{120 \cdot score}$

Tijdens de examenperiode kom je het project mondeling verdedigen. Je toont wat je gebouwd hebt en je krijgt een aantal vragen om te polsen of je de code begrijpt en deze zelf geschreven hebt.