Gestire lo stato dell'app

In egui, lo stato dell’applicazione è costituito da normali dati Rust che risiedono nella struct che implementa eframe::App. Non esiste un archivio speciale né un modello gestito dal framework.

I campi contengono tutto: valori dei moduli, selezioni, dati caricati e flag. A ogni frame, update legge e modifica direttamente questi campi tramite &mut self.

eframe crea l’applicazione all’interno di una closure passata a run_native. Il modello più semplice consiste nell’usare #[derive(Default)] e creare l’istanza con App::default().

Per valori iniziali non predefiniti, implementi manualmente Default oppure aggiunga un costruttore che riceva il CreationContext per configurazioni come font o persistenza.

Poiché i widget prendono in prestito con &mut i campi a cui si appoggiano, la struct è sempre l’unica fonte di verità. Non esiste uno stato separato della vista da mantenere sincronizzato.

Una casella di controllo collegata a &mut self.enabled riflette e aggiorna direttamente quel valore booleano: se lo legge in un altro punto dello stesso frame, vede il valore aggiornato.

Un problema sottile dei prestiti si presenta quando si itera su un Vec mentre si desidera rimuovere un elemento. Non è possibile modificare il vettore finché è attivo un prestito condiviso.

La soluzione consiste nel registrare l’azione desiderata in una variabile locale durante il ciclo e applicarla dopo la fine del ciclo.

Per le applicazioni con più schermate, modelli la vista corrente come un campo di tipo enum. Il metodo update esegue il match su questo campo per decidere cosa disegnare.

In questo modo la navigazione è esplicita ed esaustiva: il compilatore obbliga a gestire ogni schermata, eliminando intere categorie di errori di instradamento.

Alcuni stati riguardano esclusivamente la UI, non il dominio dell’applicazione: sezioni compresse, posizioni di scorrimento e stato del trascinamento. egui li memorizza in ctx.memory, indicizzandoli tramite l’Id del widget.

Raramente dovrà accedervi direttamente, ma ctx.data_mut consente di memorizzare piccoli valori associati a un id, persistenti tra i frame, senza appesantire la struct dell’applicazione.

Non blocchi mai update con operazioni I/O lente: il ciclo a 60 fps si bloccherebbe. Avvii un thread e comunichi tramite un channel std::sync::mpsc.

Il worker invia indietro i risultati; a ogni frame, update svuota il receiver senza bloccare usando try_recv. Chiami ctx.request_repaint() dal worker, così la UI si ridisegna quando arrivano nuovi dati.

Cloni Context e il sender all’interno del thread. La copia è economica: internamente è un Arc e consente al worker di richiedere il ridisegno.

Sposti la proprietà degli input del lavoro nella closure, così da soddisfare il borrow checker ed evitare problemi di durata dei prestiti.

eframe può serializzare l’applicazione tra un’esecuzione e l’altra. Abiliti la feature persistence, derivi serde::Serialize / Deserialize e implementi App::save.

All’avvio, legga lo stato salvato da cc.storage nel costruttore, ricorrendo ai valori predefiniti quando non è stato memorizzato nulla.

Poiché update viene eseguito a ogni frame, eviti di ricalcolare al suo interno dati derivati costosi. Memorizzi i risultati nei campi e li ricalcoli solo quando cambiano gli input.

Un modello comune consiste nel tenere traccia di un flag dirty impostato da Response::changed() e ricostruire le cache all’inizio di update solo quando il flag è attivo.

Il tema ricorrente è questo: egui si affida alla proprietà di Rust per gestire lo stato, invece di usare framework appositi. La struct possiede i dati, &mut self concede l’accesso esclusivo per ogni frame e i thread comunicano tramite channel.

Non ci sono sottoscrizioni nascoste né grafi di callback, quindi è possibile ragionare in modo locale ed esplicito su quando e come cambia lo stato.

Come dovrebbe eseguire un recupero lento dalla rete?

Lo stato dell’applicazione è costituito da normali campi della struct eframe::App, modificati tramite &mut self a ogni frame; la struct diventa così l’unica fonte di verità.

Rimandi le modifiche durante l’iterazione, modelli le schermate con gli enum, deleghi il lavoro lento ai thread tramite channel e renda persistente lo stato usando l’archiviazione di eframe. Mantenga leggero update memorizzando nella cache i dati derivati e controllandoli con flag di modifica. Prossimo argomento: preparare l’applicazione per la distribuzione.