Utilizziamo i cookie per analisi, contenuti personalizzati e pubblicità.

Queste informazioni possono essere condivise con i nostri partner per fornire i servizi necessari.

Approfondisci

AccettoRifiuto

Dall'archivio articoli > WinRT 8.1

I nuovi controlli XAML di Windows 8.1

di Matteo TumiatiMatteo Tumiati, in WinRT 8.1,

Windows 8.1 non rappresenta solamente la nuova release disponibile al pubblico un anno esatto dopo il rilascio di Windows 8, ma una vera e propria rivoluzione dal punto di vista dello sviluppatore.

Molte richieste fatte da noi sviluppatori, infatti, sono state accolte positivamente da Microsoft: in questo articolo analizzeremo sia alcuni dei nuovi controlli introdotti, sia quelli che sono stati ridisegnati, per dare agli sviluppatori una mano nella scrittura del codice semplificato.

Le novità più significative sono sotto il cofano: lo XAML viene ora compilato, così da favorire i tempi di startup. Per lo stesso motivo, gli stili sono impliciti e vengono caricati in maniera differita, così come le risorse. L'effetto è che, a parità di codice, semplicemente migrando un'app da WinRT 8 a WinRT 8.1, noteremo un netto aumento delle performance in fase di avvio. Il tutto è poi condito da molte migliorie che riguardano i controlli di tipo lista, che ora hanno performance molto migliorate, che rendono l'UI più fluida.

Benché, come anticipato, ci siano molte migliorie, sia a livello di runtime, che di Visual Studio 2013, in questo articolo ci soffermeremo in maniera specifica sui controlli XAML.

Iniziamo, quindi, a dare un'occhiata alle novità relative alla parte più interessante di XAML: partiamo, dunque, con quanto viene ora offerto per la gestione dello spazio sullo schermo.

Niente più ViewState

In Windows 8 eravamo abituati a tre viste differenti: full, filled e snapped. In Windows 8.1 sono stati rimossi tutti i ViewState e la modalità snapped non è più uno stato da gestire obbligatoriamente.

Questo è stato fatto principalmente perché Windows 8.1 supporta un nuovo sistema per un multitasking decisamente più ricco e potente di quello offerto nella versione precedente: le applicazioni possono essere ridimensionate continuamente e possiamo vedere più app aperte contemporaneamente, ciascuna delle quali occupa una parte ridimensionabile in larghezza dello schermo.

E' pur vero che la snapped non esiste più, però è comunque un tipo di vista che è da considerare quando abbiamo 3 o più app aperte. In questo caso, la dimensione della modalità snapped rimane di 320px: poiché esiste questo nuovo modello di multitasking e la dimensione minima dello schermo rimane 1024px, la dimensione minima della View è ora di 500px e dobbiamo noi, esplicitamente, impostarla a 320px: la modalità snapped, insomma, è diventata facoltativa.

Per questo motivo, abbiamo più viste da dover gestire e, per farlo, dobbiamo registrarci per l'evento di resize, che non farà altro che prendere le dimensioni della porzione di schermo a disposizione dall'applicazione ed eventualmente di altre proprietà come l'orientamento. Eccone un esempio:

Esempio - C#
private void WindowSizeChanged(object sender, WindowSizeChangedEventArgs e)
{
  //Dimensione della finestra
  var WindowWidth = Window.Current.Bounds.Width;

  ApplicationViewOrientation orientamento = ApplicationView.GetForCurrentView().Orientation;

  if (orientamento == ApplicationViewOrientation.Landscape)
  {
    // Landscape
  }
  else if (orientamento == ApplicationViewOrientation.Portrait)
  {
    // Portrait 
  }
}

Questa nuova modalità consente maggiore flessibilità e semplifica la creazione dei layout: in generale, è consigliabile supportare la modalità snapped semplicemente facendo fallback su quella portrait e gestendo i layout in maniera tale che siano fluidi, cioè che adattino i contenuti allo spazio a disposizione.

Le migliorie del binding

Il binding è stato notevolmente migliorato con Windows 8.1, con l'introduzione di funzionalità appartenenti già al mondo di Silverlight e WPF. In particolare, abbiamo il supporto alle proprietà TargetNullValue, FallbackValue e UpdateSourceTrigger.

Supponiamo di avere una banale lista di Person, come questa che andiamo a mettere in binding alla nostra ListView all'interno dello XAML:

Esempio - C#
var people = new ObservableCollection<Person>
{
  new Person {Age = 22, Name = "Matteo", Surname = "Tumiati"},
  new Person {Age = 22, Name = null, Surname = null}
};
ListView.ItemsSource = people;

Se il template del nostro controllo ListView è scritto correttamente, dovemmo vedere tutti i risultati esposti dalla nostra lista, come nell'esempio che segue.

Esempio - XAML
<ListView x:Name="ListView">
  <ListView.ItemTemplate>
    <DataTemplate>
      <StackPanel>
        <TextBlock Text="{Binding Age}" />
        <TextBlock Text="{Binding Name}" />
        <TextBlock Text="{Binding Surname}" />
      </StackPanel>
    </DataTemplate>
  </ListView.ItemTemplate>
</ListView>

Cosa succede però quando vado a visualizzare una proprietà nulla, come nel secondo caso' Purtroppo, nel caso predefinita, non accade nulla e il nome ed il cognome non vengono visualizzati.

Per ovviare a questo inconveniente, ci fa comodo la proprietà TargetNullValue, che non fa altro che intercettare i valori nulli e mettere un messaggio nella TextBlock che abbiamo impostato noi.

Esempio - XAML
<TextBlock Text="{Binding Name, TargetNullValue='Valore null'}" />
<TextBlock Text="{Binding Surname, TargetNullValue='Valore null'}" />

Se andiamo ad eseguire l'applicazione, ci ritroveremo con il messaggio "Valore null", come ci saremmo aspettati.

In caso di errore di binding, perché specifichiamo una proprietà che non esiste all'interno della classe, il binding fallisce senza dare nessun risultato a video. Per fortuna, in Windows 8.1 è stata aggiunta la proprietà FallbackValue, che ci permette di risolvere questo nostro problema. Eccone un esempio:

Esempio - XAML
<TextBlock Text="{Binding CodiceFiscale, FallbackValue='Binding non corretto'}" />

Ed ecco il risultato che avremmo a video.

Ultima, ma non per importanza, è UpdateSourceTrigger: in genere, in presenza di un binding di tipo TwoWay, la sorgente dati viene automaticamente aggiornata ogni qualvolta si verifichi un aggiornamento sulla view. Questo comportamento è modificabile impostando un valore differente per la proprietà appena citata, che è impostata di default sul valore Default. Altri valori possibili sono PropertyChanged ed Explicit.

In questi due casi dobbiamo andare a recuperare manualmente il valore in binding, per aggiornare la sorgente con questo metodo:

Esempio - C#
var expression = TextBlockName.GetBindingExpression(TextBlock.TextProperty);
expression.UpdateSource();

L'effetto che otteniamo è quello di poter gestire molto meglio gli scenari di aggiornamento condizionato del binding.

5 pagine in totale: 1 2 3 4 5
Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn
Aggiorna

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti

Top Ten Articoli

Articoli via e-mail

Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!

In primo piano

.NET Conference Italia 2024 - Milano

.NET Conference Italia 2023 - Milano e Online

Le novità di .NET 7 e C# 11

Le novità in ASP.NET Core e Blazor con .NET 7

I più letti di oggi

In evidenza

Misc