Up-Sync et Down-Sync dans Android?
Je travaille sur une application de Point de vente qui doit être un très bon mécanisme de synchronisation. Nous avons la base de données Magento.L'appareil android a SQLite Local Db. Maintenant, nous devons synchroniser de la manière suivante:
Local ------Sync Pour---------------> Serveur (Synchronisation)
Serveur------Sync Pour---------------> Les Habitants (En Bas De La Synchronisation)
Il y a 2 choses:
1) écrire à (Comment prendre soin??)
Pour chaque changement que je fais sur local, il sera synchroniser directement mon local au serveur
2) réécriture (comment prendre soin???)
Chaque fois qu'il y a un changement dans le serveur, nous devons synchroniser tous nos locaux avec le serveur.
Donc, la tâche est: identifier une mise à jour du serveur
Et synchroniser nos locaux. Comme il y a 4 appareils sont en cours d'exécution dans un magasin et nous avons ajouté un nouveau client à travers un seul appareil. Maintenant, je veux que les trois autres périphériques db local soient également mis à jour avec les informations sur ce client et ce serveur mettre.
J'ai entendu parler des threads d'arrière-plan et des threads d'exécution après un intervalle de temps. Mais quelle est la meilleure façon de faire ce qui n'affecte pas l'application. Aussi tous les Grands magasins de Détail utilise le processus de synchronisation. ce qu'ils ont utilisé pour cela ?
Toute aide est appréciée.
6 réponses
Cela dépend entièrement de votre structure de base de données...
Vous avez DATABASE dans LOCAL (device) et sur SERVER
MAINTENANT
Vous devez avoir TIMESTAMP fieLd ajouté au {[5] } que vous voulez réellement synchroniser.
Chaque fois que vous apporterez des modifications sur le serveur, le TIMESTAMP sera mis à jour et il en sera de même pour la base de données locale.
Exécutez un service en arrière-plan qui continuera à comparer le TIMESTAMPS de LOCAL avec celle de SERVER.
Maintenant, vous devez mettre la condition que, si TIMESTAMP de SERVER est plus récente que de LOCAL, puis d'apporter des modifications à partir de SERVER à LOCAL,
and vice versa will be the condition to take changes from LOCAL to SERVER.
En outre, vous devez décider à quelle fréquence vous souhaitez exécuter ce SERVICE.
Alternativement:
Vous pouvez créer la table sur SERVER qui stockera LAST_SYNCHED date pour un périphérique particulier
Chaque fois que vous vous connectez à votre appareil (ou à tout autre événement particulier sur lequel vous souhaitez qu'il effectue cela), le serveur vérifiera-
- lorsque ce périphérique a été LAST_SYNCHED
- ensuite, il le comparera à la DATE D'AUJOURD'hui
- et vérifiera ce que upadets s'est réellement passé entre ces dates et enverra les modifications au LOCAL (périphérique)
Et vice versa pour LOCAL (périphérique) au serveur
Vous devez jouer avec TIMESTAMPS rest vous pouvez avoir votre propre logique pour structurer la base de données.
Je vous ai dit ce que j'ai observé, quand j'ai fait partie de un tel projet similaire
Modifier
Le processus ci-dessus définit comment synchroniser les périphériques avec le serveur, je veux dire la stratégie..
Si vous souhaitez que vos appareils soient notifiés du serveur lors de la synchronisation au lieu de frapper le SERVICE Web de manière récurrente ..
Vous pouvez utiliser la NOtification PUSH , GCM est l'un d'entre eux qui envoient des notifications push aux périphériques, vous pouvez l'intégrer à votre projet
Pour la synchronisation, vous devez gérer les deux situations suivantes.
- Comment et quand recevoir les mises à jour du serveur
- Comment identifier les données locales non synchronisées
Comment et quand recevoir les mises à jour du serveur:
Pour recevoir des mises à jour, nous pouvons utiliser GCM (Google Cloud Messaging). Si des mises à jour sont effectuées dans le serveur, le serveur envoie un message push à tous les périphériques. Les appareils recevront cette poussée et en fonction du message, les appareils téléchargeront les données du serveur. (Je pense c'est une meilleure approche que le service de frappe continue pour certains intervalles particuliers comme l'interrogation)
Pour recevoir uniquement les données mises à jour du serveur, le serveur conserve la colonne modified_timestamp pour toutes les tables. Les périphériques pour la première fois envoient un horodatage vide, de sorte que le serveur envoie toutes les données au périphérique avec un horodatage du serveur. Le périphérique reçoit les nouvelles données et met à jour la base de données locale et enregistre le dernier horodatage du serveur. Pour la prochaine fois pour obtenir des mises à jour du serveur, l'appareil enverra le serveur stocké horodatage puis le serveur enverra uniquement les données modifiées après cet horodatage uniquement. Pour chaque serveur de réponse envoie l'horodatage du serveur, les périphériques doivent stocker cet horodatage et doivent l'utiliser lors de l'appel du service.
Comment identifier les données locales non synchronisées:
Pour envoyer des mises à jour locales, La base de données locale doit conserver une colonne 'isSynced' dans les tables. Si une ligne modifiée dans isSynced local sera false, après la synchronisation réussie des données locales au serveur isSynced sera true. de sorte que nous peut gérer les données locales à jour avec le serveur.
Mise à Jour:
Vous pouvez trouver plus d'informations sur ce développeur lien
Avez-vous envisagé d'utiliser une solution commerciale?
Http://www.mobeelizer.com/ ressemble à ce que vous voulez réaliser. Il y a probablement beaucoup d'autres.
Remarque: aucune affiliation avec cette société.
Je dirais que l'énoncé du problème est incomplet. Dans la configuration décrite ci-dessus, ce qui manque est ce que vous allez réellement synchroniser.
Le cas habituel dans POS est qu'il existe peu d'indices (id,value,...) les tables qui doivent être distribuées du serveur central aux périphériques clients. Dans la plupart des cas, il s'agit d'une liste de prix, d'une liste de stock, etc. Ces tables devraient rarement être modifiées sur les périphériques clients (en fait, elles pourraient mais doivent ensuite être redistribuées à partir du serveur central et reconnues par les périphériques client).
L'autre direction a tendance à être assez simple sur l'appareil client que vous générez des factures ou des factures. Ce sont encore des choses locales qui doivent être propagées vers le serveur. Ainsi, vous les stockez localement et, au point de synchronisation, vous les envoyez au serveur. Plus tard, vous pourriez recevoir vos propres éléments de retour du serveur comme un accusé de réception.
EDIT: pour détecter les changements, les horodatages en écriture comme mentionné ci-dessus sont indispensables.
Jusqu'à présent décrit ci-dessus est le flux de données.
Ensuite, vous devez vous déplacer dans le domaine de la solution et implémenter ces règles. Il y a quelques approches de synchronisation (C'est-à-dire SyncML). D'autre part en gardant rulez simple. Ainsi, la principale préoccupation devrait être une sorte de verrouillage et des files d'attente qui rend la chose robuste.
Il pourrait également utiliser le client basé sur l'agent, dans ce cas chaque périphérique a son propre agent (pourrait être une réplique du dernier état connu de la base de données du périphérique) mais je considérerais cela comme une fonctionnalité avancée qui pourrait entrer prochaine version:-)
Je travaille également sur l'application de vente dans laquelle je dois mes objectifs locaux au serveur et les objectifs du serveur à mes objectifs locaux
Mon proceder est que chaque fois que mon application est démarrée, je reçois les dernières données de mon serveur de mon tout mon membre et met à jour ma base de données locale avec ces données et chaque fois que je change de données dans ma base de données locale également mise à jour sur sever side
J'ai également utilisé un bouton de synchronisation qui récupérera les dernières données du serveur si le membre de mon équipe change d'objectif ou de profil
Si vous voulez des données mises à jour sur tous les périphériques, pourquoi n'utilisez-vous pas uniquement la base de données distante, pourquoi introduisez-vous une base de données locale pour cela.
Pour votre cas, je vous suggérerai de travailler avec uniquement une base de données distante directement afin que les choses puissent être faites en temps réel.