Contexte
Dans XT3, la seule fonction des alarmes était de déclencher l'affichage d'un message à un moment programmé.
La notion de répétition était assurée par le recalcul du prochain moment de déclenchement, il n'y avait ni date de début ni date de fin, mais un mécanisme permettait de ne pas déclencher les alarmes "en retard".
Le système était géré de façon simple, les données manipulées en mémoire et stockées sur disque étant exactement celles affichées dans l'outil.
Cette notion d'alarme en tant que donnée indépendante ne sera plus présente dans XT4.
Une alarme dans XT4 représentera désormais la même chose que dans les autres logiciels : un reminder facultativement attaché à un évènement.
Prenons par exemple le cas d'un RDV à 15h00 nécessitant 15 min de trajet :
- Dans XT3 : programmation d'une alarme pour 14h45 avec comme texte "RDV à 15h00".
- Dans XT4 : programmation d'un évènement pour 15h00 avec comme texte "RDV" et programmation d'une alarme 15 min avant. L'évènement reste dans l'agenda après déclenchement de l'alarme.
Modèle
Une fois ces alarmes créées ou importées, la première tâche de l'outil va être de les analyser afin de connaitre le moment où déclencher la prochaine alarme.
Dans XT3, il suffisait de lire les informations de la première alarme de la liste.
Dans XT4, il était envisagé de ne pas considérer les alarmes comme des objets séparés, mais uniquement comme un ensemble de propriétés de l'évènement, encadrées en rouge ci-dessous: Cela signifie que la recherche de la prochaine alarme devrait :
- Boucler récursivement sur les tous dossiers de l'utilisateur.
- Dans chaque dossier utilisateur :
- Analyser les évènemenst récurrents avec alarme, ne pas considérer la date de l'évènement mais calculer celle de l'alarme, celle-ci pouvant se déclencher jusqu'à 5 jours avant l'évènement.
- Boucler sur les dossiers techniques "Week" qui servent d'index au calendrier, et sous-boucler sur les évènements uniques. Afin de gérer les alarmes "en retard", il a d'abord été envisagé de gérer jusqu'à 8 semaines de retard, puis de stocker une date de dernière utilisation.
- Il faudrait également analyser les évènements futurs, puisque qu'une alarme peut être programmée jusqu'à 5 jours avant son évènement.
On commençait à s'aventurer aux frontières du réalisable, jusqu'à la question fatidique : comment gérer une alarme qui a été déclenchée à l'heure programmée, repoussée par l'utilisateur et immédiatement suivie d'une fermeture de l'application ? Où stocker les informations de la nouvelle alarme, celle-ci ne pouvant pas se permettre d'écraser les données originales stockées sur l'évènement ?
Stop.Une nouvelle analyse va maintenant être lancée avec l'utilisation d'objets dédiés, qui seraient créés en plus des propriétés de l'évènement. Ça éliminerait au moins les problèmes de performances et de report d'alarme. On se rapprocherait donc du modèle XT3, mais avec le lien "Alarme -> Evènement" en plus (ce qui va créer des problèmes), et il faut maintenant analyser si les impacts de ce système ne seront pas pires que le précédent.