Depuis environ deux ans, je travaille à temps partiel sur un projet iOS avec une petite équipe. L’application a la forme d’un calendrier, mais contrairement aux autres applications de calendrier celle ci permet de prévoir combien de temps il reste, combien de temps a été prévu et a été fait pour différentes choses, et vient avec un outil pour noter ce qu’on fait en temps réel (ce qui vous donne au final un historique de l’utilisation du temps).
Je n’irai pas dans les détails de ce que l’app peut faire. Elle a été publié la semaine dernière, jetez-y un coup d’œil.
Pour cette application j’ai construit un système de synchronisation. Chaque appareil possède sa copie de la base de donnée, et chaque fois qu’il se connecte sur le serveur les bases de données sont fusionnés et les changements propagés aux autres appareils. Le fonctionnement est particulièrement intéressant, je vais donc élaborer un peu.
Notre système de synchronisation est construit d’une façon similaire à un système de contrôle de version distribué (Git, Mercurial, etc.). Ça comprend un étage de dépôt (repository) utilisé pour synchroniser des blocs de données binaire avec d’autre dépôts. Par dessus l’application maintient une base de donnée SQLite correspondant au modèle. Les chanements dans le dépôt local sont gardés synchronisés avec la base de donnée du modèle. Les changement au dépôt local sont aussi poussé sur le serveur, et vice versa. Et ainsi votre iPhone reste synchronisé avec votre iPad.
Ce système a deux propriétés intéressantes en commun avec les SCVD. D’abord, si un dépôt est perdu (que ce soit sur le serveur ou sur un autre appareil), il peut être reconstruit à partir des autres dépôts. Ensuite, en théorie on pourrait faire une sychronisation pair-à-pair sans serveur central même si en pratique gérer des comminications pair-à-pair est plus compliqué et rien n’a encore été fait de de côté.
C’est intéressant de noter que la base de donnée du modèle est essentiellement une cache pour ce qui se trouve dans le dépôt. Si le schéma de la base de donnée du modèle change (en mettant à jour l’application), il est inutile de migrer les données : on se débarasse de l’ancienne base de donnée et on la reconstruit à partir du dépôt local. Même principe que lors d’une synchronisation.
Au final, je suis bien content de ce système. Ça a pris du temps à construire, et il reste encore des détails à améliorer, mais ça en vallait l’effort. Essayez MeoTempo si vous voulez voir la synchronisation en action.