Movil con worker

Cuando usar este modo

Es el modo correcto para:

• aplicaciones moviles que emiten en campo
• escenarios offline con posterior sincronizacion
• integraciones donde la firma depende del store seguro del dispositivo

Principio operativo

En movil no conviene depender de un proceso largo permanente como en escritorio. Lo correcto es combinar:

• una capa host visible para la experiencia de usuario
• un worker o scheduler del sistema operativo
• el cliente local embebido via FFI

Responsabilidades del host movil

• capturar datos del comprobante
• invocar prepare_draft, emit_xml o sign_only
• persistir referencias de negocio propias
• mostrar errores funcionales al usuario
• decidir si la operacion requiere envio inmediato o puede quedar pendiente

Responsabilidades del worker

• sincronizar terminal en ventanas controladas
• reservar rangos cuando el stock baja
• flush de outbox
• reintentos con backoff
• reconciliacion despues de reinicios o cortes

Recomendaciones por plataforma

Android

Usar WorkManager para:

• sync periodico
• reintentos de envio
• reconciliacion al recuperar conectividad

iOS

Usar BGTaskScheduler para:

• tareas de mantenimiento
• reintentos controlados
• refresh de parametros y estado

Flujo recomendado

1. La app hace bootstrap del runtime local.
2. Sincroniza el punto de emision al abrir o al autenticar.
3. Emite y firma localmente.
4. Persiste en outbox local.
5. Si hay conectividad, intenta flush inmediato.
6. Si no hay conectividad, el worker reintenta luego.

Consideraciones de seguridad

• usar store seguro del sistema para certificados y secretos
• no dejar passwords de P12 en texto plano en storage de la app
• proteger logs locales contra lectura casual
• auditar cada firma y cada sincronizacion relevante

Consideraciones de UX

• no bloquear la pantalla esperando una confirmacion remota si la politica permite cola offline
• distinguir claramente entre:
  • firmado localmente
  • enviado al servidor
  • confirmado por el servidor
• exponer una bandeja de pendientes y reintentos

Lo que el worker no deberia hacer

• pedir interaccion del usuario en segundo plano
• depender de pantallas abiertas
• asumir conectividad estable
• ejecutar render pesado de PDF si la politica del dispositivo lo penaliza

Criterio de cierre

Un despliegue movil esta bien cerrado cuando:

• puede firmar y persistir sin conectividad
• reintenta luego de forma segura
• no pierde folios por reinicios
• usa el store seguro de la plataforma
• el usuario entiende el estado real del comprobante