21

Jan

WebBrowser, App Hub e capabilities: occhio alla proprietà x:Name!

Recentemente ho avuto un’esperienza singolare con il marketplace e voglio raccontarvela, nel caso doveste imbattervi nella stessa problematica.

Ho realizzato un’applicazione dedicata al mio blog, con la possibilità di vedere i miei ultimi post e i miei ultimi tweet. L’applicazione è molto semplice: ho utilizzato la libreria Quick And Feed Dirty Parser per fare il parsing dei feed RSS. E’ possibile leggere ogni post direttamente dall’applicazione, grazie ad una view dedicata contenente un controllo WebBrowser

Ho fatto il submit dell’applicazione parecchie volte e tutte le volte è stata rifiutata: il problema è che non ero in grado in alcun modo di riprodurre il motivo che veniva indicato nel report, ovvero un crash sistematico dell’applicazione nel momento in cui veniva selezionato un post.

Dopo parecchi tentativi il team del Marketplace è entrato in contatto con me e, dopo uno scambio di mail, ho scoperto il problema, dovuto ad uno step del processo di submit di cui non ero a conoscenza. Avete presente CapDetect, il tool a linea di comando in grado di analizzare un progetto Windows Phone e restituire l’elenco delle capabilities richieste dall’applicazione? Questo tool analizza l’IL prodotto dalla compilazione e non lo XAML e, per questo motivo, a volte i risultati non sono perfetti: ad esempio, può capitare che vengano riconosciute delle capabilities che poi effettivamente non sono utilizzate, oppure che alcune di quelle impiegate non vengano rilevate correttamente.

Questo tool viene utilizzato anche da App Hub in fase di submit: le eventuali capabilities presenti nel file di manifest che non vengono rilevate vengono automaticamente rimosse.

E’ bastato un semplice test con il CapDetect tool per capire che mi trovavo proprio in questa situazione: la capabilities ID_CAP_WEBBROWSERCOMPONENT (necessaria per le applicazioni che fanno uso del controllo WebBrowser) non veniva rilevata. Di conseguenza, in fase di submit questa veniva rimossa, causando il crash sistematico dell’applicazione nel momento in cui si selezionava un post e veniva fatto il redirect alla view contenente il controllo WebBrowser.

La soluzione a questo problema è molto semplice: basta valorizzare la proprietà x:Name del controllo, affinchè questo venga istanziato nel codice sorgente e venga quindi rilevato dal tool CapDetect. Nel mio caso, non lo avevo fatto perché ho sviluppato l’applicazione usando il pattern MVVM e quindi non mi serviva nel codice riferirmi al controllo direttamente.

Ovviamente, si tratta di un workaround e non di una soluzione vera e propria: in Silverlight non è obbligatorio valorizzare la proprietà x:Name di un controllo, anzi, è buona prassi non farlo in caso non sia necessario per ridurre il consumo di memoria (anche se in minima parte). In attesa però di una versione più efficiente del tool CapDetect è sicuramente una soluzione pratica e funzionale!

In linea di massima, comunque, fate un sempre un test con il CapDetect tool (o con il Marketplace Test Kit, che è il suo sostituto nella versione 7.1 dell’SDK) e assicuratevi che le capabilities richieste dalla vostra applicazione siano tutte rilevate: se così non fosse, correte il rischio che in fase di submit succeda lo stesso e quindi che la vostra applicazione non funzioni correttamente, come nel mio caso.

by Il blog di Matteo Pagani on 1/21/2012
Post archive