Hoe hebben wij agenda functionaliteit gebouwd?

Voor de Mantelzorger App hebben wij als HelioBit onder andere de agenda functionaliteit ontwikkeld. Bij het implementeren hiervan liepen waren er aantal uitdagingen. Hieronder geven wij een toelichting van de uitdaging en legen we uit hoe we dit hebben opgelost.

Een visuele weergave van de agenda binnen de Mantelzorger App. — *Agenda binnen de Mantelzorger App*

Data Model

De eerste uitdaging had te maken met het data-model. Wat gaan we opslaan van een agenda-afspraak? Dit is natuurlijk erg afhankelijk van de functionaliteiten, denk hierbij aan herhalende afspraken, meldingen voor de start en bijv. locatie gegevens. Omdat wij als HelioBit ons graag laten inspireren door andere software kwamen we al snel uit bij een standaard voor agenda’s. Dit is de iCalendar-standaard. In RFC 5545 staat heel gedetailleerd beschreven hoe het data-model voor agenda-afspraken eruit ziet. Dit hebben wij gebruikt bij het bepalen van de data die wij opslaan. Uiteindelijk slaan wij de afspraken niet op in een tekst-bestand met het iCalendar formaat, maar in een gestructureerde database. Dit met als rede dat het verwijderen en wijzigen op deze manier makkelijker gaat. De server daarentegen geeft wel de agenda terug in het iCalendar formaat aan de frontend.

Herhalende afspraken

De volgende uitdaging had te maken met herhalende afspraken. Bij het veranderen van een herhalende afspraak kan het namelijk zo zijn dat alleen één specifieke afspraak of afspraken vanaf een specifieke datum gewijzigd moeten worden. De vraag hierbij was hoe we dit binnen het data-model konden opslaan. RFC 5545 zegt hier niet direct iets over.

BiBij het vinden van een juiste oplossing hebben wij gekeken naar hoe Google Calendar en Apple Calendar dit oplossen. Dit hebben we gedaan door z’n specifieke afspraak aan te maken en dit te exporteren naar het iCalendar standaard. Hieruit konden we afleiden dat beiden platformen gebruik maken van meerdere velden binnen de standaard voor afwijkingen in herhalende afspraken. Allereerst wordt het veld “UID” gebruikt. Het originele en afwijkende item krijgen dezelfde UID. Op deze manier kan worden vastgesteld dat de items bij elkaar horen. Om aan te geven wanneer de afwijking plaatsvindt, wordt het veld “RECURRENCE-ID” gebruikt. In dit veld kan worden aangegeven voor welke datum de afwijking geldt. Voor items waarvoor geldt dat de afwijking bestemd is voor een specifieke datum en alle toekomstige items wordt de volgende waarde gebruikt: “RECURRENCE-ID;RANGE=THISANDFUTURE:19980401T133000Z“.

Een voorbeeld van een dialoog die gebruikers zien bij het aanpassen vaan een herhalende afspraak. — *Dialoog voor het aangeven van het veranderen van een agenda afspraak.*

Eigen data binnen de standaard

De laatste backend uitdaging was dat we ook eigen data terug wilde geven aan de frontend. Dit is data die niet in iCalendar standaard worden beschrijven, maar wel nodig is voor de juiste werking voor de Mantelzorger App. Dit kunnen identifiers zijn, maar ook aanvullende data zoals profielfoto of naam van de persoon die de afspraak heeft aangemaakt. De RFC 5545 beschrijft deze data als “Non-Standard Properties”. Deze velden kunnen herkend worden door de prefix “X-”. Dit hebben wij dan ook gebruikt om extra data toe te voegen voor de functionaliteit in de Mantelzorger App.

Een visuele weergave van de agenda details afkomstig uit het iCalendar-formaat. — *Scherm met details vanuit de iCalendar data.*

Frontend

Na de hiervoor genoemde backenduitdagingen zijn we nu aangekomen bij de frontend. In de frontend wordt de iCalendar data uitgelezen. Na het uitlezen wordt berekend op welke dag een afspraak getoond moet worden. Dit wordt per dag berekend. Wanneer je snel door de agenda scrolt betekent dit dat de berekening vaak wordt uitgevoerd. Mede hierdoor moet deze berekening dus zo efficiënt mogelijk zijn, zodat de afspraken direct zichtbaar zijn als langs de dagen wordt gescrold. Dit hebben wij voor elkaar gekregen door de berekening te splitsen tussen herhalend en niet-herhalend en vooraf selecties te maken op datum indien mogelijk. Op deze manier nemen we alleen het deel van de afspraken mee dat behoort tot de dag waar de berekening voor wordt uitgevoerd.

Resultaat

Het resultaat van deze ontwikkelingen is dat er software is neergezet dat makkelijk herbruikbaar is. Met de code aan de frontend is het zelfs mogelijk om andere iCalendar’s te importeren bijv. van Google Calendar of Apple Calendar d.m.v. een abonnement. Dit biedt weer extra mogelijkheden in de Mantelzorger App. Door de oplossing is het nu ook makkelijk om de agenda van de Mantelzorger App te importeren in andere agenda oplossingen/apps. Vaak is het ook mogelijk om een iCalendar te importeren of een abonnement toe te voegen. Deze oplossing biedt dus beide kanten op voordelen.