Comment synchroniser les données de base de l'iPhone avec le serveur web, puis les pousser vers d'autres appareils ?

Question

J'ai travaillé sur une méthode permettant de synchroniser les données de base stockées dans une application iPhone entre plusieurs appareils, comme un iPad ou un Mac. Il n'existe pas beaucoup (voire pas du tout) de cadres de synchronisation à utiliser avec les données de base sur iOS. Cependant, j'ai réfléchi au concept suivant :

1. Une modification est apportée au magasin de données de base local, et la modification est enregistrée. (a) Si le dispositif est en ligne, il essaie d'envoyer le jeu de modifications au serveur, y compris l'ID du dispositif qui a envoyé le jeu de modifications. (b) Si le jeu de modifications n'atteint pas le serveur, ou si le dispositif n'est pas en ligne, l'application ajoute le jeu de modifications à une file d'attente pour l'envoyer lorsqu'il sera en ligne.
2. Le serveur, situé dans le nuage, fusionne les ensembles de modifications spécifiques qu'il reçoit avec sa base de données principale.
3. Après qu'un ensemble de modifications (ou une file d'attente d'ensembles de modifications) est fusionné sur le serveur en nuage, le serveur pousse tous ces ensembles de modifications vers les autres appareils enregistrés auprès du serveur en utilisant une sorte de système d'interrogation. (J'ai pensé à utiliser les services Push d'Apple, mais apparemment, selon les commentaires, ce n'est pas un système exploitable).

Y a-t-il quelque chose de spécial auquel je dois penser ? J'ai regardé les frameworks REST tels que ObjectifRessource , Ressource principale y RestfulCoreData . Bien sûr, toutes ces applications fonctionnent avec Ruby on Rails, auquel je ne suis pas lié, mais c'est un point de départ. Les principales exigences que j'ai pour ma solution sont les suivantes :

1. Toute modification doit être envoyée en arrière-plan sans mettre en pause le fil principal.
2. Il doit utiliser le moins de bande passante possible.

J'ai réfléchi à un certain nombre de ces défis :

1. S'assurer que les ID d'objets pour les différents magasins de données sur les différents appareils sont attachés sur le serveur. C'est-à-dire que je disposerai d'une table d'identifiants d'objets et d'identifiants de dispositifs, qui sont liés via une référence à l'objet stocké dans la base de données. J'aurai un enregistrement (DatabaseId [unique pour cette table], ObjectId [unique pour l'objet dans toute la base de données], Datafield1, Datafield2), le champ ObjectId fera référence à une autre table, AllObjects : (ObjectId, DeviceId, DeviceObjectId). Ensuite, lorsque le dispositif envoie un ensemble de modifications, il transmet l'identifiant du dispositif et l'identifiant de l'objet à partir de l'objet de données principal dans le magasin de données local. Ensuite, mon serveur en nuage vérifiera l'objectId et le deviceId dans la table AllObjects, et trouvera l'enregistrement à modifier dans la table initiale.
2. Toutes les modifications doivent être horodatées, afin qu'elles puissent être fusionnées.
3. L'appareil devra interroger le serveur, sans consommer trop de batterie.
4. Les dispositifs locaux devront également mettre à jour tout ce qui est conservé en mémoire si/quand des changements sont reçus du serveur.

Y a-t-il autre chose qui m'échappe ici ? Quels types de frameworks dois-je envisager pour rendre cela possible ?

Answer 1

J'ai fait quelque chose de similaire à ce que vous essayez de faire. Je vais vous dire ce que j'ai appris et comment je l'ai fait.

Je suppose que vous avez une relation univoque entre votre objet Core Data et le modèle (ou schéma de base de données) sur le serveur. Vous voulez simplement garder le contenu du serveur en synchronisation avec les clients, mais les clients peuvent aussi modifier et ajouter des données. Si j'ai bien compris, alors continuez à lire.

J'ai ajouté quatre champs pour faciliter la synchronisation :

1. sync_status - Ajoutez ce champ uniquement à votre modèle de données principal. Il est utilisé par l'application pour déterminer si vous avez une modification en attente sur l'élément. J'utilise les codes suivants : 0 signifie qu'il n'y a pas de changement, 1 signifie qu'il est en attente de synchronisation avec le serveur, et 2 signifie que c'est un objet temporaire et qu'il peut être purgé.
2. est_supprimé - Ajoutez ceci au serveur et au modèle de données principal. L'événement Delete ne doit pas réellement supprimer une ligne de la base de données ou de votre modèle client, car il ne vous laisse rien à synchroniser en retour. En ayant ce simple drapeau booléen, vous pouvez définir is_deleted à 1, le synchroniser, et tout le monde sera content. Vous devez également modifier le code sur le serveur et le client pour interroger les éléments non supprimés avec "is_deleted=0".
3. dernière_modification - Ajoutez ceci au serveur et au modèle de données principal. Ce champ doit être automatiquement mis à jour avec la date et l'heure actuelles par le serveur chaque fois que quelque chose change dans cet enregistrement. Il ne doit jamais être modifié par le client.
4. guide - Ajouter un identifiant unique au niveau mondial (voir http://en.wikipedia.org/wiki/Globally_unique_identifier ) au serveur et au modèle de données principal. Ce champ devient la clé primaire et devient important lors de la création de nouveaux enregistrements sur le client. Normalement, votre clé primaire est un nombre entier incrémentiel sur le serveur, mais nous devons garder à l'esprit que le contenu peut être créé hors ligne et synchronisé ultérieurement. Le GUID nous permet de créer une clé tout en étant hors ligne.

Sur le client, ajoutez du code pour définir sync_status à 1 sur votre objet modèle chaque fois que quelque chose change et doit être synchronisé avec le serveur. Les nouveaux objets modèles doivent générer un GUID.

La synchronisation est une demande unique. La demande contient :

• L'horodatage MAX last_modified des objets de votre modèle. Cela indique au serveur que vous souhaitez uniquement les modifications postérieures à cette date.
• Un tableau JSON contenant tous les éléments avec sync_status=1.

Le serveur reçoit la demande et fait cela :

• Il prend le contenu du tableau JSON et modifie ou ajoute les enregistrements qu'il contient. Le champ last_modified est automatiquement mis à jour.
• Le serveur renvoie un tableau JSON contenant tous les objets dont l'horodatage last_modified est supérieur à l'horodatage envoyé dans la requête. Ce tableau comprendra les objets qu'il vient de recevoir, ce qui sert de confirmation que l'enregistrement a été synchronisé avec succès sur le serveur.

L'application reçoit la réponse et fait ceci :

• Il prend le contenu du tableau JSON et modifie ou ajoute les enregistrements qu'il contient. Chaque enregistrement reçoit un sync_status de 0.

J'espère que cela vous aidera. J'ai utilisé les mots "record" et "modèle" de manière interchangeable, mais je pense que vous avez compris l'idée. Bonne chance.

Answer 2

Je suggère de lire attentivement et de mettre en œuvre la stratégie de synchronisation discutée par Dan Grover lors de la conférence iPhone 2009, disponible à l'adresse suivante aquí en tant que document pdf.

Il s'agit d'une solution viable et pas si difficile à mettre en œuvre (Dan l'a mise en œuvre dans plusieurs de ses applications), qui recoupe la solution décrite par Chris. Pour une discussion approfondie et théorique de la synchronisation, voir l'article de Russ Cox (MIT) et William Josephson (Princeton) :

Synchronisation de fichiers avec des paires de temps vectorielles

qui s'applique aussi bien aux données de base avec quelques modifications évidentes. Cela fournit une stratégie de synchronisation globale beaucoup plus robuste et fiable, mais nécessite plus d'efforts pour être mise en œuvre correctement.

EDIT :

Il semble que le fichier pdf de Grover's ne soit plus disponible (lien brisé, mars 2015). MISE À JOUR : le lien est disponible via la Way Back Machine. aquí

Le cadre Objective-C appelé ZSync et développé par Marcus Zarra a été déprécié, étant donné qu'iCloud semble enfin supporter une synchronisation correcte des données de base.

Answer 3

Si vous êtes toujours à la recherche d'une solution, jetez un coup d'œil au Couchbase mobile. Il fait tout ce que vous voulez. ( http://www.couchbase.com/nosql-databases/couchbase-mobile )

Answer 4

Comme @Cris, j'ai implémenté une classe pour la synchronisation entre le client et le serveur et j'ai résolu tous les problèmes connus jusqu'à présent (envoyer/recevoir des données vers/depuis le serveur, fusionner les conflits basés sur les horodatages, supprimer les entrées en double dans des conditions de réseau peu fiables, synchroniser les données et les fichiers imbriqués, etc.)

Il suffit de dire à la classe quelle entité et quelles colonnes elle doit synchroniser et où se trouve votre serveur.

M3Synchronization * syncEntity = [[M3Synchronization alloc] initForClass: @"Car"
                                                              andContext: context
                                                            andServerUrl: kWebsiteUrl
                                             andServerReceiverScriptName: kServerReceiverScript
                                              andServerFetcherScriptName: kServerFetcherScript
                                                    ansSyncedTableFields:@[@"licenceNumber", @"manufacturer", @"model"]
                                                    andUniqueTableFields:@[@"licenceNumber"]];

syncEntity.delegate = self; // delegate should implement onComplete and onError methods
syncEntity.additionalPostParamsDictionary = ... // add some POST params to authenticate current user

[syncEntity sync];

Vous pouvez trouver la source, un exemple fonctionnel et plus d'instructions ici : github.com/knagode/M3Synchronisation .

Answer 5

Notification à l'utilisateur de la mise à jour des données via une notification push. Utilisez un fil d'arrière-plan dans l'application pour vérifier les données locales et les données sur le serveur en nuage, lorsque des changements se produisent sur le serveur, les données locales sont modifiées, et vice versa.

Je pense donc que la partie la plus difficile est d'estimer les données dans lesquelles le côté est invalidé.

J'espère que cela pourra vous aider