Når vi snakker om mobile applikasjoner, er utvikling ikke det eneste aspektet vi må vurdere. Hvis vi ønsker å lykkes, må vi også distribuere og fremme vår søknad. I denne opplæringen skal vi diskutere lokalisering, Windows Phone-butikken og kjøp av apper.
Trial Apps
En av de fremtredende funksjonene i Windows Phone-applikasjoner er at de støtter en prøvemodus, som gjør at de kan lastes ned fra Windows Phone Store som en prøveversjon med begrensede funksjoner. Når brukerne bestemmer seg for å kjøpe hele programmet, trenger de ikke å laste det ned fra grunnen av det. Store vil bare laste ned et oppdatert sertifikat, som vil låse opp alle tidligere blokkerte funksjoner.
Fra utviklerens synspunkt er det enkelt å administrere en prøveversjon. De Windows.ApplicationModel.Store namespace inneholder en klasse som heter LicenseInformation, som tilbyr en eiendom kalt IsTrial. Hvis verdien er ekte, det betyr at programmet har blitt installert i prøvemodus, så vi må låse funksjonene vi ikke vil aktivere; Ellers har brukeren kjøpt den, slik at alle funksjoner kan gjøres tilgjengelige.
Det er opp til deg å velge den beste prøveopplevelsen for søknaden din. For eksempel kan du deaktivere noen funksjoner, begrense antall ganger programmene kan utføres, eller i et spill, velge hvilke nivåer som skal låse opp.
LicenseInformation info = ny lisensinformasjon (); hvis (info.IsTrial) MessageBox.Show ("Programmet kjører i prøvemodus"); ellers MessageBox.Show ("Programmet kjører i full modus!");
lokalisering
En av de beste måtene å øke salget og antall nedlastinger av et program er å støtte flere språk. Standard Windows Phone 8-mal i Visual Studio støtter allerede lokalisering ved å inkludere en mappe som heter ressurser. Den inneholder alle ressursfiler, som er enkle XML-filer med en spesiell .ResX forlengelse.
Ressursfiler er rett og slett en samling verdier (den oversatte teksten) knyttet til en bestemt nøkkel som brukes i programmet for å referere til den teksten. Ifølge brukerens språk bruker programmet automatisk den riktige ressursfilen.
Standardmalen lager en fil som heter AppResources.resx inne i ressurser mappe, som refererer til standardspråket (vanligvis engelsk).
Det er enkelt å støtte et nytt språk. Bare Høyreklikk Ditt prosjekt i Solution Explorer og velg Eiendommer. Den støttede kulturen boksen vil vise alle tilgjengelige språk. Når du legger til nye språk ved å velge dem i listen, oppretter Visual Studio automatisk en ny AppResources filen heter AppResources.xx-yy.resx i mappen Resources, hvor xx-yy er kulturkoden til det valgte språket (for eksempel hvis du har lagt til italiensk, vil den opprette en fil som heter AppResources.it-IT.resx).
Visual Studio tilbyr en nyttig visuell editor for å jobbe med ressursfiler. Den viser alle verdiene i et bord, hvor du enkelt kan definere en nøkkel, dens verdi og en valgfri kommentar. Å få tilgang til det, ganske enkelt Dobbeltklikk på en ressursfil i ressurser mappe.
I tillegg til å tilby en standard ressursfil, inkluderer Windows Phone-malen også en klasse som heter LocalizedStrings, som fungerer som en omslag mellom lokaliseringsfilen og XAML. Du kan finne den definert som en global ressurs i App.xaml fil:
Takket være denne wrappen kan du få tilgang til ressurser direkte i XAML. Du trenger ikke legge den direkte i XAML hver gang du trenger å vise tekst i brukergrensesnittet. I stedet legger du til ressursfilene og kobler dem til din XAML med følgende syntaks:
Takk til LocalizedStrings klasse, kan vi få tilgang til alle verdier i ressursfilen ved å bruke LocalizedResources.MyKey syntaks, hvor Nøkkelen min er nøkkelen som identifiserer teksten du vil vise.
Hvis du vil ha tilgang til ressursstrengen direkte fra koden, må du bruke AppResources singleton klasse, som vist i følgende prøve:
Microsoft har opprettet en nyttig Visual Studio-utvidelse som heter Multilingual App Toolkit, som kan lastes ned fra Windows Dev Center. Verktøyet endrer ikke hvordan lokalisering fungerer; Den vil alltid være basert på ressursfiler, som nås av programmet ved hjelp av LocalizedString klasse.
Følgende liste beskriver noen av de viktigste fordelene med Multilingual App Toolkit:
En av de mest tidkrevende aspektene ved å jobbe med lokalisering, kopierer manuelt alle de nye verdiene du har lagt til i grunnspråket til alle andre ressursfiler. Multilingual App Toolkit vil gjøre dette for deg. Under byggeprosessen vil den kopiere alle de nye nøklene som er lagt til AppResources.resx fil til alle andre ressursfiler.
Det gir et bedre visuelt grensesnitt for å håndtere oversettelser. Du vil umiddelbart kunne identifisere de nye nøklene for å oversette og angi en annen oversettelsesstatus.
Den støtter Bing-tjenester for automatisk å oversette setninger. Åpenbart kan du ikke helt stole på automatiske oversettelser, men de kan være en god start for din lokaliseringsprosess.
Det er i stand til å automatisk generere pseudo språk, som er en måte å umiddelbart identifisere utranslaterte ressurser og få en bedre ide om hvor mye plass tekst okkuperer i brukergrensesnittet.
Etter at du har installert verktøyet, må du aktivere det for prosjektet ditt i Verktøy menyen av Visual Studio ved å velge Aktiver flerspråklig appverktøy alternativ. Etter at du har aktivert det, vil Visual Studio jobbe med .XLF filer i stedet for .ResX filer (unntatt hovedspråket). Under samlingsprosessen vil verktøykassen generere alle nødvendige .ResX filer for deg.
For å få tilgang til visningsgrensesnittet, sett bare dobbeltklikk på en .XLF filen, og du vil se den komplette listen over ressurser. Et ikon vil varsle deg om statusen til hver ressurs. Hvis ressursen ennå ikke er oversatt, vises en rød sirkel. Hvis ressursen er oversatt, men krever revisjon, vises en gul sirkel. Hvis oversettelsen er godkjent, vises en grønn sirkel.
Tvinge et språk
Windows Phone velger automatisk ressursfilen som samsvarer med telefonens språk. Hvis en passende ressursfil mangler (fordi telefonens språk ikke støttes av programmet ditt), vil standard bli brukt.
Du kan forandre denne oppførselen, for eksempel hvis du vil gi brukerne muligheten til å velge språket de foretrekker, uavhengig av telefonens språk. For å gjøre dette må du angi en annen kulturkode når app klasse (erklært i App.xaml.cs fil) er opprettet:
Etter at du har definert a Culture objekt ved å overføre kulturkoden som en parameter, kan du tilordne den til to forskjellige egenskaper av Thread.CurrentThread gjenstand:
CurrentCulture er programmets kultur, som brukes til å definere funksjoner som dato og klokkeslettformater, valuta osv.
CurrentUICulture er brukergrensesnittkulturen, som brukes til å forstå hvilken ressursfil som skal velges.
Denne tilnærmingen er også nødvendig hvis du vil bruke pseudo-språket som genereres av Multilingual App Toolkit under testprosessen. Siden pseudot språk ikke er et offisielt språk støttet av plattformen, må du tvinge det ved å bruke QPS-ploc kulturkode, som vist i følgende prøve:
Bruk av pseudo-språk er en fin måte å identifisere tekst som ennå ikke er oversatt og teste om programmets layout er i stand til å håndtere lang tekst. Det som vanligvis skjer når du utvikler et program, er at du tester det med bare et par språk, og glemmer at et ord som ser veldig kort på engelsk, kan for eksempel være veldig lenge når det er oversatt til tysk.
Butikken Erfaring
Som nevnt i den første artikkelen, er Windows Phone Store den eneste måten å distribuere applikasjoner til brukerne dine, med mindre du forfølger bedriftsfordeling. Du trenger en betalt utvikler konto, som kan kjøpes fra Windows Dev Center. Gebyret er $ 19 per år, med mindre du er student abonnert på DreamSpark-programmet, i så fall er tilgangen gratis. En lignende fordel er gitt til MSDN-abonnenter: På fordelingssiden kan du få et token som lar deg registrere deg gratis.
Annet enn årsavgiften, bruker Microsoft en inntektsdeling tilnærming: 30% av søknadens pris holdes av Microsoft, mens de andre 70% er gitt til utvikleren. Selvfølgelig gjelder denne delingen ikke hvis appen er ledig.
Når utviklerkontoen din er aktivert og søknaden din er klar, kan du sende den til portalen på dev.windowsphone.com. Under prosessen må du definere programmets markedsføringsfunksjoner, som pris, metadata og distribusjonstype. Etter det er innsendingen fullført, og sertifiseringsprosessen starter. Programmer blir ikke automatisk publisert i butikken; først må de passere en sertifiseringsprosess som validerer søknaden både fra teknisk og innholdsposisjon.
De tekniske testene sørger for at applikasjonen gir en god opplevelse til brukerne: den krasjer ikke, den er rask og lydhør, og brukergrensesnittet er ikke forvirrende.
De manuelle testene kontrollerer innholdet i søknaden. Noen typer innhold som pornografi, overdreven vold, etc., er ikke tillatt og vil føre til en sertifiseringsfeil.
Når du starter innleveringsprosessen, ser du en liste over trinn som skal følges for å fullføre prosessen. La oss se nærmere på hvert trinn.
Trinn 1: App Info
Det første trinnet i publiseringsprosessen brukes til å angi grunnleggende informasjon, som appens kategori, prisnivå og markedsfordeling. Din søknad vil automatisk bli distribuert i alle de støttede landene til den prisen du har valgt. Prisen vil automatisk bli konvertert til hvert lands valuta.
I dette trinnet kan du velge å automatisk utelukke land som Kina, der innholdsretningslinjene er strengere. Sertifiseringsprosessen tilbyr også en valgfri Markedsvalg og tilpasset prising trinn, som tilbyr dypere tilpasning: du kan velge å distribuere søknadene bare i bestemte land og tilpasse prisen for hvert land.
Det andre viktige alternativet som skal settes under dette trinnet er distribusjonskanalen. Det er tre måter å distribuere et Windows Phone-program på:
Den offentlige butikken: Appen kan oppdages og lastes ned av alle brukere.
skjult: Appen er fortsatt tilgjengelig i den offentlige butikken, men den kan ikke oppdages av brukerne. Den eneste måten å finne den på er å bruke den direkte koblingen som genereres når appen publiseres.
Beta: Programmet kan ikke oppdages av brukere, og i tillegg vil bare autoriserte brukere få lov til å laste den ned. Brukere er autorisert med Microsoft-kontoen de registrerte telefonen med. Du kan inkludere opptil 10 000 brukere under innleveringsprosessen. Denne distribusjonskanalen ble opprettet for å støtte beta-testing; I dette scenariet vil applikasjonen imidlertid ikke bli testet, men vil være tilgjengelig for de valgte brukerne innen to timer etter at appen er sendt. En beta-applikasjon utløper automatisk 90 dager etter at den er sendt for første gang, uansett senere oppdateringer.
Trinn 2: Last opp og beskriv din XAP
Det andre trinnet krever mer tid å fullføre, siden du må oppgi all programinformasjon som vil bli vist i Windows Phone Store.
Det første trinnet er å laste opp XAP-filen. XAP er pakken produsert av Visual Studio når du kompilerer prosjektet ditt, og det inneholder alle nødvendige filer for at programmet skal kjøre. Du finner den inne i bin mappe av Visual Studio-prosjektet. Husk å alltid kompilere programmet i utgivelsesmodus; ellers vil det ikke bli akseptert.
Når du har lastet opp XAP, viser portalen automatisk en oversikt over programmets funksjoner, som de støttede resolusjonene, de nødvendige funksjonene og så videre. Du må også angi versionsnummeret til programmet du laster opp.
Portalen vil også automatisk oppdage språkene du støtter, som vises i en rullegardinmeny som heter Språk detaljer. Du må sette programmets metadata (tittel, beskrivelse og søkeord) for hvert støttet språk. Denne informasjonen vil bli vist i butikken når brukeren åpner programmets side.
Du må også laste opp minst ett skjermbilde (åtte er tillatt) for hvert språk og støttet oppløsning, samt applikasjonsikonet. De vil bli vist i skjermbilder av Store. For å ta skjermbilder, kan du bruke et av verktøyene som er tilgjengelige i emulatoren.
Når du har fullført alle nødvendige trinn, vil portalen vise deg et sammendrag av innleveringen for bekreftelsen.
Administrere applikasjonens livssyklus
Når søknaden din er sertifisert, har du tilgang til mange rapporter som vil hjelpe deg å forstå hvor godt søknaden din utfører. Det er nedlastingsrapporter, salgsrapporter og krasjrapporter.
Hvis programmet ikke overholder sertifiseringsprosessen, finner du i PDF-filen din en fullstendig rapport i oversikten. Det vil fortelle deg i detalj hva som gikk galt og hva du bør gjøre for å fikse de identifiserte problemene.
Til slutt, selvfølgelig, kan du også oppdatere søknaden din. I dette tilfellet må du ganske enkelt gjenta alle innleveringsstrinnene, selv om alle feltene allerede er fylt med den gamle informasjonen og metadataene. Prosessen er også den samme hvis du bare vil endre informasjon som pris, beskrivelse og skjermbilder. Innleveringen må bare sertifiseres dersom du har endret all informasjon som må valideres. Hvis du bare endrer prisen, oppdateres oppdateringen umiddelbart.
Kjøp i app
En annen måte å tjene penger på med Windows Phone apps, er å støtte kjøp av apper. I tillegg til å kjøpe appen fra butikken, kan brukerne også foreta kjøp innenfor selve applikasjonen.
Kjøp av apper har alltid vært tillatt, men Windows Phone 8 har introdusert spesifikke APIer og Microsoft Backend-støtte. Tidligere var utvikleren ansvarlig for å opprette serverinfrastrukturen, administrere betalinger og koble til klienten.
Nå kan du bare stole på Store-infrastrukturen. Brukerne vil betale med samme kredittkort de brukte til å kjøpe apps eller musikk fra butikken, og portalen tillater deg å opprette ett eller flere produkter å kjøpe i programmet. Også i dette tilfellet vil inntektsdeling tilnærming bli brukt. Hvis du vil unngå det, er du fri til å implementere din egen innkjøpsinfrastruktur for apper; Microsoft tvinge ikke utviklere til å bruke sine tjenester.
Det er viktig å fremheve at innkjøp via Microsoft-tjenester kun er tillatt for virtuelle produkter (som nye funksjoner, spillnivåer, etc.); Det kan ikke brukes til å kjøpe fysiske varer.
To typer produkter støttes av Windows Phone:
goder er produkter som kan kjøpes bare en gang, som applikasjonsfunksjoner, nivåpakker, osv.
forbruks~~POS=TRUNC er produkter som kan kjøpes igjen etter at de har blitt konsumert, som virtuelle mynter.
Definere et produkt
Produktene er definert i portalen. På programmets side, er Produkter delen inneholder et alternativ for å legge til nye produkter i appen. Definere et produkt ligner på å sende inn et program: du må angi noen grunnleggende egenskaper som navn, pris og metadata, og deretter sender du inn det.
Det er to nøkkelegenskaper:
Produktidentifikatoren, som er en unik ID som du bruker i din søknad for å referere til produktet
Produkttypen, som kan brukes eller holdbar
Interagere med produkter
Når du har definert alle egenskapene, kan du begynne å jobbe med produktene i søknaden din. Sannsynligvis er det første kravet å vise listen over tilgjengelige produkter som brukere kan kjøpe. Dette målet oppnås ved å bruke CurrentApp klasse som tilhører Windows.ApplicationModel.Store namespace.
De CurrentApp klassen avslører LoadListingInformationAsync () metode, som returnerer a ListingInformation objekt som lagrer all informasjon om de tilgjengelige produktene.
Produktene er lagret inne i productlistings samling. I den forrige prøven viser vi dem til brukeren ved hjelp av en LongListSelector kontroll, som har følgende definisjon:
Hver ProductListing objekt inneholder samme egenskap som vi har tildelt produktet i butikken. I den forrige prøven viser vi navnet (Navn) og pris (FormattedPrice) av produktet.
Når du har produktlisten, må du administrere kjøpsprosessen. Igjen må vi bruke CurrentApp klassen, som tilbyr RequestProductPurchaseAsync () metode. Som en parameter skal vi passere ProductListing objekt valgt av brukeren.
Når et produkt er kjøpt, kan du sjekke statusen ved å bruke CurrentApp.LicenseInformation.ProductLicenses samling. Den inneholder alle støttede produkter med tilhørende lisensstatus. Hvert produkt er identifisert med en nøkkel, som er den unike identifikatoren vi tildelte da vi opprettet den i portalen.
private void MainPage_Loaded (objekt sender, RoutedEventArgs e) if (CurrentApp.LicenseInformation.ProductLicenses.ContainsKey ("CoolProduct")) ProductLicense license = CurrentApp.LicenseInformation.ProductLicenses ["CoolProduct"]; hvis (license.IsActive) // Lås opp funksjonen. ellers // Lås funksjonen.
I den forrige prøven kan vi avgjøre om produktet med CoolProduct Identifikatoren er kjøpt ved å sjekke verdien av Er aktiv eiendom. Operasjonen utføres når siden er lastet: Hvis produktet er kjøpt, låser vi opp den tilknyttede funksjonen, ellers venter vi på at brukeren kjøper den.
For et forbruksprodukt er kjøpsprosessen den samme. Den eneste forskjellen er at etter at den er blitt konsumert, må vi rapportere den slik at den kan "låses opp" for å bli kjøpt igjen.
Vi kan rapportere det ved å ringe ReportProductFullfillment () metode av CurrentApp klasse, som krever som en parameter på ProductLicense objekt som identifiserer produktet.
Dessverre er det ikke veldig enkelt å teste et kjøp i appen. Siden produktene må defineres i portalen, må du sende inn søknaden din før du kan teste kjøpsprosessen.
Ett arbeid er å publisere søknaden som beta; siden appen ikke trenger å være sertifisert, vil den være umiddelbart tilgjengelig for testing. Ulempen er at det er vanskelig å ordentlig teste det hvis noe går galt siden du ikke kan feilsøke det ved hjelp av Visual Studio som du normalt ville med noe annet program.
Av denne grunn har Microsoft gitt et testbibliotek kalt MockIAP. Formålet er å "mock" de ekte applikasjonsprogrammene for apper, slik at operasjonene ikke utføres mot den virkelige Microsoft-tjenesten, men bruk falske produkter som er definert i søknaden.
Det er to ting å gjøre for å begynne å bruke MockIAP-biblioteket. Den første er å legge til noen betingede kompileringsdirektiv, slik at når applikasjonen blir kompilert i feilsøkingsmodus (vanligvis under testing), vil den bruke mock-biblioteket. Når den er kompilert i utgivelsesmodus, vil den bruke de virkelige Microsoft-tjenestene.
Følgende kodeprøve viser hvordan navneområdedeklarasjonen vil se på siden din:
#if DEBUG bruker MockIAPLib; bruker Store = MockIAPLib; #else bruker Windows.ApplicationModel.Store; #slutt om
Det andre trinnet er å definere produktene vi trenger å bruke. Siden applikasjonen ikke vil være koblet til de virkelige tjenestene, må vi duplisere i koden produktene vi har definert i portalen.
Følgende kode viser en prøveinitialisering:
privat tomrom SetupMockIAP () MockIAP.Init (); MockIAP.RunInMockMode (true); MockIAP.SetListingInformation (1, "en-US", "Dette er en prøveapp", "1", "SampleApp"); ProductListing p = ny ProductListing Name = "Cool produkt", ProductId = "CoolProduct", ProductType = Windows.ApplicationModel.Store.ProductType.Durable, Description = "Et kjølig produkt", FormattedPrice = "10.00 €", Tag = streng. Tom; MockIAP.AddProductListing ("CoolProduct", p); ProductListing p2 = new ProductListing Name = "Kjølig produktforbruk", ProductId = "CoolProductConsumable", ProductType = Windows.ApplicationModel.Store.ProductType.Consumable, Beskrivelse = "Et kjølig forbruksprodukt", FormattedPrice = "5.00 €", Tag = streng.Empty; MockIAP.AddProductListing ("CoolProductConsumable", p2);
Vi lager to produkter: en holdbar en identifisert av nøkkelen CoolProduct, og en forbruksvare identifisert av nøkkelen CoolProductConsumable. Hvert produkt er identifisert av ProductListing klasse (samme klasse vi brukte med de virkelige tjenestene), og vi kan bruke den til å definere alle produktegenskaper som vanligvis hentes fra Microsoft-tjenester som navn, type, pris og så videre.
Vi legger til hvert produkt ved hjelp av AddProductListing () metode av MockIAP klasse. Etter at du har lagt til produktene, kan vi bruke standard APIer for kjøp i app. Operasjoner vil bli utført lokalt med de falske produktene i stedet for de virkelige tjenestene, men oppførselen vil være nøyaktig den samme. Vi vil kunne liste, kjøpe og konsumere de tilgjengelige produktene.
Konklusjon
Når vi snakker om mobile applikasjoner, er utvikling ikke det eneste aspektet vi må vurdere. Hvis vi ønsker å lykkes, må vi også distribuere og fremme vår søknad. I denne opplæringen har vi diskutert:
Hvordan lokalisere søknaden slik at den appellerer til et bredere publikum.
Hvordan Windows Phone Store og sertifiseringsprosessen fungerer. Innlevering av appen er et avgjørende skritt siden vi må gjøre mange viktige markedsføringsbeslutninger som appens pris, landene den vil få tilgjengelig i, osv..
Slik øker du inntektene ved å støtte kjøp i appen.
Share
Accentsconagua
