Quando parliamo di applicazioni mobili, lo sviluppo non è l'unico aspetto che dobbiamo considerare. Se vogliamo avere successo, dobbiamo anche distribuire e promuovere la nostra applicazione. In questo tutorial, discuteremo della localizzazione, dello store Windows Phone e degli acquisti in-app.
App di prova
Una delle caratteristiche distintive delle applicazioni Windows Phone è che supportano una modalità di prova, che consente loro di essere scaricati da Windows Phone Store come una versione di prova con funzionalità limitate. Una volta che gli utenti decidono di acquistare l'intera applicazione, non devono scaricarlo da zero; lo Store scaricherà semplicemente un certificato aggiornato, che sbloccherà tutte le funzionalità precedentemente bloccate.
Dal punto di vista dello sviluppatore, la gestione di una sperimentazione è semplice. Il Windows.ApplicationModel.Store namespace contiene una classe chiamata LicenseInformation, che offre una proprietà chiamata IsTrial. Se il suo valore è vero, significa che l'applicazione è stata installata in modalità di prova, quindi dobbiamo bloccare le funzionalità che non vogliamo abilitate; in caso contrario, l'utente l'ha acquistato, quindi tutte le funzionalità possono essere rese disponibili.
Sta a te scegliere la migliore esperienza di prova per la tua applicazione. Ad esempio, puoi disabilitare alcune funzionalità, limitare il numero di volte che le applicazioni possono essere eseguite, o in un gioco, scegliere quali livelli sbloccare.
LicenseInformation info = new LicenseInformation (); if (info.IsTrial) MessageBox.Show ("L'applicazione è in esecuzione in modalità di prova"); else MessageBox.Show ("L'applicazione è in esecuzione in modalità completa!");
Localizzazione
Uno dei modi migliori per aumentare le vendite e il numero di download di un'applicazione è supportare più lingue. Il modello predefinito di Windows Phone 8 in Visual Studio supporta già la localizzazione includendo una cartella chiamata risorse. Contiene tutti i file di risorse, che sono semplici file XML con uno speciale .resx estensione.
I file di risorse sono semplicemente una raccolta di valori (il testo tradotto) associati a una chiave specifica che viene utilizzata nell'applicazione per fare riferimento a quel testo. Secondo la lingua dell'utente, l'applicazione utilizzerà automaticamente il file di risorse appropriato.
Il modello standard crea un file chiamato AppResources.resx dentro il risorse cartella, che si riferisce alla lingua standard (di solito inglese).
Sostenere una nuova lingua è facile. Appena tasto destro del mouse il tuo progetto nel Esploratore di soluzioni e scegliere Proprietà. Il riquadro delle colture supportate mostrerà tutte le lingue disponibili. Quando aggiungi nuove lingue selezionandole nell'elenco, Visual Studio creerà automaticamente una nuova AppResources file chiamato AppResources.xx-yy.resx nella cartella Risorse, dove xx-yy è il codice cultura della lingua selezionata (ad esempio, se hai aggiunto italiano, verrà creato un file chiamato AppResources.it-IT.resx).
Visual Studio offre un utile editor visuale per lavorare con i file di risorse. Visualizza tutti i valori all'interno di una tabella, in cui è possibile definire facilmente una chiave, il suo valore e un commento facoltativo. Per accedervi, semplicemente doppio click su un file di risorse nel risorse cartella.
Oltre a offrire un file di risorse standard, il modello di Windows Phone include anche una classe chiamata LocalizedStrings, che funge da wrapper tra il file di localizzazione e XAML. Potete trovarlo definito come una risorsa globale nel App.xaml file:
Grazie a questo wrapper, sarai in grado di accedere alle risorse direttamente in XAML. Non è necessario aggiungerlo direttamente in XAML ogni volta che è necessario visualizzare il testo nell'interfaccia utente; invece dovrai aggiungere i file di risorse e quindi collegarli al tuo XAML con la seguente sintassi:
Grazie al LocalizedStrings classe, possiamo accedere ad ogni valore nel file di risorse semplicemente usando il LocalizedResources.MyKey sintassi, dove La mia chiave è la chiave che identifica il testo che vuoi mostrare.
Se si desidera accedere alla stringa di risorse direttamente dal codice, sarà necessario utilizzare il AppResources classe singleton, come mostrato nel seguente esempio:
Microsoft ha creato un'utile estensione di Visual Studio chiamata Multilingual App Toolkit, che può essere scaricata da Windows Dev Center. Lo strumento non cambia il modo in cui la localizzazione funziona; sarà sempre basato su file di risorse, a cui l'applicazione accede tramite il LocalizedString classe.
L'elenco seguente descrive alcuni dei principali vantaggi del kit di app multilingue:
Uno degli aspetti più dispendiosi in termini di tempo di utilizzo della localizzazione consiste nel copiare manualmente tutti i nuovi valori aggiunti nella lingua di base a tutti gli altri file di risorse. Il Toolkit di app multilingue lo farà per te. Durante il processo di compilazione, copierà tutte le nuove chiavi aggiunte al AppResources.resx file su tutti gli altri file di risorse.
Offre un'interfaccia visiva migliore per la gestione delle traduzioni. Sarai in grado di identificare immediatamente le nuove chiavi da tradurre e impostare uno stato di traduzione diverso.
Supporta i servizi di Bing per tradurre automaticamente le frasi. Ovviamente, non è possibile affidarsi completamente a traduzioni automatiche, ma possono essere un buon inizio per il processo di localizzazione.
È in grado di generare automaticamente pseudo linguaggio, che è un modo per identificare immediatamente le risorse non tradotte e avere una migliore idea di quanto spazio occupi il testo nell'interfaccia utente.
Dopo aver installato il toolkit, dovrai abilitarlo per il tuo progetto in Utensili menu di Visual Studio selezionando il Abilita toolkit per app multilingue opzione. Dopo averlo abilitato, Visual Studio funzionerà con .xlf file invece di .resx file (tranne per la lingua principale). Durante il processo di compilazione, il toolkit genererà tutto il necessario .resx file per te.
Per accedere all'interfaccia visiva del toolkit, basta fare doppio clic su .xlf file e vedrai l'elenco completo delle risorse. Un'icona ti notificherà lo stato di ogni risorsa. Se la risorsa non è stata ancora tradotta, viene visualizzato un cerchio rosso. Se la risorsa è stata tradotta ma richiede la revisione, viene visualizzato un cerchio giallo. Se la traduzione è stata approvata, viene visualizzato un cerchio verde.
Costringendo una lingua
Windows Phone seleziona automaticamente il file di risorse che corrisponde alla lingua del telefono. Se manca un file di risorse appropriato (poiché la lingua del telefono non è supportata dall'applicazione), verrà utilizzato il valore predefinito.
È possibile modificare questo comportamento, ad esempio, se si desidera offrire agli utenti la possibilità di scegliere la lingua che preferiscono, indipendentemente dalla lingua del telefono. Per fare ciò, dovrai impostare un codice cultura differente quando il file App classe (dichiarata nel app.xaml.cs file) è stato creato:
Dopo aver definito a CultureInfo oggetto passando il codice cultura come parametro, è possibile assegnarlo a due diverse proprietà di Thread.currentThread oggetto:
CurrentCulture è la cultura dell'applicazione, che viene utilizzata per definire funzionalità come formati di data e ora, valuta, ecc.
CurrentUICulture è la cultura dell'interfaccia utente, che viene utilizzata per capire quale file di risorse scegliere.
Questo approccio è necessario anche se si desidera utilizzare la pseudo-lingua generata dal kit di app multilingue nel corso del processo di test. Poiché la pseudo lingua non è una lingua ufficiale supportata dalla piattaforma, dovrai forzarla usando il QPS-ploc codice cultura, come mostrato nel seguente esempio:
L'uso di pseudo linguaggio è un ottimo modo per identificare il testo che deve ancora essere tradotto e verificare se il layout dell'applicazione è in grado di gestire un testo lungo. Ciò che in genere accade quando si sviluppa un'applicazione è che lo si testa solo con un paio di lingue, dimenticando che una parola che sembra molto breve in inglese, ad esempio, può essere molto lunga quando viene tradotta in tedesco.
L'esperienza del negozio
Come menzionato nel primo articolo, Windows Phone Store è l'unico modo per distribuire applicazioni ai tuoi utenti, a meno che tu non stia perseguendo la distribuzione aziendale. Avrai bisogno di un account sviluppatore a pagamento, che può essere acquistato da Windows Dev Center. La quota è di $ 19 all'anno, a meno che tu non sia uno studente iscritto al programma DreamSpark, nel qual caso l'accesso è gratuito. Un vantaggio simile è concesso agli abbonati MSDN: nella pagina dei vantaggi, è possibile ottenere un token che consente di registrarsi gratuitamente.
Oltre al canone annuale, Microsoft applica un approccio di revenue-sharing: il 30% del prezzo dell'applicazione viene mantenuto da Microsoft, mentre l'altro 70% viene assegnato allo sviluppatore. Naturalmente, questa condivisione non si applica se l'app è gratuita.
Una volta che il tuo account sviluppatore è stato attivato e la tua applicazione è pronta, puoi inviarla al portale su dev.windowsphone.com. Durante il processo, dovrai definire le funzionalità di marketing dell'applicazione, come prezzo, metadati e tipo di distribuzione. Successivamente, l'invio è completato e inizia il processo di certificazione. Le applicazioni non vengono automaticamente pubblicate nello Store; prima devono passare un processo di certificazione che convalida l'applicazione sia dal punto di vista tecnico che di contenuto.
I test tecnici assicurano che l'applicazione offra una buona esperienza agli utenti: non si blocca, è veloce e reattiva e l'interfaccia utente non confonde.
I test manuali controllano il contenuto dell'applicazione. Alcuni tipi di contenuti come la pornografia, la violenza eccessiva, ecc. Non sono consentiti e porteranno a un fallimento della certificazione.
Quando avvii la procedura di invio, visualizzerai un elenco di passaggi da seguire per completare la procedura. Esaminiamo brevemente ogni passaggio.
Passaggio 1: informazioni sull'app
Il primo passaggio del processo di pubblicazione viene utilizzato per impostare alcune informazioni di base, come la categoria dell'app, il livello di prezzo e la distribuzione del mercato. La tua applicazione verrà automaticamente distribuita in tutti i Paesi supportati al prezzo che hai scelto. Il prezzo verrà automaticamente convertito nella valuta di ciascun paese.
In questo passaggio, puoi scegliere di escludere automaticamente paesi come la Cina, dove le norme sui contenuti sono più rigide. Il processo di certificazione offre anche un optional Selezione del mercato e prezzi personalizzati passo, che offre una personalizzazione più profonda: puoi scegliere di distribuire le applicazioni solo in paesi specifici e personalizzare il prezzo per ogni paese.
L'altra importante opzione da impostare durante questo passaggio è il canale di distribuzione. Esistono tre modi per distribuire un'applicazione Windows Phone:
Il negozio pubblico: L'app può essere scoperta e scaricata da qualsiasi utente.
Nascosto: L'app è ancora disponibile nel negozio pubblico, ma non può essere rilevata dagli utenti. L'unico modo per trovarlo è usare il collegamento diretto che viene generato quando l'app è pubblicata.
Beta: L'applicazione non può essere scoperta dagli utenti e, inoltre, solo gli utenti autorizzati potranno scaricarlo. Gli utenti sono autorizzati con l'account Microsoft con cui hanno registrato il telefono. Sarai in grado di includere fino a 10.000 utenti durante il processo di invio. Questo canale di distribuzione è stato creato per supportare il beta test; in questo scenario, tuttavia, l'applicazione non verrà effettivamente testata, ma sarà disponibile per gli utenti selezionati entro due ore dall'invio dell'app. Un'applicazione beta scade automaticamente 90 giorni dopo che è stata inviata per la prima volta, indipendentemente dagli aggiornamenti successivi.
Passaggio 2: carica e descrivi il tuo XAP
Il secondo passaggio richiede più tempo per essere completato, dal momento che dovrai fornire tutte le informazioni dell'applicazione che verranno visualizzate nel Windows Phone Store.
Il primo passo è caricare il file XAP. XAP è il pacchetto prodotto da Visual Studio durante la compilazione del progetto e contiene tutti i file necessari per l'esecuzione dell'applicazione. Lo troverai all'interno del bidone cartella del tuo progetto Visual Studio. Ricordarsi di compilare sempre l'applicazione in modalità di rilascio; altrimenti non sarà accettato.
Una volta caricato XAP, il portale visualizzerà automaticamente un riepilogo delle funzionalità dell'applicazione, come le risoluzioni supportate, le funzionalità richieste e così via. Dovrai anche impostare il numero di versione dell'applicazione che stai caricando.
Il portale rileverà automaticamente anche le lingue supportate, che verranno visualizzate in un menu a discesa chiamato Dettagli della lingua. Dovrai impostare i metadati dell'applicazione (titolo, descrizione e parole chiave) per ogni lingua supportata. Queste informazioni verranno visualizzate nello Store quando l'utente apre la pagina dell'applicazione.
Dovrai inoltre caricare almeno uno screenshot (otto sono consentiti) per ogni lingua e risoluzione supportata, oltre all'icona dell'applicazione. Verranno visualizzati nella sezione degli screenshot dello Store. Per scattare screenshot, puoi utilizzare uno degli strumenti disponibili nell'emulatore.
Una volta completati tutti i passaggi necessari, il portale ti mostrerà un riepilogo della richiesta per la tua conferma.
Gestire il ciclo di vita dell'applicazione
Una volta che la tua domanda è stata certificata, avrai accesso a molti rapporti che ti aiuteranno a capire quanto la tua applicazione sta funzionando. Sono disponibili report di download, rapporti sulle vendite e rapporti sugli arresti anomali.
Se l'applicazione non supera il processo di certificazione, nella dashboard troverai un file PDF contenente il rapporto completo. Vi dirà in dettaglio cosa è andato storto e cosa dovreste fare per risolvere i problemi identificati.
Alla fine, ovviamente, puoi anche aggiornare la tua applicazione. In questo caso dovrai semplicemente ripetere tutte le fasi di invio, anche se tutti i campi saranno già riempiti con le vecchie informazioni e i metadati. Il processo è lo stesso anche se vuoi solo modificare informazioni come il prezzo, la descrizione e gli screenshot. La presentazione deve essere certificata solo se hai cambiato le informazioni che devono essere convalidate. Se si modifica solo il prezzo, l'aggiornamento viene immediatamente pubblicato.
Acquisti in-app
Un altro modo per guadagnare con le app di Windows Phone è supportare gli acquisti in-app. Oltre ad acquistare l'app dallo Store, gli utenti possono anche effettuare acquisti all'interno dell'applicazione stessa.
Gli acquisti in-app sono sempre stati consentiti, ma Windows Phone 8 ha introdotto API specifiche e il supporto back-end Microsoft. In precedenza, lo sviluppatore si occupava della creazione dell'infrastruttura server, della gestione dei pagamenti e della connessione del client.
Ora puoi semplicemente fare affidamento sull'infrastruttura dello Store. Gli utenti pagheranno utilizzando la stessa carta di credito utilizzata per acquistare app o musica dallo Store e il portale consentirà di creare uno o più prodotti da acquistare all'interno dell'applicazione. Anche in questo caso verrà applicato l'approccio di condivisione delle entrate. Se vuoi evitarlo, sei libero di implementare la tua infrastruttura di acquisto in-app; Microsoft non impone agli sviluppatori di utilizzare i suoi servizi.
È importante sottolineare che gli acquisti in-app tramite i servizi Microsoft sono consentiti solo per i prodotti virtuali (come nuove funzionalità, livelli di gioco, ecc.); non può essere usato per comprare beni fisici.
Windows Phone supporta due tipi di prodotti:
beni durevoli sono prodotti che possono essere acquistati una sola volta, come le funzionalità dell'applicazione, i pacchetti di livello, ecc.
Materiali di consumo sono prodotti che possono essere acquistati di nuovo dopo essere stati consumati, come monete virtuali.
Definizione di un prodotto
I prodotti sono definiti nel portale. Nella pagina dell'applicazione, il Prodotti sezione offre un'opzione per aggiungere nuovi prodotti in-app. La definizione di un prodotto è simile all'invio di un'applicazione: devi impostare alcune proprietà di base come il nome, il prezzo e i metadati, quindi inviarlo.
Ci sono due proprietà chiave:
l'identificativo del prodotto, che è un ID univoco che si utilizza nella propria applicazione per fare riferimento al prodotto
il tipo di prodotto, che può essere consumabile o durevole
Interagire con i prodotti
Una volta definite tutte le proprietà, puoi iniziare a lavorare con i prodotti nella tua applicazione. Probabilmente, il primo requisito è quello di visualizzare l'elenco dei prodotti disponibili che gli utenti possono acquistare. Questo obiettivo è raggiunto usando il CurrentApp classe che appartiene al Windows.ApplicationModel.Store namespace.
Il CurrentApp la classe espone il LoadListingInformationAsync () metodo, che restituisce a ListingInformation oggetto che memorizza tutte le informazioni sui prodotti disponibili.
I prodotti sono memorizzati all'interno del schedeprodotto collezione. Nell'esempio precedente, li mostriamo all'utente utilizzando a LongListSelector controllo, che ha la seguente definizione:
Ogni ProductListing oggetto contiene la stessa proprietà che abbiamo assegnato al prodotto nello Store. Nell'esempio precedente, mostriamo il nome (Nome) e prezzo (FormattedPrice) del prodotto.
Una volta ottenuto l'elenco dei prodotti, è necessario gestire la procedura di acquisto. Ancora una volta, dobbiamo usare il CurrentApp classe, che offre il RequestProductPurchaseAsync () metodo. Come parametro, stiamo per passare il ProductListing oggetto selezionato dall'utente.
Una volta acquistato un prodotto, è possibile verificarne lo stato utilizzando il CurrentApp.LicenseInformation.ProductLicenses collezione. Contiene tutti i prodotti supportati con lo stato della licenza correlata. Ogni prodotto è identificato da una chiave, che è l'identificatore univoco che abbiamo assegnato quando lo abbiamo creato nel portale.
private void MainPage_Loaded (object mittente, RoutedEventArgs e) if (CurrentApp.LicenseInformation.ProductLicenses.ContainsKey ("CoolProduct")) ProductLicense license = CurrentApp.LicenseInformation.ProductLicenses ["CoolProduct"]; if (license.IsActive) // Unlock the feature. else // Blocca la funzione.
Nel precedente esempio, possiamo determinare se il prodotto con il CoolProduct l'identificatore è stato acquistato controllando il valore di È attivo proprietà. L'operazione viene eseguita quando la pagina è caricata: se il prodotto è stato acquistato, sbloccheremo la relativa funzionalità, altrimenti aspetteremo che l'utente lo acquisti.
Per un prodotto consumabile, il processo di acquisto è lo stesso. L'unica differenza è che, dopo che è stato consumato, dobbiamo segnalarlo in modo che possa essere "sbloccato" per essere nuovamente acquistato.
Possiamo segnalarlo chiamando il ReportProductFullfillment () metodo del CurrentApp classe, che richiede come parametro il ProductLicense oggetto che identifica il prodotto.
Sfortunatamente, testare un acquisto in-app non è molto semplice. Poiché i prodotti devono essere definiti nel portale, dovrai inviare la domanda prima di poter testare il processo di acquisto.
Una soluzione è pubblicare l'applicazione come beta; poiché l'app non ha bisogno di essere certificata, sarà immediatamente disponibile per i test. Il rovescio della medaglia è che è difficile verificarlo correttamente se qualcosa va storto dato che non è possibile eseguirne il debug usando Visual Studio come faresti normalmente con qualsiasi altra applicazione.
Per questo motivo, Microsoft ha fornito una libreria di test chiamata MockIAP. Il suo scopo è "prendere in giro" le vere API di acquisto in-app in modo che le operazioni non vengano eseguite contro il vero servizio Microsoft, ma utilizzare prodotti contraffatti definiti all'interno dell'applicazione.
Ci sono due cose da fare per iniziare a utilizzare la libreria MockIAP. Il primo consiste nell'aggiungere alcune direttive di compilazione condizionale in modo che quando l'applicazione viene compilata in modalità di debug (in genere durante il test) utilizzerà la libreria di simulazione. Quando è compilato in modalità di rilascio, utilizzerà i veri servizi Microsoft.
Il seguente esempio di codice mostra come apparirà la dichiarazione dello spazio dei nomi nella tua pagina:
#if DEBUG usando MockIAPLib; usando Store = MockIAPLib; #else using Windows.ApplicationModel.Store; #finisci se
Il secondo passo è definire i prodotti che dobbiamo usare. Poiché l'applicazione non sarà collegata ai servizi reali, dobbiamo duplicare nel codice i prodotti che abbiamo definito nel portale.
Il codice seguente mostra un'inizializzazione di esempio:
private void SetupMockIAP () MockIAP.Init (); MockIAP.RunInMockMode (true); MockIAP.SetListingInformation (1, "en-US", "Questa è un'app di esempio", "1", "SampleApp"); ProductListing p = new ProductListing Name = "Prodotto cool", ProductId = "CoolProduct", ProductType = Windows.ApplicationModel.Store.ProductType.Durable, Descrizione = "Un prodotto interessante", FormattedPrice = "10,00 €", Tag = stringa. Vuoto ; MockIAP.AddProductListing ("CoolProduct", p); ProductListing p2 = new ProductListing Name = "Prodotto di consumo fresco", ProductId = "CoolProductConsumable", ProductType = Windows.ApplicationModel.Store.ProductType.Consumable, Descrizione = "Un prodotto di consumo interessante", FormattedPrice = "5,00 €", Tag = string.Empty; MockIAP.AddProductListing ("CoolProductConsumable", p2);
Creiamo due prodotti: uno durevole identificato dalla chiave CoolProduct, e un materiale consumabile identificato dalla chiave CoolProductConsumable. Ogni prodotto è identificato dal ProductListing classe (la stessa classe che abbiamo usato con i servizi reali), e possiamo usarla per definire tutte le proprietà del prodotto che vengono solitamente recuperate dai servizi Microsoft come il nome, il tipo, il prezzo e così via.
Aggiungiamo ogni prodotto usando il AddProductListing () metodo del MockIAP classe. Dopo aver aggiunto i prodotti, possiamo utilizzare le API standard per gli acquisti in-app. Le operazioni saranno eseguite localmente con i prodotti falsi invece dei servizi reali, ma il comportamento sarà esattamente lo stesso. Saremo in grado di elencare, acquistare e consumare i prodotti disponibili.
Conclusione
Quando parliamo di applicazioni mobili, lo sviluppo non è l'unico aspetto che dobbiamo considerare. Se vogliamo avere successo, dobbiamo anche distribuire e promuovere la nostra applicazione. In questo tutorial, abbiamo discusso:
Come localizzare l'applicazione in modo che si rivolga a un pubblico più ampio.
Come funzionano Windows Phone Store e il processo di certificazione. L'invio dell'app è un passaggio cruciale poiché dobbiamo prendere molte importanti decisioni di marketing come il prezzo dell'app, i paesi in cui sarà disponibile, ecc..
Come aumentare le entrate sostenendo gli acquisti in-app.
Share
Accentsconagua
