Amener Task dans les nuages
→ This post is translated in English
Avant Task, nous avons pu expérimenter un peu iCloud : nos jeux, SEQ et ON/OFF, l'utilisent pour synchroniser la progression des joueurs entre leurs devices. Evidemment, avec Task, nous avons eu à synchroniser des tâches, ce qui est un problème bien plus complexe.
La synchronisation de SEQ et ON/OFF est basée sur le Key-value storage fourni par l'API d'iCloud qui est simple à mettre en place et à utiliser. Malheureusement, nous ne pouvions pas l'utiliser avec Task car cette solution ne permet pas de gérer de grandes quantités de données. Il y a deux autres types de stockage iCloud : le Document storage et le Core Data storage. Notre premier réflexe a été d'essayer de baser notre synchronisation sur le stockage Core Data d'iCloud. Grave erreur : nous avons été incapables, comme beaucoup d'autres développeurs avant nous, de le faire marcher correctement. La seule option restante était donc le Document storage.
Et en fait ça marche plutôt bien ! Alors, comment l'utilise-t-on pour synchroniser des tâches ? Comme pour des nombreux problèmes, la solution la plus simple est souvent la meilleure : utiliser des changelogs. Leur utilisation est naturelle et, si iCloud perd les pédales, permet aux utilisateurs d'accéder quand même à leurs données.
Dans Task, les tâches d'un utilisateur sont stockées dans une base de données locale. Pour être synchronisée, une application doit "envoyer" ses changements à iCloud et "récupérer" les nouveaux sur celui-ci. Il y a donc 3 acteurs : iCloud, les changelogs et la base de données locale. De plus, il convient d'identifier deux types de changement : local vers iCloud et iCloud vers local.
Pour ce faire, chaque occurrence de l'application (i.e. un device avec Task connecté au même compte iCloud) est responsable de son propre changelog. A chaque fois qu'un changement est effectué, il doit être ajouté au changelog, c'est la partie local vers iCloud. Les changelogs sont stockés sur iCloud donc une occurrence de Task peut accéder aux autres changelogs, c'est la partie iCloud vers local. Facile, non ? Evidemment il y a des subtilités : par exemple il n'est pas possible de récupérer les changements d'iCloud et de les appliquer à la base de données locale directement, l'application doit être prête (l'utilisateur n'est pas en train de faire quelque chose). Donc, les changements bruts sont premièrement convertis en changements applicables à la base de données (cela peut être fait en tâche de fond à tout moment) puis, quand l'application sera prête, elle vérifiera si changements en attente il y a et, uniquement à ce moment là, les appliquera à la base de données locale.
Intégrer iCloud à Task n'a pas été une sinécure, mais cela en valait la peine d'un point de vue utilisateur. Cependant, gardez bien tête qu'iCloud n'est pas si magique qu'Apple veut bien le laisser entendre, en particulier pour les développeurs. Sa mise en place est ardue alors soyez indulgents :)
La synchronisation de SEQ et ON/OFF est basée sur le Key-value storage fourni par l'API d'iCloud qui est simple à mettre en place et à utiliser. Malheureusement, nous ne pouvions pas l'utiliser avec Task car cette solution ne permet pas de gérer de grandes quantités de données. Il y a deux autres types de stockage iCloud : le Document storage et le Core Data storage. Notre premier réflexe a été d'essayer de baser notre synchronisation sur le stockage Core Data d'iCloud. Grave erreur : nous avons été incapables, comme beaucoup d'autres développeurs avant nous, de le faire marcher correctement. La seule option restante était donc le Document storage.
Et en fait ça marche plutôt bien ! Alors, comment l'utilise-t-on pour synchroniser des tâches ? Comme pour des nombreux problèmes, la solution la plus simple est souvent la meilleure : utiliser des changelogs. Leur utilisation est naturelle et, si iCloud perd les pédales, permet aux utilisateurs d'accéder quand même à leurs données.
Dans Task, les tâches d'un utilisateur sont stockées dans une base de données locale. Pour être synchronisée, une application doit "envoyer" ses changements à iCloud et "récupérer" les nouveaux sur celui-ci. Il y a donc 3 acteurs : iCloud, les changelogs et la base de données locale. De plus, il convient d'identifier deux types de changement : local vers iCloud et iCloud vers local.
Pour ce faire, chaque occurrence de l'application (i.e. un device avec Task connecté au même compte iCloud) est responsable de son propre changelog. A chaque fois qu'un changement est effectué, il doit être ajouté au changelog, c'est la partie local vers iCloud. Les changelogs sont stockés sur iCloud donc une occurrence de Task peut accéder aux autres changelogs, c'est la partie iCloud vers local. Facile, non ? Evidemment il y a des subtilités : par exemple il n'est pas possible de récupérer les changements d'iCloud et de les appliquer à la base de données locale directement, l'application doit être prête (l'utilisateur n'est pas en train de faire quelque chose). Donc, les changements bruts sont premièrement convertis en changements applicables à la base de données (cela peut être fait en tâche de fond à tout moment) puis, quand l'application sera prête, elle vérifiera si changements en attente il y a et, uniquement à ce moment là, les appliquera à la base de données locale.
Intégrer iCloud à Task n'a pas été une sinécure, mais cela en valait la peine d'un point de vue utilisateur. Cependant, gardez bien tête qu'iCloud n'est pas si magique qu'Apple veut bien le laisser entendre, en particulier pour les développeurs. Sa mise en place est ardue alors soyez indulgents :)
June 20, 2013