Guest Post di Matteo Pagani, MVP Windows Phone
Pochi giorni fa il team di Windows Phone ha rilasciato una nuova versione dei tool di sviluppo di Windows Phone, caratterizzata dal numero di versione 7.1.1.
Nota bene! La versione attuale dell'SDK 7.1.1 è in CTP (ovvero non è definitiva) e non ha la licenza go live: ciò significa che non potete pubblicare sul Marketplace applicazioni compilate con questa versione. Se volete perciò iniziare a fare esperimenti, vi consiglio di installare la nuova SDK su una macchina di test.
Non si tratta di una major release: l'unica novità è il supporto per i nuovi device low cost (come ad esempio il Nokia Lumia 610 presentato a Barcellona) che usciranno sul mercato, caratterizzati, oltre che da processori di potenza inferiore e da fotocamere con un numero ridotto di Mpixel, dalla presenza di 256 MB di RAM contro i 512 MB di cui sono dotati tutti i device attualmente in commercio.
La presenza di poche novità non significa che si tratti di una release di poco conto: la disponibilità di questi nuovi device apre infatti una serie di nuovi scenari, sia per gli utenti finali (questa strategia potrà sicuramente favorire una maggiore diffusione dei device Windows Phone) che per gli sviluppatori (che dovranno imparare a tenere conto del fatto che la loro applicazione potrà girare su device meno potenti).
In questo post vedremo come i tool e il sistema operativo si sono aggiornati per supportare questa nuova generazione di device.
L'emulatore
Per poter testare le nostre applicazioni su entrambe le tipologie di device senza doverli fisicamente possedere la nuova versione dei tool di sviluppo include un nuovo emulatore, in grado di simulare la presenza di 512 o 256 MB di RAM.
L'utilizz o è molto semplice: avete presente il menu a tendina incluso in Visual Studio che vi permette di specificare il target del deploy tra Windows Phone Device e Windows Phone Emulator? Questo menu è stato modificato, per supportare, oltre ovviamente al device, anche le due nuove tipologie di emulatore, come potete vedere nell'immagine:
Una volta lanciato l'emulatore, questi si comporterà come se avesse il limite di memoria che avete scelto, restituendo perciò un'eccezione nel momento in cui lo superate oppure nel caso in cui stiate usando qualche funzionalità non consentita sui device di fascia bassa.
Come identificare il tipo di device da codice
La strada migliore per poter supportare qualsiasi tipo di device è quella di migliorare il più possibile le performance della nostra applicazione, stando attenti agli sprechi e a consumi eccessivi che potrebbero essere risolti magari semplicemente con una progettazione migliore.
Ci sono però alcuni casi in cui proprio non è possibile ridurre il consumo di memoria, ad esempio perchè state utilizzando elementi multimediali (audio, video, immagini, ecc.) ad alta qualità. Quello che possiamo fare perciò, ad esempio, è non caricare determinate elementi oppure utilizzane degli altri di qualità inferiore. In questo caso ci serve però un meccansimo per riconoscere su che tipo di device è in esecuzione la nostra applicazione e, proprio per questo motivo, Microsoft ha aggiunto una nuova proprietà che ci restituisce la quantità massima di RAM disponibile all'applicazion e stessa.
Per ottenere questa informazione dobbiamo usare la classe DeviceExtendedProperties, disponibile sin dalla prima versione di Windows Phone, che ci permette di estrarre tutta una serie di dati riguardo al device come, ad esempio, l'ID univoco del device, la versione del firmware, ecc. (potete leggere questo post per approfondire l'argomento).
Nell'ultimo aggiornamento del sistema operativo è stata inclusa una nuova proprietà, chiamata ApplicationWorkingSetLimit, che rappresenta la massima quantità di memoria utilizzabile da un'applicazione. Tale valore sarà sempre inferiore ai 90 MB per i device con 256 MB di RAM: vi basta perciò recuperare questa proprietà per capire la tipologia di device. Vediamo come fare:
long memory = (long)DeviceExtendedProperties.GetValue("ApplicationWorkingSetLimit");
Questa istruzione vi restituirà la massima quantità di memoria utilizzabile dall'applicazione espressa in byte: il valore di riferimento è 94371840, che corrisponde a 90 MB (vi ricordo infatti che 1 KB corrisponde a 1024 byte, perciò non si tratta di un mulitplo preciso di 10).
La proprietà ApplicationWorkingSetLimit è disponibile però solo sui device che hanno già ricevuto l'update all'ultima versione di Windows Phone: può verificarsi perciò che la riga di codice riportata sopra restituisca un'eccezione di tipo ArgumentOutOfRangeException. In questa situazione avrete la certezza di trovarvi in presenza di un dispositivo con 512 MB di RAM (dato che i device di nuova generazione dotati di una quantità di RAM inferiore usciranno già in commercio con la versione più recente del sistema operativo). Per gestire questa casistica, la classe DeviceExtendedProperties espone un metodo TryGetValue, che accetta un ulteriore parametro in out. Cosa signific a? Che il metodo proverà a recuperare l'informazione richiesta e, in caso non si verifichino errori, andarà a salvarne il risultato nella variabile che abbiamo contrassegnato come out. In caso contrario, non si verificherà alcuna eccezione ma semplicemente il metodo restituirà false e la variabile indicata come out sarà impostata a null. Il codice seguente fa esattamente questa cosa: dopo aver dichiarato preventivamente una variabile di nome memory, cerchiamo di recuperare il valore della proprietà ApplicationWorkingSetLimit. Se il valore della variabile memory è a null oppure superiore a 94371840, allora siamo in presenza di un device dotato di 512 MB di RAM; in caso contrario, si tratta di uno dei nuovi device da 256 MB.
object memory;
DeviceExtendedProperties.TryGetValue("ApplicationWorkingSetLimit", out memory);
if (memory == null || (long)memory > 94371840)
{
MessageBox.Show("Device con 512 MB di RAM");
}
else
{
MessageBox.Show("Device con 256 MB di RAM");
}
Come ottimizzare la nostra applicazione?
Nel prossimo post vedremo l'impatto di questi nuovi device sulle nostre applicazioni: come ottimizzare l'uso della memori a, quali limiti dovremo gestire e come comportarci in caso non sia possibile ridurre in alcun modo il consumo di memoria da parte della nostra applicazione.
read full article
