Applicazioni 4D senza testa

Come sviluppatori 4D, potreste aver già incontrato la necessità di sviluppare applicazioni senza interfaccia grafica (GUI), altrimenti note come applicazioni headless. In precedenza, in 4D non era possibile farlo …. fino a 4D v18! In questo post del blog, esamineremo alcune delle nuove funzionalità disponibili per rendere le vostre applicazioni “senza testa”!

Perché creare applicazioni headless? Ci sono diversi casi d’uso, come ad esempio simulare il comportamento di Windows su macOS, o avere il comportamento dei servizi di Windows senza usare il service manager, e così via. Ma soprattutto, si aprono nuove opportunità come lo sviluppo di bot con 4D.

Come lanciare un’applicazione 4D in modalità headless?

È ora possibile lanciare un’applicazione 4D in modalità headless tramite la CLI (Command Line Interface) con il nuovo parametro“headless“. Disponibile per tutti i tipi di applicazione: 4D, 4D Server, applicazioni standalone, remote e unite. Negli esempi che seguono, la directory corrente è quella dell’eseguibile.

Esempi macOS (quando il terminale è collocato nella cartella “Contents/MacOS” del bundle):

Esempi di Windows:

Abbiamo aggiunto un nuovo attributo “headless” all’oggetto restituito dal comando Get application info . Rende molto più semplice la codifica a seconda della modalità di esecuzione: con o senza interfaccia.

Nota: ora, quando si esegue un’applicazione in modalità servizio sui sistemi Windows, questa viene automaticamente eseguita come applicazione senza testa. L’arresto del servizio chiude l’applicazione 4D nel modo corretto (ad esempio, utilizzando l’azione “Esci” nel monitor attività di macOS).

Cosa succede durante l’esecuzione?

Vi starete chiedendo: “Ok, è divertente, ma cosa succede se doveva apparire una finestra di dialogo?”. Per tenervi informati su ciò che accade in fase di esecuzione, 4D attiva automaticamente i log diagnostici quando viene eseguito in modalità headless. I registri catturano tutte le interfacce utente che avrebbero potuto essere visualizzate e le registrano con il tag [{applicationName}.HDLS].

Il comportamento generale è che 4D cattura i comandi che cercano di visualizzare qualcosa, registra un evento di avviso con il nome del comando e la sua catena di chiamate e annulla l’azione. Esistono alcuni casi speciali:

• Se non è disponibile alcuna licenza, 4D lo registra nel registro degli eventi di sistema e nei flussi standard, quindi si chiude.
• Se il database deve essere convertito, 4D lo segnala nel registro degli eventi di sistema e nei flussi standard, quindi esce.
• Se non è stato trovato un database o un file di dati disponibile, 4D lo registra nel registro degli eventi di sistema e nei flussi standard, quindi esce.
• Quando è necessario visualizzare il debugger, 4D registra un errore e simula l’azione “interrompi”.
• Quando appare un avviso, 4D registra e simula l’azione “OK”.
• Quando viene richiamato il comando QUIT 4D, 4D registra e simula l’azione “OK”.
• Quando un’applicazione unita deve essere aggiornata, viene generato un log, l’aggiornamento viene eseguito e l’applicazione viene riavviata in modalità headless.

Esempio

Ad esempio, un comando ALERT eseguito su un server eseguito come servizio su Windows non interromperà più l’esecuzione del server. 4D rileva automaticamente il comando e scrive una riga di avviso nei registri di diagnostica. L’aspetto è il seguente:

Questo sistema è stato creato per aiutarvi a vedere cosa succede nelle vostre applicazioni headless e a migliorare il vostro codice (se necessario).

UTILIZZARE I FLUSSI STANDARD DEL SISTEMA

Abbiamo aggiunto il nuovo selettore Into system standard outputs al comando LOG EVENT in modo da poter inviare un testo agli stream standard stdout e stderr. Come forse sapete, il comando LOG EVENT ha un parametro opzionale“importanza“. Quindi, a seconda dell’importanza dell’evento, il comando invierà il testo allo stream stdout per Information message e Warning message, e allo stream stderr per Error message.

Inviare il testo a stdout:

LOG EVENT(Into system standard outputs; "Questo è un testo per stdout";Information message)

Inviare il testo a stderr:

LOG EVENT(Into system standard outputs; "Questo è un testo per stderr";Error message)

È inoltre possibile utilizzare i reindirizzamenti per i flussi standard del sistema stdout e stderr per recuperare le informazioni generate da 4D e dall’applicazione. Per impostazione predefinita, questi flussi sono generalmente diretti alla console, raramente allo schermo, a seconda delle impostazioni del sistema. Ad esempio, è possibile reindirizzare i flussi standard ai file utilizzando le seguenti righe di comando.

macOS:

Windows:

Promemoria per le combinazioni di reindirizzamento del flusso:

• 1>outputFile: il flusso di output standard verrà scritto nel file invece dell’output predefinito del sistema. Il file viene creato automaticamente all’avvio del comando. Se esiste già, il vecchio contenuto viene cancellato.
• 1>>outputFile: stesso comportamento della sintassi precedente, tranne per il fatto che se il file esiste già, viene aggiunto al contenuto del flusso.
• 2>errorFile: il flusso di errore standard verrà scritto nel file invece dell’output predefinito del sistema. Il file viene creato automaticamente all’avvio del comando. Se esiste già, il vecchio contenuto viene cancellato.
• 2>>errorFile: stesso comportamento della sintassi precedente, ma se il file esiste già, viene aggiunto il contenuto del flusso.
• 2>&1: il flusso di errore viene unito al flusso di uscita.
• 1>&2: il flusso di uscita viene unito al flusso di errore.

Nota: è anche possibile usare il comando open per eseguire un pacchetto 4D su un sistema macOS, i flussi saranno generati da questo comando e non dall’applicazione 4D!

Conclusione

Questi nuovi progressi consentono di soddisfare i requisiti di sistema e di creare nuove opportunità, come i bot. Sta a voi combinare tutto questo con i canali di integrazione continua (CI) e di test continuo (CT) per la vostra fabbrica di software. L’unico limite è la vostra immaginazione!