Ci sono situazioni in cui le nostre applicazioni necessitano di una serie di Form per poter guidare l'utente verso una ben precisa UI (User Interface). E' il classico caso in cui all'inizio dell'applicazione, all'utente vengono proposte alcune opzioni di configurazione e un bottone "Next" tramite il quale si finisce in un'altra Form in cui vengono prese altre decisioni. Così via fino a che l'utente non giunge in una Form definitiva in cui c'è l'applicazione vera e propria. Devo dire che mi sono trovato spesso in situazioni del genere e la soluzione migliore che ho avuto modo di implementare è quella di evitare di avere troppe Form (che appesantiscono la memoria dell'applicazione e quindi anche le performance) e di usare al loro posto dei Component che avessero la stessa "faccia" delle Form, ma che una volta caricati tutti sulla Form principale, venivano visualizzati uno alla volta secondo la posizione corrente della navigazione.
Partiamo dalla classica situazione di un'applicazione con diverse Form. Nella mia "solution" di cui potrete fare il download, ci sono due progetti SmartDevice. Il primo chiamato AppWithForm. Ovviamente è il caso in cui si utilizzano più form per implementare l'applicazione. Vedremo il secondo caso successivamente.
Il primo progetto contiene 3 form le quali servono rispettivamente per impostare il primo set di variabili dell'applicazione, impostare il secondo set di variabili e infine a presentare la vera e propria UI dell'applicazione. Guardiamo in figura le UI di ciascuna form:

Prima Form
Naturalmente nella prima form (e lo troverete nel codice) il bottone di BACK è invisibile.

Seconda Form
C'è una piccola sbavatura che è aggiustata nel codice. Nelle variabili della form2 si ripete per due volte il LastName (Barba) invece che FirstName e LAstNAme (Gianni Barba :-) ).
In pratica nella prima form si impostano il nome, il cognome e lo stato di appartenenza . Al Next si passa alla form2 passandogli i dati impostati nella form1, ma lasciandoli ovviamente 'readonly'. Se si decide di tornare indietro ritorneremmo alla form1 impostando uovamente questi valori. Se nella form2 si va avanti con Next finalmente otteniamo la UI dell'applicazione vera e propria:

UI Applicazione
Ora questa situazione si può comunque ritrovare in maniera del tutto analoga in situazioni in cui l'utente si vede costretto a girare per varie schermate (form) dell'applicazione anche durante la vita stessa di quest'ultima.
Controls
Un altro approccio è quello dell'utilizzo dei controlli. In pratica l'idea è quella di avere solo una Form attiva e popolarla con i controlli che via via ci interessano. All'inizio carichiamo tutti i controlli che ci servono e a seconda delle necessità di navigazione rendiamo visibile quel controllo che ci serve. Ma come si fa a costruire i controlli in maniera semplice? quando scriviamo un controllo infatti, non abbiamo la possibilità di utilizzare un editor UI. Il trucco è semplice. E' quello usato nel progetto 2 della soluzione (AppWithoutForm) Scrivo la MainForm dentro la quale mi istanzierò tutti i controlli. Per costruire il controllo che dovrà avere la stessa interfaccia grafica di form1, faccio copia e incolla della form1 dal primo progetto. rinomino il file SettingsOne (cosicchè tutto lì dentro mi si rinomina). Faccio in modo di ereditare da System.Windows.Form.Control e non più da Form come indicato qui sotto

Primo passo per costruire il Control
Dopodichè elimino alcune istruzioni dal designer:

Secondo passo per costruire il Control
Bene, a questo punto abbiamo i nostri controls e possiamo via via che vengono premuti i vari next e back decidere a livello di mainform quali rendere visible e quali no.
I benefici che si ottengono saranno molto evidenti per UI molto complesse. A riprova di questo ho utilizzato il Performance Monitor di SDK 6 Windows Mobile che potete scaricare qui .Performance Monitor è uno dei Power Toys che ci servono per fare un sacco di cose interessanti. Una di queste è il controllo delle performance della nostra applicazione. Parleremo più dettagliatamente del Performance Monitor in un altro post. Per ora basti sapere che si installa senza nessun problema e al momento del lancio appare cosi
Performance Monitor da PowerToys for Mobile CF 3.5
Si scegli quindi il tipo di device target su cui provare l'applicazione e l'applicazione stessa (che deve essere già deployate nel device)
Dopo di che il monitor lancia direttamente l'applicazione e in diretta possiamo vedere le performance relative ad un sacco di indicatori veramente molto interessanti. Per esempio, tornando al nostro caso, si può notare che con l'uso delle Form l'impiego della memoria è effettivament più pesante, soprattutto in termini di collection. Sappiamo infatti che quando la Form principale va in background, vene lanciata una Collection ( e questo comporta lo stop di tutti i thread attivi dell'applicazione vissto che la GC deve avvenire quando nessuno può creare nuovi oggetti). Vengono sicuramente allocati più byte per il codice managed. Inoltre è effettivamente più reattiva un'applicazione che carica dei controlli piuttosto che una che carica o scarica delle Form.
Applicazione con le Form
Applicazione senza form
In conclusione, quando vi sono delle Form molto numerose e complesse, dovremmo effettuare dei confronti di performance per testare quale delle due soluzioni si avicina di più alle migliori esigenze di reattività dell'applicazione
Come tradizione trovate la soluzione zippata per il download da qui :-)
sv.