Je travaille actuellement sur une application mobile / de bureau / distribuée avec exactement les mêmes exigences et les mêmes problèmes.
Premièrement, ces exigences ne sont pas inhérentes aux applications mobiles en elles-mêmes, mais à toutes les transactions client / serveur déconnectées / distribuées (programmation parallèle, multithreading, vous obtenez le point). En tant que tels, ils constituent bien sûr des problèmes typiques à résoudre dans les applications mobiles.
En gros, tout cela revient à dire que vous avez un enregistrement de données potentiel qui est distribué à n clients, qui peuvent le modifier en même temps. Ce dont tu as besoin c'est
- un mécanisme de contrôle / verrouillage de version approprié,
- une gestion des droits / accès appropriée,
- une stratégie de synchronisation / mise en cache appropriée
Pour (1) , vous pouvez appliquer certains modèles: Il existe deux stratégies de verrouillage fréquemment utilisés: Optimiste hors ligne de verrouillage , et Pessimiste Hors ligne de verrouillage . Certains d'entre eux sont appliqués dans différents "modèles" de contrôle de version, tels que le contrôle MVCC ( MultiVersion Concurrency Control ), qui utilise un compteur (sorte d'un "horodatage" très simple) pour chaque enregistrement de données, qui est mis à jour chaque fois que l'enregistrement est modifié. .
(2) et (3) sont des questions très vastes en elles-mêmes, qui doivent être traitées indépendamment de (1). Quelques conseils de mon expérience:
Utilisez une technologie client-serveur qui résout pour vous la plupart des problèmes. Je recommande fortement une technologie Web telle que CouchDb , qui gère très bien (1) via Optimistic Offline Locking + MVCC, (2) via Web API et (3) via la mise en cache Http.
Essayez de ne pas inventer des choses vous-même si vous pouvez compter sur des technologies et des approches éprouvées. Je crois que chaque heure passée à rechercher et à comparer les technologies / schémas existants est bien mieux dépensée que d'essayer de mettre en œuvre votre / vos système (s).
Essayez d'utiliser des technologies homogènes si possible. Par "homogène", j'entends des technologies conçues avec les mêmes principes, par exemple des scénarios d'utilisation du Web 2.0. Un exemple: utiliser un client CouchDb et REST approprié (API Web) avec une stratégie de mise en cache locale est un meilleur choix que d'utiliser SQL pour les applications mobiles.
Je déconseille fortement l’utilisation de MySQL car il s’agit d’une technologie qui n’était pas explicitement conçue pour de tels scénarios d’utilisation. Cela fonctionne, mais vous êtes beaucoup mieux avec un système de base de données qui intègre déjà le style de communication Web et de concurrence (tel que de nombreuses bases de données NoSQL).
En passant, j'ai opté pour CouchDb avec un client local personnalisé fonctionnant contre les API CouchDb, qui fonctionne et évolue à merveille. J'ai abandonné MSQL + (N) Hibernate et j'ai payé le prix fort pour ne pas avoir fait le bon choix (c'est-à-dire ne pas avoir fait assez de recherche).