Etter at du har installert verktøysettet, må du aktivere den for prosjektet i Verktøy-menyen i Visual Studio ved å velge Aktiver flerspråklig app toolkit alternativet. Når du har aktivert den, vil Visual Studio jobbe med .xlf filer i stedet for .resx filer (unntatt hovedspråket). Under innsamlingsprosessen, vil verktøysettet generere alle de nødvendige .resx filene for deg.

For å få tilgang til verktøykasse visuelt grensesnitt, bare dobbeltklikker en .xlf filen, og du vil se en fullstendig liste over ressurser. Et ikon vil varsle deg om status for hver ressurs. Hvis ressursen ennå ikke er oversatt, er en rød sirkel vises. Hvis ressursen er oversatt, men krever revisjon, er en gul sirkel vises. Hvis oversettelsen er godkjent, er en grønn sirkel vises.

Tvinge språk

Windows Phone vil automatisk velge den ressursen filen som matcher telefonen språk. Hvis en passende ressurs fil mangler (fordi telefonen språk ikke støttes av søknaden), vil standard brukes.

Du kan endre denne atferden, for eksempel hvis du ønsker å gi brukerne muligheten til å velge språket de foretrekker, uavhengig av telefonens språk. For å gjøre dette, må du angi en annen kultur koden når App klasse (deklarert i App.xaml.cs fil) opprettes:
offentlig App () {Culture kultur = new Culture (" it-IT "); Thread.CurrentThread.CurrentCulture = kultur; Thread.CurrentThread.CurrentUICulture = kultur;}

Etter at du har definert en Culture objekt ved å føre kulturen kode som parameter, kan du tilordne den til to forskjellige egenskaper av Thread.CurrentThread objekt:

CurrentCulture er programmets kultur, som brukes til å definere funksjoner som dato og klokkeslett formater, valuta, etc.

CurrentUICulture er brukergrensesnittet kultur, som brukes til å forstå hvilke ressursfilen å plukke. < .no>

Denne tilnærmingen er også nødvendig hvis du ønsker å bruke pseudo språket generert av Multilingual App Toolkit løpet av testperioden. Siden pseudo språk er ikke et offisielt språk som støttes av plattformen, må du tvinge den ved hjelp av QPS-ploc kultur kode, som vist i følgende eksempel:
offentlig App () {Culture kultur = new Culture ("QPS-ploc"); Thread.CurrentThread.CurrentCulture = kultur; Thread.CurrentThread.CurrentUICulture = kultur;}

Ved hjelp av pseudo språk er en flott måte å identifisere tekst som ennå ikke er oversatt og teste om programmets layout er i stand til å håndtere lang tekst. Hva skjer vanligvis når du utvikler et program er at du teste den med bare et par språk, glemmer at et ord som ser veldig kort på engelsk, for eksempel, kan være svært lang når den er oversatt til tysk.

The Store Erfaring

Som nevnt i den første artikkelen, er Windows Phone butikken den eneste måten å distribuere applikasjoner til brukerne med mindre du arbeider bedriften distribusjon. Du trenger en betalt utviklerkonto, som kan kjøpes fra Windows Dev Center. Gebyret er $ 19 per år, med mindre du er en student abonnerer på Dreamspark program, i så fall er gratis. En lignende ytes til MSDN-abonnenter. I fordeler siden, kan du få en token som lar deg registrere deg gratis

Annet enn årsavgiften, gjelder Microsoft en inntektsdeling tilnærming: 30% av programmets prisen er holdt av Microsoft, mens den andre 70% er gitt til utvikleren. Naturligvis har dette deling gjelder ikke dersom programmet er gratis.

Når utviklerkontoen din har blitt aktivert og søknaden din er klar, kan du sende det på portalen dev.windowsphone.com. I løpet av prosessen, må du definere program markedsføring funksjoner, som pris, metadata og distribusjon type. Etter det er innlevering ferdig, og sertifiseringsprosessen starter. Søknader blir ikke automatisk publisert til Store; Først må de bestå en sertifiseringsprosess som validerer programmet både fra et teknisk og innholds synspunkt

De tekniske tester gjør at programmet gir en god opplevelse for brukerne. det ikke krasjer, er det rask og responsiv, og brukergrensesnittet er ikke forvirrende.

manuelle tester sjekke innholdet i søknaden. Noen typer innhold som pornografi, overdreven vold, osv, er ikke tillatt og vil føre til en sertifisering fiasko.

Når du starter innsending prosessen, vil du se en liste over tiltak for å følge for å fullføre behandle. La oss kort se på hvert trinn

Trinn 1:. App Info

Det første trinnet i publiseringsprosessen brukes til å stille noen grunnleggende informasjon, som app i kategorien, pris tier, og markedsfordeling . Din søknad vil automatisk bli distribuert i alle de støttede landene på 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, hvor innholdet politikk er strengere. Sertifiseringsprosessen har også en valgfri Market utvalg og tilpasset prising steg, som tilbyr dypere tilpasning: du kan velge å distribuere applikasjonene i spesifikke land og tilpasse prisen for hvert land

Den andre viktige muligheten til å sette. i løpet av dette trinnet er distribusjonskanalen. Det er tre måter å distribuere en Windows Phone-programmet:

Den offentlige butikken. Appen kan bli oppdaget og ned av alle brukere

Skjulte: Appen er fortsatt tilgjengelig i offentlig butikken, men det kan ikke bli oppdaget av brukerne. Den eneste måten å finne det er ved hjelp av direkte kobling som genereres når programmet er publisert

Beta. Søknaden kan ikke bli oppdaget av brukerne, og dessuten vil bare autoriserte brukere få lov til å laste ned den. Brukerne er autorisert med Microsoft kontoen de registrerte telefonen med. Du vil være i stand til å inkludere opp til 10.000 brukere i løpet av innsendingsprosessen. Denne distribusjonskanal ble opprettet for å støtte beta testing; i dette scenariet, men søknaden vil faktisk ikke bli testet, men vil være tilgjengelig for utvalgte brukere innen to timer å sende inn app. En beta søknaden utløper automatisk 90 dager etter at den er sendt inn for første gang, uavhengig av senere oppdateringer

Trinn 2:. Last opp og beskrive XAP

Det andre trinnet krever mer tid til å fullføre, siden du må gi all den søknaden informasjon som vil bli vist i Windows Phone Store.

Det første trinnet er å laste opp XAP filen. Den XAP er pakken produsert av Visual Studio når du kompilere prosjektet, og den inneholder alle de nødvendige filene for programmet å kjøre. Du finner det inne i bin mappen på Visual Studio prosjektet. Husk å alltid kompilere programmet i utgivelsen modus; ellers vil det ikke bli akseptert.

Når du har lastet opp XAP, vil portalen automatisk vise en oppsummering av programmets funksjoner, som de støttede oppløsninger, de nødvendige evner, og så videre. Du vil også måtte sette versjonsnummeret til programmet du laster opp.

Portalen vil også automatisk gjenkjenner språkene du støtter, som skal vises i en rullegardinmeny kalt Språk detaljer. Du må sette programmet metadata (tittel, beskrivelse og nøkkelord) for hver støttede språk. Denne informasjonen vil bli vist i Store 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, pluss søknaden ikon. De vil bli vist i skjermdelen av Store. Å ta skjermbilder, kan du bruke en av de verktøyene som er tilgjengelige i emulator.

Når du har fullført alle de nødvendige skritt, portalen vil vise deg en oppsummering av innlevering for bekreftelsen.
< h3> Administrere Søknad Life Cycle

Når søknaden er sertifisert, vil du ha tilgang til mange rapporter som vil hjelpe deg å forstå hvor godt din søknad presterer. Det finnes laste ned rapporter, salgsrapporter, og krasjrapporter.

Hvis søknaden ikke består sertifiseringsprosessen, finner du i oversikten en PDF-fil som inneholder den fullstendige rapporten. Den 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, du kan også oppdatere din søknad. I dette tilfellet vil du bare nødt til å gjenta alle innsending trinnene, selv om alle feltene vil allerede være fylt med gammel informasjon og metadata. Prosessen er også det samme hvis du bare ønsker å endre informasjon som pris, beskrivelse og skjermbilder. Innsending bare å være sertifisert hvis du har endret noen informasjon som må valideres. Hvis du bare endre prisen, er oppdateringen umiddelbart publisert.

In-App Purchases

En annen måte å tjene penger med Windows Phone-apps er å støtte in- app kjøp. I tillegg til å kjøpe appen fra Store, kan brukerne også foreta kjøp i selve programmet.

In-app kjøp har alltid vært tillatt, men Windows Phone 8 har innført spesifikke APIer og Microsoft backend støtte. Tidligere utvikleren hadde ansvaret for å skape serverinfrastrukturen, administrerende betalinger, og koble klienten.

Nå kan du bare stole på Store infrastruktur. Brukerne vil betale med det samme kredittkortet de brukt til å kjøpe apps eller musikk fra Store, og portalen vil tillate deg å lage en eller flere produkter å kjøpe i programmet. Også i dette tilfellet vil omsetningen deling tilnærming bli anvendt. Hvis du ønsker å unngå det, står du fritt til å implementere din egen in-app kjøp infrastruktur; Microsoft har ikke tvinge utviklere å bruke sine tjenester

Det er viktig å understreke at i-app innkjøp gjennom Microsoft-tjenester er kun 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.

varige er produkter som kan kjøpes bare en gang, som programfunksjoner, nivå pakker, etc.

Forbruksvarer er produkter som kan kjøpes på nytt etter at de har blitt konsumert, som virtuelle mynter.

Definere et produkt

produkter er definert i portalen. I søknaden side, tilbyr produkter seksjonen et alternativ til å legge til nye produkter i appen. Definere et produkt er lik sende inn en søknad: du må sette noen grunnleggende egenskaper som navn, pris og metadata, og deretter sende den

Det er to viktige egenskaper:.

produktet identifikator, som er en unik ID som du bruker i programmet for å se produktets

produkttypen, som kan være forbruks eller holdbart

samspill med Produkter

Når du har definert alle egenskaper, kan du begynne å jobbe med produktene i søknaden din. Sannsynligvis er det første kravet for å vise listen over tilgjengelige produkter brukerne kan kjøpe. . Dette målet er oppnådd ved hjelp av CurrentApp klasse som tilhører Windows.ApplicationModel.Store navnerom
privat async void OnListStuffClicked (objekt avsenderen, RoutedEventArgs e) {ListingInformation notering = avvente CurrentApp.LoadListingInformationAsync (); List < ProductListing > productListings = listing.ProductListings.Values.ToList (); Purchases.ItemsSource = productListings;}

CurrentApp klasse eksponerer LoadListingInformationAsync () metoden, som returnerer en ListingInformation objekt som lagrer all informasjon om de tilgjengelige produkter.

Produktene er lagret inne i ProductListings samlingen. I forrige prøven, viser vi dem til brukeren ved hjelp av en LongListSelector kontroll, som har følgende definisjon:
< telefon: LongListSelector x: Name = "kjøp" SelectionChanged = "OnSelectedPurchaseChanged" > < telefon: LongListSelector.ItemTemplate > < DataTemplate > < StackPanel Orientation = "Horisontal" Margin = "15, 0, 0, 20" > < TextBlock Text = "{Sti = Name Binding}" Margin = "0, 0, 20, 0" /> < TextBlock Text = "{Binding Sti = FormattedPrice}" /> < /StackPanel > < /DataTemplate > < /telefon: LongListSelector.ItemTemplate > < /telefon: LongListSelector >

Hver ProductListing objekt inneholder den samme egenskapen vi har tilordnet til produktet i butikk. I forrige prøven, vi viser 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 () -metoden. Som parameter, kommer vi til å passere ProductListing objektet valgt av brukeren
privat async void OnSelectedPurchaseChanged (objekt avsenderen, SelectionChangedEventArgs e) {ProductListing selectedPurchase = Purchases.SelectedItem som ProductListing.; avvente CurrentApp.RequestProductPurchaseAsync (selectedPurchase.ProductId, true);}

Når et produkt er kjøpt, kan du sjekke status ved å bruke CurrentApp.LicenseInformation.ProductLicenses samlingen. Den inneholder alle de støttede produkter med tilhørende lisensstatus. Hvert produkt er identifisert av en nøkkel, som er unik identifikator vi tildelt da vi laget den i portalen.
Private void MainPage_Loaded (objekt avsenderen, RoutedEventArgs e) {if (CurrentApp.LicenseInformation.ProductLicenses.ContainsKey ( "CoolProduct")) {ProductLicense lisens = CurrentApp.LicenseInformation.ProductLicenses ["CoolProduct"]; if (license.IsActive) {//Lås opp funksjonen. } Else {//Lås funksjonen. }}}

I forrige prøven, kan vi finne ut om produktet med CoolProduct identifikator har blitt kjøpt ved å sjekke verdien av IsActive eiendommen. Operasjonen utføres når siden er lastet: hvis produktet er kjøpt, låser vi den tilhørende funksjonen, ellers vil vi venter for brukeren å kjøpe det

For en forbruksvare, er kjøpsprosessen. det samme. Den eneste forskjellen er at, etter at den er fortært, må vi rapportere det slik at det kan bli "låst" til å bli kjøpt igjen.

Vi kan rapportere det ved å ringe ReportProductFullfillment () metoden i CurrentApp klasse , som krever som et parameter på ProductLicense objekt som identifiserer produktet
private void OnConsumeButtonClicked (objekt avsenderen, RoutedEventArgs e) {var lisenser = CurrentApp.LicenseInformation.ProductLicenses.; if (licenses.ContainsKey ("CoolProductConsumable")) {ProductLicense productLicense = lisenser ["CoolProductConsumable"]; CurrentApp.ReportProductFulfillment (productLicense.ProductId); }}
Testing In-App Purchases

Dessverre er ikke veldig lett å teste en in-app kjøp. Siden produktene må være definert i portalen, må du sende inn din søknad før å kunne teste kjøpsprosessen

En work-around er å publisere programmet som beta.; siden programmet ikke trenger å bli sertifisert, vil det være umiddelbart tilgjengelig for testing. Ulempen er at det er vanskelig å riktig teste det hvis noe går galt siden du ikke kan feilsøke den ved hjelp av Visual Studio som du vanligvis ville gjort med et annet program.

Av denne grunn har Microsoft gitt en testing bibliotek kalt MockIAP. Dens formål er å "mock" the real in-app kjøp APIer slik at operasjonene ikke blir utført mot ekte Microsoft-tjenesten, men bruker falske produkter som er definert i programmet.

MockIAP kan lastes ned fra MSDN og legges til løsning. APIene det tilbyr er de samme som de som utsettes av den innfødte SDK; den eneste forskjellen er at de tilhører den MockIAPLib navne stedet for Windows.ApplicationModel.Store navnerom.

Det er to ting du kan gjøre for å begynne å bruke MockIAP biblioteket. Den første er å legge til noen betingede samleplater direktiver slik at når programmet er kompilert i feilsøkingsmodus (typisk under testing) vil bruke mock biblioteket. Når det er utarbeidet i utløserfunksjon, vil den bruke de virkelige Microsoft-tjenester

Følgende kodeeksempel viser hvordan navneromdeklarasjon vil se på siden din.
#if DEBUG hjelp MockIAPLib; bruker butikken = MockIAPLib; #else hjelp Windows.ApplicationModel.Store; #endif

Det andre trinnet er å definere de produktene vi trenger å bruke. Siden søknaden ikke vil bli koblet til de reelle tjenester, må vi duplisere i koden de produktene vi har definert i portalen

Følgende kode viser et eksempel initialisering.
private void SetupMockIAP () {MockIAP.Init (); MockIAP.RunInMockMode (true); MockIAP.SetListingInformation (1, "en-US", "Dette er en prøve app", "1", "SampleApp"); ProductListing p = new ProductListing {Name = "Cool produkt", ProductID = "CoolProduct", Produkttype = Windows.ApplicationModel.Store.ProductType.Durable, beskrivelse = "En kul produkt", FormattedPrice = "10,00 €", Tag = streng. tom}; MockIAP.AddProductListing ("CoolProduct", s); ProductListing p2 = new ProductListing {Name = "Cool produkt forbruks", ProductID = "CoolProductConsumable", Produkttype = Windows.ApplicationModel.Store.ProductType.Consumable, Description = "En kul forbruksvare", FormattedPrice = "5,00 €", Tag = string.Empty}; MockIAP.AddProductListing ("CoolProductConsumable", p2);}

Vi skaper to produkter: en holdbar man identifisert av nøkkelen CoolProduct, og en forbruks man identifisert av nøkkelen CoolProductConsumable. Hvert produkt er identifisert av ProductListing klasse (samme klasse vi brukte med reelle tjenester), og vi kan bruke den til å definere alle produktegenskapene som vanligvis hentes fra Microsoft-tjenester som navn, type, pris, og så videre.

Vi legger hvert produkt ved hjelp av AddProductListing () metoden i MockIAP klassen. Etter å legge produktene, kan vi bruke standard APIer for in-app kjøp. Operasjoner vil bli utført lokalt med de falske produkter i stedet for de virkelige tjenester, men atferden vil være nøyaktig den samme. Vi vil være i stand til å liste, kjøpe og forbruke de tilgjengelige produkter.

Konklusjon

Når vi snakker om mobile applikasjoner, er ikke utviklingen den eneste aspekt vi må vurdere . Hvis vi ønsker å være vellykket, må vi også distribuere og fremme søknaden vår. I denne opplæringen, har vi diskutert.

Denne opplæringen er siste kapittel fra Windows Phone 8 Succinctly, en gratis eBok fra teamet på Syncfusion. Vi håper du har hatt glede av denne serien på å utvikle applikasjoner for Windows Phone 8!