När vi pratar om mobila applikationer är utveckling inte den enda aspekten vi behöver tänka på. Om vi vill bli framgångsrika måste vi också distribuera och marknadsföra vår ansökan. I den här handledningen kommer vi att diskutera lokalisering, Windows Phone Store och inköp i app.
Trial Apps
En av de särdragen i Windows Phone-applikationer är att de stöder ett provläge, vilket gör det möjligt för dem att hämtas från Windows Phone Store som ett försök med begränsade funktioner. När användarna bestämmer sig för att köpa hela applikationen behöver de inte ladda ner den från början. Butiken kommer helt enkelt att ladda ner ett uppdaterat certifikat, vilket låser upp alla tidigare blockerade funktioner.
Från utvecklarens synvinkel är det enkelt att hantera en försök. De Windows.ApplicationModel.Store namnrymden innehåller en klass som heter LicenseInformation, som erbjuder en egendom som heter IsTrial. Om dess värde är Sann, det betyder att applikationen har installerats i försöksläge, så vi måste låsa de funktioner som vi inte vill ha aktiverat. annars har användaren köpt det, så alla funktioner kan göras tillgängliga.
Det är upp till dig att välja den bästa provupplevelsen för din ansökan. Du kan till exempel avaktivera vissa funktioner, begränsa antalet gånger applikationerna kan utföras, eller i ett spel, välj vilka nivåer att låsa upp.
LicenseInformation info = ny licensinformation (); om (info.IsTrial) MessageBox.Show ("Program körs i provläge"); else MessageBox.Show ("Programmet körs i fullt läge!");
Lokalisering
Ett av de bästa sätten att öka försäljningen och antalet nedladdningar av en applikation är att stödja flera språk. Standardprogrammet Windows Phone 8 i Visual Studio stöder redan lokalisering genom att inkludera en mapp som heter Medel. Den innehåller alla resursfiler, som är enkla XML-filer med en speciell .resx förlängning.
Resursfiler är helt enkelt en samling värden (den översatta texten) som är associerad med en specifik nyckel som används i programmet för att hänvisa till den texten. Enligt användarens språk använder programmet automatiskt den rätta resursfilen.
Standardmallen skapar en fil som heter AppResources.resx inuti Medel mapp, som refererar till standardspråk (vanligtvis engelska).
Att stödja ett nytt språk är enkelt. Bara Högerklicka ditt projekt i Lösningsutforskare och välj Egenskaper. Den stödda kulturen låda visar alla tillgängliga språk. När du lägger till nya språk genom att markera dem i listan skapar Visual Studio automatiskt en ny AppResources filen heter AppResources.xx-yy.resx i mappen Resurser, var xx-yy är odlingskoden för det valda språket (till exempel om du har lagt till italienska kommer det att skapa en fil med namnet AppResources.it-IT.resx).
Visual Studio erbjuder en användbar visuell redigerare för att arbeta med resursfiler. Det visar alla värden i ett bord där du enkelt kan definiera en nyckel, dess värde och en valfri kommentar. För att komma åt det, helt enkelt dubbelklicka på en resursfil i Medel mapp.
Förutom att erbjuda en standardresursfil innehåller även Windows Phone-mallen en klass som heter LocalizedStrings, som fungerar som en omslag mellan lokaliseringsfilen och XAML. Du kan hitta den definierad som en global resurs i App.xaml fil:
Tack vare denna omslag kan du få tillgång till resurser direkt i XAML. Du behöver inte lägga till den direkt i XAML varje gång du behöver visa text i användargränssnittet. istället lägger du till i resursfilerna och ansluter dem sedan till din XAML med följande syntax:
Tack vare LocalizedStrings klass kan vi få tillgång till alla värden i resursfilen genom att använda LocalizedResources.MyKey syntax, var Min nyckel är nyckeln som identifierar texten som du vill visa.
Om du vill komma åt resurssträngen direkt från koden måste du använda AppResources singleton klass, som visas i följande prov:
Microsoft har skapat en användbar Visual Studio-extensions som heter Multilingual App Toolkit, som kan hämtas från Windows Dev Center. Verktyget ändrar inte hur lokalisering fungerar. Den kommer alltid att baseras på resursfiler, som nås av programmet med hjälp av LocalizedString klass.
Följande lista beskriver några av de viktigaste fördelarna med den flerspråkiga appverktyget:
En av de mest tidskrävande aspekterna av att arbeta med lokalisering kopierar manuellt alla nya värden som du har lagt till i grundsproget till alla andra resursfiler. Den flerspråkiga App Toolkit gör det här för dig. Under byggprocessen kopieras alla nya nycklar som läggs till AppResources.resx fil till alla andra resursfiler.
Det ger ett bättre visuellt gränssnitt för hantering av översättningar. Du kan genast identifiera de nya nycklarna för att översätta och ställa in en annan översättningsstatus.
Det stöder Bing-tjänster att automatiskt översätta meningar. Självklart kan du inte helt förlita dig på automatiska översättningar, men de kan vara en bra start för din lokaliseringsprocess.
Det kan automatiskt generera pseudo språk, vilket är ett sätt att omedelbart identifiera otranslaterade resurser och få en bättre uppfattning om hur mycket rymdtext upptar i gränssnittet.
När du har installerat verktygsverktyget måste du aktivera det för ditt projekt i Verktyg menyn Visual Studio genom att välja Aktivera flerspråkig appverktygsverktyg alternativ. Efter att ha aktiverat det, kommer Visual Studio att arbeta med .XLF filer istället för .resx filer (förutom huvudspråket). Under samlingsprocessen genererar verktyget alla nödvändiga .resx filer för dig.
För att komma åt visningsgränssnittet för verktygslåda, dubbelklicka bara på en .XLF filen och du får se den kompletta listan över resurser. En ikon kommer att meddela dig statusen för varje resurs. Om resursen ännu inte har översatts visas en röd cirkel. Om resursen har översatts men kräver revision, visas en gul cirkel. Om översättningen har godkänts visas en grön cirkel.
Tvinga ett språk
Windows Phone väljer automatiskt resursfilen som matchar telefonens språk. Om en lämplig resursfil saknas (eftersom telefonens språk inte stöds av din ansökan) används standardvärdet.
Du kan ändra detta beteende, till exempel om du vill ge användarna möjlighet att välja vilket språk de föredrar, oavsett telefonens språk. För att göra detta måste du ange en annan kulturkod när App klass (deklarerad i App.xaml.cs fil) skapas:
När du har definierat a Culture objekt genom att överföra odlingskoden som en parameter, kan du tilldela den till två olika egenskaper hos Thread.CurrentThread objekt:
CurrentCulture är programmets kultur, som används för att definiera funktioner som datum- och tidsformat, valuta osv.
CurrentUICulture är användargränssnittskulturen, som används för att förstå vilken resursfil att välja.
Detta tillvägagångssätt krävs även om du vill använda det pseudo-språk som genereras av den flerspråkiga appverktyget under testprocessen. Eftersom pseudospråket inte är ett officiellt språk som stöds av plattformen måste du tvinga det med hjälp av QPS-ploc odlingskod, som visas i följande prov:
Att använda pseudo-språk är ett bra sätt att identifiera text som ännu inte översatts och testa om din applikations layout kan hantera lång text. Det som vanligtvis händer när du utvecklar en applikation är att du testar det med endast ett par språk, glöm det att ett ord som ser väldigt kort på engelska, kan till exempel vara mycket länge när det översätts till tyska.
Affärserfarenheten
Som nämnts i den första artikeln är Windows Phone Store det enda sättet att distribuera program till dina användare om du inte bedriver företagsdistribution. Du behöver ett betalt utvecklare konto, som kan köpas från Windows Dev Center. Avgiften är $ 19 per år, om du inte är en student som prenumererar på DreamSpark-programmet, i vilket fall tillgången är gratis. En liknande fördel ges till MSDN-abonnenter: På förmånssidan kan du få ett token som låter dig registrera dig gratis.
Annat än årsavgiften tillämpar Microsoft ett intäktsdelningsförfarande: 30% av ansökans pris hålls av Microsoft, medan de övriga 70% ges till utvecklaren. Självklart gäller inte denna delning om appen är ledig.
När ditt utvecklarkonto har aktiverats och din ansökan är klar kan du skicka in den till portalen på dev.windowsphone.com. Under processen måste du definiera programmets marknadsföringsfunktioner, till exempel pris, metadata och distributionstyp. Därefter avslutas inlämningen, och certifieringsprocessen börjar. Applikationer publiceras inte automatiskt i Store; Först måste de skicka en certifieringsprocess som validerar ansökan både ur teknisk och innehållssynpunkt.
De tekniska testerna ser till att applikationen ger en bra upplevelse för användarna: det kraschar inte, det är snabbt och lyhört och användargränssnittet är inte förvirrande.
De manuella testerna kontrollerar programmets innehåll. Vissa typer av innehåll som pornografi, överdriven våld, etc., är inte tillåtna och leder till ett certifieringsfel.
När du startar inlämningsprocessen visas en lista över steg att följa för att slutföra processen. Låt oss kortfattat titta på varje steg.
Steg 1: App Info
Det första steget i publiceringsprocessen används för att ställa in någon grundläggande information, till exempel appens kategori, prisnivå och marknadsfördelning. Din ansökan distribueras automatiskt i alla de stödda länderna till det pris du har valt. Priset omvandlas automatiskt till varje lands valuta.
I det här steget kan du välja att automatiskt utesluta länder som Kina, där innehållsreglerna är strängare. Certifieringsprocessen erbjuder också en valfri Marknadsval och anpassad prissättning steg, som erbjuder djupare anpassning: du kan välja att distribuera programmen endast i specifika länder och anpassa priset för varje land.
Det andra viktiga alternativet att ställa in under detta steg är distributionskanalen. Det finns tre sätt att distribuera en Windows Phone-applikation:
Den offentliga affären: Appen kan upptäckas och laddas ner av någon användare.
Dold: Appen är fortfarande tillgänglig i den offentliga butiken, men den kan inte upptäckas av användarna. Det enda sättet att hitta det är att använda den direkta länken som genereras när appen publiceras.
Beta: Applikationen kan inte upptäckas av användare, och dessutom får endast behöriga användare hämta det. Användare är auktoriserade med det Microsoft-konto de registrerade telefonen med. Du kommer att kunna inkludera upp till 10 000 användare under inlämningsprocessen. Denna distributionskanal skapades för att stödja beta-testning. I det här scenariot kommer emellertid programmet inte att bli testat, men kommer att vara tillgängligt för de valda användare inom två timmar efter att appen skickades in. En beta-ansökan upphör automatiskt 90 dagar efter det att den har skickats in för första gången, oavsett senare uppdateringar.
Steg 2: Ladda upp och beskriv din XAP
Det andra steget kräver mer tid att slutföra, eftersom du måste tillhandahålla all programinformation som kommer att visas i Windows Phone Store.
Det första steget är att ladda upp XAP-filen. XAP är paketet som produceras av Visual Studio när du sammanställer ditt projekt, och det innehåller alla nödvändiga filer för att programmet ska köras. Du hittar den inuti bin mapp för ditt Visual Studio-projekt. Kom ihåg att alltid kompilera programmet i släppläge; annars kommer det inte att accepteras.
När du har laddat upp XAP-porten kommer portalen automatiskt att visa en omgång av programmets funktioner, till exempel de stödda resolutionerna, de nödvändiga funktionerna och så vidare. Du måste också ställa in versionsnumret för programmet du laddar upp.
Portalen identifierar automatiskt de språk du stöder, vilket kommer att visas i en rullgardinsmeny som heter Språkuppgifter. Du måste ange programmets metadata (titel, beskrivning och sökord) för varje språk som stöds. Denna information kommer att visas i Butiken när användaren öppnar programmets sida.
Du måste också ladda upp minst en skärmdump (åtta är tillåtna) för varje språk och stöds upplösning plus applikationsikonen. De kommer att visas i skärmbilderna i butiken. För att ta skärmdumpar kan du använda ett av de tillgängliga verktygen i emulatorn.
När du har slutfört alla nödvändiga steg visar portalen dig en omgång av inlämningen för din bekräftelse.
Hantera programmets livscykel
När din ansökan har certifierats har du tillgång till många rapporter som hjälper dig att förstå hur bra din ansökan utför. Det finns nedladdningsrapporter, försäljningsrapporter och kraschrapporter.
Om programmet inte klarar certifieringsprocessen hittar du en PDF-fil som innehåller hela rapporten i instrumentpanelen. Det kommer att berätta i detalj vad som gick fel och vad du bör göra för att åtgärda de identifierade problemen.
Till sist kan du naturligtvis också uppdatera din ansökan. I det här fallet måste du helt enkelt upprepa alla inlämningssteg, även om alla fält redan fylls med den gamla informationen och metadata. Processen är också densamma om du bara vill ändra information som pris, beskrivning och skärmdumpar. Inlämningen måste endast certifieras om du har ändrat all information som måste valideras. Om du bara ändrar priset uppdateras uppdateringen omedelbart.
In-App Purchases
Ett annat sätt att tjäna pengar med Windows Phone-appar är att stödja inköp i app. Förutom att köpa appen från affären kan användarna också göra inköp inom själva ansökan.
Köp i app har alltid varit tillåtet, men Windows Phone 8 har infört specifika API och Microsoft Backend Support. Tidigare var utvecklaren ansvarig för att skapa serverns infrastruktur, hantera betalningar och ansluta klienten.
Nu kan du helt enkelt lita på affärsinfrastrukturen. Användarna betalar med samma kreditkort som de brukade köpa appar eller musik från butiken, och portalen tillåter dig att skapa en eller flera produkter att köpa inom programmet. Även i det här fallet kommer intäktsdelningen att tillämpas. Om du vill undvika det är du fri att genomföra din egen inköpsinfrastruktur i appen. Microsoft tvingar inte utvecklare att använda sina tjänster.
Det är viktigt att markera att inköp via inköp via Microsoft-tjänster endast är tillåten för virtuella produkter (som nya funktioner, spelnivåer etc.). Det kan inte användas för att köpa fysiska varor.
Två typer av produkter stöds av Windows Phone:
varaktiga är produkter som kan köpas en gång, till exempel applikationsfunktioner, nivåpaket etc..
Förbruknings är produkter som kan köpas igen efter att de har konsumeras, som virtuella mynt.
Definiera en produkt
Produkter definieras i portalen. På programmets sida, den Produkter avsnittet erbjuder ett alternativ att lägga till nya in-app produkter. Definiera en produkt liknar inlämning av en ansökan: du måste ange några grundläggande egenskaper som namn, pris och metadata och sedan skicka in det.
Det finns två viktiga egenskaper:
Produktidentifieraren, som är ett unikt ID som du använder i din ansökan för att referera till produkten
Produkttypen, som kan vara förbrukningsbar eller hållbar
Samverkan med produkter
När du har definierat alla egenskaper kan du börja arbeta med produkterna i din ansökan. Förmodligen är det första kravet att visa listan över tillgängliga produkter som användare kan köpa. Detta mål uppnås med hjälp av CurrentApp klass som tillhör Windows.ApplicationModel.Store namespace.
De CurrentApp klassen avslöjar LoadListingInformationAsync () metod som returnerar a ListingInformation objekt som lagrar all information om tillgängliga produkter.
Produkterna lagras inuti produktannonser samling. I det föregående provet visar vi dem till användaren med hjälp av a LongListSelector kontroll som har följande definition:
Varje ProductListing objekt innehåller samma egenskap som vi har tilldelat produkten i butiken. I föregående exempel visar vi namnet (namn) och pris (FormattedPrice) av produkten.
När du har produktlistan måste du hantera inköpsprocessen. Återigen måste vi använda CurrentApp klass, som erbjuder RequestProductPurchaseAsync () metod. Som en parameter kommer vi att passera ProductListing objekt valt av användaren.
När en produkt har köpts kan du kontrollera dess status genom att använda CurrentApp.LicenseInformation.ProductLicenses samling. Den innehåller alla produkter som stöds med den relaterade licensstatusen. Varje produkt identifieras med en nyckel, som är den unika identifieraren vi tilldelade när vi skapade den i portalen.
privat tomt MainPage_Loaded (objekt avsändare, RoutedEventArgs e) if (CurrentApp.LicenseInformation.ProductLicenses.ContainsKey ("CoolProduct")) ProductLicense license = CurrentApp.LicenseInformation.ProductLicenses ["CoolProduct"]; om (licens.IsActive) // Lås upp funktionen. else // Lås funktionen.
I det föregående provet kan vi avgöra om produkten med CoolProduct identifieraren har köpts genom att kontrollera värdet av Är aktiv fast egendom. Åtgärden utförs när sidan laddas: om produkten har köpts öppnar vi den relaterade funktionen, annars väntar vi på att användaren köper den.
För en förbrukningsprodukt är inköpsprocessen densamma. Den enda skillnaden är att vi, efter det att den konsumeras, måste anmäla den så att den kan "upplåsas" för att köpas igen.
Vi kan rapportera det genom att ringa ReportProductFullfillment () metod för CurrentApp klass som kräver som en parameter ProductLicense objekt som identifierar produkten.
Tyvärr är det inte så lätt att testa ett inköp i app. Eftersom produkter måste definieras i portalen måste du skicka in din ansökan innan du kan testa inköpsprocessen.
Ett arbete är att publicera applikationen som beta; Eftersom appen inte behöver vara certifierad kommer den vara omedelbart tillgänglig för testning. Nackdelen är att det är svårt att korrekt testa det om något går fel eftersom du inte kan felsöka det med Visual Studio som du normalt skulle med någon annan applikation.
Av denna anledning har Microsoft tillhandahållit ett testbibliotek som heter MockIAP. Dess syfte är att "mocka" de verkliga API-inköps API-erna så att operationerna inte exekveras mot den verkliga Microsoft-tjänsten, men använd falska produkter som definieras i ansökan.
Det finns två saker att göra för att börja använda MockIAP-biblioteket. Den första är att lägga till några villkorliga kompileringsdirektiv så att när applikationen sammanställs i debug-läge (vanligtvis under testningen) kommer den att använda mock-biblioteket. När den sammanställs i släppläge, kommer den att använda de verkliga Microsoft-tjänsterna.
Följande kodprov visar hur navnefrasdeklarationen kommer att se på din sida:
#if DEBUG med MockIAPLib; använder Store = MockIAPLib; #else använder Windows.ApplicationModel.Store; #endif
Det andra steget är att definiera de produkter vi behöver använda. Eftersom programmet inte kommer att anslutas till de reella tjänsterna måste vi duplicera i koden de produkter som vi definierat i portalen.
Följande kod visar en provinitiering:
privat tomgång SetupMockIAP () MockIAP.Init (); MockIAP.RunInMockMode (true); MockIAP.SetListingInformation (1, "en-US", "This is a sample app", "1", "SampleApp"); ProductListing p = new ProductListing Name = "Cool produkt", ProductId = "CoolProduct", ProductType = Windows.ApplicationModel.Store.ProductType.Durable, Description = "En cool produkt", FormattedPrice = "10.00 €", Tag = sträng. Tom; MockIAP.AddProductListing ("CoolProduct", p); ProductListing p2 = new ProductListing Name = "Cool produktförbrukning", ProductId = "CoolProductConsumable", ProductType = Windows.ApplicationModel.Store.ProductType.Consumable, Beskrivning = "En cool förbrukningsprodukt", FormattedPrice = "5.00 €", Tag = string.Empty; MockIAP.AddProductListing ("CoolProductConsumable", p2);
Vi skapar två produkter: en hållbar som identifieras av nyckeln CoolProduct, och en förbrukningsbar som identifieras av nyckeln CoolProductConsumable. Varje produkt identifieras av ProductListing klass (samma klass som vi använde med de verkliga tjänsterna) och vi kan använda den för att definiera alla produktegenskaper som vanligtvis hämtas från Microsoft-tjänster som namn, typ, pris osv..
Vi lägger till varje produkt med hjälp av AddProductListing () metod för MockIAP klass. Efter att du har lagt till produkterna kan vi använda standard API för inköp i app. Verksamheten utförs lokalt med de falska produkterna istället för de reella tjänsterna, men beteendet kommer att vara exakt detsamma. Vi kommer att kunna lista, köpa och konsumera de tillgängliga produkterna.
Slutsats
När vi pratar om mobila applikationer är utveckling inte den enda aspekten vi behöver tänka på. Om vi vill bli framgångsrika måste vi också distribuera och marknadsföra vår ansökan. I denna handledning har vi diskuterat:
Hur lokaliseras ansökan så att den vädjar till en bredare publik.
Hur Windows Phone Store och certifieringsprocessen fungerar. Att skicka in appen är ett viktigt steg eftersom vi måste göra många viktiga marknadsföringsbeslut som appens pris, länderna det kommer att finnas i, etc..
Så här ökar du intäkterna genom att stödja inköp i app.
Share
Accentsconagua
