Desarrollo de aplicaciones móviles: Sincronización con el servidor. Desarrollo del back-end de aplicaciones móviles Creación del back-end de la aplicación

Sin conexión en el pasado, estar en línea hoy es imprescindible. Al menos para el mundo empresarial moderno. Presentaciones de productos y servicios de marcas, pedidos y entregas en línea, mantenimiento de una base de clientes, comunicación con los clientes y mucho más: todo esto es simplemente imposible sin una presencia en Internet. Si necesita una aplicación, debe tener un Front-end (la interfaz web) y un Back-End (el lado del servidor de su aplicación). Y si desea poder editar el contenido de su aplicación sin la participación de los desarrolladores, necesita un buen panel de administración.

Mientras Front-end en la esfera aplicaciones móviles creado utilizando tecnologías como X-Code y Java, Back-end, donde se almacenará la base de datos y toda la lógica de la aplicación, requiere un conocimiento profesional del lenguaje de programación del lado del servidor. buen ejemplo es PHP, que es quizás el lenguaje de programación más popular que se utiliza para desarrollar casi cualquier back-end. Este es el líder indiscutible.

Hay muchas aplicaciones para PHP: sitios web estáticos y dinámicos + sistemas de administración de contenido personalizados, redes sociales, sistemas CRM especializados, software de comercio electrónico y mucho más. Por supuesto, hay piezas de servidor y paneles de control gratuitos o baratos. Sin embargo, en muchos casos no brindan el nivel necesario de comodidad, personalización y capacidad de actualización.

Nuestros programadores trabajan con tecnologías que nos permiten implementar una amplia gama de soluciones para diversos objetivos, necesidades y requisitos comerciales. analizamos Requisitos del sistema para cada proyecto individualmente y utilizamos varios software de servidor especializados para un rendimiento óptimo de su aplicación móvil.

Si está buscando un equipo que pueda guiarlo hacia la solución más inteligente y rentable para crear una aplicación desde cero o restaurar una existente para una experiencia de usuario perfecta, no busque más. Appsmob está listo para ayudarte a encontrar la mejor decisión Para usted.

El desarrollo del lado del servidor de una aplicación cliente-servidor comienza con el diseño de la arquitectura. Mucho depende de la arquitectura: desde la extensibilidad de la aplicación hasta su rendimiento y facilidad de soporte/mantenimiento.

En primer lugar, debe determinar cómo se colocarán los datos en el servidor y cómo se procesarán las solicitudes provenientes del cliente. También es necesario pensar en la organización del almacenamiento en caché de datos del lado del servidor.

Es necesario decidir sobre los protocolos de intercambio de datos y los formatos de transferencia de datos.

API (interfaz de programación de aplicaciones): interfaz de programación de aplicaciones. En un lenguaje más comprensible, se trata de un conjunto de peticiones al servidor, que éste entiende y puede dar la respuesta correcta. La API define la funcionalidad de la lógica del servidor, mientras que la API le permite abstraer cómo se implementa esta funcionalidad. En otras palabras, la API es una parte necesaria de la infraestructura global cliente-servidor.

Compara JSON y XML. Dé un ejemplo de protocolos según el tipo de aplicación.

subprocesos múltiples

Uno de los aspectos clave en la programación moderna es el subprocesamiento múltiple. Con la ayuda de subprocesos múltiples, podemos separar varios subprocesos en la aplicación que realizarán varias tareas al mismo tiempo.

El subproceso múltiple es una propiedad de una plataforma (por ejemplo, un sistema operativo, una máquina virtual, etc.) o una aplicación que un proceso generado en el sistema operativo puede consistir en varios subprocesos que se ejecutan "en paralelo", es decir, sin un prescrito orden durante el tiempo.

La esencia de los subprocesos múltiples es cuasi multitarea a nivel de un proceso ejecutable, es decir, todos los subprocesos se ejecutan en el espacio de direcciones del proceso. Además, todos los subprocesos de un proceso no solo tienen un espacio de direcciones común, sino también descriptores de archivo comunes. Un proceso en ejecución tiene al menos un subproceso (maestro).

Los subprocesos múltiples (como doctrina de programación) no deben confundirse con la multitarea o el multiprocesamiento, aunque los sistemas operativos que implementan la multitarea tienden a implementar también los subprocesos múltiples.

Las ventajas de los subprocesos múltiples en la programación incluyen lo siguiente:

Simplificando el programa en algunos casos usando un espacio de direcciones común.

Menos tiempo dedicado a crear un hilo en relación con el proceso.

Mejora del rendimiento del proceso al paralelizar los cálculos del procesador y las operaciones de E/S.

Caudal(hilo) es una unidad administrada de código ejecutable. En un entorno multitarea basado en subprocesos, todos los procesos en ejecución necesariamente tienen un subproceso principal, pero puede haber más. Esto significa que un solo programa puede ejecutar varias tareas de forma asíncrona. Por ejemplo, editar texto en un editor de texto mientras se imprime, porque estas dos tareas se realizan en subprocesos diferentes.

En un procesador convencional, la gestión de subprocesos está a cargo del sistema operativo. El subproceso se ejecuta hasta que se produce una interrupción de hardware, llamada al sistema o hasta que expire el tiempo asignado para ello por el sistema operativo. Después de eso, el procesador cambia al código del sistema operativo, que guarda el estado del hilo (su contexto) o cambia al estado de otro hilo, al que también se le asigna tiempo para la ejecución. Con tales subprocesos múltiples, es suficiente un gran número de Los ciclos de CPU se gastan en el código del sistema operativo que cambia de contexto. Si el soporte de subprocesos se implementa en el hardware, entonces el propio procesador podrá cambiar entre subprocesos y, en el caso ideal, ejecutar varios subprocesos simultáneamente para cada ciclo de reloj.

– Subprocesamiento múltiple temporal (subproceso único)

– Subprocesos múltiples simultáneos (varios subprocesos al mismo tiempo)

Los subprocesos múltiples, como modelo generalizado de programación y ejecución de código, permiten que se ejecuten múltiples subprocesos dentro de un solo proceso. Estos hilos de ejecución comparten los recursos de un proceso, pero también pueden ejecutarse por su cuenta. El modelo de programación multiproceso proporciona a los desarrolladores una práctica abstracción de ejecución paralela. Sin embargo, quizás la aplicación más interesante de la tecnología es cuando se aplica a un solo proceso, lo que permite su ejecución en paralelo sobre un sistema multiprocesador.

Esta ventaja de un programa de subprocesos múltiples le permite ejecutarse más rápido en sistemas informáticos, que tienen múltiples procesadores, un procesador con múltiples núcleos o en un grupo de máquinas, debido al hecho de que los subprocesos de ejecución de programas se prestan naturalmente a una ejecución de procesos verdaderamente paralela. En este caso, el programador debe tener mucho cuidado para evitar condiciones de carrera y otros comportamientos no intuitivos. Para manipular correctamente los datos, los subprocesos de ejecución deben pasar con frecuencia por un procedimiento de encuentro para procesar los datos en el orden correcto. Los subprocesos de ejecución también pueden necesitar mutex (que a menudo se implementan mediante semáforos) para evitar que los datos compartidos se modifiquen al mismo tiempo o se lean durante el proceso de modificación. El uso descuidado de tales primitivas puede conducir a un punto muerto.

Otro uso de subprocesos múltiples, incluso para sistemas de un solo procesador, es la capacidad de una aplicación para responder a la entrada. En los programas de subproceso único, si el subproceso principal de ejecución está bloqueado por la ejecución de una tarea de ejecución prolongada, toda la aplicación puede estar congelada. Al mover tales tareas de ejecución prolongada a un subproceso de trabajo que se ejecuta en paralelo con el subproceso principal, es posible que las aplicaciones continúen respondiendo a la entrada del usuario mientras las tareas se ejecutan en antecedentes. Por otro lado, en la mayoría de los casos, los subprocesos múltiples no son la única forma de mantener un programa receptivo. Lo mismo se puede lograr a través de E/S asíncrona o señales en UNIX.

Hay dos tipos de multitarea: basado en procesos y basado en flujo. Las diferencias entre la multitarea basada en procesos y la basada en subprocesos son las siguientes: la multitarea basada en procesos está organizada para la ejecución paralela de programas y la multitarea basada en subprocesos es para la ejecución paralela de partes individuales de un programa.

Hay dos tipos de flujos:

Hilos de primer plano o primer plano. De forma predeterminada, cada subproceso creado a través del método Thread.Start() se convierte automáticamente en un subproceso en primer plano. Este tipo de subproceso proporciona protección para que la aplicación actual no finalice. Common Language Runtime no detendrá la aplicación hasta que se hayan completado todos los subprocesos en primer plano.

Hilos de fondo. Este tipo Common Language Runtime trata los subprocesos, también conocidos como subprocesos daemon, como rutas de ejecución extensibles que se pueden ignorar en cualquier momento. Por lo tanto, si se terminan todos los subprocesos en primer plano, todos los subprocesos en segundo plano se eliminan automáticamente cuando se descarga el dominio de la aplicación. Para crear subprocesos de fondo, debe establecer la propiedad IsBackground en verdadero.

Habla sobre los estados de los hilos: en ejecución, suspendido, en ejecución, pero esperando algo.

Problema de sincronización de subprocesos y recursos compartidos.

Interacción de subprocesos

En un entorno de subprocesos múltiples, a menudo hay problemas asociados con el uso de los mismos datos o dispositivos mediante subprocesos de ejecución en paralelo. para soluciones problemas similares Se utilizan métodos de interacción de subprocesos, como mutexes, semáforos, secciones críticas y eventos.

exclusión mutua es un objeto de sincronización que se establece en un estado señalado especial cuando no está ocupado por ningún subproceso. Solo un subproceso posee este objeto en cualquier momento, de ahí el nombre de dichos objetos (del inglés acceso mutuamente exclusivo - acceso mutuamente exclusivo): se excluye el acceso simultáneo a un recurso compartido. Después de todas las acciones necesarias, se libera el mutex, dando acceso a otros subprocesos al recurso compartido. Un objeto puede admitir la captura recursiva una segunda vez por el mismo subproceso, incrementando el contador sin bloquear el subproceso y luego requiriendo múltiples liberaciones. Tal, por ejemplo, es la sección crítica en Win32. Sin embargo, hay algunas implementaciones que no admiten esto y provocan que el subproceso se interbloquee al intentar una captura recursiva. Esto es FAST_MUTEX en el kernel de Windows.

semáforos representan los recursos disponibles que pueden ser adquiridos por varios subprocesos al mismo tiempo hasta que el grupo de recursos esté vacío. Luego, los subprocesos adicionales deben esperar hasta que la cantidad requerida de recursos esté disponible nuevamente. Los semáforos son muy eficientes porque permiten el acceso simultáneo a los recursos.

Eventos. Objeto que almacena 1 bit de información “señalado o no”, sobre el cual se definen las operaciones “señalar”, “restablecer a un estado no señalizado” y “esperar”. Esperar un evento señalado es la ausencia de una operación con una continuación inmediata de la ejecución del hilo. Esperar un evento no señalado hace que la ejecución de un subproceso se suspenda hasta que otro subproceso (o la segunda fase de un controlador de interrupciones en el kernel del sistema operativo) señale el evento. Es posible esperar varios eventos en los modos "cualquiera" o "todos". También es posible crear un evento que se restablece automáticamente a un estado no señalado después de activar el primer y único subproceso en espera (dicho objeto se utiliza como base para implementar el objeto de "sección crítica"). Utilizado activamente en MS Windows, tanto en modo usuario como en modo kernel. Hay un objeto similar en el kernel de Linux llamado kwait_queue.

Secciones críticas proporcionar sincronización como mutexes, excepto que los objetos que representan secciones críticas son accesibles dentro del mismo proceso. Los eventos, mutexes y semáforos también se pueden usar en una aplicación de un solo proceso; sin embargo, las implementaciones de secciones críticas en algunos sistemas operativos (por ejemplo, Windows NT) brindan un mecanismo más rápido y eficiente para la sincronización mutuamente excluyente: la adquisición y liberación las operaciones en la sección crítica están optimizadas para el caso de un solo subproceso (sin contención) para evitar cualquier llamada al sistema que conduzca al kernel del sistema operativo. Al igual que los mutex, un objeto que representa una sección crítica solo puede ser utilizado por un subproceso a la vez, lo que los hace extremadamente útiles para restringir el acceso a los recursos compartidos.

Variables de condición(convaras). Similares a los eventos, pero no son objetos que ocupan memoria, solo se usa la dirección de la variable, el concepto de "contenido de la variable" no existe, la dirección de un objeto arbitrario se puede usar como variable de condición. A diferencia de los eventos, establecer una variable de condición en el estado señalado no tiene consecuencias si actualmente no hay subprocesos esperando en la variable. Establecer un evento en un caso similar implica almacenar el estado "señalado" dentro del propio evento, después de lo cual los subprocesos posteriores que desean esperar el evento continúan la ejecución inmediatamente sin detenerse. Para hacer un uso completo de dicho objeto, también es necesaria la operación "liberar el mutex y esperar atómicamente la variable de condición". Utilizado activamente en sistemas operativos tipo UNIX. Los debates sobre las ventajas y desventajas de los eventos y las variables de condición son una parte importante de los debates sobre las ventajas y desventajas de Windows y UNIX.

Puerto de terminación de E/S(Puerto de terminación de E/S, IOCP). Implementado en el kernel del sistema operativo y accesible a través de llamadas al sistema, el objeto "cola" con las operaciones "poner la estructura al final de la cola" y "tomar la siguiente estructura del principio de la cola" - la última llamada suspende la ejecución del subproceso si la cola está vacía, y hasta que ningún otro subproceso realice la llamada put. La característica más importante de IOCP es que las estructuras se pueden colocar en él no solo mediante una llamada explícita al sistema desde el modo de usuario, sino también implícitamente dentro del kernel del sistema operativo como resultado de la finalización de una operación de E/S asíncrona en uno de los archivos. descriptores. Para lograr este efecto, debe utilizar la llamada al sistema "asociar un descriptor de archivo con IOCP". En este caso, la estructura colocada en la cola contiene el código de error de la operación de E/S y también, en caso de éxito de esta operación, el número de bytes realmente ingresados o emitidos. La implementación del puerto de finalización también limita la cantidad de subprocesos que se ejecutan en un solo procesador/núcleo después de recibir una estructura de la cola. El objeto es específico de MS Windows y permite el procesamiento de solicitudes de conexión entrantes y fragmentos de datos en el software del servidor en una arquitectura donde la cantidad de subprocesos puede ser menor que la cantidad de clientes (no es necesario crear un subproceso separado con recursos). costos por cada nuevo cliente).

Grupo de subprocesos

Cuéntanos sobre el grupo de subprocesos

Nuestra empresa ofrece servicios para crear la parte del servidor de aplicaciones comerciales móviles y servicios web de clientes que operan en entornos de alta carga. Al desarrollar cada proyecto, tratamos de aplicar un enfoque individual para que el producto resultante sea el más solucion optima objetivos específicos del cliente.

Si está utilizando una aplicación compleja que almacena y/o procesa datos en un servidor, entonces está respaldada por un Back-end: un paquete de software alojado en un servidor web y que funciona con una aplicación, que en este caso se llama Front-end. fin. Una aplicación alojada en un servidor puede trabajar simultáneamente con una gran cantidad de clientes, lo que impone requisitos de alta velocidad y seguridad en su funcionamiento.

A menudo, el lado del servidor de una aplicación está escrito en lenguaje PHP, como el más popular para este tipo de soluciones. Para implementar tareas de servidor simples se pueden utilizar sistemas estándar, pero para los más específicos ya se requiere desarrollar una solución propia o complementos sobre sistemas estándar.

Principios de desarrollo de un servidor para una aplicación móvil

Nuestros programadores trabajan con tecnologías que hacen posible implementar amplia gama soluciones para cualquier carga, incluso muy alta y varias direcciones. También creamos soluciones de servidor separadas para tareas individuales.

control organizativo

Cada proyecto es creado por un grupo separado de especialistas responsables de todas las etapas de desarrollo y entrega del proyecto a tiempo.

Programación

El diseño de la arquitectura del servidor es el paso más importante durante el cual se crean las bases de datos y se forman los algoritmos necesarios.

Pruebas

La parte del software debería funcionar sin errores ni fallas. Esta es responsabilidad de los probadores que realizan la verificación del sistema.

Soporte técnico

Nuestros empleados realizan un soporte técnico completo de los programas, lo que le permite eliminar rápidamente las deficiencias y realizar actualizaciones.

Funciones de desarrollo

Para desarrollar de manera competente el lado del servidor de la aplicación, se requieren ciertas habilidades y conocimientos del lenguaje de programación utilizado en el servidor. Como muestra la práctica, el cliente aplicaciones de servidor creado en PHP. Es el líder indiscutible en este campo. Más de la mitad de los sitios en el mundo están escritos en PHP, es conveniente para el desarrollo y soporte.

Marco de referencia

Esta plataforma de software le permite hacer que el proyecto sea más escalable y flexible. Sin embargo, el marco debe elegirse de la manera más correcta posible, por lo tanto, se requiere un análisis profundo de la documentación de trabajo del proyecto, que posteriormente ayudará a desarrollar un producto de alta calidad.

Hay otros lenguajes utilizados para el desarrollo de back-end. Por ejemplo, las aplicaciones de servidor creadas en Entorno Delfos. Debido a ello, el programa ha mejorado la depuración. Además, es más fácil desarrollar programas únicos, proporciona creación visual. Todo esto le permite hacer una interfaz clara y conveniente.

Las aplicaciones de servidor Java no son menos populares. Se complementan fácilmente, se ejecutan fácilmente en diferentes plataformas y tienen un alto nivel de seguridad.

Otro lenguaje de uso común. Con él, las aplicaciones del servidor se crean de manera fácil, rápida y sin costo adicional.

Casi todas las empresas modernas tienen sus propias oficinas virtuales. El sitio web puede ser cualquiera tarjeta de llamada, o un portal o catálogo online con posibilidad de realizar pedidos.

En este caso, los procesos comerciales dependen de los servidores web, es decir, de su capacidad para soportar ataques, intentos de piratería y ataques externos. impactos negativos, así como un rendimiento suficiente para muchas solicitudes simultáneas.

Etapas del desarrollo de un servicio web

Al crear aplicaciones para diferentes segmentos del mercado, organizamos nuestro trabajo de acuerdo con un solo principio: dividimos todo el proceso en pasos individuales, cuyo progreso y resultados se informan a los clientes. Así, el servidor para la aplicación móvil se desarrolla de la misma forma.

1. Desarrollo de ideas

hasta 2 semanas

En esta etapa, se está creando la base, dando una idea de lo que se establecerá y en qué dirección se desarrollará.

2. Evaluación del proyecto

2-3 semanas

Nuestros expertos evalúan el tiempo y el costo del trabajo, luego se elabora una propuesta preliminar para el desarrollo.

3. Términos de referencia y contrato

hasta 2 semanas

Después de discutir con el cliente todos los matices del proceso y redactar un TOR detallado, se prepara y firma un contrato.

4. Desarrollo de interfaz

2-3 semanas

Los diseñadores son responsables de crear las interfaces necesarias al escribir módulos de programa.

6. Pruebas

2-3 semanas

Verificación completa de recibido solución de software producido por probadores a través de un conjunto de herramientas apropiadas.

7. Finalización del proyecto

hasta 2 semanas

Dentro del plazo acordado, se entrega al cliente un servicio web listo para usar y probado exhaustivamente.

nuestro equipo

A través del análisis de las actividades comerciales y las necesidades de nuestros clientes, creamos productos del mundo real que ayudan a resolver una variedad de problemas comerciales. Uso tecnologías modernas proporciona una amplia gama de posibilidades para la implementación de software de servidor, lo que garantiza el alto rendimiento de las aplicaciones móviles correspondientes. Nuestro equipo está representado por:

Gerentes de Proyecto

Estos empleados interactúan tanto con los clientes como con los desarrolladores, facilitando la comunicación entre ellos. Supervisan la implementación tanto de las acciones ya planificadas como de las mejoras necesarias.

Diseñadores

En su trabajo, nuestros especialistas tienen en cuenta los requisitos para construir interfaces para sistemas operativos iOS y Android, por lo que las aplicaciones lanzadas funcionan correctamente en diferentes dispositivos.

Desarrolladores

Para optimizar el rendimiento de las aplicaciones móviles, los programadores analizan los requisitos de su sistema y crean un software de servidor especializado.

Probadores

Las pruebas exhaustivas son una garantía de la calidad del producto terminado y una garantía de la seguridad de los datos almacenados y procesados. Estos especialistas utilizan diferentes herramientas y una metodología eficaz.

¿Qué servicios creamos?

Al ser un software integrado en el sitio o un programa independiente, el servicio web se utiliza para realizar tareas relacionadas con publicidad, análisis, planificación comercial y promoción. En este sentido, es necesario decidir qué tipo de recurso será la mejor solución.

Proyectos de información

Diseñado para acomodar contenido diverso.

sitios temáticos

Casi todas sus páginas están dedicadas a un tema. La demanda de ellos sigue siendo bastante alta.

sitios de noticias

Informan sobre diversas noticias en el marco de uno o más temas, reflejando los principales ámbitos de la vida.

blogs

El nivel de popularidad de estos recursos crece constantemente. Al igual que los sitios de noticias, transmiten tal o cual información a la comunidad de Internet, pero en este caso, los autores expresan su opinión personal.

Proyectos sociales

Estos incluyen servicios sociales especializados redes, comunidades, foros, etc.

Foros

Creado para discutir varias noticias, productos / servicios, etc. Pueden tener un enfoque limitado y ser diversos.

Medios de comunicación social

Estos recursos tienen una audiencia multimillonaria. Su tarea principal es brindar a los usuarios de Internet la oportunidad de comunicarse en línea a través de texto / mensajes de voz y videocomunicaciones.

Varios servicios web

Recibida hoy amplio uso, se dividen en varios tipos.

Catálogos

servicios postales

Proporcionar a los usuarios todas las características y beneficios. Correo electrónico, incluida la visualización, el envío, la edición de cartas y documentos, etc.

Los motores de búsqueda

Se utilizan para buscar sitios e información diversa sobre solicitudes específicas.

Tablones de anuncios

Son recursos web donde los usuarios de la red colocan sus anuncios de compra y venta de servicios dentro de diversas temáticas.

Sitios de alojamiento

Diseñado para el almacenamiento temporal de archivos. Algunos de ellos brindan la oportunidad de familiarizarse con los datos antes de descargarlos.

Preguntas frecuentes

A continuación, ofrecemos respuestas a las preguntas que a menudo se hacen a nuestros especialistas. Si no encuentra la información que busca aquí, publique su pregunta aquí. forma y definitivamente lo responderemos.

¿Cuánto tiempo puede llevar crear una aplicación y un servidor web?

En promedio, este trabajo dura de 9 a 20 semanas. Todo depende de la complejidad de la tarea que se está implementando.

COPIAS DE SEGURIDAD

Por qué se necesitan copias de seguridad en una plataforma móvil

Los expertos saben cuán poco confiables son a veces las aplicaciones móviles 1C: pueden ocurrir errores en cualquier momento, debido a que las bases de usuarios simplemente colapsan. Al mismo tiempo, nos enfrentamos a la falta de fiabilidad de los propios dispositivos: pueden romperse, perderse, robarse y los usuarios quieren conservar sus datos. Y hasta la versión 8.3.9 no teníamos un mecanismo de copia de seguridad de la plataforma.

Dado que los usuarios no tenían un botón "guardar una copia" antes, los desarrolladores de la aplicación Boss tuvieron que hacer copias de seguridad ellos mismos. ¿Cómo lo hicimos?

Guardamos los datos de la base de datos en forma de XML.

Es recomendable ofrecer al usuario varias opciones para almacenar copias; en primer lugar, es conveniente para los clientes, pueden elegir la mejor opción para ellos: cargar en la nube, enviarlo a su correo, guardarlo en el dispositivo.

Por lo tanto, los desarrolladores se aseguran adicionalmente. Si algo salió mal y el mecanismo para crear copias en Google Drive o Yandex Drive se rompió repentinamente, siempre puede decirle al usuario que el desarrollador está lidiando con el error, pero por ahora puede guardar los datos de una manera alternativa. Y los usuarios están satisfechos porque pueden estar tranquilos con sus datos.

Necesariamente centrarse en los servicios en la nube, porque si el dispositivo se pierde o se rompe, y el usuario guardó una copia en el mismo dispositivo, los datos se perderán.

También nosotros asegúrese de recordarle al usuario la necesidad de crear copias de seguridad.

¿Cómo guardar copias si cambia la configuración?

Cuando hablamos de una solución masiva, de una aplicación que está en constante cambio, desarrollo y mejora, debemos tener en cuenta el comportamiento de los clientes. El usuario puede querer restaurar una copia de seguridad guardada en versión antigua aplicación, donde no había detalles. Y luego surge la tarea: leer los datos, luego completar los datos de acuerdo con la lógica de actualización de la versión anterior de la aplicación. ¿Cómo hacerlo? Además de los datos, guarde la estructura de datos en sí, para que luego sepa cómo leerlos.

Hay varias opciones para almacenar esta estructura de datos, incluido el almacenamiento en la propia configuración. Es decir, con el lanzamiento de cada nueva versión, guarde la estructura de metadatos de la versión anterior en el diseño en la configuración.

No olvides que en una aplicación móvil, la configuración no debe crecer así, debemos valorar el lugar en ella, debemos hacerla lo más compacta posible. Pero la aplicación se está desarrollando, y habrá muchos diseños de este tipo, y con el tiempo habrá más y más de ellos.

Por lo tanto, en el caso de una aplicación móvil, es preferible otra forma: guardar la estructura de metadatos directamente en el archivo de datos. En la salida, obtenemos dicho archivo, donde primero almacenamos algunos datos auxiliares: la versión de configuración, el esquema de configuración, los límites de secuencia, y luego escribimos los datos del usuario en formato XML. Además, en la sección "Datos auxiliares" del archivo, también puede almacenar otros datos importantes que, por alguna razón, no se pudieron escribir en XML.

Tomamos el esquema de datos que se guardó en el archivo y, en base a él, construimos el paquete XDTO para leer el archivo. Creamos un objeto similar en la base de datos, lo completamos, realizamos el procesamiento de finalización al actualizar y guardamos el objeto terminado en la base de datos.

A continuación, en la imagen, puede ver una pista sobre cómo escribir bellamente el modelo XDTO de estas configuraciones. La empresa que lanzó la aplicación Boss experimentó con esto, encontró varias formas, pero se decidió solo por esta opción para escribir el esquema de metadatos. Cuando se abre el archivo de datos, puede ver el XML estructurado habitual, legible, que enumera todos los metadatos de la aplicación.

// Escribir el esquema de configuración XDTO Model = XDTO Factory.XDTO Model Export("http://v8.1c.ru/8.1/data/enterprise/current-config"); FactoryXDTO.WriteXML(FileUpload, ModelXDTO); // Leer el esquema de configuración ModelXDTO = FactoryXDTO.ReadXML(ReadingXML, FactoryXDTO.Type("http://v8.1c.ru/8.1/xdto","Model")); Descargar Fábrica = Nueva Fábrica XDTO (Modelo XDTO);

Para proteger al usuario, es necesario volver a preguntarle si necesita restaurar la copia de seguridad. Tal vez solo estaba experimentando y haciendo clic en los botones de todo en la aplicación :) Y ahora sus datos actuales pueden perderse. Por lo tanto, cuando realizamos acciones potencialmente "peligrosas", siempre aclaramos si realmente quiere esto y cómo debería suceder. El usuario debe ser consciente de sus acciones.

Debe haber un mecanismo para crear copias de seguridad cuando hablamos de una solución fuera de línea, cuando el usuario tiene todos los datos almacenados exclusivamente en un dispositivo móvil: el usuario puede perder su dispositivo y luego se perderán los datos. Y parece que si la aplicación no funciona sin conexión, pero está conectada a un servidor central, entonces el usuario no debería tener ese problema, porque si el dispositivo se pierde, se conectará al servidor, recibirá todos sus datos de el servidor de nuevo, y todo estará bien.

Sin embargo, los usuarios no siempre usan las copias de seguridad de la manera que esperamos de ellos :) Muy a menudo las usan para simplemente "revertir" los datos. Este es realmente un comportamiento muy extraño, pero los usuarios de aplicaciones móviles son demasiado flojos para darse cuenta de dónde podrían cometer un error al ingresar datos, y simplemente revierten los datos y reinician los datos para el día actual. Después de analizar las estadísticas de trabajo con la aplicación Boss, nos dimos cuenta de que esta es una práctica normal y que ese comportamiento de los usuarios es más común de lo que podríamos haber imaginado.

Y si usa la sincronización con otros dispositivos, debe procesar esto. Hay varias soluciones aquí:

romper la conexión con el servidor, especificando que los datos en él permanecerán como estaban, y la copia se restaurará solo en el dispositivo del usuario;
es mejor que el usuario le permita restaurar una copia en todos los dispositivos a la vez, habiendo prescrito previamente dichos mecanismos.

Hay un punto más aquí. Hasta ahora, guardábamos las copias de seguridad nosotros mismos, controlábamos todo el proceso, captamos las acciones del usuario directamente en el código cuando hacía clic en el botón "guardar una copia". Todo esto puede ser procesado posteriormente. En la plataforma 8.3.9, fue posible guardar copias de seguridad utilizando las herramientas de la plataforma. Y el usuario lo hace sin nuestro conocimiento. Si se utiliza la sincronización con una base de datos central, se debe procesar dicho escenario. De alguna manera debemos averiguar en nuestro servidor que el usuario ha restaurado una copia previamente guardada y debemos darle algún tipo de decisión. No podemos darnos el lujo de dejar que los datos se desincronicen.

INTERCAMBIO

Cuando hablamos de una solución privada en una plataforma móvil, generalmente tenemos un cliente que, por ejemplo, quiere usar una plataforma móvil para sus agentes de ventas y que intercambien datos con una base de datos central. Aquí todo es simple: una base de datos, varios dispositivos, levanta el servidor, establece la comunicación con él. Por lo que el problema del intercambio entre dispositivos se resuelve fácilmente.

Pero si estamos hablando de una aplicación masiva, donde hay muchas bases de datos, cada una de las cuales tiene muchos usuarios, la situación se vuelve más complicada. Los usuarios han descargado la aplicación del mercado y quieren sincronizar entre sí. Por ejemplo, un esposo descargó una aplicación de finanzas personales y ahora quiere que su esposa también se conecte para que puedan trabajar juntos en la misma aplicación. Hay muchos usuarios, la aplicación se está desarrollando, creciendo y se necesita una gran, gran cantidad de bases de datos. ¿Cómo organizar todo esto? Los usuarios no contactarán personalmente a los desarrolladores para crear una base de datos separada para ellos y habilitar la sincronización. Quieren presionar un botón y hacer que todo funcione de inmediato. En el mismo momento.

¿Cómo proceder? Aquí es donde el mecanismo de separación de datos viene al rescate. Le permite organizar una sola base de datos, donde hay una configuración común, pero al mismo tiempo, un número ilimitado de bases de datos de usuarios se almacenan dentro de una base de datos común.

La mejor parte es que puede agregar usuarios de forma dinámica, mediante programación, sin nuestra participación. En realidad, los usuarios simplemente hacen clic en el botón "registrarse en el servidor" y todo sucede por sí solo: se crea una base de datos personal para él en el servidor y puede comenzar a trabajar en ella de inmediato.

¿Cómo hacerlo? La primera y más sencilla solución es escribir su propia base de datos de servidor con este mecanismo. Cuando nuestra empresa comenzó a hacer la aplicación Boss y los intercambios en ella, hicimos exactamente eso en la primera versión: escribimos una base de datos de servidor con un mecanismo de intercambio de datos. Todo funcionó, especialmente porque no había nada complicado: el separador de base es un atributo común.

Pero luego nos dimos cuenta de que estábamos reinventando la rueda :) De hecho, ya hay solución llave en mano, y ya tiene en cuenta momentos en los que ni siquiera hemos pensado. Esto es 1C: fresco.

Aquí se piensa en la escalabilidad del servicio: qué hacer cuando hay muchos datos y bases de datos, cómo crecer con todo eso. Hay un momento aquí sobre la creación copias de seguridadáreas de datos: es decir, no solo hacemos backup de una base de datos común, hacemos copias de un usuario específico. Además, el mecanismo allí es tal que las copias se hacen solo cuando realmente se necesitan. Si el usuario no ha iniciado sesión en la base de datos durante una semana, no hacemos copias para él, porque nada ha cambiado allí. Otra característica de Fresh es que el servicio tiene un mecanismo para reducir la carga en el servidor, y esto es muy importante cuando tienes muchas bases de datos.

En general, Fresh es algo nuevo e interesante para nosotros. Poco a poco estamos tratando de resolverlo, pero en su mayor parte estamos contentos con su trabajo.

Transferencia de datos. Cómo implementarlo para compartir entre dispositivos

La plataforma proporciona dos mecanismos: servicios SOAP y http. Hay matices aquí sobre cómo acceder a estos servicios cuando el mecanismo de intercambio de datos está habilitado. En particular, debe agregar parámetros que indiquen el número específico del reino al que está accediendo, porque la plataforma no puede determinar a qué base de datos acceder desde el nombre de usuario. Además, un mismo usuario puede trabajar con varias bases de datos dentro de una sola base de datos (ver imagen).

En cuanto a los servicios, la aplicación Boss implementa intercambio instantáneo: Un usuario ingresa datos y otro los recibe. Los usuarios de aplicaciones móviles están acostumbrados a que todo suceda al instante, así que pensamos en cómo mejor servicio para usar - SOAP o http. La velocidad de conexión jugó un papel clave. En http, la velocidad de conexión es mucho mayor, y cuando nos conectamos a través de SOAP, obtenemos una descripción del servicio que es pesada y tarda mucho en cargar. La plataforma tiene una forma de almacenar una descripción del servicio, pero debido a los parámetros que agregamos dinámicamente, no podemos usar enlaces WS. Además, acceder a los servicios http es más conveniente y flexible, según nuestra experiencia.

Por lo tanto, nuestro objetivo es implementar el intercambio en tiempo real. Es decir, tratamos de que el usuario no tenga que ir a algún lado, hacer clic en algún botón, pensar qué tan actualizados están sus datos, si debe actualizarlos... Los usuarios siempre deben tener los datos actualizados. hasta la fecha. Están tan acostumbrados a trabajar en mensajeros: uno envió los datos, el otro los recibió de inmediato. Todo sucede al instante. Lo mismo se aplica a las aplicaciones relacionadas con los negocios: un vendedor ha emitido una venta, el otro debe ver inmediatamente la situación actual, sin tomar ninguna medida.

Por lo tanto, la aplicación Boss utiliza trabajos en segundo plano para los intercambios. Después de cada entrada de datos en la base de datos, se lanza una tarea en segundo plano que inicia el intercambio. La primera parte es enviar los datos al servidor. Los otros dispositivos necesitan saber que hay nuevos datos. Para ello utilizamos las notificaciones PUSH. Este esquema ya está funcionando y funciona lo suficientemente rápido.

Pero queríamos aún más rápido, porque trabajamos en tiempo real y normalmente tenemos pocos datos. Tenemos un XML pequeño, pero al mismo tiempo enviamos un mensaje con estos datos desde el primer dispositivo al servidor, el servidor envía PUSH a otro dispositivo, y luego el segundo dispositivo, después de recibir PUSH, inicia el intercambio por su parte, accede al servidor y solicita datos, recibe estos datos y luego envía una respuesta de que los datos han sido recibidos. Esto es mucho tiempo, pero había muy pocos datos en sí.

Pensamos en cómo se puede acelerar este proceso.

Para hacer esto, descubrimos qué contiene PUSH, cómo se puede usar. Resultó que PUSH contiene campos como datos y texto. La documentación para iOS y Android indica los límites en el tamaño de los mensajes PUSH, pero esto nos pareció insuficiente y quisimos averiguarlo nosotros mismos. Y comprobamos que para iOS la suma de caracteres permitidos es de 981 caracteres, y para Android es de 3832 caracteres. En el último caso, es bastante posible usar la restricción; uno o varios objetos base pueden insertarse en dicho volumen. Y luego los desarrolladores de la compañía cambiaron un poco el esquema. Cuando no hay muchos datos, los enviamos desde un dispositivo, los recibimos en el servidor, los empaquetamos en PUSH y los enviamos directamente a otro dispositivo. El esquema se ha acortado y el intercambio se ha vuelto aún más rápido :)

Un punto importante de usar PUSH es que no molesta a los usuarios.

Es muy fácil deshacerse de esta situación: simplemente no envíe muchos mensajes PUSH al usuario :) Si actualmente está trabajando en la aplicación, puede enviar muchos mensajes. Cuando la plataforma se está ejecutando, el usuario no ve PUSH, todo sucede automáticamente para él. Pero cuando se cierra la aplicación, el cliente tiene muchas mensajes no leídos. Por tanto, en ningún caso debe enviar el siguiente PUSH hasta que no reciba respuesta del dispositivo de que la aplicación está en ejecución, activa y el anterior PUSH ya ha sido procesado.

Otro matiz del intercambio es el trabajo vía web. Necesitamos usar la asincronía tanto como sea posible. No puede trabajar como de costumbre: escriba código, llame a una función, espere a que se ejecute, obtenga una respuesta, y todo está bien. Si trabaja a través de la web, aún encontrará ciertas limitaciones, como Internet inestable, tiempos de espera al realizar operaciones largas. Por lo tanto, es necesario pensar en la arquitectura de antemano.

Veamos el ejemplo del registro de dispositivos, qué pasa en la aplicación cuando el usuario quiere registrarse. Mantiene registros por un tiempo, ingresó muchos datos, pero luego quiere que el vendedor también trabaje con esta base de datos. El usuario hace clic en el botón "registrarse". Al principio, todo fue muy simple: tomaron sus datos, los registraron en el servidor y, por favor, puedes trabajar y conectar a los usuarios. Pero luego nos encontramos con una situación en la que, para algunos usuarios, las bases de datos en el dispositivo ya habían crecido mucho en el momento del registro. Y este esquema ya no funcionó, porque. mientras se registraba toda la base de datos en el servidor, se activaba el tiempo de espera de la conexión o simplemente se interrumpía Internet. Por lo tanto, hemos reemplazado una llamada síncrona con muchas llamadas cortas. Los datos ahora se comparten en lugar de transferirse todos a la vez. No esperamos en ningún caso mientras el servidor procesa y escribe los datos. Enviamos los datos, recibimos una respuesta de que se recibieron los datos, cerramos la conexión. Periódicamente, es necesario sondear el servidor, qué está sucediendo allí y cómo, y mientras tanto, se ejecuta una tarea en segundo plano en el servidor, que escribe los datos recibidos. Esto genera muchas llamadas al servidor, pero tenemos la garantía de que todo irá bien. Y ni los tiempos de espera ni la inestabilidad de Internet te impedirán subir todos los datos al servidor.

ACTUALIZACIONES

Compartir entre dispositivos con diferentes versiones de la aplicación

Dado que estamos hablando de una aplicación masiva que se lanza a los mercados, es necesario tener en cuenta algunas características del proceso de actualización e intercambio de datos.

Si lanzó una aplicación para una empresa y decidió actualizarla, generalmente solo da un comando para que todos los empleados instalen la nueva aplicación por unanimidad. Con usuarios que descargaron la aplicación del mercado, esto no se puede hacer. No puedes decirles qué hacer en absoluto. Por ejemplo, trabajan en la aplicación y no quieren actualizarla ni ahora ni nunca. No tienen actualización automática, por lo que es bastante común que varios dispositivos estén conectados a la base de datos central, y todos ellos con diferentes versiones. Otro motivo de este fenómeno es el tiempo de publicación en los mercados: es diferente para iOS y Android. A menudo implementamos cosas clave como corregir errores críticos y no queremos esperar dos semanas para que iOS revise nueva versión, queremos al menos solo para Android, pero lanzar una actualización ahora mismo.

No tenemos derecho a mandar a los usuarios. Si quieren, actualizan, y si no, no hacen nada. La imagen muestra la proporción de instalaciones de la aplicación Boss por versiones en GooglePlay, así como las estadísticas de nuestro servidor: la proporción real de versiones de la aplicación que están instaladas en dispositivos que han intercambiado datos con el servidor durante la última semana. Aquí hay un conjunto para trabajar. Estas son versiones diferentes y metadatos diferentes. Y necesitamos organizar un intercambio normal al mismo tiempo :)

Los desarrolladores enfrentan los siguientes desafíos:

Todo tiene que funcionar. Los usuarios no deberían sentirse mal por olvidarse de actualizar. No deberían notarlo en absoluto. Actualizado: se volvió mejor, bueno, bueno.
Debemos garantizar la seguridad de los datos. Por ejemplo, un usuario tiene un directorio y un nuevo atributo, mientras que otro todavía no. Además, si un usuario que no tiene nuevos detalles cambia algo en su dispositivo, los datos de otros dispositivos no deberían perderse.
Es necesario asegurarse de que los datos estén actualizados cuando cambiamos a una nueva versión. Cuando el usuario decide que está listo para actualizar, debería tener automáticamente toda la información nueva que no tenía solo porque tenía la versión anterior.

¿Cómo lo hicimos?

1. Usamos 2 planes de intercambio en el servidor. El primero es para compartir entre dispositivos y el segundo es para actualizaciones. Por ejemplo, enviamos un directorio al usuario, pero no tiene unidades de medida, es decir, datos incompletos. Debemos recordar esto. Y cuando se actualice, debemos enviarle toda la información que no tenía. Para ello, se necesita un segundo plan de intercambio.

2. Para escribir y leer objetos, usamos el mismo mecanismo que se usa para las copias de seguridad, es decir, guardamos la versión de metadatos. En este caso, estamos trabajando con el servidor y podemos darnos el lujo de agregar cualquier cosa que queramos directamente a la configuración, por lo que simplemente agregamos esquemas de metadatos a la configuración en forma de diseños a medida que se desarrolla la aplicación.

Cómo monitorear errores masivos en el intercambio y en el servidor

Primero, debe controlar la disponibilidad del propio servidor. Con los servidores sucede: se caen. No inventamos nada especial para monitorear, simplemente encontramos un bot en un telegrama que grita si algo anda mal. Comprueba el rendimiento del servidor cada minuto, y si de repente el servidor no está disponible, comienza a gritar, los administradores ven esto y activan el servidor.

También recopilamos un registro de errores del registro. Tampoco nada sobrenatural: solo cada tres horas recopilamos un registro de errores, los enviamos al correo y los revisamos periódicamente. Esto ayuda a ver problemas comunes y algunos situaciones excepcionales. No es difícil ver el correo, rastrear y corregir errores rápidamente. Pero esto le permite identificar y resolver rápidamente problemas que pueden crecer con el crecimiento de las bases de datos.

Más punto importante- asegúrese de darle al usuario la oportunidad de "quejarse". Esto mejora nuestro estatus a sus ojos y nos salva. Hay usuarios, como los llamamos, "histéricos" que al menor error nos empiezan a mandar un montón de mensajes por correo que nada funciona, la base de datos no carga, todo está terriblemente mal. Pero a veces nos salvan de verdad, porque a veces encuentran fallos que el resto aún no ha descubierto milagrosamente, fallos graves.

El usuario no debe asustarse. No hay mensajes de miedo, nada más. Necesitan explicar todo bellamente y ofrecer quejarse. Y prometemos solucionarlo todo. Entonces los usuarios están satisfechos, porque ven que los atienden, e inmediatamente creen que serán ayudados :)

Este artículo fue escrito siguiendo los resultados del informe leído en la conferencia INFOSTART EVENT 2016 DEVELOPER. Se pueden leer más artículos.

En 2020, invitamos a todos a participar en 7 encuentros regionales, así como en el aniversario INFOSTART EVENT 2020 en Moscú.

Una parte importante de la modernidad aplicaciones para plataformas móviles(iOS, Android, etc.) funciona en conjunto con el servidor. Una aplicación con datos obsoletos pierde su utilidad. Por lo tanto, es importante asegurarse de que los datos del servidor al dispositivo se actualicen constantemente. Esto se aplica a las aplicaciones fuera de línea que deberían funcionar sin Internet. por completo aplicaciones en línea, que no funcionan (o son inútiles) sin Internet (por ejemplo, Foursquare, Facebook) tienen sus propias especificidades, que están más allá del alcance del presente artículo.

Usando una de nuestras aplicaciones fuera de línea como ejemplo, le diré qué enfoques usamos para sincronizar datos. En las primeras versiones hemos desarrollado algoritmos simples y, en el futuro, con la experiencia, los mejoramos. En el artículo se presenta una secuencia similar, desde prácticas simples y obvias hasta otras más complejas.

Cabe aclarar que el artículo trata de la transferencia de datos solo en una dirección: del servidor al dispositivo. Aquí el servidor es la fuente de datos.

Disposiciones generales para todos los enfoques

Por ejemplo, consideraremos transferir un directorio de platos ("platos") al dispositivo. Supondremos que el dispositivo realiza una solicitud a la url “/service/dishes/update”, el intercambio se realiza a través del protocolo http en formato JSON ( www.json.org). El servidor tiene una tabla de "platos" con los siguientes campos: id (identificador de registro), nombre (nombre del plato), actualizado (hora de actualización del plato, es mejor admitir inmediatamente la zona horaria, "AAAA-MM-DDThh: mm: ssTZD", por ejemplo, “1997 -07-16T19:20:30+01:00”), is_deleted (signo de una entrada eliminada).

Observación sobre la presencia del último campo. Por defecto su valor es 0. En una aplicación donde las entidades están sincronizadas entre el cliente y el servidor, no se recomienda borrar físicamente los datos del servidor (para que no haya errores). Por lo tanto, para los platos eliminados se establece is_deleted = 1. Cuando una entidad con is_deleted = 1 llega al dispositivo, se elimina del dispositivo.

Con cualquier enfoque, que se analizará a continuación, el servidor devuelve una matriz de objetos a los dispositivos JSON (puede estar vacío):

[
(identificación: ,nombre: .actualizado: ,esta borrado: },…
]

Ejemplo de respuesta del servidor:

[
(id: 5625, nombre: "Pan", actualizado: "2013-01-06 06:23:12", se elimina: 0),
(id: 23, nombre: "Sémola cocida", actualizado: "2013-02-01 14:44:21", se elimina: 0), (

nombre: "Sopa de Pescado",

actualizado: "2013-08-02 07:05:19",

Principios de actualización de datos en el dispositivo.

Si llegó un elemento que está en el dispositivo y está Eliminado = 0, entonces se actualiza
Si ha llegado un elemento que no está en el dispositivo y está Eliminado = 0, entonces se agrega
Si llegó un elemento que está en el dispositivo y está Eliminado = 1, entonces se elimina
Si llega un elemento que no está en el dispositivo y es Eliminado = 1, entonces no se hace nada

Enfoque 1: sincronizar siempre todo

Este es el método más fácil. El dispositivo solicita una lista de platos del servidor y el servidor envía la lista completa. La lista completa aparece cada vez. No ordenado.

Ejemplo de solicitud: nulo o "()"

ventajas:

la lógica en el servidor es simple: siempre damos todo
la lógica en el dispositivo es simple: siempre sobrescribimos todo

Desventajas:

si solicita la lista con frecuencia (cada 10 minutos), entonces habrá mucho tráfico en Internet
si solicita la lista rara vez (una vez al día), se violará la relevancia de los datos

Área de aplicación:

para aplicaciones de poco tráfico
transmisión de datos que cambian muy raramente (lista de ciudades, categorías)
transferir la configuración de la aplicación
al comienzo del proyecto para el primer prototipo de aplicación móvil

Enfoque 2: solo actualizado

El dispositivo solicita la lista de platos actualizada de la sincronización anterior. La lista viene ordenada por "actualizado" en orden ascendente (opcional, pero útil). El dispositivo almacena el valor "actualizado" para el plato enviado más recientemente y lo envía al servidor en el parámetro "última actualización" en la próxima solicitud. El servidor envía una lista de platos que son más nuevos que "lastUpdated" (actualizado > lastUpdated). En la primera solicitud al servidor, “lastUpdated” = null.

Ejemplo de solicitud: (última actualización: “2013-01-01 00:00:00”)

En el diagrama: “last_updated” es el valor que se almacena en el dispositivo. Por lo general, se crea una tabla separada en el dispositivo para almacenar estos valores de "última actualización" para cada entidad (platos, ciudades, organizaciones, etc.)

Este enfoque es adecuado para sincronizar listas lineales simples, que tienen las mismas reglas de llegada para el dispositivo para todos los dispositivos. Para una sincronización más selectiva, consulte Enfoque 5: sincronizar sabiendo lo que ya está en el dispositivo.

Por lo general, este enfoque cubre la mayoría de las necesidades. Solo llegan nuevos datos al dispositivo, puede sincronizar al menos cada minuto; el tráfico será pequeño. Sin embargo, existen problemas asociados con las restricciones. dispositivos móviles. Estos son la memoria y el procesador.

Enfoque 3: sincronización en fragmentos

Los dispositivos móviles tienen pocos memoria de acceso aleatorio. Si hay 3000 platos en el directorio, analizar una cadena json grande del servidor en objetos en el dispositivo puede provocar una escasez de memoria. En este caso, la aplicación fallará o no guardará esos 3000 platos. Pero incluso si el dispositivo pudo digerir dicha cadena, entonces el rendimiento de la aplicación en los momentos de sincronización en segundo plano será bajo (retrasos en la interfaz, desplazamiento no suave, etc.) Por lo tanto, es necesario solicitar el lista en porciones más pequeñas.

Para hacer esto, el dispositivo pasa otro parámetro ("cantidad"), que determina el tamaño de la porción. La lista se envía necesariamente ordenada por el campo “actualizado” en orden ascendente. El dispositivo, de manera similar al enfoque anterior, recuerda el valor "actualizado" de la última entidad enviada y lo pasa al campo "última actualización". Si el servidor envió exactamente la misma cantidad de entidades, entonces el dispositivo continúa sincronizándose y realiza una solicitud nuevamente, pero con la actualización "lastUpdated". Si el servidor envió menos entidades, significa que no tiene más datos nuevos y la sincronización finaliza.

En el diagrama: "last_updated" y "amount" son los valores que se almacenan en aplicación movil. “last_item”: la última entidad (plato) enviada desde el servidor. Es más nuevo que este valor que se solicitará la siguiente lista.

Ejemplo de solicitud: (última actualización: “2013-01-01 00:00:00”, cantidad: 100)

ventajas:

El dispositivo recibe tantos datos como puede procesar al mismo tiempo. Tamaño de la porción determinado por pruebas de práctica. Las entidades simples se pueden sincronizar 1000 a la vez. Pero también sucede que las entidades con una gran cantidad de campos y una lógica de procesamiento de guardado compleja normalmente no se sincronizan en más de 5 piezas.

Desventajas:

Si hay 250 platos con el mismo actualizado, entonces con monto = 100 los últimos 150 no se entregarán a los dispositivos. Esta situación es bastante real y se describe en el siguiente enfoque.

Enfoque 4: sincronización correcta de fragmentos

En el enfoque anterior, es posible que si hay 250 platos en la mesa con el mismo "actualizado" (por ejemplo, "2013-01-10 12:34:56") y el tamaño de la porción es 100, entonces solo el vendrán los primeros 100 registros. Los 150 restantes serán cortados por una condición estricta (actualizado > última actualización). ¿Por qué sucederá esto? Al consultar los primeros 100 registros, lastUpdated se establecerá en "2013-01-10 12:34:56" y la siguiente consulta tendrá la condición (actualizado > "2013-01-10 12:34:56"). Incluso suavizar la condición (actualizado >= “2013-01-10 12:34:56”) no ayudará, porque el dispositivo solicitará incesantemente los primeros 100 registros.

La situación con el mismo "actualizado" no es tan rara. Por ejemplo, al importar datos de Archivo de texto el campo "actualizado" se estableció en AHORA(). Importar un archivo con miles de líneas puede llevar menos de un segundo. También puede ocurrir que todo el directorio tenga el mismo “actualizado”.

Para solucionar esto, debe usar algún campo de plato que sea único al menos dentro de un momento ("actualizado"). El campo "id" es único en toda la tabla, por lo que también debe usarlo en sincronización.

En resumen, la implementación de este enfoque se ve así. El servidor devuelve una lista ordenada por "actualizado" e "id", y los dispositivos solicitan datos utilizando "lastUpdated" y el nuevo parámetro "lastId". Para el servidor, la condición de selección se vuelve más complicada: ((actualizado > último actualizado) O (actualizado = último actualizado e id > último id)).

En el diagrama: “last_updated”, “last_id” y “amount” son los valores que se almacenan en la aplicación móvil. “last_item”: la última entidad (plato) enviada desde el servidor. Es más nuevo que este valor que se solicitará la siguiente lista.

Enfoque 5: Sincronización con el conocimiento de lo que ya está en el dispositivo

Los enfoques anteriores no tienen en cuenta el hecho de que el servidor realmente no sabe con qué éxito se almacenaron los datos en el dispositivo. El dispositivo simplemente no pudo guardar algunos de los datos debido a errores inexplicables. Por lo tanto, sería bueno recibir la confirmación del dispositivo de que se han conservado todos (o no todos) los platos.

Además, el usuario de la aplicación puede configurar la aplicación de tal forma que solo necesite una parte de los datos. Por ejemplo, un usuario desea sincronizar platos de solo 2 ciudades de 10. Esto no se puede lograr con las sincronizaciones descritas anteriormente.

La idea detrás del enfoque es la siguiente. El servidor almacena (en una tabla separada "stored_item_list") información sobre qué platos hay en el dispositivo. Puede ser solo una lista de pares "id - actualizados". Esta tabla almacena todas las listas de pares de platos "id - actualizados" para todos los dispositivos.

El dispositivo envía información sobre los platos disponibles en el dispositivo (una lista de pares “id – actualizado”) al servidor junto con una solicitud de sincronización. Cuando se solicita, el servidor verifica qué platos deben estar en el dispositivo y cuáles están disponibles actualmente. Después de eso, la diferencia se envía al dispositivo.

¿Cómo determina el servidor qué platos deben estar en el dispositivo? En el caso más simple, el servidor realiza una solicitud que devolverá una lista de pares "id - actualizados" de todos los platos (por ejemplo, SELECCIONAR id, actualizado DESDE platos). En el diagrama, esto se hace mediante el método "WhatShouldBeOnDeviceMethod()". Esta es la desventaja del enfoque: el servidor tiene que calcular (a veces haciendo consultas sql pesadas) qué debería estar en el dispositivo.

¿Cómo determina el servidor qué platos hay en el dispositivo? Consulta la tabla "stored_item_list" para este dispositivo y obtiene una lista de pares "id - actualizados".

Al analizar estas dos listas, el servidor decide qué debe enviarse al dispositivo y qué debe eliminarse. En el diagrama, esto es "delta_item_list". Por lo tanto, no hay "lastUpdated" y "lastId" en la solicitud, su tarea se realiza mediante pares "id - actualizado".

¿Cómo sabe el servidor sobre los platos disponibles en el dispositivo? Agregado a la solicitud al servidor. nuevo parámetro"elementos", que contiene una lista de elementos de identificación que se enviaron al dispositivo en la última sincronización ("device_last_stored_item_list"). Por supuesto, puede enviar una lista de identificación de todos los platos que están en el dispositivo y no complicar el algoritmo. Pero si hay 3000 platos en el dispositivo y se enviarán cada vez, entonces los costos de tráfico serán muy altos. En la gran mayoría de las sincronizaciones, el parámetro "elementos" estará vacío.

El servidor debe actualizar constantemente su “stored_item_list” con los datos que provienen del dispositivo en el parámetro “items”.

Debe implementar un mecanismo para borrar los datos del servidor en lista_de_elementos_almacenados. Por ejemplo, después de reinstalar una aplicación en un dispositivo, el servidor asumirá que los datos aún están actualizados en el dispositivo. Por lo tanto, al instalar la aplicación, el dispositivo debe informar de alguna manera al servidor para que borre la lista_elementos_almacenados para este dispositivo. En nuestra aplicación enviamos parámetro adicional"clearCache" = 1 en este caso.

Conclusión

Cuadro resumen sobre las características de estos enfoques:

№	Un acercamiento	Volumen de tráfico(5 - grande)	Intensidad laboral del desarrollo(5 - alto)	Uso de la memoria del dispositivo(5 - alto)	Corrección de los datos en el dispositivo.(5 - alto)	Puede seleccionar un dispositivo específico
1	Todo está siempre sincronizado.	5	1	5	5	No
2	Sincronizado solo actualizado	1	2	5	3	No
3	Sincronización en trozos	1	3	1	3	No
4	Sincronización correcta en trozos	1	3	1	3	No
5	Sincronización con el conocimiento de lo que ya está en el dispositivo	2	5	2	5	Sí

La "corrección de datos en el dispositivo" es la probabilidad de que el dispositivo tenga todos los datos enviados por el servidor. En el caso de los enfoques n.º 1 y n.º 5, existe un 100 % de certeza de que el dispositivo tiene todos los datos que se necesitan. De lo contrario, no existe tal garantía. Esto no significa que no se puedan utilizar otros enfoques. Solo si el dispositivo tiene una parte los datos se perderán, entonces no funcionará arreglarlo desde el servidor (y más aún para aprender sobre él en el lado del servidor).

Quizás, en presencia de tarifas ilimitadas para Internet y libre problema wifi las restricciones al tráfico generado por una aplicación móvil serán menos relevantes. Pero por ahora, tenemos que recurrir a todo tipo de trucos, idear enfoques más "inteligentes" que puedan reducir los costos de la red y aumentar el rendimiento de las aplicaciones. No siempre funciona. A veces sucede “cuanto más simple, mejor”, dependiendo de la situación. Espero que este artículo pueda ayudarlo a encontrar un enfoque que le resulte útil.

Hay sorprendentemente pocas descripciones de la sincronización del servidor y dispositivos móviles. Además, hay muchas aplicaciones que funcionan según este esquema. Para los interesados, un par de enlaces.