QMatteoQ's blog

I servizi di background audio in Windows Phone Mango

Print Content | More

Chiudiamo il ciclo di articoli dedicati al multitasking in Windows Phone Mango parlando di Background Audio, una serie di nuove API che ci da la possibilità di realizzare player multimediali in grado di riprodurre musica anche quando l’applicazione è chiusa.

Al giorno d’oggi, infatti, la diffusione di player alternativi (legati ad esempio a celebri servizi di streaming come Spotify) è scarsa o nulla su Windows Phone, proprio in virtù del fatto che non c’è supporto per l’audio in background: l’utente può ascoltare la musica solo se mantiene aperta l’applicazione. Se sceglie di chiuderla o sospenderla, ad esempio, per rispondere ad un SMS la riproduzione audio si interrompe.

Una delle feature più interessanti dei servizi di background audio è l’integrazione con la barra del volume di Windows Phone: esattamente come avviene con il player nativo Zune, avremo modo di controllare lo stato della riproduzione e di visualizzare alcune informazioni (come titolo e autore del brano in riproduzione) direttamente nella barra superiore che viene visualizzata quando premiamo i pulsanti di controllo del volume (che, per l’occasione, è stata rivista in Mango, come possiamo vedere in figura).

image

Un tipo particolare di background agent

In uno dei tutorial pubblicati nell’ultimo mese abbiamo parlato di background agent, ovvero dei servizi che possono accompagnare la nostra applicazione e che sono in grado di eseguire operazioni in background, anche quando questa non è in esecuzione.

I servizi di background audio sono un tipo particolare di background agent: anche in questo caso parliamo di un progetto di Visual Studio separato dall’applicazione vera e propria, per il quale sono stati introdotti due differenti template, uno per i player “tradizionali” e uno per i player in streaming. In entrambi i casi, esattamente come per i background agent, avremo una classe che erediterà da AudioPlayerAgent, la quale offre una serie di eventi di cui potremo fare l’override per gestire gli eventi legati alla riproduzione.

Tra i due tipi di agent c’è però una differenza molto importante: se ricordate, i background agent sono servizi che vengono istanziati in foreground (dall’app vera e propria) ma che vengono poi eseguiti in background, quando questa non è in esecuzione. I background agent di tipo audio invece vengono invocati ogni qualvolta si interagisce con la riproduzione, anche se l’applicazione è aperta. Da qui, si deduce una considerazione molto importante: tutta la logica di riproduzione del nostro player è contenuta nel background agent. Proprio per questo motivo, il limite di memoria che può occupare un background agent di tipo audio è di 12 MB, al contrario dei 5 di un background agent tradizionale.

Da ciò emerge inoltre come l’applicazione vera e propria funga solo da “contenitore” per la nostra UI: si occuperà solamente, ad esempio, di mostrare le informazioni aggiornate sulla traccia corrente (titolo, autore, ecc.), ma ogni cambiamento di stato della riproduzione (pausa, play, traccia successiva, ecc.) verrà gestito dal background agent.

La classe AudioTrack

La classe AudioTrack è alla base dei servizi di background audio, in quanto definisce la singola traccia audio che possiamo riprodurre nella nostra applicazione. La classe AudioTrack non funge solamente da mero contenitore della canzone vera e propria, ma contiene anche tutta una serie di informazioni come titolo, autore, album fino ad arrivare alla copertina del disco. Vediamone un esempio:

AudioTrack track = new AudioTrack(
new Uri("http://localhost/Mango/AlbertFarrington-ItsALongWayToTipperary1915.mp3", UriKind.Absolute),
"It's a long way to Tipperary", "Albert Farrington", "Unknown album", “http://localhost/Mango/Cover.png");

Vediamo come il costruttore della classe AudioTrack supporti, già in fase di inizializzazione, i principali parametri che definiscono la traccia, nell’ordine:

I file relativi alla traccia e alla copertina possono essere memorizzati in due posizioni diverse: ospitati su un server web o salvati nell’Isolated Storage della nostra applicazione. Se ricordate quando abbiamo parlato di background transfers, infatti, ora siamo in grado di esprimere percorsi locali nello storage sotto forma di Uri.

Il ciclo di vita dei background agents

I background agents sono dei servizi che hanno un ciclo di vita molto breve: vengono infatti istanziati ad ogni utilizzo, per essere poi terminati una volta completato il loro lavoro. Già parlando di background agents tradizionali era emerso questo aspetto e di come fosse necessario mantenere certe informazioni nell’Isolated Storage così che non andassero perse.

Nei background agents di tipo audio diventa ancora più importante gestire bene questa architettura. Cosa succede infatti ogni volta che l’agent audio entra in azione (ad esempio, perchè l’utente ha premuto Play)?

  1. Il background agent viene istanziato.
  2. Vengono eseguite le operazioni relative al cambiamento di stato richiesto (ad esempio, eseguire la traccia audio richiesta).
  3. Il background agent viene terminato.

Diventa indispensabile perciò memorizzare tutta una serie di informazioni cruciali per la riproduzione (come quale traccia è correntemente in riproduzione) nell’Isolated Storage: se si mantenessero in memoria, all’esecuzione successiva il background agent avrebbe perso questa informazione e quindi si comporterebbe come se non ci fossero tracce in riproduzione in quel momento.

Nel prossimo post

Nel prossimo post realizzeremo un vero e proprio player multimediale per WIndows Phone, partendo dall’applicazione vera e propria e arrivando fino al background agent di tipo audio. Stay tuned!


Windows Phone , Microsoft , Mango

0 comments

Related Post