Et avant ça, une petite précision : dans la gestion des données de l’application, je fais la différence entre ce que j’appelle le référentiel et les données applicatives :
Référentiel : liste de valeurs qui servent principalement dans des lookups, ou listes de paramétrage, etc. (par ex. une liste des véhicules de location de l’entreprise, ou une liste de bouquins à louer, etc.). Ces données ne sont pas modifiées par les utilisateurs mais plutôt par les admins.
Données applicatives : ces données sont celles qui sont manipulées par les utilisateurs finaux (par ex. : les locations des véhicules par les salariés, ou les emprunts de bouquins, etc.).
Revenons sur la synchro…
La synchro a 2 raisons d’être :
T’as des données stockées dans le cache local lorsque tu étais en mode déconnecté et tu ne les as pas encore poussées vers tes sources de données.
T’as des utilisateurs qui peuvent aussi modifier les données côté backend et il faut donc les pousser vers l’application pour qu’elle en aie connaissance.
L’idéal c’est évidemment d’éviter le point 2 😉 et de faire en sorte que tes données ne puissent être modifiées que par le biais de l’application. Ca évite de faire une synchro avec gestion des conflits où tu finis par redévelopper l’algorithme de OneDrive 😁.
En gros y’a 3 solutions pour réaliser la synchro :
soit ton appli synchronise les données dès l’ouverture : toutes les données du cache local non encore sauvegardées sont poussées vers tes sources de données puis tous les référentiels de tes sources de données sont mis à jour dans le cache local ;
soit ton appli effectue cette synchro à intervalle régulier “en tâche de fond” à l’aide d’un timer (toutes les 2mn par ex.)
soit la synchro est déclenchée manuellement par l’utilisateur : l’avantage c’est qu’il peut choisir ce qu’il pousse ou pas côté sources de données (c’est que j’avais fait dans mon appli).
Et pour finir j’ai oublié de préciser aussi que j’ai ouï dire que les applications model-driven intègrent automatiquement un mode déconnecté. A creuser…