Codename One añade continuidad entre dispositivos y arrastrar y soltar nativo
El framework open source para Java y Kotlin estrena el módulo com.codename1.continuity, que reconstruye la pila de navegación en otro equipo, y el drag and drop nativo, todo en el PR 5663.
Codename One, el framework open source que compila apps nativas para iOS, Android, escritorio y web desde una sola base de código Java o Kotlin, ha añadido continuidad entre dispositivos y arrastrar y soltar nativo. Ambos cambios llegan en el mismo pull request 5663. El planteamiento de fondo es el mismo en los dos casos: separar el dato útil de la pantalla que lo está mostrando.
Continuidad: el estado, no la pantalla
El módulo com.codename1.continuity serializa la pila de rutas del router y la reconstruye en otro dispositivo sin animar por todas las pantallas intermedias. Para que la tarea se retome de verdad hace falta un StateProvider que devuelva un mapa con los datos de la aplicación —el texto del borrador, por ejemplo— y sepa volver a aplicarlos. El mapa debe describir estado reconstruible: nada de objetos de UI ni credenciales viajando a otro equipo, y conviene decidir de forma explícita si el contenido sensible entra ahí.
El framework lanza un checkpoint una vez por pasada del event loop y en cada navegación. Las ediciones que no navegan pueden pedirlo a mano con Continuity.checkpoint(). Guardar de forma continua evita que el único momento de persistir sea el apagado, o un callback de suspensión que puede estar bloqueando un hilo de plataforma.
La restauración es explícita: Continuity.restore() se llama cuando la autenticación y el registro de rutas han terminado. Una ruta restaurada identifica trabajo, no autoriza a acceder a él; la app tiene que comprobar que la cuenta activa puede abrir ese documento.
Para transportar el checkpoint hay tres vías. El estado local y la pila de rutas funcionan en iOS, macOS, Android, escritorio y simulador, y JavaScript. La continuación entre dispositivos Apple va por Handoff. La sincronización clave-valor usa iCloud y vive en com.codename1.continuity.sync, que exige el entitlement correspondiente en el App ID de Apple; la restauración básica y Handoff no lo necesitan. El relé propio se apoya en StateRelay, con RestStateRelay como punto de partida HTTP: el endpoint, las cuentas, la retención y los conflictos entre checkpoints los decide quien despliega. Continuity.isContinuationSupported() comprueba si la plataforma ofrece la facilidad.
Se puede desactivar la restauración automática con setAutoRestore(false) y ofrecer al usuario la elección; al rechazar una actividad conviene llamar a Continuity.acknowledge(state) para que el mismo estado sin cambios no vuelva a ofrecerse en cada arranque. setMaxAge limita la antigüedad de los checkpoints, algo que tiene sentido en un checkout o una confirmación, donde precios y disponibilidad caducan. Al cerrar sesión toca llamar a clear() y a disable(): limpiar sin desactivar deja la puerta abierta a que una actividad posterior restaure la ruta de la cuenta anterior encima del login. Ninguna de las dos operaciones sustituye la revocación de credenciales en el servidor.
Arrastrar y soltar
El otro añadido ofrece el contenido —un documento, una imagen, una selección— a otra aplicación a través del sistema operativo, y arranca igual: describir el dato al margen de la vista. No hay por ahora detalle de la matriz de plataformas ni de cómo se negocia el tipo de dato con la aplicación receptora.
Los ejemplos de la guía cubren el relé, la confirmación del usuario, la caducidad y el cierre de sesión, y el builder de Apple unifica las declaraciones de continuidad y App Intents en un único NSUserActivityTypes. Quien tenga la app repartida entre varias cuentas va a tener que decidir qué entra en el mapa de estado y cuánto tiempo vive, y eso es diseño de aplicación, no algo que resuelva el framework.
