blogs.ASPItalia.com

Progress di una chiamata Silverlight ad un servizio

Cristian "Ricciolo" Civera — Wed, 09 Jun 2010 16:13:00 GMT

Ormai si sa, Silverlight come unico strumento di accesso ad informazioni remote, permette di usare i servizi, siano essi sviluppati lato server in asmx, WCF o altre tecnologie. Non � propriamente l'unica perch� possiamo effettuare chiamate HTTP generiche e tramite REST/POX ottenere sottoforma di Json e XML i dati. Ad ogni modo i servizi usano uno standard e sono molto comodi e facili da utilizzare, grazie alla generazione automatica del proxy.

Durante un corso mi � stato per� chiesto se possiamo conoscere lo stato di avanzamento di una chiamata ad un servizio. Partiamo dal presupposto che un servizio non dovrebbe mai restituire una quantit� notevole di dati per due principali motivi:

� una chiamata HTTP, se qualcosa si interrompe siamo costretti a rieffettuare la chiamata e riottenere l'intera risposta;
� probabile che tutti questi dati non servano per intero all'utente fin dall'inizio e una buona politica di frammentazione di download delle informazioni � la strada ideale.

Ad ogni modo, un servizio che restituisce 1/5MB pu� essere accettabile e l'ideale sarebbe fornire lo stato di avanzamento all'utente. Per capire come conoscere lo stato di avanzamento dobbiamo prima di tutto sapere che sia Silverlight, lato client, che WCF, lato server, bufferizzano la richiesta e la risposta. Questo significa che entrambi preparano il messaggio SOAP, lo serializzano e lo mandano in risposta, o viceversa, leggono i byte della richiesta/risposta e solo quando interamente caricata preparano il messaggio e lo interpretano.

Poich� a noi interessa l'aspetto Silverlight dobbiamo prima di tutto modificare nel file ServiceReferences.ClientConfig l'attributo transferMode:

<basichttpbinding>
  <binding transfermode="StreamedResponse">
</binding>

In questo modo il binding HTTP di Silverlight comincer� a leggere la risposta pian piano che i byte giungono dal server. Questo per� non basta perch� non abbiamo cognizione dell'avanzamento della lettura della risposta. In Silverlight 4.0 possiamo scrivere behavior, binding e inserire message inspector, tutte cose ereditate da WCF del .NET Framework, ma non possiamo riscrivere parzialmente il basicHttpBinding e in generale HttpChannelFactory. Fortunatamente questo oggetto sfrutta al suo interno, per effettuare fisicamente la chiamata HTTP, la classe HttpWebRequest.

Per conoscere lo stato di avanzamento possiamo quindi personalizzare il modo in cui l'HttpWebRequest viene creato. Per farlo nel .NET Framework, ma anche in Silverlight, abbiamo a disposizione il metodo statico WebRequest.RegisterPrefix per indicare, in base allo schema, quale IWebRequestCreate utilizzare. Normalmente possiamo scegliere tra WebRequestCreator.BrowserHttp e WebRequestCreator.ClientHttp. Il primo sfrutta lo stesso motore del browser e contiene quindi i cookie del dominio e permette al browser di leggere la risposta, mentre il secondo scavalca il browser e permette di effettuare chiamate HTTP in liber�.

L'idea � quindi di creare un IWebRequestCreate e relativi HttpWebRequest, HttpWebResponse e Stream personalizzati che mi permettano di sapere a che punto si trova la lettura dello Stream. Quando infatti impostiamo il transferMode a streamed viene impostato sull'oggetto HttpWebRequest la propriet� AllowReadStreamBuffering a false, permettendo la lettura dello Stream mentre riceviamo i byte.

Per andare al sodo, qua trovate un'applicazione di esempio. Prima di tutto registro il mio creator personalizzato:

WebRequest.RegisterPrefix("http://", AdvancedWebRequestCreator.Default);

Tramite esso posso poi intercettare l'evento che mi notifica lo stato di avanzamento di una chiamata.

AdvancedWebRequestCreator.Default.UriProgressChanged += new EventHandler<UriProgressChangedEventArgs>(Default_UriProgressChanged);

Nell'evento so l'URI del servizio che sto chiamando, la percentuale, i byte scaricati e totali. Ho anche aggiunto una propriet� per indicare, per ogni URI, quale creator utilizzare, utile per quando usiamo i due client (http e browser) in modo misto.

AdvancedWebRequestCreator.Default.Mappings.Add(new UriCreateMapping(new Uri("http://sito.it"), WebRequestCreator.ClientHttp));

Per il resto basta chiamare il servizio come normalmente facciamo. Un'ultima nota per quanto riguarda WCF lato server: il transferMode dev'essere obbligatoriamente su buffered altrimenti la risposta non conterr� il ContentLength ed � impossibile per noi indicare lo stato.

Tags: .NET Framework 3.0, Silverlight, Web Service, Windows Communication Foundation, XAML

Continua a leggere Progress di una chiamata Silverlight ad un servizio.

Silverlight - Real time audio peak meter

Cristian "Ricciolo" Civera — Sun, 31 May 2009 09:14:00 GMT

In un post precedente ho mostrato di come si pu� realizzare un misuratore di picchi per l'audio di un MediaElement precalcolandoli con un'applicazione console. Ovviamente questa non � la prassi normale di tutti i lettori normali, dove il calcolo della FFT applicata ai samples avviene in real time, man mano che questi vengono renderizzati sulla periferica audio.

Da Silverlight 2.0 sull'oggetto MediaElement � presente un metodo SetSource che accetta uno Stream oppure un'oggetto MediaStreamSource. Questa classe ha dei metodi che MediaElement chiama, come OpenMediaAsync, GetSampleAsync, SeekAsync per chiederci di aprire la sorgente, di restituirgli gruppi di samples o di posizionarci ad uno specifico timestamp. Con i metodi ReportOpenMediaCompleted, ReportGetSampleCompleted e ReportSeekCompleted non si fa altro che notificargli l'avvenuta operazione e ciclicamente mandargli pacchetti audio/video.

La brutta notizia � che i samples audio e video devono essere compressi (MP4, WMV) e quindi quello che noi possiamo fare � solo fare da tramite per fonire tracce audio e video con i protocolli che vogliamo: RTP, UPNP, streaming custom. Questa � una brutta notizia perch� per applicare la FFT occorre avere i samples grezzi, gi� decodificati. L'oggetto MediaElement non permette di caricare file WAV direttamente, ma il MediaStreamSouce permette invece di passare anche i samples raw, che il file WAV appunto contiene. Sebbene si potrebbe scrivere un decoder MP3, non sono cos� pazzo da farlo :-), perci� ho scelto di creare un file WavMediaStreamSource che carica tramite WebRequest un file wav e legge l'header per conoscere il numero di canali, i samples al secondo (solitamente 44100) e i bit (8/16). L'implementazione poi non fa altro che rigirare i byte al MediaElement.

Ho portato poi l'algoritmo FFT e di calcolo dei picchi sulla mia libreria Silverlight e diviso il controllo del post precedente in due parti: DataAudioPeakMeter e SamplesAudioPeakMeter. Il primo lavora con il file dat precalcolato e funziona con tutti i formati supportati da SL. Il secondo lavora solo con i file WAV, ma funziona in real time. Entrambi poi fanno uso della BarVisualization per l'animazione.

L'utilizzo � piuttosto semplice:

<MediaElement AutoPlay="False"
              x:Name="media" />

<!-- Visualization -->
<a:SamplesAudioPeakMeter x:Name="sa">
    <a:BarVisualization BarSegmentHeight="4"
        BarMargin="1"
        BarSegmentMargin="1"
        StrokeBrush="Yellow"
        StrokeThickness="1">
        <a:BarVisualization.BarBrush>
            <LinearGradientBrush StartPoint="0,0" EndPoint="0,1">
                <GradientStop Offset="1"
                              Color="Black" />
                <GradientStop Offset="0"
                              Color="Blue" />

            </LinearGradientBrush>
        </a:BarVisualization.BarBrush>
    </a:BarVisualization>
</a:SamplesAudioPeakMeter>

Da codice poi dobbiamo legare la sorgente wav sia al MediaElement che al SamplesAudioPeakMeter:

WavMediaStreamSource source = new WavMediaStreamSource(new Uri("test1.wav", UriKind.RelativeOrAbsolute));
source.Loop = true;

// Binding Source -> Visualization
sa.SetSource(source);
// Binding Source -> MediaElement
media.SetSource(source);

Ed ecco il risultato:

Ovviamente i file wav sono di grandi dimensioni quindi questa tecnica � adatta per file di piccola di dimensione sulla quale fare loop, ma meglio di niente :-). Poi speriamo che magari nella RTM di Silverlight 3.0 ci sia la possibilit� di accedere ai samples gi� decodificati.

Infine le performance: escludendo l'animazione sono rimasto piuttosto colpito. La mia CPU resta su un 2% per calcolare FFT e picchi. Includendo l'animazione si arriva poi ad un 25/30%, ma va considerato che SL tenta sempre di andare al massimo di frame rate per l'esecuzione delle animazioni.
Presto metter� i sorgenti: promesso!

Tags: Silverlight, Silverlight - animazioni, Silverlight 2.0, XAML

Continua a leggere Silverlight - Real time audio peak meter .

Salvare immagini Bitmap con Silverlight 3.0

Cristian "Ricciolo" Civera — Fri, 29 May 2009 17:56:00 GMT

In Silverlight 3.0 � stato aggiunta la possibilit� di salvare file in locale attraverso la SaveFileDialog. Per motivi di sicurezza, questa pu� essere visualizzata solo all'interno di un evento scatenato dall'utente (pressione del pulsante, ecc) mentre attraverso OpenFile � possibile poi aprire uno Stream per la scrittura sulla quale � possibile scrivere qualsiasi cosa.

In una discussione con Marco ci � venuto il dubbio se si poteva salvare immagini in locale, ma purtroppo la cosa non � molto semplice da raggiungere. In SL infatti non ci sono API per effettuare encoding ed decoding di immagini ad eccezione del passare uno Stream da visualizzare. Inoltre con WriteableBitmap � stata aggiunta la possibilit� di caricare uno Stream o di renderizzare un UIElement su un'immagine, ma poi non � possibile accedere ai byte. Insomma, se si ha un'immagine gi� codificata in JPEG/PNG basta semplicemente travasare lo Stream sorgente verso il file locale, altrimenti se si ha solo i byte grezzi dell'immagine occorre scriversi il motore di encoding e di creazione del contenitore.

Per fortuna c'� il buon vecchio file BMP, la cui definizione si pu� trovare qui, che � abbastanza semplice da creare e a parte dover accodare i byte dell'immagine dal basso verso l'altro, non necessita di algoritmi di compressione. Ovviamente il file risultante � di grandi dimensioni, ma non dev'essere trasportato in rete, ma bens� salvato direttamente in locale. Ho scritto quindi un BitmapEncoder e un BitmapFrame per salvare un'immagine in BMP, lo trovate completo di sorgente qua. L'esempio allegato genera un'immagine con un algoritmo e la mostra anche attraverso un WriteableBitmap.

Purtroppo non serve a tantissimo, perch� attualmente la WriteableBitmap non permette di accedere ai pixel e quindi non � possibile salvare screenshot effettuati sugli elementi. Potenzialmente si pu� creare qualsiasi file, ma ovviamente non � semplice doversi riscrivere librerie di creazione di file, non potendosi appoggiare a oggetti COM.

Tags: Silverlight, XAML, Silverlight 3.0

Continua a leggere Salvare immagini Bitmap con Silverlight 3.0.

Silverlight - Audio peak meter

Cristian "Ricciolo" Civera — Sat, 23 May 2009 16:59:00 GMT

Qualche tempo fa realizzai un controllo per l'analisi dello stream audio e la visualizzazione dei picchi attraverso WPF. Nel tempo libero del tempo libero, da appassionato di DirectShow e di fuffologie mi son chiesto se si poteva fare una cosa simile anche in Silverlight.

Il problema � che in Silverlight non si ha a disposizione DirectShow, non si pu� usare codice unmanaged ne si pu� accedere allo stream audio. L'unico oggetto che abbiamo � MediaElement che permette di riprodurre audio e video; nella versione 2.0 c'� la classe MediaStreamSource, ma sebbene non abbia avuto ancora modo di provarla a fondo, permette di accedere allo stream codificato e non quello decodificato, perci� scrivere un decoder mp3 in codice managed non � proprio una passeggiata :-). Per poter applicare FFT e calcolare decibel e picchi dobbiamo infatti avere i byte grezzi, come i file wav.

Siccome per la maggior parte dei casi pu� bastare un piccolo loop su una canzone ho trovato una facile soluzione: precalcolare. In pratica ho realizzato una console application, interamente managed, che apre un file audio, calcola FFT ecc e salva in un file tutti i byte rappresentativi dei picchi, circa 12 suddivisi per 19 frequenze al secondo.

Una volta che si ha il file audio e il file .dat contenente i picchi, tramite un controllo posso mostrarne i valori. Il controllo AudioMeter ha bisogno del file .dat e del MediaElement sul quale basarsi per mostrare i picchi in funzione della posizione. Ecco il risultato:

Per rendere il pi� fluido possibile l'animazione intercetto CompositionTarget.Rendering che viene scatenato ad ogni frame dell'applicazione Silverlight che viene renderizzato. Le barre che vanno su e gi� sono invece animate da DoubleAnimation.

Devo dire che sono molto soddisfatto del risultato. Anche se il video non rende moltissimo, l'animazione � molto fluida e ben sincronizzata, meglio di quanto avevo fatto con WPF.

Tags: Silverlight, Silverlight - animazioni, Silverlight 2.0, Silverlight 3.0, XAML

Continua a leggere Silverlight - Audio peak meter.

Mostrare la WebCam in Silverlight

Cristian "Ricciolo" Civera — Thu, 07 May 2009 11:00:00 GMT

Nel precedente post ho illustrato la mia idea di dialogo tra Silverlight e la macchina host, ma ora vediamo un caso pratico.

Prima di tutto ho preparato un'applicazione Windows senza finestre, ma che rimane sulla system tray mettendosi in ascolto come policy server e su un'altra porta in attesa di connessioni. Questo "server" alla prima connessione avvia un filtro DirectShow che prende l'immagine della WebCam, prende ogni frame attraverso un Sample Grabber e lo comprime in Jpeg ad una qualit� non troppo impegnativa. I bytes risultati vengono inviati al client preceduti da 8 byte che indicano la dimensione dell'immagine e quindi dei bytes che il client si deve aspettare. Ci� che ottengo quindi � di fatto un Motion Jpeg pi� alcuni controlli che il server fa per saltare frame qualora il client sia in ritardo a ricevere i fotogrammi.

Il client Silverlight invece avvia la connessione e in modo ciclico legge nel buffer i primi 8 byte per conoscere la dimensione dell'immagine. Carica i restanti byte con i quale crea un MemoryStream che d� poi in pasto al metodo BitmapImage.SetSource. Quest'ultimo carica l'immagine che viene poi associata ad un oggetto Image di Silverlight. In pratica quindi, vi � un flusso continuo di bytes di immagini compresse che vengono poi ricostruite per formare i fotogrammi dell'immagine con il quale poi ci si pu� sbizzarrire come si vuole.

Ho creato poi un deployment con ClickOnce per avviare il server automaticamente e dei byte "magici" che manda il client per chiudere il server. Questo il risultato finale:

Silverlight con questa tecnica si comporta bene e l'uso della CPU � non � intenso, garantendo sempre un flusso fluido dell'immagine.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, Silverlight, Silverlight 2.0, Windows 7, Windows Client, XAML

Continua a leggere Mostrare la WebCam in Silverlight.

Comunicazione TCP tra Silverlight e WPF

Cristian "Ricciolo" Civera — Wed, 06 May 2009 21:46:00 GMT

Negli ultimi giorni mi sono incuriosito su come risolvere un'esigenza che potrebbe capitarmi in futuro: la comunicazione tra Silverlight e una application WPF/WinForms.
Silverlight ha potenzialit� limitate e potrebbe utile usare un'applicazione classica locale che non ha limiti in termini di funzionalit�.

Per questo scopo in Silverlight fortunatamente hanno lasciato la classe Socket che, sebbene il suo utilizzo differisce dal .NET Framework, permette di connettersi ad un end point e dialogare direttamente con i bytes, permettendo ampio margine di movimento e consentendo di implementare protocolli standard o custom.

Con questo post non � mio intento spiegare in dettaglio come si usa il socket, ma illustrare come vedo io una possibile implementazione e una collaborazione tra un'applicazione locale e una in Silverlight. Innanzitutto bisogna tenere conto che Silverlight pu� connettersi solo al range di porte 4502-4534, per ovvi motivi di sicurezza: evitare che un'applicazione possa essere strumento di attacchi DoS o Reverse tunnel. Inoltre sia che ci si connetta al host di origine sia ad un host esterno (cross site), � necessario che il server sia in ascolto anche sulla porta 943 (fissa) che su richiesta deve restituire il file clientAccessPolicy.xml che gi� conosciamo per le richieste HTTP, ma che viene validato anche per le richieste socket.
A questo indirizzo troviamo un esempio di classe PolicyServer per implementare questa logica di validazione, qualora un client Silverlight la richieda.

Con l'esempio indicato possiamo anche vedere come con il pattern Begin/End possiamo accettare nuove connessioni, inviare e ricevere bytes e creare di fatto un nostro protocollo di dialogo. Infatti l'idea � che una volta avviata l'applicazione Silverlight, qualora serva, facciamo partire quella locale che si mette in ascolto e con la quale poi si instaura un dialogo per chiedere informazioni al server o viceversa.

Per far partire il server viene in aiuto ClickOnce che grazie al sua capacit� di installare un'applicazione al volo, la fa anche avviare. Basta navigare aprendo una popup al file .application e l'applicazione viene installata, previa conferma, e poi avviata.

private void StartButton_Click(object sender, RoutedEventArgs e)
{
    // Avvio l'applicazione con ClickOnce
    Uri appUri = new Uri("http://test.aspitalia.com:50658/setup/WebCamStreaming.application");
    HtmlPage.PopupWindow(appUri, "_blank", new HtmlPopupWindowOptions());

    // Avvia la comunicazione TCP
    client.ConnectAsync();
}

Attraverso poi un Mutex si pu� impedire che pi� istanze partano, lasciando sempre un solo server attivo. Qualora poi non serva pi�, possiamo sfruttare sempre la connessione tcp per inviare un segnale di chiusura dell'applicazione.

Nel prossimo post mostrer� un esempio completo di tutto questo ambaradam di cui dar� i sorgenti.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, Silverlight, Silverlight 2.0, XAML

Continua a leggere Comunicazione TCP tra Silverlight e WPF.