Nell’articolo “Longhorn: XAML o Code?” abbiamo fatto una riflessione sulla modalità di scrittura applicazioni per Longhorn partendo dagli attuali Windows Forms e ASP.NET. Ideologie a parte, abbiamo visto che dietro qualunque applicazione Longhorn esistono delle classi (memorizzate in assembly .NET) che forniscono le funzionalità di base per le applicazioni. In particolare, abbiamo dato un primo sguardo alla classe MSAvalon.Windows.Application. Se non avete letto l’articolo citato vi consiglio di farlo adesso... aspetterò qui.

Esiste una seconda classe in Avalon (Avalon è il nome in codice del sottosistema di gestione dell’interfaccia utente) chiamata MSAvalon.Windows.Navigation.NavigationApplication. Tale classe estende la classica MSAvalon.Windows.Application fornendo una serie di caratteristiche interessanti.

La prima di queste (da qui il nome della classe) è fornire supporto per la navigazione all’interno di pagine (o documenti... o se volete form) di una applicazione Longhorn. Questa caratteristica porta con sé anche la possibilità di mantenere lo stato delle informazioni fra pagine e la possibilità di intercettare gli eventi di navigazione. Per esempio, è possibile intercettare l’evento Navigating (che scatta quando l’utente inizia la navigazione), l’evento Navigated (vi lascio immaginare), l’evento NavigationError (anche questo non è molto criptico... per fortuna) e l’evento LoadCompleted (quando la risorsa richiesta è stata caricata completamente).

Questa classe funge anche da contenitore per i valori delle proprietà da condividere alle varie finestre (altro termine per pagine o documenti... o form) che compongono l’applicazione.

Un’altra caratteristica interessante è sicuramente la possibilità, da codice, di interrogare tale classe (o ricevere degli eventi) per conoscere lo stato della rete. Questa classe, infatti, fornisce informazioni all’applicazione sulla disponibilità di una connessione. In un articolo separato (che tratterà le applicazioni per l’ambiente mobile... vi ricordo che anche un portatile vive in un ambiente mobile) vedremo anche le API che Longhorn espone per lavorare in modo intelligente con la rete. Per adesso chiudiamo qui il discorso.

Un utente potrà navigare all’interno dei cosiddetti entry-point dell’applicazione definiti nell’applicazione stessa: potremmo dire che l’utente si potrà spostare da una pagina (finestra) all’altra secondo quanto definito dall’applicazione stessa. Durante queste operazioni noi sviluppatori possiamo intercettare gli eventi corrispondenti (inizio navigazione, termine navigazione ecc.) e agire di conseguenza: per esempio, potremmo capire dove l’utente si sta muovendo e ridirigire o annullare l’operazione. Oppure potremmo intercettare e gestire gli errori che si possono verificare.

Tutte le operazioni di navigazione vengono registrate all’interno della history (in Longhorn si parla di Travelog). Da codice possiamo intervenire sul Travelog inserendo, modificando o cancellando le varie entry. È possibile anche fornire il supporto per Forward e Back esattamente come per un’applicazione Web.

Un’applicazione Navigable può lavorare sia online che offline (con un paradigma simile a quello utilizzato da Internet Explorer). Sappiate anche che in Longhorn un’applicazione può essere ospitata all’interno di un browser oppure vivere stand-alone (classico exe) senza modificare il codice sorgente. Le applicazioni possono inoltre essere installate in locale oppure essere scaricate direttamente da un server ed essere utilizzate senza installazione. Questa possibilità viene offerta dalla tecnologia che prende il nome di ClickOnce, di cui Paolino ha già pubblicato sul sito un articolo introduttivo.

Come per le applicazioni classiche Longhorn, anche nelle applicazioni Navigable definiremo una classe che deriva da una classe base (MSAvalon.Windows.Navigation.NavigationApplication) per poi personalizzarne il comportamento. Se vi ricordate quanto abbiamo fatto nell’articolo citato all’inizio del presente (se non ve lo ricordate è perché non avete seguito il mio consiglio... leggetelo adesso prima che sia troppo tardi!) è arrivato il momento di riproporre la versione navigabile della classe Applicazione.

namespace DevLeap
{
public class Applicazione : 

MSAvalong.Windows.Navigation.NavigationApplication
{
MSAvalon.Windows.Controls.SimpleText label1;
MSAvalon.Windows.Window           mainWindow;
protected override void OnStartingUp(StartingUpCancelEventArgs e)
{
Base.OnStartingUp();
VisualizzaForm();
}
private void VisualizzaForm()
{
mainWindow = new MSAvalon.Windows.Window();
label1 = new MSAvalon.Windows.Controls.SimpleText();
label1.Text = “DevLeap e Longhorn”;
label1.FontSize = new FontSize(12, FontSizeType.Point);
mainWindow.Children.Add(label1);
mainWindow.Show();
}
}
internal sealed class EntryClass
{
[STAThread]
Private static void Main()
{
                 Applicazione app = new Applicazione();
app.Run();
}
}
}

Come vedete, l’unica differenza con Applicazione1.cs è evidenziata in grassetto. Cambiando la classe base di una applicazione MSAvalon.Windows.Application in MSAvalon.Windows.Navigation.NavigationApplication otteniamo un’applicazione Navigable.

Dopo aver definito la nostra classe, procediamo con l’override del metodo di inizializzazione. In un’applicazione Longhorn si utilizza il metodo OnStartingUp che riceve come argomento StartingUpCancelEventArgs.

Dopo aver lanciato il metodo OnStartingUp della classe base, chiamiamo un nostro metodo (è l’analogo di quanto Visual Studio.NET fa oggi con InizializeComponent) che creerà il controllo SimpleText e ne valorizzerà le proprietà. A differenza di quanto accade oggi in Windows Forms, dovremmo anche creare la finestra (mainWindow) e visualizzarla. Ricordatevi che siamo all’interno di un’applicazione Longhorn, non in una finestra di un’applicazione Longhorn.

Chiudiamo questo breve articolo sottolineando due punti.

È molto probabile che si creeranno quasi sempre applicazioni Navigable piuttosto che Application tradizionali. Se l’applicazione non ha bisogno di navigare su varie pagine utilizzeremo una sola pagina. Che ne dite? Uno dei vantaggi è sicuramente quello di lavorare con un unico modello a oggetti per tutte le applicazioni. Il secondo potrebbe essere rappresentato dal fatto che se in un secondo momento volessimo aggiungere altre pagine all’applicazione potremmo farlo tranquillamente senza modificare l’impostazione dell’applicazione stessa. Affronteremo di nuovo questo argomento quando riusciremo a eseguire test sulle performance reali (intendo magari con una beta del prodotto e non con una pre-alfa): le caratteristiche di un’applicazione Navigable potrebbero appesantire l’applicazione rallentandone le prestazioni.

Il secondo punto da sollineare è rappresentato dal fatto che probabilmente sarà difficile che si scriva codice come quello presentato, in quanto sicuramente uno strumento di sviluppo ci consentirà di disegnare l’interfaccia utente. Inoltre, come ho indicato nell’articolo citato più volte, in Longhorn è possibile definire le interfacce utente interamente con un linguaggio dichiarativo denominato XAML. Questo semplifica lo sviluppo (e lo strumento di sviluppo).

http://schemas.microsoft.com/2003.xaml Visible=”true”>
DevLeap e Longhorn

Che ve ne pare ? Mi direte: allora perché hai scritto questi due articoli ? Perché ogni elemento dichiarativo del linguaggio XAML corrisponde a una classe MSAvalon.qualcosa. Quando si utilizza XAML il runtime utilizza la dichiarazione XAML per instanziare la classe MSAvalon corrispondente e valorizzarne le proprietà. Ho scritto questi due articoli per sottolineare come XAML sia un ulteriore linguaggio (o potremmo anche definirlo strumento) per creare interfacce utente. Il linguaggio è semplice, intuitivo e molto potente, ma alla fine della fiera dietro le quinte verranno utilizzate sempre delle classi, che è fondamentale conoscere (almeno come esistenza) per essere qualcosa in più di un “semplice” (si fa per dire) disegnatore di interfacce utente.