Développement d'applications mobiles : Synchronisation avec le serveur. Développement du back-end des applications mobiles Création du back-end de l'application

Hors ligne dans le passé, être en ligne aujourd'hui est un must. Au moins pour le monde des affaires moderne. Présentations de produits et services de marques, commande et livraison en ligne, maintien d'une clientèle, communication avec les clients, et bien plus encore - tout cela est tout simplement impossible sans une présence sur Internet. Si vous avez besoin d'une application, vous devez disposer à la fois d'un Front-end (l'interface Web) et d'un Back-End (le côté serveur de votre application). Et si vous souhaitez pouvoir modifier le contenu de votre application sans la participation des développeurs, vous avez besoin d'un bon panneau d'administration.

Tandis que Front-end dans la sphère Applications mobiles créé à l'aide de technologies telles que X-Code et Java, Back-end, où la base de données et toute la logique de l'application seront stockées, nécessite une connaissance professionnelle du langage de programmation côté serveur. bon exemple est PHP, qui est peut-être le langage de programmation le plus populaire utilisé pour développer presque n'importe quel back-end. C'est le leader incontesté.

Il existe de nombreuses applications pour PHP : sites Web statiques et dynamiques + systèmes de gestion de contenu personnalisés, réseaux sociaux, systèmes CRM spécialisés, logiciels de commerce électronique, et bien plus encore. Bien sûr, il existe des pièces de serveur et des panneaux de contrôle gratuits ou bon marché. Cependant, dans de nombreux cas, ils n'offrent pas le niveau de commodité, de personnalisation et d'évolutivité nécessaire.

Nos programmeurs travaillent avec des technologies qui nous permettent de mettre en œuvre une large gamme de solutions pour divers objectifs, besoins et exigences d'affaires. Nous analysons Configuration requise pour chaque projet individuellement et nous utilisons divers logiciels de serveur spécialisés pour une performance optimale de votre application mobile.

Si vous recherchez une équipe capable de vous guider vers la solution la plus intelligente et la plus rentable pour créer une application à partir de zéro ou en restaurer une existante pour une expérience utilisateur parfaite, ne cherchez pas plus loin. Appsmob est prêt à vous aider à trouver la meilleure solution Pour toi.

Le développement du côté serveur d'une application client-serveur commence par la conception de l'architecture. Beaucoup dépend de l'architecture : de l'extensibilité de l'application à ses performances et à sa facilité de support/maintenance.

Tout d'abord, vous devez déterminer comment les données seront placées sur le serveur et comment les requêtes provenant du client seront traitées. Il faut également réfléchir à l'organisation de la mise en cache des données côté serveur.

Il est nécessaire de décider des protocoles d'échange de données et des formats de transfert de données.

API (interface de programmation d'application) - interface de programmation d'application. Dans un langage plus compréhensible, il s'agit d'un ensemble de requêtes adressées au serveur, que ce dernier comprend et peut donner la bonne réponse. L'API définit la fonctionnalité de la logique du serveur, tandis que l'API vous permet d'abstraire la façon dont cette fonctionnalité est implémentée. En d'autres termes, l'API est une partie nécessaire de l'infrastructure client-serveur globale.

Comparez JSON et XML. Donner un exemple de protocoles selon le type d'application.

Multithreading

L'un des aspects clés de la programmation moderne est le multithreading. Avec l'aide du multithreading, nous pouvons séparer plusieurs threads dans l'application qui effectueront diverses tâches en même temps.

Le multithreading est une propriété d'une plate-forme (par exemple, un système d'exploitation, une machine virtuelle, etc.) ou une application selon laquelle un processus engendré dans le système d'exploitation peut consister en plusieurs threads s'exécutant "en parallèle", c'est-à-dire sans un commande dans le temps.

L'essence du multithreading est le quasi-multitâche au niveau d'un processus exécutable, c'est-à-dire que tous les threads sont exécutés dans l'espace d'adressage du processus. De plus, tous les threads d'un processus ont non seulement un espace d'adressage commun, mais également des descripteurs de fichiers communs. Un processus en cours d'exécution a au moins un thread (maître).

Le multithreading (en tant que doctrine de programmation) ne doit pas être confondu avec le multitâche ou le multitraitement, même si les systèmes d'exploitation qui implémentent le multitâche ont tendance à implémenter également le multithreading.

Les avantages du multithreading en programmation sont les suivants :

Simplification du programme dans certains cas en utilisant un espace d'adressage commun.

Moins de temps passé à créer un thread par rapport au processus.

Améliorer les performances des processus en parallélisant les calculs du processeur et les opérations d'E/S.

Couler(thread) est une unité gérée de code exécutable. Dans un environnement multitâche basé sur des threads, tous les processus en cours d'exécution ont nécessairement un thread principal, mais il peut y en avoir plus. Cela signifie qu'un seul programme peut exécuter plusieurs tâches de manière asynchrone. Par exemple, modifier du texte dans un éditeur de texte pendant l'impression, car ces deux tâches sont effectuées sur des threads différents.

Sur un processeur conventionnel, la gestion des threads est gérée par le système d'exploitation. Le thread est exécuté jusqu'à ce qu'une interruption matérielle se produise, appel système ou jusqu'à ce que le temps qui lui est alloué par le système d'exploitation expire. Après cela, le processeur passe au code du système d'exploitation, qui enregistre l'état du thread (son contexte) ou passe à l'état d'un autre thread, qui se voit également allouer du temps pour l'exécution. Avec un tel multithreading, il suffit un grand nombre de Les cycles CPU sont consacrés au code du système d'exploitation qui change de contexte. Si la prise en charge des threads est implémentée dans le matériel, le processeur lui-même pourra basculer entre les threads et, dans le cas idéal, exécuter plusieurs threads simultanément pour chaque cycle d'horloge.

– Multithreading temporaire (fil unique)

– Multithreading simultané (plusieurs threads en même temps)

Le multithreading, en tant que modèle de programmation et d'exécution de code répandu, permet à plusieurs threads de s'exécuter au sein d'un même processus. Ces threads d'exécution partagent les ressources d'un processus, mais peuvent également s'exécuter seuls. Le modèle de programmation multithread fournit aux développeurs une abstraction pratique de l'exécution parallèle. Cependant, l'application la plus intéressante de la technologie est peut-être lorsqu'elle est appliquée à un seul processus, ce qui permet son exécution parallèle sur un système multiprocesseur.

Cet avantage d'un programme multithread lui permet de s'exécuter plus rapidement sur systèmes informatiques, qui ont plusieurs processeurs, un processeur à plusieurs cœurs ou sur un cluster de machines - en raison du fait que les threads d'exécution de programme se prêtent naturellement à une exécution véritablement parallèle des processus. Dans ce cas, le programmeur doit être très prudent pour éviter les conditions de concurrence et autres comportements non intuitifs. Afin de manipuler correctement les données, les threads d'exécution doivent fréquemment passer par une procédure de rendez-vous pour traiter les données dans le bon ordre. Les threads d'exécution peuvent également avoir besoin de mutex (qui sont souvent implémentés à l'aide de sémaphores) pour empêcher que les données partagées soient modifiées en même temps ou lues pendant le processus de modification. L'utilisation négligente de ces primitives peut conduire à un blocage.

Une autre utilisation du multithreading, même pour les systèmes monoprocesseurs, est la capacité d'une application à répondre à une entrée. Dans les programmes à thread unique, si le thread principal d'exécution est bloqué par l'exécution d'une tâche de longue durée, l'application entière peut être dans un état figé. En déplaçant ces tâches de longue durée vers un thread de travail qui s'exécute en parallèle avec le thread principal, il devient possible pour les applications de continuer à répondre aux entrées de l'utilisateur pendant que les tâches s'exécutent dans Contexte. D'un autre côté, dans la plupart des cas, le multithreading n'est pas le seul moyen de garder un programme réactif. La même chose peut être obtenue via des E/S asynchrones ou des signaux sous UNIX.

Il existe deux types de multitâches : basé sur le processus Et basé sur le flux. Les différences entre le multitâche basé sur les processus et le multitâche basé sur les threads sont les suivantes : le multitâche basé sur les processus est organisé pour l'exécution parallèle de programmes, et le multitâche basé sur les threads est pour l'exécution parallèle de parties individuelles d'un programme.

Il existe deux types de flux :

Threads de premier plan ou premier plan. Par défaut, chaque thread créé via la méthode Thread.Start() devient automatiquement un thread de premier plan. Ce type de thread protège l'application en cours contre l'arrêt. Le Common Language Runtime n'arrêtera pas l'application tant que tous les threads de premier plan ne seront pas terminés.

Fils de fond. Ce type Les threads, également appelés threads démons, sont traités par le Common Language Runtime comme des chemins d'exécution extensibles qui peuvent être ignorés à tout moment. Ainsi, si tous les threads de premier plan sont terminés, tous les threads d'arrière-plan sont automatiquement tués lorsque le domaine d'application est déchargé. Pour créer des threads d'arrière-plan, vous devez définir la propriété IsBackground sur true.

Parlez des états des threads : en cours d'exécution, suspendu, en cours d'exécution, mais en attente de quelque chose.

Problème de synchronisation des threads et ressources partagées.

Interaction avec le fil

Dans un environnement multithread, il existe souvent des problèmes associés à l'utilisation des mêmes données ou périphériques par des threads à exécution parallèle. Pour les solutions problèmes similaires des méthodes d'interaction de thread telles que les mutex, les sémaphores, les sections critiques et les événements sont utilisées

mutex est un objet de synchronisation qui est défini sur un état signalé spécial lorsqu'il n'est occupé par aucun thread. Un seul thread possède cet objet à tout moment, d'où le nom de ces objets (de l'anglais mutually exclusive access - mutually exclusive access) - l'accès simultané à une ressource partagée est exclu. Après toutes les actions nécessaires, le mutex est libéré, donnant aux autres threads l'accès à la ressource partagée. Un objet peut prendre en charge la capture récursive une deuxième fois par le même thread, incrémentant le compteur sans bloquer le thread, puis nécessitant plusieurs versions. Telle est, par exemple, la section critique de Win32. Cependant, certaines implémentations ne le prennent pas en charge et provoquent un blocage du thread lors d'une tentative de capture récursive. Il s'agit de FAST_MUTEX dans le noyau Windows.

sémaphores représentent les ressources disponibles qui peuvent être acquises par plusieurs threads en même temps jusqu'à ce que le pool de ressources soit vide. Ensuite, les threads supplémentaires doivent attendre que la quantité requise de ressources soit à nouveau disponible. Les sémaphores sont très efficaces car ils permettent un accès simultané aux ressources.

Développements. Un objet qui stocke 1 bit d'information "signalé ou non", sur lequel sont définies les opérations "signaler", "remettre à un état non signalé" et "attendre". L'attente d'un événement signalé est l'absence d'opération avec une poursuite immédiate de l'exécution du thread. L'attente d'un événement non signalé entraîne la suspension de l'exécution d'un thread jusqu'à ce qu'un autre thread (ou la deuxième phase d'un gestionnaire d'interruption dans le noyau du système d'exploitation) signale l'événement. Il est possible d'attendre plusieurs événements dans les modes "tout" ou "tous". Il est également possible de créer un événement qui est automatiquement réinitialisé à un état non signalé après le réveil du premier - et unique - thread en attente (un tel objet sert de base à l'implémentation de l'objet "section critique"). Activement utilisé dans MS Windows, à la fois en mode utilisateur et en mode noyau. Il existe un objet similaire dans le noyau Linux appelé kwait_queue.

Sections critiques fournissent une synchronisation comme les mutex, sauf que les objets représentant les sections critiques sont accessibles au sein du même processus. Les événements, les mutex et les sémaphores peuvent également être utilisés dans une application à processus unique, cependant, les implémentations de sections critiques dans certains systèmes d'exploitation (par exemple, Windows NT) fournissent un mécanisme plus rapide et plus efficace pour une synchronisation mutuellement exclusive - l'acquisition et la libération les opérations sur la section critique sont optimisées pour le cas d'un seul thread (pas de conflit) afin d'éviter tout appel système menant au noyau du système d'exploitation. Comme les mutex, un objet représentant une section critique ne peut être utilisé que par un thread à la fois, ce qui les rend extrêmement utiles pour restreindre l'accès aux ressources partagées.

Variables conditionnelles(condvars). Semblable aux événements, mais ce ne sont pas des objets qui occupent de la mémoire - seule l'adresse de la variable est utilisée, le concept de "contenu de la variable" n'existe pas, l'adresse d'un objet arbitraire peut être utilisée comme variable de condition. Contrairement aux événements, la définition d'une variable de condition sur un état signalé n'a aucune conséquence s'il n'y a actuellement aucun thread en attente sur la variable. Définir un événement dans un cas similaire implique de stocker l'état "signalé" dans l'événement lui-même, après quoi les threads suivants qui souhaitent attendre l'événement continuent leur exécution immédiatement sans s'arrêter. Pour utiliser pleinement un tel objet, l'opération "libérer le mutex et attendre la variable de condition de manière atomique" est également nécessaire. Activement utilisé dans les systèmes d'exploitation de type UNIX. Les discussions sur les avantages et les inconvénients des événements et des variables de condition constituent une partie importante des discussions sur les avantages et les inconvénients de Windows et UNIX.

Port de fin d'E/S(port d'achèvement IO, IOCP). Implémenté dans le noyau du système d'exploitation et accessible via des appels système, l'objet "file d'attente" avec les opérations "mettre la structure en queue de file d'attente" et "prendre la structure suivante en tête de file d'attente" - le dernier appel suspend l'exécution du thread si la file d'attente est vide, et jusqu'à ce qu'aucun autre thread ne fasse l'appel put. La caractéristique la plus importante d'IOCP est que des structures peuvent y être placées non seulement par un appel système explicite à partir du mode utilisateur, mais également implicitement à l'intérieur du noyau du système d'exploitation à la suite de l'achèvement d'une opération d'E / S asynchrone sur l'un des fichiers. descripteurs. Pour obtenir cet effet, vous devez utiliser l'appel système « associer un descripteur de fichier à IOCP ». Dans ce cas, la structure placée dans la file d'attente contient le code d'erreur de l'opération I/O, et également, en cas de succès de cette opération, le nombre d'octets effectivement entrés ou sortis. L'implémentation du port d'achèvement limite également le nombre de threads s'exécutant sur un seul processeur/cœur après la réception d'une structure de la file d'attente. L'objet est spécifique à MS Windows et permet le traitement des demandes de connexion entrantes et des blocs de données dans le logiciel serveur dans une architecture où le nombre de threads peut être inférieur au nombre de clients (il n'est pas nécessaire de créer un thread séparé avec la ressource coûts pour chaque nouveau client).

Pool de fils

Parlez du pool de threads

Notre société propose des services pour la création de la partie serveur des applications métiers mobiles et des services web clients fonctionnant dans des environnements à forte charge. Lors du développement de chaque projet, nous essayons d'appliquer une approche individuelle afin que le produit résultant devienne le plus solution optimale objectifs spécifiques du client.

Si vous utilisez une application complexe qui stocke et/ou traite des données sur un serveur, elle est alors adossée à un Back-end - un progiciel hébergé sur un serveur Web et fonctionnant avec une application, qui dans ce cas est appelée Front- finir. Une application hébergée sur un serveur peut fonctionner simultanément avec un grand nombre de clients, ce qui impose des exigences de rapidité et de sécurité de son fonctionnement.

Souvent, le côté serveur d'une application est écrit en Langage PHP, comme le plus populaire pour de telles solutions. Pour implémenter des tâches de serveur simples peuvent être utilisées systèmes standards, mais pour les plus spécifiques, il est déjà nécessaire de développer votre propre solution ou des modules complémentaires par rapport aux systèmes standard.

Principes de développement d'un serveur pour une application mobile

Nos programmeurs travaillent avec des technologies qui permettent de mettre en œuvre large éventail des solutions pour toutes les charges, même très élevées et diverses directions. Nous créons également des solutions de serveur distinctes pour des tâches individuelles.

Contrôle organisationnel

Chaque projet est créé par un groupe distinct de spécialistes responsables de toutes les étapes de développement et de livraison du projet dans les délais.

Programmation

La conception de l'architecture du serveur est l'étape la plus importante au cours de laquelle les bases de données sont créées et les algorithmes nécessaires sont formés.

Essai

La partie logicielle doit fonctionner sans erreurs ni échecs. Ceci est de la responsabilité des testeurs qui procèdent à la vérification du système.

Soutien technique

Nos employés effectuent un support technique complet des programmes, ce qui vous permet d'éliminer rapidement les lacunes et d'effectuer des mises à jour.

Fonctionnalités de développement

Afin de développer avec compétence la partie serveur de l'application, certaines compétences et connaissances du langage de programmation utilisé sur le serveur sont requises. Comme le montre la pratique, le client application serveur créé en PHP. Il est le leader incontesté dans ce domaine. Plus de la moitié des sites dans le monde sont écrits en PHP, c'est pratique pour le développement et le support.

Cadre

Cette plateforme logicielle permet de rendre le projet plus évolutif et flexible. Néanmoins, le cadre doit être choisi aussi correctement que possible, par conséquent, une analyse approfondie de la documentation de travail du projet est nécessaire, ce qui aidera par la suite à développer un produit de haute qualité.

Il existe d'autres langages utilisés pour le développement back-end. Par exemple, les applications serveur créées dans Environnement Delphi. Grâce à cela, le programme a amélioré le débogage. De plus, il est plus facile de développer programmes uniques, il permet la création visuelle. Tout cela vous permet de créer une interface claire et pratique.

Les applications serveur Java ne sont pas moins populaires. Ils se complètent facilement, s'exécutent facilement sur différentes plates-formes et présentent un haut niveau de sécurité.

Une autre langue couramment utilisée. Avec lui, les applications serveur sont créées facilement, rapidement et sans frais supplémentaires.

Presque toutes les entreprises modernes ont leurs propres bureaux virtuels. Le site Web peut être soit carte téléphonique, ou un portail ou un catalogue en ligne avec la possibilité de passer des commandes.

Dans ce cas, les processus métier dépendent des serveurs Web, à savoir de leur capacité à résister aux attaques, aux tentatives de piratage et aux attaques externes. impacts négatifs, ainsi que des performances suffisantes pour de nombreuses requêtes simultanées.

Étapes du développement du service Web

En créant des applications pour différents segments de marché, nous organisons notre travail selon un principe unique - nous divisons l'ensemble du processus en étapes individuelles, dont l'avancement et les résultats sont communiqués aux clients. Ainsi, le serveur de l'application mobile est développé de la même manière.

1. Développement d'idées

Jusqu'à 2 semaines

A ce stade, la fondation est en cours de création, donnant une idée de ce qui sera posé et dans quelle direction elle se développera.

2. Évaluation du projet

2-3 semaines

Nos experts évaluent le temps et le coût des travaux, puis une proposition préliminaire d'aménagement est établie.

3. Termes de référence et contrat

Jusqu'à 2 semaines

Après avoir discuté avec le client de toutes les nuances du processus et rédigé un cahier des charges détaillé, un contrat est préparé et signé.

4. Développement d'interfaces

2-3 semaines

Les concepteurs sont responsables de la création des interfaces nécessaires lors de l'écriture des modules de programme.

6. Tests

2-3 semaines

Vérification complète des reçus solutions logicielles produits par les testeurs grâce à un ensemble d'outils appropriés.

7. Achèvement du projet

Jusqu'à 2 semaines

Dans les délais convenus, un service Web prêt à l'emploi et soigneusement testé est remis au client.

notre équipe

Grâce à l'analyse des activités commerciales et des besoins de nos clients, nous créons des produits du monde réel qui aident à résoudre une série de problèmes commerciaux. Usage technologies modernes offre un large éventail de possibilités pour la mise en œuvre de logiciels de serveur, ce qui garantit la haute performance des applications mobiles correspondantes. Notre équipe est représentée par :

Chefs de projet

Ces employés interagissent avec les clients et les développeurs, assurant la communication entre eux. Ils contrôlent la mise en œuvre des actions déjà planifiées et des améliorations nécessaires.

Créateurs

Dans leur travail, nos spécialistes tiennent compte des exigences de construction d'interfaces pour systèmes d'exploitation iOS et Android, de sorte que les applications publiées fonctionnent correctement sur différents appareils.

Développeurs

Afin d'optimiser les performances des applications mobiles, les programmeurs analysent leurs exigences système et créent des logiciels de serveur spécialisés.

Testeurs

Des tests approfondis sont une garantie de la qualité du produit fini et une garantie de la sécurité des données stockées et traitées. Ces spécialistes utilisent différents outils et une méthodologie efficace.

Quels services créons-nous

Qu'il s'agisse d'un logiciel intégré au site ou d'un programme indépendant, le service Web est utilisé pour effectuer des tâches liées à la publicité, à l'analyse, à la planification commerciale et à la promotion. À cet égard, il est nécessaire de décider quel type de ressource sera la meilleure solution.

Projets d'information

Conçu pour accueillir divers contenus.

Sites thématiques

Presque toutes leurs pages sont consacrées à un sujet. La demande pour eux est encore assez élevée.

sites d'actualités

Ils informent sur diverses actualités dans le cadre d'un ou plusieurs thèmes, reflétant les principaux domaines de la vie.

Blogues

Le niveau de popularité de ces ressources ne cesse de croître. Comme les sites d'information, ils véhiculent telle ou telle information auprès de la communauté Internet, mais dans ce cas, les auteurs expriment leur opinion personnelle.

Projets sociaux

Il s'agit notamment des services sociaux spécialisés réseaux, communautés, forums, etc.

Forums

Créé pour discuter de diverses nouvelles, produits / services, etc. Ils peuvent être à la fois étroitement ciblés et diversifiés.

Réseaux sociaux

Ces ressources ont une audience de plusieurs millions de personnes. Leur tâche principale est de fournir aux internautes la possibilité de communiquer en ligne par SMS / Messages vocaux et communication vidéo.

Webservices divers

Reçu aujourd'hui large utilisation, ils sont divisés en plusieurs types.

Catalogues

services postaux

Fournir aux utilisateurs toutes les fonctionnalités et tous les avantages E-mail, y compris la visualisation, l'envoi, l'édition de lettres et de documents, etc.

Moteurs de recherche

Ils sont utilisés pour rechercher des sites et diverses informations sur des demandes spécifiques.

Tableaux d'affichage

Il s'agit de ressources Web où les utilisateurs du réseau placent leurs publicités pour la vente et l'achat de services dans divers domaines.

Sites d'hébergement

Conçu pour le stockage temporaire de fichiers. Certains d'entre eux permettent de se familiariser avec les données avant de les télécharger.

FAQ

Ci-dessous, nous proposons des réponses aux questions souvent posées à nos spécialistes. Si vous ne trouvez pas l'information que vous cherchez ici, veuillez poster votre question ici. forme et nous y répondrons certainement.

Combien de temps faut-il pour créer une application et un serveur Web ?

En moyenne, ce travail dure de 9 à 20 semaines. Tout dépend de la complexité de la tâche mise en œuvre.

SAUVEGARDES

Pourquoi les sauvegardes sont nécessaires sur une plateforme mobile

Les experts savent à quel point les applications mobiles 1C sont parfois peu fiables : des erreurs peuvent survenir à tout moment, à cause desquelles les bases d'utilisateurs s'effondrent tout simplement. Dans le même temps, nous sommes confrontés au manque de fiabilité des appareils eux-mêmes : ils peuvent être cassés, perdus, volés et les utilisateurs souhaitent conserver leurs données. Et jusqu'à la version 8.3.9, nous n'avions pas de mécanisme de sauvegarde de plate-forme.

Étant donné que les utilisateurs n'avaient pas de bouton "enregistrer une copie" auparavant, les développeurs de l'application Boss ont dû effectuer eux-mêmes des sauvegardes. Comment avons-nous fait ça?

Nous enregistrons les données de la base de données sous forme de XML.

Il est conseillé d'offrir à l'utilisateur plusieurs options pour stocker les copies - tout d'abord, c'est pratique pour les clients, ils peuvent choisir la meilleure option pour eux-mêmes : télécharger sur le cloud, l'envoyer à leur courrier, l'enregistrer sur l'appareil.

Ainsi, les développeurs s'assurent en plus. Si quelque chose ne va pas et que le mécanisme de création de copies sur Google Drive ou Yandex Drive tombe soudainement en panne, vous pouvez toujours dire à l'utilisateur que le développeur traite actuellement l'erreur, mais pour l'instant, il peut enregistrer les données d'une autre manière. Et les utilisateurs sont satisfaits car ils peuvent être sereins vis-à-vis de leurs données.

Nécessairement se concentrer sur les services cloud, car si l'appareil est perdu ou cassé et que l'utilisateur a enregistré une copie sur le même appareil, les données seront perdues.

Comme nous assurez-vous de rappeler à l'utilisateur la nécessité de créer des sauvegardes.

Comment sauvegarder des copies si la configuration change ?

Lorsque nous parlons d'une solution de masse, d'une application qui évolue, se développe et s'améliore constamment, nous devons prendre en compte le comportement des clients. L'utilisateur peut vouloir restaurer une sauvegarde enregistrée dans ancienne version demande, où il n'y avait pas de détails. Et puis la tâche se pose : lire les données, puis renseigner les données selon la logique de mise à jour de l'ancienne version de l'application. Comment faire? En plus des données, enregistrez la structure de données elle-même, afin que vous sachiez plus tard comment les lire.

Il existe plusieurs options pour stocker cette structure de données, y compris son stockage dans la configuration elle-même. C'est-à-dire qu'à la sortie de chaque nouvelle version, enregistrez la structure des métadonnées de la version précédente dans la mise en page de la configuration.

N'oubliez pas que dans une application mobile, la configuration ne doit pas grossir comme ça, il faut valoriser la place dedans, il faut la rendre la plus compacte possible. Mais l'application se développe et il y aura de nombreuses mises en page de ce type, et avec le temps, il y en aura de plus en plus.

Par conséquent, dans le cas d'une application mobile, un autre moyen est préférable - enregistrer la structure des métadonnées directement dans le fichier de données. À la sortie, nous obtenons un tel fichier, où nous stockons d'abord des données auxiliaires - la version de configuration, le schéma de configuration, les limites de séquence, puis nous écrivons les données utilisateur elles-mêmes au format XML. De plus, dans la section "Données auxiliaires" du fichier, vous pouvez également stocker d'autres données importantes qui, pour une raison quelconque, n'ont pas pu être écrites en XML.

Nous prenons le schéma de données qui a été enregistré dans le fichier et, sur cette base, nous construisons le package XDTO pour lire le fichier. Nous créons un objet similaire dans la base de données, le remplissons, effectuons le traitement d'achèvement lors de la mise à jour et enregistrons l'objet fini dans la base de données.

Ci-dessous dans l'image, vous pouvez voir un indice sur la façon d'écrire magnifiquement le modèle XDTO de ces configurations. La société qui a publié l'application Boss a expérimenté cela, a trouvé plusieurs façons, mais s'est contentée de cette option pour écrire le schéma de métadonnées. Lorsque le fichier de données lui-même est ouvert, vous pouvez voir le XML structuré habituel, lisible, qui répertorie toutes les métadonnées de l'application.

// Écrire le schéma de configuration XDTO Model = XDTO Factory.XDTO Model Export("http://v8.1c.ru/8.1/data/enterprise/current-config"); FactoryXDTO.WriteXML(FileUpload, ModelXDTO); // Lire le schéma de configuration ModelXDTO = FactoryXDTO.ReadXML(ReadingXML, FactoryXDTO.Type("http://v8.1c.ru/8.1/xdto","Model")); Décharger l'usine = Nouvelle usine XDTO (modèle XDTO) ;

Pour protéger l'utilisateur, il faut lui redemander s'il a besoin de restaurer la sauvegarde. Peut-être qu'il était juste en train d'expérimenter et de cliquer sur des boutons sur tout dans l'application :) Et maintenant, ses données actuelles peuvent être perdues. Par conséquent, lors de l'exécution d'actions potentiellement "dangereuses", nous clarifions toujours s'il le souhaite vraiment et comment cela devrait se produire. L'utilisateur doit être conscient de ses actions.

Il doit y avoir un mécanisme pour créer des sauvegardes lorsque nous parlons d'une solution hors ligne, lorsque l'utilisateur a toutes les données stockées exclusivement sur un appareil mobile : l'utilisateur peut perdre son appareil, puis les données seront perdues. Et il semblerait que si l'application ne fonctionne pas hors ligne, mais est connectée à un serveur central, alors l'utilisateur ne devrait pas avoir un tel problème, car si l'appareil est perdu, il se connectera au serveur, recevra toutes ses données de le serveur à nouveau, et tout ira bien.

Cependant, les utilisateurs n'utilisent pas toujours les sauvegardes de la manière que nous attendons d'eux :) Ils les utilisent très souvent afin de simplement « restaurer » les données. C'est vraiment un comportement très étrange, mais les utilisateurs d'applications mobiles sont trop paresseux pour comprendre où ils pourraient faire une erreur lors de la saisie de données, et ils annulent simplement les données et redémarrent les données pour la journée en cours. Après avoir analysé les statistiques de travail avec l'application Boss, nous avons réalisé qu'il s'agit d'une pratique normale et qu'un tel comportement des utilisateurs est plus courant que nous n'aurions pu l'imaginer.

Et si vous utilisez la synchronisation avec d'autres appareils, vous devez traiter cela. Il y a plusieurs solutions ici :

• rompre la connexion avec le serveur, en précisant que les données qu'il contient resteront telles qu'elles étaient et que la copie ne sera restaurée que sur l'appareil de l'utilisateur ;
• il est préférable pour l'utilisateur de le laisser restaurer une copie sur tous les appareils à la fois, après avoir préalablement prescrit de tels mécanismes.

Il y a encore un point ici. Jusqu'à présent, nous enregistrions nous-mêmes les sauvegardes, contrôlions l'ensemble du processus, capturions les actions de l'utilisateur directement dans le code lorsqu'il cliquait sur le bouton "enregistrer une copie". Tout cela peut être traité plus tard. Dans la plate-forme 8.3.9, il est devenu possible d'enregistrer des sauvegardes à l'aide des outils de la plate-forme. Et l'utilisateur le fait à notre insu. Si la synchronisation avec une base de données centrale est utilisée, un tel scénario doit être traité. Nous devons en quelque sorte découvrir sur notre serveur que l'utilisateur a restauré une copie précédemment enregistrée et devons lui donner une sorte de décision. Nous ne pouvons pas nous permettre de laisser les données se désynchroniser.

ÉCHANGER

Lorsque nous parlons d'une solution privée sur une plateforme mobile, nous avons généralement un client qui, par exemple, souhaite utiliser une plateforme mobile pour ses commerciaux et les faire échanger des données avec une base de données centrale. Tout est simple ici : une base de données, plusieurs appareils, vous montez le serveur, établissez la communication avec lui. Ainsi, le problème d'échange entre les appareils est résolu facilement.

Mais si nous parlons d'une application de masse, où il existe de nombreuses bases de données, dont chacune a beaucoup d'utilisateurs, la situation devient plus compliquée. Les utilisateurs ont téléchargé l'application sur le marché et souhaitent se synchroniser les uns avec les autres. Par exemple, un mari a téléchargé une application de finances personnelles et souhaite maintenant que sa femme se connecte également afin qu'ils puissent travailler ensemble sur la même application. Il y a beaucoup d'utilisateurs, l'application se développe, grandit, et il y a un besoin d'un grand, très grand nombre de bases de données. Comment organiser tout cela ? Les utilisateurs ne contacteront pas personnellement les développeurs pour créer une base de données distincte pour eux et activer la synchronisation. Ils veulent appuyer sur un bouton et faire en sorte que tout fonctionne immédiatement. Au même moment.

La façon de procéder? C'est là que le mécanisme de séparation des données vient à la rescousse. Il vous permet d'organiser une base de données unique, où il existe une configuration commune, mais en même temps, un nombre illimité de bases de données utilisateur sont stockées dans une base de données commune.

La meilleure partie est que vous pouvez ajouter des utilisateurs dynamiquement, par programmation, sans notre participation. En réalité, les utilisateurs cliquent simplement sur le bouton "s'inscrire sur le serveur", et tout se passe tout seul : une base de données personnelle est créée pour lui sur le serveur, et il peut immédiatement commencer à y travailler.

Comment faire? La première solution, et la plus simple, consiste à écrire votre propre base de données de serveur avec ce mécanisme. Lorsque notre entreprise a commencé à faire l'application Boss et à y échanger, nous avons fait exactement cela dans la première version : nous avons écrit une base de données serveur avec un mécanisme de partage de données. Tout a fonctionné, d'autant plus qu'il n'y avait rien de compliqué - le séparateur de base est un attribut commun.

Mais ensuite nous avons réalisé que nous réinventions la roue :) En fait, il y a déjà clé en main, et il prend déjà en compte des moments auxquels nous n'avons même pas pensé. C'est 1C : Frais.

La scalabilité du service est pensée ici : que faire quand il y a beaucoup de données et de bases de données, comment grandir avec tout ça. Il y a un moment ici sur la création sauvegardes zones de données : c'est-à-dire que nous ne sauvegardons pas seulement une base de données commune, nous faisons des copies d'un utilisateur spécifique. De plus, le mécanisme y est tel que les copies ne sont faites que lorsqu'elles sont vraiment nécessaires. Si l'utilisateur ne s'est pas connecté à la base de données pendant une semaine, nous ne faisons pas de copies pour lui, car rien n'y a changé. Une autre caractéristique de Fresh est que le service dispose d'un mécanisme pour réduire la charge sur le serveur, ce qui est très important lorsque vous avez beaucoup de bases de données.

En général, Fresh est quelque chose de nouveau et d'intéressant pour nous. Lentement, nous essayons de comprendre, mais pour la plupart, nous sommes simplement satisfaits de son travail.

Transfert de données. Comment l'implémenter pour le partage entre appareils

La plate-forme fournit deux mécanismes - les services SOAP et http. Il y a des nuances ici sur la façon d'accéder à ces services lorsque le mécanisme de partage de données est activé. En particulier, vous devez ajouter des paramètres qui indiquent le numéro spécifique du domaine auquel vous accédez, car la plate-forme ne peut pas déterminer à quelle base de données accéder à partir du nom d'utilisateur. De plus, un même utilisateur peut travailler avec plusieurs bases de données au sein d'une même base de données (voir image).

Côté services, l'application Boss implémente échange instantané: Un utilisateur saisit des données et un autre les reçoit. Les utilisateurs d'applications mobiles sont habitués au fait que tout se passe instantanément, nous avons donc réfléchi à la façon dont meilleur service utiliser - SOAP ou http. La vitesse de connexion a joué un rôle clé. En http, la vitesse de connexion est beaucoup plus élevée, et lors de la connexion via SOAP, on obtient une description de service lourde et longue à charger. La plate-forme a un moyen de stocker une description du service, mais à cause des paramètres que nous ajoutons dynamiquement, nous ne pouvons pas utiliser les liens WS. De plus, l'accès aux services http est plus pratique et flexible, d'après notre expérience.

Notre objectif est donc de mettre en place un échange en temps réel. Autrement dit, nous essayons de ne pas faire en sorte que l'utilisateur doive aller quelque part, cliquer sur un bouton, réfléchir à la mise à jour de ses données, s'il doit les mettre à jour ... Les utilisateurs doivent toujours avoir des données à jour- à ce jour. Ils sont tellement habitués à travailler dans des messagers - l'un a envoyé les données, l'autre les a immédiatement reçues. Tout se passe instantanément. Il en va de même pour les demandes liées aux affaires : un vendeur a émis une vente, l'autre devrait voir immédiatement la situation actuelle, sans prendre aucune mesure.

Par conséquent, l'application Boss utilise des tâches d'arrière-plan pour les échanges. Après chaque entrée de données dans la base de données, une tâche en arrière-plan est lancée qui initie l'échange. La première partie consiste à envoyer les données au serveur. Les autres appareils doivent alors savoir qu'il y a de nouvelles données. Pour cela, nous utilisons les notifications PUSH. Ce schéma fonctionne déjà et il fonctionne assez vite.

Mais nous voulions encore plus vite, car nous travaillons en temps réel et nous avons généralement peu de données. Nous avons un petit XML, mais en même temps nous envoyons un message avec ces données du premier appareil au serveur, le serveur envoie PUSH à un autre appareil, puis le deuxième appareil, après avoir reçu PUSH, initie l'échange de son côté, accède au serveur et demande des données, reçoit ces données, puis envoie une réponse indiquant que les données ont été reçues. C'est long, mais il y avait très peu de données elles-mêmes.

Nous avons réfléchi à la manière d'accélérer ce processus.

Pour ce faire, nous avons compris ce que contient PUSH, comment il peut encore être utilisé. Il s'est avéré que PUSH contient des champs tels que des données et du texte. La documentation pour iOS et Android indique les limites sur la taille des messages PUSH, mais cela ne nous a pas semblé suffisant et nous avons voulu le découvrir par nous-mêmes. Et nous avons vérifié que pour iOS, la somme des caractères autorisés est de 981 caractères, et pour Android, de 3832 caractères. Dans ce dernier cas, il est tout à fait possible d'utiliser la restriction, un ou plusieurs objets de base peuvent être poussés dans un tel volume. Et puis les développeurs de l'entreprise ont un peu changé le schéma. Lorsqu'il n'y a pas beaucoup de données, nous les envoyons depuis un appareil, les recevons sur le serveur, les emballons dans PUSH et les envoyons directement à un autre appareil. Le schéma est devenu plus court, et l'échange est devenu encore plus rapide :)

Un point important de l'utilisation de PUSH est qu'il n'ennuie pas les utilisateurs.

Il est très facile de se débarrasser de cette situation : il suffit de ne pas envoyer beaucoup de messages PUSH à l'utilisateur :) S'il travaille actuellement dans l'application, vous pouvez envoyer beaucoup de messages. Lorsque la plateforme est en cours d'exécution, l'utilisateur ne voit pas PUSH, tout se passe automatiquement pour lui. Mais lorsque l'application est fermée, le client a beaucoup de messages non lus. Par conséquent, vous ne devez en aucun cas envoyer le prochain PUSH jusqu'à ce qu'une réponse soit reçue de l'appareil indiquant que l'application est en cours d'exécution, active et que le PUSH précédent a déjà été traité.

Une autre nuance de l'échange est le travail via le web. Nous devons utiliser l'asynchronisme autant que possible. Vous ne pouvez pas travailler comme d'habitude - écrire du code - appeler une fonction - attendre qu'elle s'exécute - obtenir une réponse - et tout va bien. Si vous travaillez via le Web, vous rencontrerez toujours certaines limitations, telles qu'un Internet instable, des délais d'attente lors de l'exécution d'opérations longues. Par conséquent, il est nécessaire de penser à l'architecture à l'avance.

Regardons l'exemple de l'enregistrement de l'appareil, ce qui se passe dans l'application lorsque l'utilisateur souhaite s'enregistrer. Il conserve des enregistrements pendant un certain temps, il a saisi beaucoup de données, mais il souhaite ensuite que le vendeur travaille également avec cette base de données. L'utilisateur clique sur le bouton "s'inscrire". Au début, tout était très simple : ils prenaient ses données, les enregistraient sur le serveur et, s'il vous plaît, vous pouvez travailler et connecter les utilisateurs. Mais nous nous sommes ensuite retrouvés dans une situation où, pour certains utilisateurs, les bases de données sur l'appareil avaient déjà considérablement augmenté au moment de l'enregistrement. Et ce schéma ne fonctionnait plus, car. alors que toute la base de données était enregistrée sur le serveur, le délai de connexion s'est déclenché ou Internet a simplement été interrompu. Par conséquent, nous avons remplacé un appel synchrone par de nombreux appels courts. Les données sont désormais partagées au lieu d'être transférées en une seule fois. Nous n'attendons en aucun cas que le serveur traite et écrive les données. Nous avons envoyé les données, reçu une réponse indiquant que les données ont été reçues, fermé la connexion. Périodiquement, il est nécessaire d'interroger le serveur, ce qui s'y passe et comment, et entre-temps, une tâche en arrière-plan s'exécute sur le serveur, qui écrit les données reçues. Cela fait beaucoup d'appels au serveur, mais nous avons la garantie que tout se passera bien. Et ni les délais d'attente ni l'instabilité d'Internet ne vous empêcheront de télécharger toutes les données sur le serveur.

MISES À JOUR

Partage entre appareils avec différentes versions d'application

Puisque nous parlons d'une application de masse qui est lancée sur les marchés, il est nécessaire de prendre en compte certaines caractéristiques du processus de mise à jour et d'échange de données.

Si vous avez publié une application pour une entreprise et que vous avez décidé de la mettre à jour, vous commandez généralement simplement à tous les employés d'installer la nouvelle application à l'unanimité. Avec les utilisateurs qui ont téléchargé l'application sur le marché, cela ne peut pas être fait. Vous ne pouvez pas du tout leur dire quoi faire. Par exemple, ils travaillent dans l'application et ne veulent pas la mettre à jour maintenant ou jamais. Ils n'ont pas de mise à jour automatique, il est donc assez courant que plusieurs appareils soient connectés à la base de données centrale, et tous avec des versions différentes. Une autre raison de ce phénomène est le délai de publication sur les marchés : il est différent pour iOS et Android. Nous mettons souvent en œuvre des éléments clés tels que la correction de bogues critiques et nous ne voulons pas attendre deux semaines pour qu'iOS passe en revue nouvelle version, nous voulons au moins uniquement pour Android, mais publions une mise à jour dès maintenant.

Nous n'avons pas le droit de commander les utilisateurs. S'ils veulent, ils mettent à jour, et sinon, ils ne font rien. L'image montre le rapport des installations de l'application Boss par versions dans GooglePlay, ainsi que les statistiques de notre serveur - le rapport réel des versions d'application installées sur les appareils qui ont échangé des données avec le serveur au cours de la semaine dernière. Voici un ensemble avec lequel travailler. Ce sont des versions différentes et des métadonnées différentes. Et il faut organiser un échange normal en même temps :)

Les développeurs sont confrontés aux défis suivants :

• Tout doit fonctionner. Les utilisateurs ne devraient pas se sentir mal d'avoir oublié de mettre à jour. Ils ne devraient pas du tout s'en apercevoir. Mise à jour - c'est devenu mieux, eh bien, bon.
• Nous devons assurer la sécurité des données. Par exemple, un utilisateur a un répertoire et un nouvel attribut, tandis qu'un autre n'en a pas encore. De plus, si un utilisateur qui ne dispose pas de nouveaux détails modifie quelque chose sur son appareil, les données sur d'autres appareils ne doivent pas être perdues.
• Il est nécessaire de s'assurer que les données sont mises à jour lorsque nous passons à une nouvelle version. Lorsque l'utilisateur décide qu'il est prêt à mettre à niveau, il devrait automatiquement disposer de toutes les nouvelles informations qu'il n'avait pas simplement parce qu'il avait l'ancienne version.

Comment avons-nous fait ça?

1. Nous utilisons 2 plans d'échange sur le serveur. Le premier est pour le partage entre appareils et le second pour les mises à jour. Par exemple, nous avons envoyé un répertoire à l'utilisateur, mais il n'a pas d'unités de mesure, c'est-à-dire des données incomplètes. Nous devons nous en souvenir. Et lorsqu'il est mis à jour, nous devons lui envoyer toutes les informations qu'il n'avait pas. Pour cela, un deuxième plan d'échange est nécessaire.

2. Pour écrire et lire des objets, nous utilisons le même mécanisme que celui utilisé pour les sauvegardes, c'est-à-dire que nous sauvegardons la version des métadonnées. Dans ce cas, nous travaillons avec le serveur et nous pouvons nous permettre d'ajouter tout ce que nous voulons directement à la configuration. Nous ajoutons donc simplement des schémas de métadonnées à la configuration sous la forme de mises en page au fur et à mesure que l'application se développe.

Comment surveiller les erreurs massives dans l'échange et sur le serveur

Tout d'abord, vous devez contrôler la disponibilité du serveur lui-même. Avec les serveurs, cela arrive - ils tombent. Nous n'avons rien inventé de spécial à surveiller, mais avons simplement trouvé un bot dans un télégramme qui crie si quelque chose ne va pas. Il vérifie les performances du serveur toutes les minutes, et si soudainement le serveur est indisponible, il se met à crier, les admins le voient et relancent le serveur.

Nous collectons également un journal des erreurs à partir du journal. Aussi rien de surnaturel - toutes les trois heures seulement, nous collectons un journal des erreurs, les envoyons par courrier, les examinons périodiquement. Cela aide à voir les problèmes courants et certains situations exceptionnelles. Il n'est pas difficile de visualiser le courrier, de suivre et de corriger rapidement les erreurs. Mais cela vous permet d'identifier et de résoudre rapidement les problèmes qui peuvent croître avec la croissance des bases de données.

Encore point important- assurez-vous de donner à l'utilisateur la possibilité de "se plaindre". Cela améliore notre statut à leurs yeux et nous sauve. Il y a des utilisateurs, comme on les appelle, des "hystériques" qui, à la moindre erreur, se mettent à nous envoyer des tas de messages par mail que rien ne marche, la base de données ne se charge pas, tout va terriblement mal. Mais parfois, ils nous sauvent vraiment, car parfois ils trouvent des bugs que les autres n'ont pas encore miraculeusement découverts, des bugs sérieux.

L'utilisateur ne doit pas avoir peur. Pas de messages effrayants, rien d'autre. Ils doivent tout expliquer magnifiquement et proposer de se plaindre. Et nous promettons de tout résoudre. Ensuite les utilisateurs sont satisfaits, car ils voient qu'on s'occupe d'eux, et croient immédiatement qu'ils seront aidés :)

Cet article a été rédigé suite aux résultats du rapport lu lors de la conférence INFOSTART EVENT 2016 DEVELOPER. D'autres articles peuvent être lus.

En 2020, nous invitons tout le monde à participer à 7 meetups régionaux, ainsi qu'à l'événement anniversaire INFOSTART EVENT 2020 à Moscou.

Une partie importante de la modernité applications pour plateformes mobiles(iOS, Android, etc.) fonctionne en tandem avec le serveur. Une application avec des données périmées perd son utilité. Par conséquent, il est important de s'assurer que les données du serveur vers l'appareil sont constamment mises à jour. Cela s'applique aux applications hors ligne qui devraient fonctionner sans Internet. Pour pleinement candidatures en ligne, qui ne fonctionnent pas (ou sont inutiles) sans Internet (par exemple, Foursquare, Facebook) ont leurs propres spécificités, qui dépassent le cadre du présent article.

En utilisant l'une de nos applications hors ligne comme exemple, je vais vous dire quelles approches nous avons utilisées pour synchroniser les données. Dans les premières versions nous avons développé algorithmes simples et, à l'avenir, avec l'expérience, nous les avons améliorés. Une séquence similaire est présentée dans l'article - des pratiques simples évidentes aux plus complexes.

Il convient de préciser que l'article ne traite du transfert de données que dans un seul sens : du serveur vers l'appareil. Ici, le serveur est la source de données.

Dispositions générales pour toutes les approches

Par exemple, on envisagera de transférer un répertoire de plats ("plats") sur l'appareil. On supposera que l'appareil fait une requête à l'url "/service/dishes/update", l'échange se fait via le protocole http au format JSON ( www.json.org). Le serveur dispose d'une table "plats" avec les champs suivants : id (identifiant de l'enregistrement), nom (nom du plat), mis à jour (heure de mise à jour du plat, il est préférable de prendre en charge immédiatement le fuseau horaire, "AAAA-MM-JJThh:mm:ssTZD", par exemple, "1997 -07-16T19:20:30+01:00"), is_deleted (signe d'une entrée supprimée).

Remarque concernant la présence du dernier champ. Par défaut, sa valeur est 0. Dans une application où les entités sont synchronisées entre le client et le serveur, il est déconseillé de supprimer physiquement les données du serveur (pour qu'il n'y ait pas d'erreurs). Par conséquent, is_deleted = 1 est défini pour les plats supprimés. Lorsqu'une entité avec is_deleted = 1 arrive sur l'appareil, elle est supprimée de l'appareil.

Avec l'une ou l'autre approche, qui sera discutée ci-dessous, le serveur renvoie un tableau d'objets aux périphériques JSON (peut être vide) :

[
(identifiant: ,Nom: .mise à jour: ,est supprimé: },…
]

Exemple de réponse du serveur :

[
(id : 5625, nom : "Bread", mis à jour : "2013-01-06 06:23:12", est supprimé : 0),
(id : 23, nom : "Semoule cuite", mis à jour : "2013-02-01 14:44:21", est supprimé : 0),(

nom : "Soupe de poisson",

mis à jour : "2013-08-02 07:05:19",

Principes de mise à jour des données sur l'appareil

1. Si un élément est arrivé qui se trouve sur l'appareil et isDeleted = 0, alors il est mis à jour
2. Si un élément est arrivé qui n'est pas sur l'appareil, et isDeleted = 0, alors il est ajouté
3. Si un élément est arrivé qui se trouve sur l'appareil et isDeleted = 1, alors il est supprimé
4. Si un élément arrive qui n'est pas sur l'appareil et isDeleted = 1, alors rien n'est fait

Approche 1 : Toujours tout synchroniser

C'est la méthode la plus simple. L'appareil demande une liste de plats au serveur, et le serveur envoie la liste complète. La liste complète revient à chaque fois. Non trié.

Exemple de requête : null ou "()"

Avantages :

• la logique sur le serveur est simple - nous donnons toujours tout
• la logique sur l'appareil est simple - nous écrasons toujours tout

Désavantages:

• si vous demandez la liste fréquemment (toutes les 10 minutes), il y aura beaucoup de trafic Internet
• si vous demandez rarement la liste (une fois par jour), la pertinence des données sera violée

Champ d'application:

• pour les applications à faible trafic
• transmission de données très peu évolutives (liste des villes, catégories)
• transférer les paramètres de l'application
• au début du projet pour le tout premier prototype d'application mobile

Approche 2 : mise à jour uniquement

L'appareil demande la liste des plats mis à jour depuis la synchronisation précédente. La liste est triée par "mis à jour" dans l'ordre croissant (facultatif, mais pratique). L'appareil stocke la valeur "mise à jour" pour le dernier plat envoyé et l'envoie au serveur dans le paramètre "lastUpdated" lors de la prochaine requête. Le serveur envoie une liste de plats plus récents que "lastUpdated" (updated > lastUpdated). Lors de la première requête au serveur, "lastUpdated" = null.

Exemple de requête : (dernière mise à jour : "2013-01-01 00:00:00")

Dans le diagramme : "last_updated" est la valeur qui est stockée sur l'appareil. Habituellement, une table séparée est créée sur l'appareil pour stocker ces valeurs "last_updated" pour chaque entité (plats, villes, organisations, etc.)

Cette approche convient à la synchronisation de listes linéaires simples, qui ont les mêmes règles d'arrivée pour l'appareil pour tous les appareils. Pour une synchronisation plus sélective, voir Approche 5 : Synchroniser en sachant ce qui est déjà sur l'appareil.

Habituellement, cette approche couvre la plupart des besoins. Seules de nouvelles données arrivent sur l'appareil, vous pouvez synchroniser au moins toutes les minutes - le trafic sera faible. Cependant, il existe des problèmes liés aux restrictions. appareils mobiles. Ce sont la mémoire et le processeur.

Approche 3 : synchroniser par tranches

Les appareils mobiles ont peu mémoire vive. S'il y a 3000 plats dans le répertoire, l'analyse d'une grande chaîne json du serveur en objets sur l'appareil peut entraîner un manque de mémoire. Dans ce cas, l'application plantera ou ne sauvegardera pas ces 3000 plats. Mais même si l'appareil a pu digérer une telle chaîne, les performances de l'application aux moments de synchronisation en arrière-plan seront faibles (décalages d'interface, défilement non fluide, etc.). Par conséquent, il est nécessaire de demander le liste en plus petites portions.

Pour ce faire, l'appareil passe un autre paramètre ("quantité"), qui détermine la taille de la portion. La liste est envoyée obligatoirement triée par le champ « mise à jour » dans l'ordre croissant. L'appareil, de manière similaire à l'approche précédente, se souvient de la valeur "mise à jour" de la dernière entité envoyée et la transmet au champ "lastUpdated". Si le serveur a envoyé exactement le même nombre d'entités, alors l'appareil continue à se synchroniser et refait une requête, mais avec le « lastUpdated » mis à jour. Si le serveur a envoyé moins d'entités, cela signifie qu'il n'a plus de nouvelles données et la synchronisation se termine.

Dans le diagramme : "last_updated" et "amount" sont les valeurs qui sont stockées dans application mobile. "last_item" - la dernière entité (plat) envoyée par le serveur. C'est plus récent que cette valeur que la prochaine liste sera demandée.

Exemple de requête : (dernière mise à jour : "2013-01-01 00:00:00", montant : 100)

Avantages :

• L'appareil reçoit autant de données qu'il peut traiter en même temps. Portion déterminée par des tests pratiques. Les entités simples peuvent être synchronisées 1000 à la fois. Mais il arrive aussi que des entités avec un grand nombre de champs et une logique de traitement d'enregistrement complexe soient synchronisées normalement pas plus de 5 pièces.

Désavantages:

• S'il y a 250 plats avec la même mise à jour, alors avec quantité = 100, les 150 derniers ne seront pas livrés aux appareils. Cette situation est bien réelle et est décrite dans l'approche suivante.

Approche 4 : Corriger le timing des blocs

Dans l'approche précédente, il est possible que s'il y a 250 plats dans le tableau avec le même "mis à jour" (par exemple, "2013-01-10 12:34:56") et que la taille de la portion soit de 100, alors seul le les 100 premiers enregistrements viendront. Les 150 restants seront coupés par une condition dure (mise à jour > dernière mise à jour). Pourquoi cela arrivera-t-il ? Lors de l'interrogation des 100 premiers enregistrements, lastUpdated sera défini sur "2013-01-10 12:34:56" et la requête suivante aura la condition (mis à jour > "2013-01-10 12:34:56"). Même adoucir la condition (mise à jour>= "2013-01-10 12:34:56") n'aidera pas, car l'appareil demandera alors sans cesse les 100 premiers enregistrements.

La situation avec le même "mis à jour" n'est pas si rare. Par exemple, lors de l'importation de données depuis fichier texte le champ "mis à jour" a été défini sur NOW(). L'importation d'un fichier contenant des milliers de lignes peut prendre moins d'une seconde. Il peut aussi arriver que tout le répertoire ait la même « mise à jour ».

Pour résoudre ce problème, vous devez utiliser un champ de parabole qui serait unique au moins en un instant ("mis à jour"). Le champ "id" est unique dans toute la table, vous devez donc l'utiliser en plus en synchronisation.

En résumé, la mise en œuvre de cette approche ressemble à ceci. Le serveur renvoie une liste triée par "updated" et "id", et les appareils demandent des données en utilisant "lastUpdated" et le nouveau paramètre "lastId". Pour le serveur, la condition de sélection devient plus compliquée : ((updated > lastUpdated) OR (updated = lastUpdated and id > lastId)).

Dans le schéma : "last_updated", "last_id" et "amount" sont les valeurs qui sont stockées dans l'application mobile. "last_item" - la dernière entité (plat) envoyée par le serveur. C'est plus récent que cette valeur que la prochaine liste sera demandée.

Approche 5 : Synchronisation avec la connaissance de ce qui est déjà sur l'appareil

Les approches précédentes ne tiennent pas compte du fait que le serveur ne sait pas vraiment dans quelle mesure les données ont été stockées avec succès sur l'appareil. L'appareil n'a tout simplement pas pu enregistrer certaines données en raison d'erreurs inexpliquées. Par conséquent, il serait bien de recevoir la confirmation de l'appareil que tous (ou pas tous) les plats ont été conservés.

De plus, l'utilisateur de l'application peut configurer l'application de manière à n'avoir besoin que d'une partie des données. Par exemple, un utilisateur veut synchroniser les paraboles de seulement 2 villes sur 10. Cela ne peut pas être réalisé avec les synchronisations décrites ci-dessus.

L'idée derrière l'approche est la suivante. Le serveur stocke (dans une table séparée "stored_item_list") des informations sur les plats qui se trouvent sur l'appareil. Il peut s'agir simplement d'une liste de paires "id - mis à jour". Cette table stocke toutes les listes de paires de paraboles "id - mis à jour" pour tous les appareils.

L'appareil envoie au serveur des informations sur les paraboles disponibles sur l'appareil (une liste de couples « identifiant - mis à jour ») ainsi qu'une demande de synchronisation. Sur demande, le serveur vérifie quels plats doivent se trouver sur l'appareil et lesquels sont actuellement disponibles. Après cela, la différence est envoyée à l'appareil.

Comment le serveur détermine-t-il quels plats doivent être sur l'appareil ? Dans le cas le plus simple, le serveur fait une requête qui renverra une liste de paires "id - mise à jour" de toutes les assiettes (par exemple, SELECT id, assiettes FROM mises à jour). Dans le diagramme, cela est fait par la méthode "WhatShouldBeOnDeviceMethod()". C'est l'inconvénient de l'approche - le serveur doit calculer (parfois en faisant de lourdes requêtes sql) ce qui devrait être sur l'appareil.

Comment le serveur détermine-t-il quels plats sont sur l'appareil ? Il interroge la table "stored_item_list" pour ce périphérique et obtient une liste de paires "id - updated".

En analysant ces deux listes, le serveur décide ce qui doit être envoyé à l'appareil et ce qui doit être supprimé. Dans le diagramme, il s'agit de "delta_item_list". Par conséquent, il n'y a pas de "lastUpdated" et "lastId" dans la requête, leur tâche est effectuée par des paires "id - updated".

Comment le serveur connaît-il les plats disponibles sur l'appareil ? Ajouté à la requête au serveur nouveau paramètre"items", qui contient une liste d'éléments d'identification qui ont été envoyés à l'appareil lors de la dernière synchronisation ("device_last_stored_item_list"). Bien sûr, vous pouvez envoyer une liste d'identifiants de tous les plats qui se trouvent sur l'appareil, et ne pas compliquer l'algorithme. Mais s'il y a 3000 paraboles sur l'appareil et qu'elles seront envoyées à chaque fois, alors les coûts de trafic seront très élevés. Dans la grande majorité des synchronisations, le paramètre "items" sera vide.

Le serveur doit constamment mettre à jour sa "stored_item_list" avec les données provenant de l'appareil dans le paramètre "items".

Vous devez implémenter un mécanisme pour effacer les données du serveur dans la liste_d'éléments_stockés. Par exemple, après avoir réinstallé une application sur un appareil, le serveur supposera que les données sont toujours à jour sur l'appareil. Par conséquent, lors de l'installation de l'application, l'appareil doit en quelque sorte informer le serveur afin qu'il efface la liste d'éléments stockés pour cet appareil. Dans notre application, nous envoyons paramètre supplémentaire"clearCache" = 1 dans ce cas.

Conclusion

Tableau récapitulatif sur les caractéristiques de ces approches :

№	Une approche	Le volume de circulation(5 - grand)	Intensité de travail du développement(5 - élevé)	Utilisation de la mémoire de l'appareil(5 - élevé)	Exactitude des données sur l'appareil(5 - élevé)	Vous pouvez sélectionner un appareil spécifique
1	Tout est toujours synchronisé	5	1	5	5	Non
2	Synchronisé uniquement mis à jour	1	2	5	3	Non
3	Synchronisation en morceaux	1	3	1	3	Non
4	Synchronisation correcte en morceaux	1	3	1	3	Non
5	Synchronisation avec la connaissance de ce qui est déjà sur l'appareil	2	5	2	5	Oui

"L'exactitude des données sur l'appareil" est la probabilité que l'appareil dispose de toutes les données envoyées par le serveur. Dans le cas des approches #1 et #5, il y a une certitude à 100 % que l'appareil dispose de toutes les données nécessaires. Sinon, il n'y a pas de telle garantie. Cela ne signifie pas que d'autres approches ne peuvent pas être utilisées. Juste si l'appareil a une partie les données seront perdues, cela ne fonctionnera pas pour le réparer depuis le serveur (et encore plus pour en savoir plus sur le côté serveur).

Peut-être, en présence de tarifs illimités pour Internet et gratuits problème de wifi les restrictions sur le trafic généré par une application mobile deviendront moins pertinentes. Mais pour l'instant, nous devons recourir à toutes sortes d'astuces, proposer des approches plus "intelligentes" qui peuvent réduire les coûts du réseau et augmenter les performances des applications. Cela ne fonctionne pas toujours. Parfois, cela se produit « le plus simple est le mieux », selon la situation. J'espère que cet article pourra vous aider à trouver une approche qui vous sera utile.

Il existe étonnamment peu de descriptions de synchronisation de serveur et appareils mobiles. De plus, il existe de nombreuses applications qui fonctionnent selon ce schéma. Pour ceux que ça intéresse, quelques liens.