Creare applicazioni Silverlight è diventato sempre più semplice grazie ai miglioramenti dei tool di sviluppo come Expression Blend e Visual Studio 2010. I tool ci aiutano enormemente nella programmazione e nella definizione del codice XAML per la parte grafica e interattiva, tuttavia questa semplificazione non trascende dalla comprensione delle logiche di base del framework di Silverlight che uno sviluppatore, e in parte anche un designer, deve avere.

Infatti, possiamo dire che il rovescio della medaglia della facilità di sviluppo è nella superficialità che questa semplicità può portare nella programmazione e nella stilizzazione: ad esempio, il fatto di poter comporre e revisionare agilmente lo XAML del layout con Expression Blend, può portarci a trascurare alcuni dettagli che successivamente possono influire sulle prestazioni dell'applicazione e sulla sua robustezza.

Nonostante le capacità dei personal computer siano molto elevate, lo strato del framework di Silverlight, atto a semplificarci enormemente lo sviluppo, richiede comunque delle risorse in termini di calcolo e memoria, utilizzate, per così dire, per tradurre il codice managed in istruzioni di basso livello. Non dimentichiamo, inoltre, che un'applicazione con scarse prestazioni, quindi con lentezza di caricamento e di risposta alle interazioni, ha un impatto negativo soprattutto sull'utente che non può beneficiare così del valore aggiunto di una Rich Internet Application, motivo che probabilmente lo ha spinto ad adottare Silverlight.

Quello che possiamo e dobbiamo fare è porre attenzione a quei particolari che influiscono sulle capacità del framework di tradurre le nostre istruzioni in comportamenti, oltre ad agire, con alcuni accorgimenti, per fare in modo che l'applicazione sia veloce da utilizzare per l'utente. Nell'articolo analizzeremo alcuni appunti per migliorare nel complesso le nostre applicazioni Silverlight.

Splash screen: il primo impatto con l'utente

Le applicazioni Silverlight sono ospitate dal browser e come applicazioni web devono essere scaricate dalla rete per poter essere eseguite dal plugin. Durante la fase di download, il plugin stesso renderizza un loader che notifica l'utente dello stato di avanzamento con una percentuale. Tuttavia, in questa fase non viene mostrata a video alcuna informazione che identifichi l'applicazione, e questo può creare imbarazzo nell'utente il quale ha raggiunto il sito web ma non ha riscontro immediato se quanto ha digitato corrisponde ai suoi obiettivi.

Per gestire questo tipo di scenario abbiamo la possibilità di sostituire il loader predefinito impostando un layout personalizzato che possa contenere le informazioni sul sito, email, telefono, logo e quant'altro possa informare l'utente. Abbiamo parlato dell'implementazione nello script #17; è importante ricordare che nel loader possiamo utilizzare XAML di Silverlight 1.0 (quindi Canvas, TextBlock e poco di più) e che la logica deve essere definita in Javascript.
Per questa attività possono essere utili le pubblicazioni del tutorial su Silverlight 1.0.

Minimizzare il download iniziale

Anche se possiamo informare l'utente durante lo stato di avanzamento del download dell'applicazione, questo non ci autorizza a trascurare la sua "pesantezza" in termini di Kb. Quando un progetto cresce è molto facile che possa crescere esponenzialmente le dimensioni del suo file XAP aggiungendo risorse, librerie esterne e ovviamente anche porzioni stesse dell'applicazione.

Poichè non è detto che tutte le risorse siano necessarie fin da subito per il funzionamento dell'applicazione, possiamo frazionarle in assembly o XAP separati, in modo da caricarli al momento dell'effettiva richiesta dell'utente o dell'applicazione stessa.

Abbiamo introdotto una modalità di caricamento "manuale" nello script #25, la soluzione illustrata può essere utile se il suo utilizzo è isolato a piccoli progetti, nel caso di applicazioni più corpose abbiamo a disposizione MEF, recentemente introdotto nel .NET Framework, e PRISM: un framework molto ricco che ci permette di unire i principi di UI composition ai pattern architetturali più utili in applicazioni Silverlight. Entrambi mettono a disposizione strumenti per gestire il download ed il caricamento on-demand nell'applicazione di porzioni di progetto.

Come ulteriore vantaggio del frazionamento delle librerie dell'applicazione, abbiamo anche la possibiltà di sfruttare la cache del browser per evitare di far scaricare ogni volta all'utente quegli assembly che non sono cambiati. Nel recente script #98 abbiamo illustrato le configurazioni da apportare per sfruttare questa funzionalità.

Anche il codice XAML richiede attenzione!

Una volta scaricato il pacchetto XAP principale, il codice XAML viene parserizzato in modo che possa essere renderizzato il layout corrispondente. Questa fase è abbastanza onerosa in quanto il codice XAML ha una struttura xml quindi deve essere elaborato elemento per elemento in modo che possano essere istanziati i controlli e gli oggetti corrispondenti.
Per questo motivo è importante rimuovere il codice che non è utilizzato, come gli Style e i Template che probabilmente abbiamo creato per personalizzare alcuni aspetti ma che poi abbiamo abbandonato.

Un altro aspetto su cui possiamo intervenire è la rimozione dei valori di defaultper le proprietà degli oggetti: qui è più probabile che sia Expression Blend ad inserire per noi questi valori, indispensabili qualora siano oggetto di animazione, ma che se non utilizzati in tale contesto portano solo un rallentamento nello startup inziale dell'applicazione.

Nel contesto di renderizzazione di molti dati, ad esempio all'interno di un DataGrid o di ListBox molto numerose, negli Style è meglio definire l'aspetto con i ControlTemplate o DataTemplate rispetto agli UserControl poichè i FrameworkTemplate vengono parserizzati una sola volta e riutilizzati per tutti i dati visualizzati. Gli UserControl, invece, richiedono una elaborazione per ogni elemento.

Monitorare il rendering

Durante lo sviluppo abbiamo diversi strumenti per controllare in modo analitico l'impatto delle animazioni sul PC. Con la proprietà EnableFrameRateCounter possiamo visualizzare, nella barra di stato di Internet Explorer, il numero di fotogrammi per secondo aggiornato in tempo reale. Abbiamo parlato di questa proprietà nello script #94.

Per cercare di uniformare il comportamento delle animazioni del nostro progetto su più PC possibile, possiamo limitare il numero di fotogrammi per secondo con la proprietà MaxFrameRate, il plugin non impegnerà più tutte le risorse possibili per ottenere il massimo framerate ma si limiterà a non superare il valore impostato. Ovviamente, come dice il nome della proprietà, questa rappresenta un valore massimo: se le risorse del PC non sono sufficienti per rispettare i tempi impostati negli Storyboard, il plugin riprodurrà le animazioni con un framerate ancora più basso del valore di MaxFrameRate.

Quando vediamo che alcune animazioni non sono fluide come dovrebbero e che la CPU ha picchi notevoli, possiamo abilitare, con la proprietà EnableRedrawRegions, una modalità di controllo in cui vengono evidenziate le porzioni di interfaccia che vengono renderizzate nuovamente ad ogni fotogramma.Possiamo specificare la proprietà a livello di parametro dell'object nel codice html:

<object data="data:application/x-silverlight-2," type="application/x-silverlight-2">
  <param name="enableRedrawRegions" value="true"/> 
</object>