BindableApplicationBar: un’alternativa alla ApplicationBar di Windows Phone

Print Content | More

La ApplicationBar, croce e delizia di tutti i programmatori Windows Phone: delizia perchè è molto utile e ci mette a disposizione un “luogo” in cui posizionare le funzioni principali della nostra applicazione; croce perchè ha una serie di limitazioni che la rendono un elemento un po’ a se rispetto a tutti i controlli di Silverlight. Nello specifico, la ApplicationBar non eredita da FrameworkElement (che è la classe padre di tutti i controlli Silverlight): il risultato è che vengono a mancare tutta una serie di proprietà fondamentali come DataContext.

In parole povere, la ApplicationBar non supporta il binding: se state perciò sviluppando un’applicazione seguendo il pattern MVVM, sarete costretti a “romperlo” per poter gestire gli eventi associati alla pressione dei pulsanti o dei menu item contenuti nella barra.

A risolvere questo problema ci ha pensato Nicolas Humann, uno sviluppatore che ha realizzato una BindableApplicationBar, ovvero una barra che si comporta in tutto e per tutto come quella originale, ma che in più supporta il binding e i command. In questo modo, invece di gestire gli eventi nel code behind, possiamo creare dei Command nel nostro ViewModel e associarli all’evento di tap dei pulsanti tramite il binding.

Una premessa: Nicolas Humann ha aggiornato il suo progetto per supportare Mango. La versione originale non era infatti compatibile con la nuova versione di Windows Phone, date le numerose differenze (Silverlight 4, infatti, a differenza di Silverlight 3 supporta nativamente i Command). La versione pubblicata sul suo blog, però, contiene un bug che fa si che il controllo non funzioni correttamente: se cercate di utilizzarlo così com’è si scatenerà un’eccezione di tipo ArgumentException con messaggio Default value type does not match type of property nel momento in cui verrà caricata la pagina che contiene il controllo.

Nello stesso post di annuncio della release compatibile con Mango un altro sviluppatore però ha indicato la correzione da apportare affinchè tutto funzioni correttamente: in allegato a questo post trovate perciò la versione corretta del controllo che non da errori.

Come usare la BindableApplicationBar

Una volta aggiunta una reference alla libreria Phone7.Fx.Preview.dll, dovete dichiarare il namespace a cui appartiene il controllo nel vostro XAML:

xmlns:Preview="clr-namespace:Phone7.Fx.Preview;assembly=Phone7.Fx.Preview"

Dopodichè, il “cuore” del controllo è il tag BindableApplicationBar, che può contenere due tipi di elementi:

  • BindableApplicationBarIconButton per aggiungere un’icona nella barra.
  • BindableApplicationBarMenuItem per aggiungere un menu item all’elenco.

Attenzione! Se guardate il codice di una pagina che utilizza la ApplicationBar standard, noterete che questa viene dichiarata fuori dalla Grid principale, proprio perché si tratta di un elemento a sé. La BindableApplicationBar, invece, si comporta come tutti gli altri controlli e quindi va inserita all’interno di tale Grid, che tipicamente si chiama LayoutRoot.

Ecco un esempio di BindableApplicationBar inserita all’interno di una pagina vuota:

<Grid x:Name="LayoutRoot" Background="Transparent">
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="*"/>
    </Grid.RowDefinitions>

    <!--TitlePanel contains the name of the application and page title-->
    <StackPanel x:Name="TitlePanel" Grid.Row="0" Margin="12,17,0,28">
        <TextBlock x:Name="ApplicationTitle" Text="MY APPLICATION" Style="{StaticResource PhoneTextNormalStyle}"/>
        <TextBlock x:Name="PageTitle" Text="page name" Margin="9,-7,0,0" Style="{StaticResource PhoneTextTitle1Style}"/>
    </StackPanel>

    <!--ContentPanel - place additional content here-->
    <Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0"></Grid>

    <Preview:BindableApplicationBar>
        <Preview:BindableApplicationBarIconButton IconUri="/Icons/Save.png" Text="Save" Command="{Binding Path=SaveCommand}" />
        <Preview:BindableApplicationBarMenuItem Text="Share" Command="{Binding Path=ShareCommand}" />
    </Preview:BindableApplicationBar>

</Grid>


Come vedete nell’esempio, abbiamo creato due metodi (SaveCommand e ShareCommand), che sono in binding con la proprietà Command. Utilizzando la ApplicationBar standard tutto ciò non sarebbe stato possibile!

Vi lascio con il download del codice sorgente della BindableApplicationBar con già apportata la correzione di cui vi ho parlato all’inizio. All’interno della cartella bin trovate la DLL già compilata e pronta per essere usata nei vostri progetti.

Se avete trovato questo post un po’ criptico perchè non sapete bene cosa sono i Command… beh, cercherò di rimediare a breve Smile

P.S.= se state sviluppando un’applicazione per Windows Phone 7.0 e avete necessità di usare la BindableApplicationBar, ecco il post da cui potete scaricare il progetto originale.


Windows Phone , Microsoft , Mango , ApplicationBar , Command , MVVM

1 comments

Le ultime dal mondo Windows Phone: Marketplace per Mango e Silverlight Toolkit

Print Content | More

Dopo la pausa estiva riprendono le novità riguardo Windows Phone, nello specifico relative a Mango. Si tratta dell’apertura del marketplace per le applicazioni a Mango (ormai imminente) e il rilascio della nuova versione del Silverlight Toolkit per Mango. Vediamole nel dettaglio.

Marketplace e Mango

Tramite un annuncio sul blog ufficiale Todd Brix ha reso note le modalità con cui verrà reso disponibile l’update compatibile con Mango delle nostre applicazioni agli utenti finali. Nel momento in cui caricheremo la “Mango release” della nostra applicazione, automaticamente tutti gli utenti che avranno già installato la nuova versione del sistema operativo riceveranno una notifica di update e potranno procedere con l’aggiornamento. Notifica che, invece, non verrà mostrata agli utenti fermi alla versione 7.0, i quali potranno continuare a scaricare la versione compatibile con la 7.0.

La nota dolente di questa procedura è che, una volta effettuato il submit della versione Mango, non avremo più modo di aggiornare la versione per NoDo: in condizioni normali non si tratterebbe di un grosso problema, anzi, sarebbe un grande punto a favore di Microsoft, perché accelererebbe notevolmente il processo di adozione di Mango da parte degli utenti finali, che sarebbero così invitati ad aggiornare il proprio device il prima possibile.

Sappiamo tutti però come sono andate le cose con NoDo, il quale, a causa dei vincoli imposti dai carrier, ha attraversato un processo di update non esente da problemi: il rischio perciò è che, se la distribuzione dell’aggiornamento dovesse subire dei ritardi e non essere uniforme in tutto il mondo, si potrebbero verificare dei problemi non indifferenti. Pensiamo ad esempio ad un client Twitter o ad un’applicazione che si appoggia ad un servizio di terze parti: se qualcosa lato server dovesse cambiare, saremmo in grado di aggiornare solamente la versione Mango per sistemare il problema. Il rischio perciò è che sul Marketplace inizino a proliferare doppie versioni di ogni applicazione, una per Windows Phone 7.0 e una Windows Phone Mango, così da essere in grado di mantenerle aggiornate entrambe.

Microsoft ha precisato però di essere conscia del problema e che farà tutto il possibile per evitare questa situazione: diamogli perciò fiducia e vediamo cosa succederà nei prossimi mesi.

Una nota importante: commenti, recensioni, descrizione e screenshot verranno “fusi”. Non sarà possibile avere perciò due descrizioni o delle immagini diverse per la versione 7.0 e per la versione Mango: Todd Brix, nel suo post, da perciò una serie di suggerimenti da tenere a mente, come aggiungere un testo in overlay sugli screenshot che mostrano funzionalità esclusive della versione 7.5 o aggiungere un link nella descrizione dell’applicazione alla pagina di Microsoft dedicata alla procedura di aggiornamento.

Silverlight Toolkit per Windows Phone 7.1 SDK

Microsoft ha rilasciato su Codeplex una nuova versione del Silverlight Toolkit compatibile con Windows Phone Mango. Questa release aggiunge una serie di nuovi controlli, migliorie a quelli già esisstenti e il supporto alle nuove lingue introdotte in Mango per alcuni di essi (come DateTimePicker).

Lo potete scaricare all’indirizzo http://silverlight.codeplex.com/releases/view/71550

Alla stessa pagina potete trovare anche l’elenco completo delle novità, che approfondiremo in un post dedicato più avanti.


Windows Phone , Microsoft , Mango , Marketplace , Silverlight Toolkit

0 comments

Buone vacanze a tutti!

Print Content | More

Finalmente sono arrivate le tanto attese vacanze estive e il blog non fa eccezione: per le prossime due / tre settimane gli aggiornamenti saranno molto più rari, soprattutto per quanto riguarda i tutorial tecnici, che invece riprenderanno regolarmente verso la fine del mese.

Ne approfitto per augurare a tutti, amici e visitatori, buone vacanze e soprattutto di godersi il meritato riposo. Ci si rivede a Settembre e quest’anno sarà una ripartenza con il botto: ci sarà BUILD con Windows 8 protagonista (vi ricordo l’evento BUILD Live se non vi siete ancora iscritti!), ci sarà la release ufficiale di Mango, ci sarà l’apertura del marketplace per le applicazioni compilate per la nuova versione di Windows Phone e tanto altro ancora.

A presto!


Windows Phone , Mango , BUILD , Windows 8

0 comments

Il multitasking in Mango: i background transfers – Un esempio pratico

Print Content | More

Ci siamo lasciati nel post precedente parlando della classe BackgroundTransferRequest, che permette di fare download e upload di dati anche ad applicazione chiusa. Abbiamo visto le proprietà esposte dall’oggetto, come possiamo configurarlo e quali eventi abbiamo a disposizione per gestire il ciclo di vita della richiesta.

Ora, come promesso, vediamo un po’ di codice concreto: nel post precedente abbiamo semplicemente inizializzato il trasferimento e lo abbiamo avviato. In questo articolo vedremo invece come gestire gli eventi messi a disposizione dall’oggetto e come gestire il fatto che il download potrebbe terminare mentre l’applicazione è chiusa.

L’applicazione che andiamo a realizzare è un semplice player audio, in grado di riprodurre musica sfruttando l’oggetto MediaElement. La canzone da riprodurre, però, verrà scaricata nell’Isolated Storage tramite la classe BackgroundTransferRequest: una volta completato il download, la canzone verrà riprodotta in automatico.

L’interfaccia della nostra applicazione

Partiamo dall’interfaccia, che vediamo nell’esempio:

<StackPanel>
    <MediaElement x:Name="MediaSong" /> 
    <ProgressBar x:Name="LoadingBar" />
    <TextBlock x:Name="Progress" />
    <Button Click="Button_Click" Content="Start transfer" />
</StackPanel>

Gli elementi che la compongono sono:

  • L’oggetto MediaElement vero e proprio, che useremo per la riproduzione audio.
  • Una ProgressBar, che mostrerà lo stato del download in maniera visuale.
  • Un TextBlock, che mostrerà lo stato del download in maniera testuale (byte trasferiti / byte totali).
  • Un pulsante, che darà l’avvio al download.

Gli eventi TransferProgressChanged e TransferStatusChanged

Nel post precedente ci siamo sottoscritti a questi due eventi, senza però entrare nel dettaglio implementativo. Partiamo dall’evento TransferProgressChanged, che viene scatenato nel momento in cui la quantità di dati trasferita è cambiata.

void backgroundRequest_TransferProgressChanged(object sender, BackgroundTransferEventArgs e)
{
    double received = backgroundRequest.BytesReceived;
    double total = backgroundRequest.TotalBytesToReceive;
    double percentage = (received/total)*100;

    LoadingBar.Value = percentage;

    Progress.Text = string.Format("{0} - {1}", received, total);
}

L’utilizzo tipico questo evento è quello di gestire un indicatore di download, che informi l’utente dello stato dell’operazione: noi non siamo da meno, perciò utilizziamo le informazioni esposte dalla classe BackgroundTransferRequest per riempire la nostra progress bar. Per fare questo, ci basta utilizzare due proprietà esposte dall’oggetto, ovvero BytesReceived (la quantità di byte trasferita) e TotalBytesToReceive (la dimensione totale in byte del file da scaricare). Occhio che questo evento è asincrono: se il trasferimento è veloce, può capitare perciò che venga richiamato più volte in poco tempo. Ecco perchè, prima di aggiornare la progress bar, andiamo a salvare le informazioni sul download in delle variabili locali: in caso contrario, andremmo sempre a recuperare il valore più recente e non riusciremmo a vedere il riempimento graduale della barra.

Vediamo ora invece quello che succede quando viene scatenato l’evento TransferStatusChanged.

void backgroundRequest_TransferStatusChanged(object sender, BackgroundTransferEventArgs e)
{
    if (backgroundRequest.TransferStatus == TransferStatus.Completed)
        PlayAudio();
}


private void PlayAudio()
{
    using (IsolatedStorageFile store = IsolatedStorageFile.GetUserStoreForApplication())
    {
        using (IsolatedStorageFileStream stream = new IsolatedStorageFileStream(Path.Combine("shared/transfers", "Cocaine.mp3"), FileMode.Open, FileAccess.Read, store))
        {
            MediaSong.SetSource(stream);
            MediaSong.Play();
        }
    }
}

Banalmente andiamo a controllare lo stato della richiesta: se questa è completata allora andiamo a invocare il metodo PlayAudio che, come possiamo vedere sotto, non fa altro che recuperare il file dall’Isolated Storage, leggerlo come stream di dati e assegnarlo come Source dell’oggetto MediaElement.

Il download in background

L’utente potrebbe però lanciare il download ed uscire dall’applicazione: in quel caso, dato che il processo è chiuso, non siamo più in grado di ricevere e gestire gli eventi TransferStatusChanged e TransferProgressChanged. Come facciamo perciò a riprodurre la nostra canzone una volta che l’utente è tornato nell’applicazione?

Il trucco sta nell’agganciarci all’evento OnNavigatedTo che ormai conosciamo molto bene e verificare qual è lo stato corrente del trasferimento, come nell’esempio:

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
    if (backgroundRequest!=null && backgroundRequest.TransferStatus==TransferStatus.Completed)
        PlayAudio();
}

In questo modo, se nel momento in cui l’utente rientra nell’applicazione il download è già terminato, la musica viene automaticamente riprodotta. Un’altra cosa che potremmo fare, nel caso in cui il download invece sia ancora in corso, è aggiornare la progress bar, così da riflettere il vero stato del download.

Il BackgroundTransferService

Come spiegato nel post precedente, il BackgroundTransferService è il servizio di scheduling che si occupa di gestire i trasferimenti in background. Analogamente a quanto possiamo fare con il ScheduledActionService, possiamo utilizzarlo per gestire tutta una serie di operazioni che possono risultare molto utili. Pensiamo ad un’applicazione mandata dallo stato Dormant allo stato Tombstoned (ricordate i post riguardo il nuovo ciclo di vita delle applicazioni in Mango?). In questo caso, essendo il processo terminato, al restore l’istanza dell’oggetto (o degli oggetti) di tipo BackgroundTransferRequest non esiste più: dobbiamo perciò recuperarlo tramite il BackgroundTransferService.

Per gestire questo tipo di situazioni ogni BackgroundTransferRequest è identificato da un id univoco, che viene assegnato all’istanza nel momento in cui questa viene creata. Tale id, di tipo string, è memorizzato nella proprietà RequestId: passando tale identificatore al metodo Find esposto dal BackgroundTransferService possiamo recuperare i download in corso nella nostra applicazione. Un esempio di scenario di utilizzo è memorizzare questi id nell’isolated storage, così da averli a disposizione anche in caso di tombstone per recuperare le informazioni sui trasferimenti in corso.

In conclusione

Abbiamo visto in dettaglio la nuova classe BackgroundTransferRequest, che può essere utilizzata in alternativa a WebClient e HttpWebRequest per gestire i trasferimenti di dati da Internet verso la nostra applicazione. Di seguito trovate il link per scaricare il progetto di esempio del quale vi ho mostrato qualche esempio di codice nel corso di questi due post.


Windows Phone , Microsoft , Mango , Background transfer , Multitasking

0 comments

Il multitasking in Mango: i background transfers

Print Content | More

Continuiamo il nostro percorso alla scoperta delle novità di Mango e parliamo questa volta dei background transfers, ovvero una nuova funzionalità che ci permette di gestire i download e gli upload di dati all’interno della nostra applicazione anche quando questa non è in esecuzione.

Al giorno d’oggi siamo abituati ad utilizzare due classi per gestire il flusso di dati verso l’esterno: WebClient (più semplice da usare ma meno performante) e HttpWebRequest (più complessa da usare ma più completa e veloce). In Mango abbiamo a disposizione una nuova classe per questo scopo, chiamata BackgroundTransferRequest, che ha la particolarità di poter continuare a mantenere il trasferimento attivo anche ad applicazione chiusa.

E’ bene ricordare che, dato che questo tipo di trasferimento può avere un impatto sulle performance e sul consumo di batteria, sono stati introdotti dei limiti analoghi a quelli per il download di applicazioni dal Marketplace: se si è collegati ad una rete 3G, il trasferimento massimo di dati consentito è di 20 MB, che diventano 2 GB se invece siamo collegati ad una rete Wi-Fi.

Prima di approfondire l’argomento, però, dobbiamo parlare di un’altra nuova feature di Mango, molto importante nell’utilizzo dei background transfers: il mapping dell’Isolated Storage.

Un nuovo metodo di mapping dell’Isolated Storage

Nella versione attuale di Windows Phone l’unico modo per lavorare con i file memorizzati nell’Isolated Storage è utilizzare le classi messe a disposizione dal framework, come IsolatedStorageFile e IsolatedStorageFIleStream.

In Mango è stata introdotta la possibilità di esprimere i file memorizzati nell’Isolated Storage con un Uri, in questo modo:

private Uri destinationUrl = new Uri("/shared/transfers/Cocaine.mp3", UriKind.RelativeOrAbsolute);

L’esempio qui riportato è un Uri che punta al file Cocaine.mp3 memorizzato nella cartella transfers dell’Isolated Storage. Nei background transfers questo nuovo metodo di mapping è molto importante, dato che quando viene inizializzata la classe BackgroundTransferRequest è necessario specificare sia la sorgente che la destinazione proprio sotto forma di Uri. Questo perchè il download potrebbe terminare anche ad applicazione chiusa: in quel caso, se mantenessimo il file scaricato solamente in memoria non avremmo modo di gestirlo.

In realtà, questo nuovo metodo di mapping può tornare utile in tutti gli scenari in cui l’oggetto con cui si sta lavorando esponga delle proprietà che accettano un Uri come sorgente: se prima eravamo limitati a riferirci solamente a risorse incorporate nel progetto oppure esposte sul web, da oggi possiamo anche utilizzare file memorizzati nell’Isolated Storage (pensiamo ad esempio alla proprietà BackgroundImage delle tile).

Iniziamo il trasferimento

Ora che abbiamo capito come funziona il nuovo metodo di mapping, vediamo come gestire il trasferimento di dati. Innanzitutto dobbiamo definire un Uri sorgente (il file che vogliamo scaricare) e un Uri di destinazione (dove vogliamo salvare il file). Occhio che abbiamo l’obbligo di salvare tutti i file scaricati usando la classe BackgroundTransfer all’interno della cartella shared/transfers che, se non esiste, verrà creata all’occorrenza (occhio che, come raccontato in un mio post, la posizione di questa cartella è cambiata dalla beta1 alla beta2). Possiamo aggiungere altri file o altre sottocartelle all’interno di transfers, possiamo spostare il file una volta terminato il download, ma non abbiamo la possibilità di scaricare direttamente i file al di fuori di essa.

L’URL sorgente deve essere passato come parametro in fase di inizializzazione dell’oggetto, mentre l’URL di destinazione può essere passato sia come secondo parametro, sia definito in un secondo momento tramite la proprietà DownloadLocation.

Vediamo un esempio di codice, che poi commenteremo:

backgroundRequest = new BackgroundTransferRequest(sourceUrl, destinationUrl);
backgroundRequest.Method = "GET";
backgroundRequest.TransferPreferences = TransferPreferences.AllowCellularAndBattery;
backgroundRequest.TransferProgressChanged += new EventHandler<BackgroundTransferEventArgs>(backgroundRequest_TransferProgressChanged);
backgroundRequest.TransferStatusChanged += new EventHandler<BackgroundTransferEventArgs>(backgroundRequest_TransferStatusChanged);

BackgroundTransferService.Add(backgroundRequest);

Come potete notare, la classe BackgroundRequest permette di definire le classiche impostazioni di una connessione HTTP, come il metodo (nell’esempio, POST) e gli headers. Ben più importante è sottolineare la proprietà TransferPreferences, che permette di definire le condizioni che devono essere soddisfatte affinché il trasferimento venga mantenuto in background. Le possibili opzioni sono:

  • None: è l’impostazione di default, consente il trasferimento solo se il device è in ricarica e collegato ad una rete Wi-Fi.
  • AllowBattery: consente il trasferimento solo se il device è collegato ad una rete Wi-Fi, ma è indifferente quale tipo di alimentazione si sta usando.
  • AllowCellular: consente il trasferimento solo se il device è in ricarica, ma è indifferente se sia collegato ad Internet tramite una rete Wi-Fi o tramite rete cellulare.
  • AllowCellularAndBattery: consente sempre il trasferimento, indipendente dal tipo di alimentazione e dal tipo di rete a cui è collegato.

Infine notiamo come l’oggetto ci metta a disposizione due eventi che possiamo sottoscrivere:

  • TransferProgressChanged: questo evento viene scatenato ogni qualvolta la quantità di dati trasferita cambia. Tipicamente, viene utilizzato per gestire eventuali progress bar o indicatori di altro tipo che mostrino lo stato del trasferimento.
  • TransferStatusChanged: questo evento viene scatenato nel momento in cui lo stato del trasferimento cambia. Questo tipo di informazione ci dice non solo se il trasferimento è stato completato (Completed), ma anche se ad esempio il device è in attesa di essere collegato ad una sorgente di alimentazione esterna (WaitingForExternalPower), ad una rete Wi-Fi (WaitingForWiFi) o se si trova in modalità risparmio batteria (WaitingDueToBatterySaverMode), in base alle impostazioni che abbiamo definito in precedenza.

Per dare via al trasferimento lo dobbiamo aggiungere al BackgroundTransferService che, analogamente a quanto fa lo SchedulerActionService per i task, si occupa di gestire lo scheduling dei trasferimenti in background.

Nella prossima puntata

Nel prossimo post vedremo un progetto di esempio più articolato, in cui gestiremo sia gli eventi esposti dalla classe BackgroundTransferRequest, sia il fatto che il trasferimento del file potrebbe terminare nel momento in cui la nostra applicazione è chiusa.


Windows Phone , Microsoft , Mango , Background transfer , Multitasking

0 comments

Il nuovo processo di submit di un’applicazione Windows Phone

Print Content | More

Come promesso, eccovi una semplice guida step by step per il nuovo processo di submit di un’applicazione Windows Phone nella nuova versione del portale App Hub.

Step 1: upload

step1

Analogamente a quanto avveniva nella versione precedente, anche se con una nuova grafica, in questo step andremo a:

  • Specificare il nome dell’applicazione da visualizzare nel portale (che, vi ricordo, non è il nome con cui comparirà l’applicazione sul Marketplace).
  • Caricare il file XAP.
  • Specificare il numero di versione

La novità è che ora potremo scegliere se pubblicare l’applicazione sul Marketplace o se distribuirla in forma privata per il beta testing, grazie all’opzione Distribute to. Non c’è più l’area per segnalare eventuali istruzioni per il tester: è stata infatti spostata nell’ultimo step.

Step 2: describe

step2

Questa sezione è rimasta più o meno invariata (layout grafico a parte) e ci permette di specificare tutte le informazioni che verranno visualizzate sul marketplace: icone, screenshot, descrizione, ecc. La novità è il metodo di caricamento delle immagini che, come anticipato nel post precedente, è molto più agevole: ora vi basterà selezionare in un colpo solo tutte le immagini e ci penserà il sistema a inserirle nella “casella” giusta, in base alle dimensioni.

Step 3: price

step3

Questo step non verrà visualizzato se avete scelto la distribuzione beta dell’applicazione. Anche in questo caso, layout grafico a parte, le informazioni richieste sono rimaste invariate: prezzo, disponibilità della trial e paesi in cui distribuire la vostra applicazione. Potete selezionarli uno per uno oppure cliccare su Select All per selezionarli tutti: tale pulsante è disponibile a livello globale (Worldwide distribution) o per continenti (Africa / Asia / Oceania, Europa, America).

Step 4: test (distribuzione beta)

test

Questo step viene visualizzato solo se avete scelto la distribuzione in beta e vi da la possibilità di specificare i Live Id delle persone che verranno invitate a partecipare al programma di testing. Potete specificare un massimo di 100 indirizzi, separati da un punto e virgola. Questo Live Id deve coincidere con quello primario registrato sul telefono della persona.

Step 4: test (distribuzione tradizionale)

step4

Questo step viene visualizzato solo se avete scelto la distribuzione sul Marketplace. In questa sezione potete inserire delle note particolari per chi testerà la vostra applicazione (ad esempio, credenziali di servizi, limitazioni da tenere a mente, ecc.) e cosa fare una volta che il processo di certificazione è stato superato. Alle opzioni già presenti in passato (pubblicazione automatica o manuale) ne è stata aggiunta una, ovvero As soon as it’s certified, but make it hidden. Questa è l’opzione da selezionare se volete distribuire la vostra applicazione in forma privata: in questo caso, infatti, verrà pubblicata sul marketplace ma non sarà visibile, se non conoscendone il deep link.

Una volta premuto il pulsante Submit, darete via al processo di pubblicazione: se avete scelto la distribuzione in beta, dovrete attendere qualche ora affinché l’applicazione sia disponibile e vi venga inviata la mail con il deep link e il riepilogo delle persone che avete scelto come tester; se avete scelto la distribuzione tradizionale, dovrete attendere invece l’esito del processo di certificazione.

Gestire il ciclo di vita della vostra applicazione

Come anticipato nel post precedente, ora avete una serie ulteriore di opzioni per gestire la vostra applicazione, raggiungibili dalla pagina di dettaglio, alla voce lifecycle.

image

Le opzioni disponibili sono:

  • Hide application: se volete distribuire privatamente un’applicazione che avevate già pubblicato in precedenza, questa è l’opzione da scegliere.
  • Submit an update: per caricare una nuova versione dell’applicazione.
  • Edit catalog details: per modificare le informazioni sul Marketplace relative all’applicazione.
  • Edit pricing: per modificare il prezzo e i paesi in cui l’applicazione viene distribuita.
  • Remove from catalog: per rimuovere completamente l’applicazione dal marketplace.

I crash report

Una delle novità più interessanti del nuovo App Hub è la disponibilità dei report dei crash, che vi dicono quante volte è crashata la vostra applicazione e per quale motivo. Per visualizzarli, vi basta andare nella sezione Reports e selezionare Crash reports. Qui, a colpo d’occhio, potremo vedere il numero di crash delle nostre applicazioni distribuiti nel tempo: avremo la possibilità di filtrare il grafico per applicazione e di modificare l’arco temporale visualizzato. In più, cliccando sul pulsante Stack traces, scaricherete un file Excel, con l’elenco dettagliato dei crash e il relativo stack trace.

image


Windows Phone , Microsoft , Marketplace , App Hub

1 comments

Nuova beta di Mango e nuovo aggiornamento dei tool!

Print Content | More

L’altro giorno Microsoft ha annunciato ufficialmente, tramite un post sul blog del team di sviluppo, che. Mango ha raggiunto lo stadio di RTM. Questo vuol dire che la nuova versione di Windows Phone è ora completa e può essere inviata ai vari carrier e vendor per iniziare la fase di testing e di preparazione dell’update per questo autunno.

La vera sorpresa però è stata la release, nella serata di ieri, di una nuova beta di Mango, più aggiornata, per tutti gli sviluppatori! Questa beta, marcata dal build number 7712, non è però la RTM, ma una versione che si avvicina molto: questo per garantire la compatibilità tra i tool di sviluppo e il device, come spiegato da Cliff Simpkins nel post di annuncio ufficiale.

Questa nuova beta introduce alcune delle feature lato consumer che erano ancora mancanti nella beta precedente, come l’integrazione con Twitter.

Come si installa questa nuova versione? Su Connect, se avevate ricevuto a suo tempo l’invito per entrare nella beta di Mango, troverete da scaricare un nuovo set di file, composto da le nuove versioni di Zune, del tool UpdateWP e del tool di aggiornamento DevUpdate. In realtà, questi tool sono rivolti soprattutto a chi non ha installato la beta precedente e offrono un processo di update più snello e veloce. Se infatti avete già un telefono con installato Mango, vi basterà collegarlo al PC: Zune (la versione 4.8 beta che è stata resa disponibile qualche mese fa su Connect è sufficiente) rileverà la presenza di un update e vi offrirà di aggiornare il telefono, esattamente come se si trattasse di un aggiornamento ufficiale.

Nuovi tool di sviluppo

In contemporanea, sempre su Connect, è stato rilasciato un refresh della Beta 2 dei tool di sviluppo, da usare in coppia con la nuova release di Mango. Quali sono le novità principali?

  • Dal punto di vista delle API, questa release si può considerare definitiva (noterete infatti durante l’installazione che è marcata come RC): potete stare certi perciò che le applicazioni compilate con questa versione saranno compatibili anche con la RTM, che uscirà in contemporanea con l’apertura del Marketplace per Mango a fine Agosto.
  • E’ stata aggiunta all’emulatore la funzionalità integrata (annunciata a suo tempo al MIX) per scattare screenshot dell’applicazione, da utilizzare nel processo di submit sul Marketplace.
  • Parecchie migliore sono state introdotte al profiler.
  • Chiunque sia uno sviluppatore Microsoft credo concorderà con me che NuGet è una delle invenzioni migliori degli ultimi anni: per chi non lo conoscesse, si tratta di un repository globale di librerie e toolkit che permette di installare velocemente (e risolvendo in automatico eventuali dipendenze) le tante, tantissime librerie .NET che ci sono in circolazione. Uno dei limiti della versione Express di Visual Studio è che, non supportando le estensioni, mancava di tale tool: limite che però ora è stato rimosso. Nel momento in cui installate i tool, se non avete già Visual Studio, verrà installata una versione Express comprensiva di NuGet.
  • Novità molto gradita è l’aggiunta di un nuovo tool (ancora non definitivo) chiamato Marketplace Test Kit, che permette di replicare gli stessi test automatici che vengono fatti dal Marketplace nel momento in cui facciamo submit di un’app. In questo modo, saremo in grado di fare il submit con la certezza che la nostra applicazione non soffrirà almeno di quella parte di problemi che vengono rilevati proprio da tali test: non ci garantirà comunque che l’applicazione passerà la certificazione, dato che una serie di test (ad esempio, quelli sulla localizzazione e sui contenuti) non possono essere automatizzati e vengono svolti dalle persone del team di certificazione.


Windows Phone , Microsoft , Mango

0 comments

The [NeutralResourceLanguage] attribute is missing on the entry assembly (2003): come risolvere l’errore con il nuovo App Hub

Print Content | More

Se avete provato a fare submit di un’applicazione Windows Phone con il nuovo App Hub è probabile che vi siate imbattuti questo errore, che si verifica dopo il primo step, quello in cui caricate lo XAP della vostra applicazione.

error

Questo errore si verifica in quanto è cambiato uno dei requisiti dell’assembly dell’applicazione, ovvero ora è necessario specificare la lingua base della nostra applicazione. Come facciamo a impostarlo?

Semplice, facciamo clic con il tasto destro sul progetto della nostra applicazione, scegliamo Properties e Assembly Information.

SNAGHTML22452732

Come potete vedere, l’ultima voce è proprio Neutral Language, che di default sarà valorizzata su (none). Dal menu a tendina selezioniamo la lingua principale della nostra applicazione, ricompiliamo e carichiamo il nuovo XAP nel primo step: questa volta tutto andrà a buon fine e verrete portati allo step 2.


Windows Phone , Mango , App Hub , Microsoft

2 comments

Grandi novità per App Hub, il portale per gli sviluppatori Windows Phone

Print Content | More

image

Come anticipato in uno dei miei ultimi post, settimana scorsa App Hub, il portale tramite il quale gli sviluppatori possono gestire il ciclo di vita delle applicazioni Windows Phone sul marketplace, è stato offline per diverse ore per aggiornamenti, i quali hanno portato tantissime novità, tanto che si può praticamente parlare di un nuovo portale: nuova grafica, nuove funzionalità, nuovi paesi supportati.

A tale aggiornamento è seguito un annuncio sul blog ufficiale del team di sviluppo con l’elenco di tutte le novità. Vediamole in dettaglio.

Nuovi mercati e nuove lingue 

Il nuovo App Hub apre le porte a nuovi mercati e a nuovi sviluppatori: sono infatti 19 i nuovi paesi in cui potremo vendere le nostre applicazioni (tra cui mercati importanti come la Cina e diversi paesi europei) e 7 quelli in cui gli sviluppatori potranno registrarsi e inviare le proprie applicazioni.

Occhio che, di default, i nuovi mercati non vengono abilitati per la distribuzione: se avete perciò applicazioni sul Marketplace ricordatevi, a meno che non abbiate buoni motivi per non farlo, di abilitare anche i nuovi paesi. In questo modo, anche gli utenti Windows Phone dei nuovi 19 paesi potranno scaricare la vostra applicazione.

Una notizia molto interessante è che anche il programma Advertising di Microsoft si espanderà in 18 nuovi paesi, tra cui l’Italia: come sapete, infatti, Microsoft ha un suo programma pubblicitario per le applicazioni Windows Phone, con tanto di controllo ufficiale, che prima veniva distribuito a parte mentre ora è integrato nei tool di sviluppo (dalla beta 2 di Mango in poi). Attualmente, il programma è attivo solo negli Stati Uniti e (da poco) in Inghilterra: questo significa che potete usare comunque il controllo, ma non avrete modo di ricevere i compensi legati all’advertising. Entro fine anno anche noi italiani invece potremo iniziare ad usare il controllo e ricevere i pagamenti.

Nuovi marketplace privati

Questa era una novità tanto attesa da tutti gli sviluppatori: la possibilità di distribuire applicazioni in forma privata, sia per scopi di testing che ad esempio per scenari di business. In entrambi i casi, l’applicazione sarà effettivamente pubblicata sul Marketplace: la differenza è che non verrà mai visualizzata tra i risultati di ricerca, ma sarà scaricabile solo conoscendone il deep link. Vediamo come funzionano e come si usano queste due nuove forme di distribuzione.

Marketplace beta

Il marketplace beta ci da la possibilità di far testare la nostra applicazione prima di distribuirla, alla ricerca di bug e problemi. L’applicazione sarà scaricabile solo conoscendone il deep link: in più, le persone che faranno da tester dovranno essere esplicitamente autorizzate tramite il Live Id associato al loro telefono.

Il caricamento sul marketplace beta viene attivato nel primo step della pubblicazione: attivando questa opzione, alla fine del processo, al posto della selezione del prezzo e dei paesi per la distribuzione, vi verrà richiesto di specificare i Live Id che saranno abilitati all’installazione. Dopodichè, nel giro di qualche ora l’applicazione verrà pubblicata e voi riceverete una mail contenente il deep link, che dovrete distribuire alle persone che avete incluso nella lista dei tester.

Tali persone (che non devono essere per forza di cose sviluppatori, basta essere semplicemente possessori di un device) saranno in grado di installare la vostra applicazione in maniera gratuita, la quale avrà validità per 90 giorni: dopodichè , cesserà di funzionare. I vostri tester avranno la possibilità di dare un voto e lasciare commenti esattamente come per un’applicazione tradizionale: tali informazioni saranno però visibili solamente a voi.

Ovviamente, trattandosi di un’applicazione in beta non verrà applicato il processo di certificazione: sarà necessario solamente attendere qualche ora per la pubblicazione e per l’invio della mail.

Purtroppo al momento il Marketplace beta ha qualche limitazione:

  • Siete costretti a caricare tutto il materiale normalmente richiesto per la pubblicazione, come dettagli, icone e screenshot. E’ plausibile invece che uno sviluppatore si concentri prima sull’applicazione vera e propria e poi, prima della pubblicazione, si occupi di creare tutto il materiale necessario.
  • Non è possibile convertire un’applicazione beta in una tradizionale: una volta che abbiamo chiuso la fase di beta testing, dobbiamo fare un nuovo submit per pubblicarla sul marketplace, creando perciò un “doppione”.
  • Non è possibile caricare l’update di un’applicazione beta: se abbiamo realizzato un aggiornamento che vogliamo far testare, dobbiamo fare un submit di una nuova applicazione.

Ultima nota importante: al momento il deep link funziona solamente dal telefono, se provate ad aprirlo dal computer con Zune otterrete il messaggio Location not found. Probabilmente questo problema è da imputare proprio a Zune e verrà perciò risolto con un update successivo.

Marketplace privato

Il marketplace privato era molto atteso soprattutto per gli scenari business, in cui era richiesto che le applicazioni sviluppate non fossero visibili da tutti. La soluzione adottata da Microsoft è quella di utilizzare comunque il Marketplace tradizionale, ma nascondendo l’applicazione dai risultati della ricerca: solo conoscendo il deep link sarà possibile installarla. E’ possibile attivare questa opzione sia in fase di submit che in un secondo momento; con questa soluzione è possibile distribuire sia applicazioni gratuite che a pagamento.

Questo tipo di distribuzione prevede comunque il superamento della fase di certificazione, così come per le applicazioni pubbliche.

Tante novità che vi semplificheranno la vita

Questo aggiornamento del’App Hub è una boccata di aria fresca per tutti gli sviluppatori, dato che riduce notevolmente il tempo necessario per pubblicare un’applicazione e ci permette di gestire in maniera più agevole il suo ciclo di vita. Come?

  • Finalmente è possibile cambiare le informazioni sulla nostra applicazione (icone, screenshot, descrizioni, ecc.) in qualsiasi momento, senza essere obbligati a fare submit di un update.
  • E’ possibile esportare i report di vendita e di download.
  • Ora sono disponibili anche informazioni dettagliate sui malfunzionamenti della vostra applicazione: sarete in grado di sapere quante volte è andata in crash e per quali motivi (grazie allo stack trace completo dell’errore).
  • Nuova procedura di upload delle immagini: ora è sufficiente selezionare tutte le immagini richieste in fase di pubblicazione (icone, screenshot, ecc) e ci penserà il sistema, in base alla dimensioni, a capire di quali si tratta. Prima si era costretti a caricare le immagini una per una (e il fatto che il file browser di Silverlight non memorizza l’ultima posizione aperta non era d’aiuto nel velocizzare il processo).
  • Sono disponibili nuove categorie e sottocategorie con cui classificare le vostre applicazioni.
  • Se avete una submission incompleta, ora potete eliminarla definitivamente.

Niente più GeoTrust per gli sviluppatori individuali

Altra ottima notizia: se siete sviluppatori individuali (non vi state perciò registrando su App Hub come azienda) ora il processo di verifica della vostra identità viene fatto semplicemente tramite la carta di credito, il cui intestatario deve coincidere con il proprietario dell’account. Se invece siete studenti e volete aprire un account gratuito, allora verrà verificato che i dati di registrazione coincidano con quelli del vostro account su Dreamspark.

Questo significa niente più verifica tramite GeoTrust, che aumentava notevolmente (soprattutto nei periodi più “caldi”) i tempi di approvazione dell’account. Diverso è il discorso se avete intenzione di aprire un account business: in tal caso la verifica della vostra identità tramite GeoTrust  è ancora richiesta, in quanto è indispensabile verificare che voi abbiate l’autorità per fare operazioni per conto dell’azienda che rappresentate.

Apertura del Marketplace per Mango a fine Agosto

A fine Agosto verrà rilasciata la versione RC (release candidate) dei tool di sviluppo per Mango: in parallelo, sul Marketplace sarà possibile iniziare a caricare le applicazioni compatibili con Mango, che dovranno essere compilate proprio con questa versione. Le applicazioni saranno disponibili inizialmente per i device degli sviluppatori già aggiornati con la beta di Mango e poi per tutti, man mano che la versione finale di Mango verrà rilasciata e resa disponibile a tutti.

Nel prossimo post

Nel prossimo post vi illustrerò step by step il nuovo processo di submit di un’applicazione Windows Phone: come caricare un’applicazione beta, le differenze rispetto al passato, ecc. Vedremo inoltre come usare il portale per gestire alcuni dei nuovi scenari: distribuire un’applicazione privatamente, vedere i report dei crash, ecc.


Windows Phone , Marketplace , App Hub , Mango

3 comments

BUILD Live: aperte le iscrizioni!

Print Content | More

BUILD

Come saprete, il 13 Settembre avrà inizio ad Anhaeim (California) BUILD, la conferenza per sviluppatori Microsoft più importante probabilmente non solo di quest’anno ma anche di quelli passati. A BUILD infatti verrà presentato ufficialmente Windows 8 e, soprattutto, le novità relative all’aspetto che ci interessa di più: lo sviluppo di applicazioni. La curiosità è tanta, soprattutto dopo i primi annunci fatti da Microsoft in cui sono emersi alcune novità importanti, come la forte integrazione con HTML5.

Purtroppo la partecipazione a BUILD non è alla portata di tutti, dato il costo della conferenza e del viaggio: per questo motivo Microsoft Italia, in collaborazione con le community italiane, ha organizzato un evento chiamato BUILD Live che toccherà le principali città e che permetterà a tutti di seguire in diretta streaming il keynote iniziale.

Certo, lo streaming sarà disponibile per tutti, ma volete mettere seguire la conferenza in compagnia? Smile

La scaletta sarà grosso modo la stessa per tutti gli appuntamenti, ovvero:

  • Ore 15: Registrazione
  • Ore 15:30: sessione a cura delle community
  • Ore 16:45: sessione a cura delle community
  • Ore 18: Keynote in diretta streaming
  • Ore 20: Aperitivo e buffet, per scambiarsi opinioni e pareri su quanto annunciato

In alcuni appuntamenti le sessioni sono già state fissate, in altri (come a Milano) sono ancora da definire. Se avete intenzione di partecipare, è importante iscriversi il prima possibile dato che i posti sono limitati. Vi ricordo che l’evento è completamente gratuito!

Io ovviamente non mancherò alla tappa di Milano (organizzata in collaborazione con UGIdotnet, Visual Basic Tips & Tricks e DotNetLombardia), che per l’occasione inaugurerà l’auditorium multimediale della nuova sede di Microsoft a Peschiera Borromeo.

Potete trovare l’elenco completo degli eventi completo di link per l’iscrizione all’indirizzo http://www.microsoft.com/italy/eventi/tour/frmRicercaEventi.aspx

Ci vediamo a Settembre!


Microsoft , BUILD , Windows 8

0 comments