Empaquetado híbrido y nativo

Elige cómo llega FieldOps a las personas que lo utilizan. Los despachadores pueden trabajar en un navegador, mientras que los técnicos necesitan opciones de entrega adaptadas a los dispositivos y conexiones poco confiables. La primera decisión es sobre su trabajo, antes de elegir un paquete.

Compare cuatro clientes que se conectan al mismo servidor Wisej.NET. Un navegador o una aplicación web progresiva utiliza capacidades web; un shell WebView2 de escritorio o un shell móvil híbrido Wisej.NET agrega un host que puede exponer las características nativas del dispositivo.

Evalúe el comportamiento fuera de línea, el acceso a los dispositivos, la distribución, las actualizaciones y los costos en conjunto. Un cambio de servidor puede llegar a todos rápidamente, mientras que un shell firmado tiene una ruta de lanzamiento más larga. Esa diferencia afecta qué responsabilidades deben permanecer en el servidor.

Mantenga cada shell enfocado en alojar el motor del navegador y exponer las características del dispositivo. Las pantallas compartidas y el comportamiento empresarial permanecen en una implementación de servidor. Las carcasas delgadas reducen la cantidad de trabajo específico de la plataforma que debe mantener y publicar por separado.

Pregúntele al anfitrión qué admite antes de mostrar una acción del dispositivo. Al verificar solo Android no se puede distinguir un navegador simple de un shell compatible. Una verificación de capacidad vincula el comando disponible a una implementación real en lugar de a una etiqueta de plataforma.

Resuelva las capacidades una vez para la sesión y deje que todas las pantallas usen ese resultado. Mantenga las reglas de cambio de estado en WorkOrderService, donde cada cliente sigue el mismo comportamiento. Las diferencias de dispositivos deberían cambiar las acciones disponibles sin duplicar las reglas comerciales.

Los cuatro clientes muestran la misma lista de órdenes de trabajo desde un servidor. Tenga en cuenta que Tomar foto aparece solo en el teléfono con la capacidad indicada. La diferencia proviene de la información de capacidad de la sesión, mientras que la pantalla compartida sigue siendo la misma.

Cuando la conectividad disminuye, distinga la información almacenada en caché del trabajo en vivo. El shell y el último resumen sincronizado permanecen disponibles, pero no se puede cargar un pedido invisible. El estado de cola se identifica explícitamente para que el técnico no lo confunda con una actualización completa del servidor.

Cree la lista inicial, los detalles y el flujo de trabajo de estado en el navegador. Luego documente qué objetivos de entrega respaldará, su pedido y las comprobaciones de capacidad y los criterios de aceptación. La versión funcional del navegador se convierte en la base compartida para shells posteriores.

Haga que FieldOps sea instalable manteniendo honesta su promesa fuera de línea. El técnico obtiene un ícono y una ventana separada, pero la interfaz aún depende de una sesión del servidor Wisej.NET. La página sin conexión debe explicar qué queda disponible cuando esa conexión desaparece.

Siga al técnico desde la conectividad del depósito hasta una habitación sin señal. El almacenamiento en caché del shell de la aplicación ayuda a abrirla, pero no conserva una sesión Wisej.NET activa. Diseñe la experiencia fuera de línea alrededor de ese límite en lugar de tratar los archivos almacenados en caché como un servidor en ejecución.

Conecte las piezas de instalación: una conexión segura, el manifiesto vinculado desde Default.html, el trabajador de servicio registrado y el evento de instalación capturado. Mantener ese evento permite que la página ofrezca la instalación más adelante, cuando el usuario lo elija deliberadamente.

Proporcione rutas diferentes a los archivos de shell y al tráfico de sesiones. El trabajador puede servir activos de shell conocidos desde la memoria caché, pero las solicitudes de sesión deben llegar a la red. Si la navegación no puede llegar al servidor, muestre la página guardada sin conexión en lugar de reproducir las respuestas de la sesión.

En el trabajador, haga coincidir una lista de archivos de shell explícita y omita las solicitudes que no sean de lectura. Restrinja el recurso sin conexión a la navegación. Estas reglas evitan que las respuestas almacenadas en caché de una sesión caducada se presenten como si la sesión actual hubiera respondido.

Versione el caché para que la actualización tenga un destino claro. El trabajador activa y toma el control a través de sus métodos de ciclo de vida, mientras el servidor escribe el resumen fuera de línea. Ofrezca la instalación solo después de que una sesión exitosa haya demostrado que FieldOps funciona.

Verifique el manifiesto, el trabajador y los nueve archivos de shell en caché antes de aceptar la oferta de instalación. El propio clic de la página invoca el mensaje almacenado. Luego, FieldOps se abre en su ventana independiente, mostrando que la instalación cambia la experiencia de inicio en lugar de mover el servidor al teléfono.

Sin señal, lea el resumen almacenado en caché y su hora de sincronización. Los cambios de estado están deshabilitados en esta versión, por lo que nada sugiere que hayan estado en cola. Cuando vuelve la conectividad, la barra de recarga le da al técnico control sobre el regreso a la aplicación en vivo.

Entregue el manifiesto, los íconos, el trabajador versionado y el resumen fuera de línea como una sola experiencia de instalación. Pruebe la oferta de la primera sesión y la ruta de actualización. Confirme que se eliminen los cachés antiguos para que el próximo lanzamiento no siga usando un shell obsoleto.

Envuelva la aplicación FieldOps existente en un host de escritorio para los técnicos que la utilizan durante un turno. La ventana, la integración de la bandeja y el instalador pertenecen al shell, mientras que las pantallas familiares continúan viniendo de la aplicación Wisej.NET.

Utilice el host WebView2 para proporcionar la integración de escritorio que esta entrega necesita: un ícono de inicio, notificaciones en la bandeja, un selector de carpeta nativo y un paquete instalable. Estas adiciones rodean la aplicación existente, por lo que no requieren duplicar sus pantallas.

Siga la solicitud de carpeta a través del límite. El servidor invoca JavaScript, la página envía mensajes WebView2 y el host abre el diálogo nativo. Su respuesta estructurada regresa a través de un evento de cliente a C sharp, completando una solicitud que abarca ambos procesos.

Verifique IsDesktopShell antes de enviar el comando del host, luego haga coincidir el identificador de respuesta con la solicitud. El shell maneja la selección de carpetas y la notificación de bandeja por separado. Correlacionar la respuesta garantiza que una respuesta no relacionada no pueda proporcionar el destino de la exportación.

Elija la ubicación del servidor como parte de la implementación. Un servidor remoto centraliza la aplicación; un proceso local en la computadora portátil proporciona el respaldo para el trabajo desconectado. La sonda de lanzamiento selecciona la ruta y hace que esa elección sea visible para el técnico.

Lea la configuración de inicio y pruebe el estado del servidor antes de iniciar el respaldo local. Detenga ese proceso local cuando salga el shell. Mantenga la verificación de actualización sin bloqueo, de modo que una búsqueda de versión fallida no impida que el técnico comience a trabajar.

Exportar demuestra el recorrido completo de ida y vuelta: elija una carpeta nativa, devuelva su ruta con el identificador coincidente y luego escriba el informe. La notificación de asignación ejerce el otro sentido, volviendo a abrir la ventana sobre el pedido correspondiente cuando el técnico responde.

Pruebe una computadora portátil recién preparada donde el tiempo de ejecución WebView2 aún no esté presente. El instalador lo proporciona, la sonda con tiempo de espera agotado selecciona el servidor local y la tira fuera de línea explica el modo. Se ofrece una actualización disponible sin interrumpir el trabajo actual.

Ofrezca la ventana del escritorio y la integración de la bandeja junto con la carpeta y el puente de notificaciones. Configure el servidor remoto y el respaldo local, luego verifique la instalación y la oferta de actualización en el momento del lanzamiento. El resultado debería ser una entrega de escritorio completa, no solo una página alojada.

Aloje FieldOps en un pequeño shell móvil nativo manteniendo las pantallas de su servidor existente. Los proyectos Android y iOS agregan alojamiento de dispositivos y comportamiento del ciclo de vida. Permitieron que la misma aplicación Wisej.NET llegara a los usuarios móviles sin recrear sus formularios para cada plataforma.

El host móvil debe encargarse de algo más que mostrar una página. Puede suspenderse durante una lectura, ocupar una pantalla con un notch o recibir un gesto hacia atrás. Planifique estas interrupciones y comportamientos de navegación junto con la instalación y las funciones del dispositivo.

El proyecto nativo contiene una vista web de plataforma conectada de forma segura al servidor FieldOps. Un cambio de caparazón sigue al proceso de lanzamiento de la tienda; Los cambios en la aplicación alojada permanecen en el servidor. Mantener este límite claro evita reconstruir el shell para cambios normales de pantalla.

Lea la secuencia del ciclo de vida como un escenario de pausa y retorno. La aplicación puede desactivarse, detenerse, reanudarse y activarse nuevamente mientras el técnico está ausente. La supervivencia de la sesión original depende del tiempo transcurrido, por lo que la reanudación necesita una decisión explícita.

No recargue la dirección automáticamente en cada currículum. Guarde el estado relevante cuando el host se detenga, luego decida si desea volver a conectarse a la sesión o recargar y reabrir la orden de trabajo guardada. Esto preserva la continuidad sin asumir que todavía existe una sesión caducada.

Enrute el gesto de retroceso a FieldOps e informe que el host lo manejó. Aplique el acolchado del área segura desde los insertos reales de la plataforma. Estas responsabilidades pertenecen al host, por lo que las pantallas de los servidores individuales no necesitan desplazamientos de píxeles específicos del dispositivo.

Ejecute la compilación Android en su emulador y la compilación iOS a través de la ruta del simulador de Mac. Ambos cargan el mismo servidor FieldOps. Compare sus pantallas de órdenes de trabajo para confirmar que los objetivos nativos comparten la aplicación en lugar de llevar implementaciones de pantalla separadas.

La llamada entrante interrumpe una lectura, por lo que el controlador de parada guarda el borrador y el tiempo. Al regresar, ciento setenta y cuatro segundos todavía están dentro del tiempo de espera de seiscientos segundos. La reconexión restaura el mismo orden sin pedirle al técnico que vuelva a escribir la lectura.

Cree objetivos móviles y pruebe el entorno con el mismo cuidado que el primer lanzamiento. Incluya recuperación de sesión, navegación hacia atrás y manejo de área segura. Capture la lista de órdenes de trabajo en ambos emuladores para que la entrega demuestre la experiencia compartida en cada plataforma.

Conecte las acciones FieldOps a las funciones nativas del dispositivo a través del puente de shell. El técnico puede fotografiar equipos o capturar una firma, mientras los controles Wisej.NET permanecen en el servidor. El puente transporta la solicitud y devuelve el resultado final del dispositivo.

Rastree la solicitud de la cámara desde el servidor, a través de la página, hasta el objeto host. El resultado llega más tarde como un evento, después de que haya regresado el comando original. Presione el cambio de interfaz resultante con Application.Update para que el técnico vea la acción completada.

Utilice el descriptor de capacidad informado al inicio de la sesión para elegir las acciones disponibles. El nombre de la plataforma de un navegador no prueba que exista el puente nativo. Cuando ese puente no está disponible, Upload aún proporciona la ruta basada en el navegador para seleccionar o capturar una imagen.

Explique por qué se necesita acceso cuando el usuario elige la acción y luego solicite permiso. Trate lo concedido, lo denegado temporalmente y lo denegado permanentemente como resultados diferentes. Abrir repetidamente el mismo mensaje no puede resolver una denegación permanente y solo bloquea el flujo de trabajo.

El controlador de clics verifica la compatibilidad, crea un token de solicitud y regresa de inmediato. Posteriormente, OnShellResult verifica que la respuesta sigue siendo relevante, maneja la cancelación y almacena datos de imágenes exitosas. Hacer coincidir el token evita que una respuesta anterior actualice el estado incorrecto.

Para la ruta del navegador, cambie el tamaño de la imagen cargada antes de almacenarla fuera de ubicaciones de acceso público. La navegación explica por separado su solicitud de ubicación. Si se rechaza el permiso, acepte una dirección escrita para que completar la ruta no dependa de otorgar acceso a la ubicación.

Mira la carcasa Android completa con dos fotografías y una firma. Cada operación aparece como una llamada puente independiente en el registro. El clic original ya regresó antes de que llegaran los datos, lo que confirma que las operaciones del dispositivo se completan de forma asincrónica a través de sus eventos de resultados.

Abra la misma pantalla en un navegador simple y compare sus acciones disponibles. Cargar reemplaza el comando de cámara nativa no compatible. Rechazar la ubicación, ingresar una dirección y continuar la ruta; el respaldo conserva la tarea incluso cuando el acceso al dispositivo no está disponible.

Implemente las acciones de fotografía, firma, navegación y notificación de asignación con sus reglas de capacidad. Incluya las rutas de reserva de carga del navegador y de permiso denegado. La matriz de capacidades debe explicar por qué cada cliente ofrece sus acciones particulares y cómo continúa el usuario cuando falla el acceso.

Prepare FieldOps para su entrega más allá de las máquinas de desarrollo. Un servidor admite cuatro formularios de cliente, pero cada uno de los tres paquetes nativos necesita una identidad de firma aceptada. Por lo tanto, la preparación para el lanzamiento incluye distribución y compatibilidad, así como pantallas de aplicación en funcionamiento.

Una implementación exitosa del servidor no garantiza un lanzamiento exitoso. Un editor de escritorio desconocido, un perfil móvil caducado o un shell antiguo que llama a un método eliminado aún pueden bloquear a los técnicos. Revise estos puntos de falla independientes antes de completar la implementación.

Trate la identidad de firma de cada plataforma como prueba de origen. Windows utiliza su certificado y marca de tiempo, Android su clave de carga y servicio de firma, y ​​Apple su certificado y perfil de distribución. La firma identifica al editor; no reemplaza las pruebas de compatibilidad.

Elija el canal de distribución por separado para cada plataforma nativa: tiendas administradas, administración de dispositivos o una descarga firmada. En cambio, el navegador y la entrega progresiva de aplicaciones web siguen la ruta de implementación web. El canal determina cómo los técnicos reciben y actualizan realmente el paquete.

Aplique la versión del shell cuando se inicie la sesión en lugar de simplemente mostrarla. AdmitShell compara la versión reportada con el mínimo de la plataforma y registra el resultado en estado de sesión. El servidor puede entonces admitir, advertir o solicitar una actualización de forma deliberada.

Reúna pruebas de ambos lados de la frontera. Una biblioteca de informes de fallas dentro del shell detecta fallas que el servidor no puede ver. Los eventos de características del dispositivo agregan resultados, plataforma y versión de shell, lo que ayuda a distinguir un problema de integración de dispositivos de un problema del lado del servidor.

Compare los tres clientes que llegan al servidor actualizado. El escritorio continúa, iOS recibe un aviso de descarte y el antiguo shell Android se detiene en la pantalla de actualización. La verificación se realiza antes de cargar los pedidos, por lo que un cliente incompatible no puede iniciar el flujo de trabajo.

Utilice una fila de la lista de verificación de lanzamiento por ruta de entrega para que ningún paquete se oculte detrás de la implementación exitosa del servidor. Revise los eventos de denegación de ubicación como evidencia del flujo de trabajo: una solicitud de permiso realizada demasiado pronto necesita un cambio de tiempo en lugar de asumir que la función de ubicación no funciona.

Complete el final con paquetes firmados, canales empresariales elegidos y un listado preliminar. Agregue comprobaciones de compatibilidad de inicio e informes de uso y fallos. Entregue la lista de verificación de lanzamiento para que otra persona pueda verificar las rutas de entrega, actualización y recuperación para cada cliente.