Aplicaciones 4D sin cabeza

Como desarrollador 4D, es posible que ya se haya encontrado con la necesidad de desarrollar aplicaciones sin interfaz gráfica de usuario (GUI), también conocidas como aplicaciones headless. ¡Anteriormente en 4D, esto no era del todo posible de hacer …. hasta 4D v18! En esta entrada del blog, repasaremos algunas de las nuevas capacidades disponibles para que pueda hacer sus aplicaciones «headless».

¿Por qué crear aplicaciones sin cabeza? Hay varios casos de uso, como simular el comportamiento de Windows en macOS, o tener el comportamiento del servicio de Windows sin usar el administrador de servicios, etc. Pero sobre todo, abre nuevas oportunidades como el desarrollo de bots con 4D.

¿Cómo lanzar una aplicación 4D en modo headless?

Ahora puede lanzar una aplicación 4D en modo headless a través de la CLI (Command Line Interface) con el nuevo parámetro«headless«. Disponible para todos los tipos de aplicaciones: 4D, 4D Server, aplicaciones autónomas, remotas y fusionadas. En los ejemplos siguientes, el directorio actual es el directorio ejecutable.

Ejemplos de macOS (cuando el terminal se coloca en la carpeta «Contents/MacOS» del bundle):

Ejemplos de Windows:

Hemos añadido un nuevo atributo «headless» al objeto devuelto por el comando Get application info comando. Facilita mucho la codificación en función del modo de ejecución: con o sin interfaz.

Nota: Ahora, cuando se ejecuta una aplicación en modo servicio en sistemas Windows, se ejecuta automáticamente como una aplicación headless. Al detener el servicio se cierra la aplicación 4D de la forma correcta (por ejemplo, utilizando la acción «Salir» en el monitor de actividad de macOS).

¿Qué sucede durante la ejecución?

Puede que se pregunte : «Vale, es divertido, pero ¿qué pasa si se supone que aparece un diálogo?». Para mantenerle informado de lo que ocurre en tiempo de ejecución, 4D activa automáticamente los registros de diagnóstico cuando se ejecuta en modo headless. Los registros capturan todas las interfaces de usuario que podrían haber sido mostradas y las registra con la etiqueta [{applicationName}.HDLS].

El comportamiento general es que 4D captura los comandos que intentan mostrar algo, registra un evento de advertencia con el nombre del comando y su cadena de llamadas, y cancela la acción. Hay algunos casos especiales:

• Si no hay licencia disponible, 4D lo registra en el registro de eventos del sistema y en los flujos estándar, y luego se cierra.
• Si la base de datos necesita ser convertida, 4D lo registra en el registro de eventos del sistema y en los flujos estándar, y luego se cierra.
• Si no se ha encontrado ninguna base de datos o archivo de datos disponible, 4D lo registra en el registro de eventos del sistema y en los flujos estándar, y luego se cierra.
• Cuando el depurador necesita ser mostrado, 4D registra un error y luego simula la acción de «abortar».
• Cuando aparece una alerta, 4D registra y luego simula la acción «OK».
• Cuando se llama al comando QUIT 4D, 4D registra y luego simula la acción «OK».
• Cuando una aplicación fusionada necesita ser actualizada, se genera un registro, se realiza la actualización y la aplicación se reinicia en modo headless.

Ejemplo

Por ejemplo, un comando ALERT ejecutado en un servidor que se ejecuta como servicio en Windows ya no detendrá la ejecución del servidor. 4D capta automáticamente el comando y escribe una línea de advertencia en los registros de diagnóstico. El aspecto es el siguiente

Este sistema ha sido creado para ayudarte a ver lo que ocurre en tus aplicaciones headless, y mejorar tu código (si es necesario).

UTILIZAR LOS FLUJOS ESTÁNDAR DEL SISTEMA

Hemos añadido el nuevo selector, Into system standard outputs, al comando LOG EVENT para poder enviar un texto a los flujos estándar stdout y stderr. Como ya sabrás, el comando LOG EVENT tiene un parámetro opcional de«importancia«. Así, dependiendo de la importancia del evento, el comando enviará el texto al flujo stdout para Information message y Warning message, y al flujo stderr para Error message.

Envía el texto a stdout:

LOG EVENT(Into system standard outputs; "Este es un texto para stdout";Information message)

Enviar el texto a stderr:

LOG EVENT(Into system standard outputs; "Este es un texto para stderr";Error message )

También puede utilizar redirecciones para los flujos estándar del sistema stdout y stderr para recuperar la información generada por 4D y su aplicación. Por defecto, estos flujos se dirigen generalmente a la consola, raramente a la pantalla, dependiendo de la configuración del sistema. Por ejemplo, puede redirigir los flujos estándar a archivos utilizando las siguientes líneas de comando.

macOS:

Windows:

Recordatorio para las combinaciones de redirección de flujos:

• 1>archivo de salida: el flujo de salida estándar se escribirá en el archivo en lugar de la salida por defecto del sistema. El archivo se crea automáticamente al iniciar el comando. Si ya existe, se borra el contenido antiguo.
• 1>>outputFile: mismo comportamiento que la sintaxis anterior, excepto que si el archivo ya existe, se añade al contenido del flujo.
• 2>errorFile: el flujo de error estándar se escribirá en el archivo en lugar de la salida por defecto del sistema. El archivo se crea automáticamente al iniciar el comando. Si ya existe, se borra el contenido antiguo.
• 2>>errorFile: mismo comportamiento que la sintaxis anterior, excepto que si el archivo ya existe, se añade el contenido del flujo.
• 2>&1: el flujo de error se fusiona con el flujo de salida.
• 1>&2: el flujo de salida se fusiona con el flujo de error.

Nota: incluso es posible utilizar el comando open para ejecutar un paquete 4D en un sistema macOS, ¡los flujos serán generados por este comando y no por la aplicación 4D!

Conclusión

Estos nuevos avances le permiten cumplir con los requisitos del sistema y también crear nuevas oportunidades, como los bots. Depende de usted combinar esto con sus canales de integración continua (CI) y pruebas continuas (CT) para su fábrica de software. El único límite es su imaginación.