Una delle cose che ho trovato più complicate da capire quando si sviluppa un’app per Windows 8 Metro-style è la gestione del suspending e del resuming. Non perchè sia di per sè complicata, quanto perchè se aprite Visual Studio 2012 e iniziate con un qualsiasi progetto per il Windows Store, vi viene già fornita un set di classi che – sotto sotto – fanno il lavoro sporco di salvataggio e di recupero dei dati. Quindi secondo me non si capisce esattamente cosa faccia davvero il sistema operativo di base, e cosa invece viene fatto dal template classico di un’app Windows Store.

Andiamo con calma. Supponiamo di dover fare una semplice app Metro che chiede all’utente tre informazioni: cognome, nome e data di nascita. Il tutto avviene in modo molto semplice, con tre TextBox. Aprite Visual Studio 2012, cominciate con un progetto scegliendo il template “Blank App (XAML)”, che si trova all’interno dei folder Visual C# –> Windows Store. Editiamo la MainPage.xaml ed incollate questo:

<Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}">
    <Grid.ColumnDefinitions>
        <ColumnDefinition />
        <ColumnDefinition />
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto" />
        <RowDefinition Height="Auto" />
        <RowDefinition Height="Auto" />
    </Grid.RowDefinitions>
        
    <TextBlock Grid.Row="0" Grid.Column="0"
                Text="Cognome" FontSize="34" VerticalAlignment="Center" Margin="4" />
    <TextBlock Grid.Row="1" Grid.Column="0"
                Text="Nome" FontSize="34" VerticalAlignment="Center" Margin="4" />
    <TextBlock Grid.Row="2" Grid.Column="0"
                Text="Data di Nascita" FontSize="34" VerticalAlignment="Center" Margin="4" />

    <TextBox Grid.Row="0" Grid.Column="1" Text="Damiani"
                x:Name="Cognome" FontSize="32" VerticalAlignment="Center"
                Foreground="Black" Margin="4" />
    <TextBox Grid.Row="1" Grid.Column="1" Text="Igor"
                x:Name="Nome" FontSize="32" VerticalAlignment="Center"
                Foreground="Black" Margin="4" />
    <TextBox Grid.Row="2" Grid.Column="1" Text="01/01/1900"
                x:Name="DataNascita" FontSize="32" VerticalAlignment="Center"
                Foreground="Black" Margin="4" />

</Grid>

 

Nulla di insolito. Per ora evitiamo MVVM. Abbiamo messo tre TextBox, ciascuna con il suo nome. Adesso, facciamola girare ed osserviamone il comportamento.

1. All’avvio vi vengono ovviamente proposti i valori di default cablati nello XAML (il mio nome, cognome, e la mia data di nascita falsa)
2. Provate a cambiare tali valori, scrivendoci i vostri, o quello che volete
3. Tornate in Visual Studio a suon di Alt+Tab e – utilizzando la toolbar Debug Location cliccate sull’opzione Suspend and Shutdown: questa opzione simula il fatto che Windows termina la vostra app perchè ha bisogno di memoria, o per qualsiasi altro motivo. Ad esempio, se passate da un’app Metro all’altra, quella che finisce in background viene sospesa, per non consumare memoria, batteria, etc. etc.
4. Se avete fatto correttamente il passo (3), l’app viene terminata: Visual Studio ed il suo debugger terminano ovviamente la sua esecuzione
5. Se rilanciate l’app, DEVE accadere una cosa molto importante: l’app parte ma NON DEVE riproporre i valori di default, ma deve recuperare il precedente stato!!

A questo punto è necessario soffermarsi sul punto (5). Per chi viene da un avanzato sviluppo di app Windows Phone come me, troverà una notevole differenza. Quando toccate una tile su Windows Phone, l’app parte SEMPRE da zero, senza alcun bisogno di restorare il precedente stato. Questo NON E’ VERO con Windows 8. Il motivo è presto detto: con Windows Phone non potete chiudere manualmente l’app, mentre con Windows 8 sì. Con Windows 8, fin tanto che non la chiudete, essa deve SEMPRE recuperare lo stato che l’utente aveva. In breve: con il nostro piccolo test di prima l’app è stata sospesa (ovvero: non l’abbiamo volutamente chiusa), per cui se la rilanciamo (dalla tile sulla Start Page oppure prendendola dalle app aperte, usando lo charm sulla sinistra dello schermo) essa deve recuperare lo stato, proponendoci non i valori di default, ma quelli che avevamo modificato. Questo adesso ovviamente non accade, perchè in questo momento il meccanismo di suspending & resuming nella nostra piccola app di prova non esiste, perchè non è stato ancora implementato. Ma è stato importante capire, secondo me, cosa succede by default, e cosa invece dobbiamo implementare.

Andiamo avanti.

Suspending, salvataggio delle informazioni

Diamo un’occhiata al costruttore della classe App, contenuto nel file App.xaml.cs. Esso sottoscrive l’evento Suspending:

this.Suspending += OnSuspending;

 

L’handler di questo evento fa una cosa semplice:

private async void OnSuspending(object sender, SuspendingEventArgs e)
{
    var deferral = e.SuspendingOperation.GetDeferral();
    await this.SaveCurrentState();
    deferral.Complete();
}

 

La parte più interessante è il this.SaveCurrentState(), che fa una cosa di cui magari parleremo in un altro post. Questo metodo viene eseguito ogni qualvolta il sistema operativo manda in sospensione la nostra app: lo scopo quindi è quello di salvare lo stato, con tutto ciò che comporta. Caselle di testo, contenuto di ListBox, viewmodel, etc. etc.: tutto ciò che serve per dare l’illusione che l’app non si sia mai chiusa, insomma. Ed il tutto deve avvenire – se ben ricordo – nell’arco di 5 secondi: trascorso questo tempo, Windows killa la nostra app e tutto è perduto.

Resuming, recupero delle informazioni

Ovviamente deve esistere anche l’operazione inversa. Quando l’app viene lanciata potrebbe essere necessario recuperare le informazioni e riadattare la view dell’utente secondo quanto salvato. Diamo un’occhiata a:

protected async override void OnLaunched(LaunchActivatedEventArgs args) { }

 

Ad un certo punto troverete una riga di codice simile alla seguente:

if (args.PreviousExecutionState == ApplicationExecutionState.Terminated)
{
    await this.RestoreLastState(rootFrame);
}

 

La proprietà PreviousExecutionState ci dice la modalità con cui è stata chiusa l’app: nel caso fosse Terminated (ovvero chiusa dal sistema operativo) allora dobbiamo recuperare lo stato. Negli altri casi (ClosedByUser, NotRunning, Running, Suspended) no. Nel mio caso ho implementato un metodo RestoreLastState che fa tutto il lavoro.

Conclusioni

Quello che mi ha confuso per un po’ di tempo è il fatto che se usate un altro template per il Windows Store (Grid App, Split App, etc.) vi viene già fornita una classe SuspensionManager che fa buona parte del lavoro, con il fatto però che non ho mai capito cosa facesse il sistema operativo nativamente, e quanto invece facesse l’app e la parte di codice già implementata per noi. Per questo ho preferito partire da una Blank App e vedere cosa accadesse. Magari in un altro post parlerò di ciò che fanno i metodi SaveCurrentState() e RestoreLastState(). In breve, vanno a recuperare la view corrente e tramite un’interfaccia ISuspendInfo chiedono alla view le informazioni che devono essere salvate o recuperate.

Introduzione
Utilizzare un servizio WCF mi è diventato così istintivo in tutte le cose che faccio che francamente non riesco più a farne a meno. Non sto qui ad elencare i vantaggi e a discutere le varie tecniche, perchè prima di tutto non ne ho le competenze (rischierei di usare termini non corretti), per cui vado diretto al succo di questo post.

Generalmente, dal punto di vista client (quindi un’applicazione WPF, un’app Windows Forms o Windows Phone, un’applicazione ASP.NET MVC, etc. etc.) un servizio WCF è un servizio al quale forniamo dati, compie elaborazioni e restituisce qualcosa. Questo avviene con chiamate a metodi esposte dal servizio tramite un contratto (un’interfaccia IQualcosa), grazie al quale noi sappiamo come comunicare, cosa passare e cosa ci aspettiamo come valori di ritorno. Questo tipo di approccio non presenta nessun tipo di problema (in realtà ce ne sono una valanga, sicurezza in primis, ma sorvoliamo): una volta che il servizio è stato esposto via http, è sufficiente aggiungerlo al nostro progetto corrente tramite il comando “Add Service Reference”. Sul nostro client viene creata una classe proxy da utilizzare per effettuare le chiamate.

Quello che succede in uno scenario di questo tipo è che il client, indipendentemente dal tipo, invoca il servizio WCF. Quest’ultimo lavora un po’ e poi restituisce i dati al client. Semplice, almeno concettualmente.

Quello su cui ho lavorato per una giornata intera è invece lo scenario seguente:

• applicazione Windows 8 Metro-style, scritta in C#
• servizio WCF in ascolto su http://localhost:1976
• il servizio WCF non solo espone dei metodi che vengono invocati dall’applicazione, ma è in grado – tramite callback ed un canale di comunicazione duplex, di invocare un metodo definito sul client

Il servizio WCF, quindi, ha diverse particolarità:

• si deve memorizzare da qualche parte il “chiamante”
• deve definire non solo un contratto col quale dialogare con il client, ma anche un contratto di callback. Quest’ultimo definisce il/i metodi da invocare sul client

Arriviamo al sodo, vediamo un po’ di codice.

Codice Server Side
Implementiamo un servizio che prende in input un ExecuteRequest e restituisce, prima o poi, un ExecuteResponse.

[DataContract]
public class ExecuteRequest
{
    [DataMember]
    public int Value { get; set; }
}

[DataContract]
public class ExecuteResponse
{
    [DataMember]
    public int Value { get; set; }
}

 

Ho scritto “prima o poi” perchè supponiamo che l’esecuzione server-side sia piuttosto lunga; quindi, NON facciamo un metodo simile a questo:

[ServiceContract]
public interface IExecuteService
{
    [OperationContract]
    ExecuteResponse Execute(ExecuteRequest value);
}

 

bensì facciamo come segue:

[ServiceContract(CallbackContract = typeof(IExecuteServiceCallback))]
public interface IExecuteService
{
    [OperationContract]
    void Execute(ExecuteRequest value);
}

 

Invochiamo il metodo Execute passandogli un ExecuteRequest, che restituisce void. Il servizio WCF lavora, lavora, lavora, e prima o poi chiamerà la callback per informarci del risultato. La funzione di callback è indicato all’interno dell’attributo ServiceContract, ed è IExecuteServiceCallback.

public interface IExecuteServiceCallback
{
    [OperationContract(IsOneWay = true)]
    void ExecuteTerminated(ExecuteResponse response);
}

 

L’implementazione del servizio è piuttosto semplice:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
public class ExecuteService : IExecuteService
{
    private ExecuteRequest Request;
    private ExecuteResponse Response = new ExecuteResponse();
    private IExecuteServiceCallback Callback;

    public void Execute(ExecuteRequest value)
    {
        this.Callback = OperationContext.Current.GetCallbackChannel<IExecuteServiceCallback>();
        this.Request = value;

        Timer timer = new Timer(10000);
        timer.Elapsed += (s, e) =>
            {
                timer.Stop();

                this.Response.Value = this.Request.Value * 3;
                this.Callback.ExecuteTerminated(this.Response);
            };
        timer.Start();
    }
}

 

Quando il cliente invoca il metodo Execute esposto dal servizio, accade che:

• il servizio si memorizza chi è il chiamante e predispone la callback
• al client restituisce un void

A solo scopo di test, parte un timer che fa aspettare il client 10 secondi, al termine dei quali viene invocata la callback sul client con il risultato dell’operazione. Praticamente, ciò che accade è che il client invoca il metodo passando un numero intero, ed il servizio restituisce il doppio di tale numero. Ripeto: è solo a scopo di test, si presuppone che un processore moderno si metta un po’ meno a calcolare il doppio di un numero!

Un pezzetto di web.config

C’è qualche accorgimento da apportare anche nel web.config. L’endpoint deve essere di tipo netHttpBinding. Come recita MSDN all’indirizzo http://msdn.microsoft.com/en-us/library/hh674273.aspx, infatti:

NetHttpBinding is a binding designed for consuming HTTP or WebSocket services and uses binary encoding by default. NetHttpBinding will detect whether it is used with a request-reply contract or duplex contract and change its behavior to match – it will use HTTP for request-reply contracts and WebSockets for duplex contracts.

Riporto qui sotto la parte più significativa del web.config:

<system.serviceModel>
    <services>
      <service name="WcfCallbackSample.ExecuteService"
            behaviorConfiguration="bev1">
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:1000/Service" />
          </baseAddresses>
        </host>
        <endpoint name="duplexendpoint" address=""
            binding="netHttpBinding"
            contract="WcfCallbackSample.IExecuteService" />
        <endpoint name="MetaDataTcpEndpoint" address="mex"
        binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="bev1">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="True" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <protocolMapping>
      <add binding="basicHttpsBinding" scheme="https" />
    </protocolMapping>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
    multipleSiteBindingsEnabled="true" />
</system.serviceModel>

 

Ovviamente alcuni valori, attributi e nodi XML dipendono dal vostro servizio.

Client Side con un’applicazione Metro per Windows 8

Ok, abbiamo quasi finito. Adesso arriva il bello, ovvero usare il nostro servizio dal client. Dopo averlo aggiunto nei service reference, ci verrebbe istintivo utilizzare la classe client proxy che ci è stata auto-generata. No. Falso. Nada. Fermi tutti.

Innanzitutto con Visual Studio 2012 creiamo una nuova Blank app, sotto la categoria Windows Store.

Dentro troveremo un’unica Page, nel cui costruttore metteremo:

EndpointAddress address = new EndpointAddress("http://localhost:1924/ExecuteService.svc");
var binding = new NetHttpBinding();
var cf = new DuplexChannelFactory<IExecuteService>(new InstanceContext(this), binding, address);
service = cf.CreateChannel();

 

L’oggetto service, definito come private della Page, è di tipo IExecuteService, ed è grazie a questo che potremo utilizzare il nostro servizio.

A questo punto aggiungiamo un Button nello Xaml, gestiamo l’evento Click, e nel code-behind inseriamo:

service.ExecuteAsync(new ExecuteRequest() { Value = 4 });

 

Proviamo ad eseguire l’app: è Metro-style, per cui come sappiamo che gira in full-screen. Clicchiamo sul Button. Non accade nulla. Ed è perfettamente normale, pensiamoci bene. La chiamata a Execute (che avviene in async) restituisce void. Cosa manca? Non abbiamo la callback, ovvero quel meccanismo che il server adotta per avvisarci quando lui ha terminato il calcolo. Morale: la Page deve implementare l’interfaccia di callback.

public sealed partial class MainPage : Page, IExecuteServiceCallback
{
    public async void ExecuteTerminated(ExecuteResponse response)
    {
        MessageDialog dialog = new MessageDialog(response.Value.ToString());
        await dialog.ShowAsync();
    }
}

 

Il timer, istanziato ed in esecuzione lato server, invoca la callback chiamando il metodo ExecuteTerminated sul client, e quindi apparirà la nostra MessageDialog con il risultato dell’operazione.

In ottica Model-View-ViewModel

In ottica MVVM, ovviamente, non sarà direttamente la Page ad implementare l’interfaccia IExecuteServiceCallback, ma la classe View Model che governa quella view. Il View Model gestisce la callback, lavorerà sulle proprie proprietà pubbliche per aggiornare la view.