Windows Phone 8 Succinctly: sentrale begreper
43
Del
en
Del

Dette Cyber ​​mandag Envato Tuts + kurs vil bli redusert til bare $ 3. Ikke gå glipp av
Dette innlegget er en del av en serie som heter Windows Phone 8 Succinctly.Windows Phone 8 Succinctly. Den bruker InterfaceWindows Phone 8 Succinctly: Data Access-Storage

I denne opplæringen, vil vi dekke noen av de sentrale begrepene Windows Phone utvikling, for eksempel asynkron programmering, navigasjon, og administrerende orientering endringer. Vi vil også ta en rask titt på livsløpet til en typisk Windows Phone-programmet.

Asynchronous Programmering

I dag er asynkron programmering en nødvendig ferdighet for utviklere. I det siste, de fleste programmer jobbet med en synkron tilnærming: brukeren i gang en operasjon, og før det var ferdig, ble søknaden frosset og helt ubrukelig

Denne oppførselen er ikke akseptabelt i dag, spesielt i mobil. verden. Brukere vil ikke kjøpe en telefon som ikke tillater dem å svare på en samtale fordi en søknad er fast prøver å fullføre en operasjon

Det er to tilnærminger i Windows Phone å håndtere asynkron programmering:. Callbacks og async /avvente mønster.

Tilbakering

I de fleste tilfeller, spesielt i Windows Phone 8, har callbacks blitt erstattet med asynkrone metoder som bruker async og venter mønster. Men er det noen APIer som fortsatt bruker tilbakeringing tilnærming, så det er viktig å lære det.

Tilbakering er delegat metoder som kalles når en asynkron operasjon er avsluttet. Dette betyr at koden som utløser drift og koden som styrer resultatet blir lagret i to ulike metoder.

La oss se på følgende eksempel på WebClient klassen, en av de grunnleggende APIer i rammeverket som utfører nettvirksomheten som nedlasting og opplasting av filer:
private void OnStartDownloadClicked (objekt avsenderen, RoutedEventArgs e) {WebClient klient = new WebClient (); client.DownloadStringCompleted + = new DownloadStringCompletedEventHandler (client_DownloadStringCompleted); client.DownloadStringAsync (ny Uri ("http://wp.qmatteoq.com", UriKind.Absolute)); Debug.WriteLine ("Download har startet");} void client_DownloadStringCompleted (objekt avsenderen, DownloadStringCompletedEventArgs e) {MessageBox.Show (e.Result);}

Filen nedlasting (i dette tilfellet, vi laster ned HTML av en webside) starter når vi kaller DownloadStringAsync () -metoden, men vi trenger å abonnere på DownloadStringCompleted arrangementet, som utløses når nedlastingen er fullført, for å administrere resultatet. Vanligvis har hendelsesbehandling (tilbakekalls-metoden) en parameter som inneholder resultatet av forespørselen. I forrige prøven, det heter e og sin type er DownloadStringCompletedEventArgs.

Legg merke til meldingen "Download har startet" som er skrevet i Visual Studio Output-vinduet. Siden metoden er asynkron, vil meldingen vises umiddelbart etter at nedlastingen har startet siden koden vil fortsette å kjøre før nedlastingen er fullført. Deretter henrettelsen flyttes til tilbakeringing metoden.

Async og avventer

Den tilbakeringing tilnærming er vanskelig å lese. I motsetning til synkron-kode, flyten av henrettelsen "hopper" fra en metode til en annen, slik at en utvikler kan ikke bare lese linje etter linje for å forstå hva som skjer. I tillegg, hvis du trenger å skrive en tilpasset metode som starter et nettverk drift og returnerer den nedlastede filen, du bare ikke kan gjøre det fordi logikken er delt i to forskjellige stykker.

async og venter mønster ble introdusert i C # 5.0 for å løse disse problemene. Windows Runtime er tungt basert på denne tilnærmingen og de fleste av APIer vi skal se i denne serien bruker den.

Når vi bruker async og venter søkeord, vi kommer til å skrive sekvensiell kode som hvis det er synkron-kompilatoren vil utføre en rad etter hverandre. For bedre å forstå hva som skjer under panseret, husk at når vi starter en asynkron operasjon, setter kompilatoren et bokmerke og deretter avsluttes metoden. På denne måten, er det UI tråden gratis og brukerne kan holde i samspill med søknaden. Når den asynkrone operasjonen er fullført, går kompilatoren tilbake til bokmerket og fortsetter utførelsen.

async og avvente mønsteret er basert på Task klassen, som er basen retur type en asynkron metode. En metode kan returnere:

Task hvis det er et tomrom metode: Kompilatoren bør vente til drift skal være ferdig til å kjøre neste linje, men det gjør ikke forvente en verdi tilbake
.
Task < T > hvis metoden returnerer en verdi. Kompilatoren vil vente på operasjon for å bli ferdig, og vil returnere resultatet (hvis typen er T) til den viktigste metoden, som vil være i stand til å utføre flere operasjoner på den.

La oss se et eksempel . Vi kommer til å legge til vårt prosjekt et bibliotek kalt Async for NET, som er utviklet av Microsoft og er tilgjengelig på nuget. Formålet er å legge async og avvente støtte til gammel teknologi som ikke støtter det, siden de ikke er basert på C # 5.0, som Windows Phone 7 eller Silverlight. Det er også nyttig i Windows Phone 8-applikasjoner, siden det legger asynkrone metoder til APIer som fortsatt basert på tilbakeringing mønster.

En av disse APIene er WebClient klassen vi har sett tidligere. Ved å installere dette biblioteket vi kan bruke DownloadStringTaskAsync () metode som støtter det nye mønsteret. Denne metoden avkastning type er Task < streng >. Dette betyr at operasjonen er asynkron og det vil returnere en streng
privat async void OnStartDownloadClicked (objekt avsenderen, RoutedEventArgs e) {WebClient klient = new WebClient (.); string resultat = avvente client.DownloadStringTaskAsync ("http://wp.qmatteoq.com"); MessageBox.Show (resultat);}

Først, la oss oppmerksom på hvordan du bruker denne nye syntaks. Enhver metode som inneholder en asynkron metoden må merkes med ASYNC ordet. I dette tilfellet er det en hendelseshåndterer som påberopes når brukeren trykker på en knapp.

Deretter må vi legge til avvente søkeord som prefiks for asynkron metoden. I vårt eksempel har vi plassert den før metoden DownloadStringTaskAsync (). Dette nøkkelordet forteller kompilatoren å vente til metoden er ferdig før du går videre.

Når asynkron metoden er startet, kan du anta at kompilatoren har satt et bokmerke og avslutt deretter metoden fordi programmet er fortsatt lydhør . Når nedlastingen er fullført, returnerer kompilatoren til bokmerket og fortsetter utførelsen. Nedlastingen resultat er lagret i resultatvariabelen, der verdien vises på skjermen ved hjelp av en messagebox.

Som du kan se, selv om koden under panseret er asynkron og fryser ikke UI, det vises synkron: koden kjøres en linje av gangen, og messagebox vises ikke før DownloadStringTaskAsync () metoden er ferdig jobben sin

Den Dispatcher

Noen ganger, spesielt når du har. å håndtere tilbakeringing metoder, er operasjonene utføres i en bakgrunnstråd, som er forskjellig fra den tråden som styrer UI. Denne tilnærmingen er svært nyttig i å holde UI tråden så fri som mulig slik at grensesnittet er alltid rask og responsiv.

Noen ganger kan en bakgrunnstråd kan trenge å samhandle med brukergrensesnittet. For eksempel, la oss si en bakgrunnstråd har fullført jobben sin og må vise resultatet i en TextBlock kontroll plassert på siden. Hvis du prøver å gjøre det, en UnauthorizedAccessException feil med meldingen "Ugyldig cross-tråden access"
vil bli vist.

Grunnen til denne feilen er at en bakgrunn tråden er ikke tillatt å få tilgang til kontrollene på en side, siden de er styrt av en annen tråd. Løsningen er å bruke et rammeverk er Dispatcher klasse. Formålet er å sende operasjoner til UI tråden fra en annen tråd. På denne måten kan du samhandler med XAML kontroller uten problemer fordi tråden er den samme. Eksemplet nedenfor viser hvordan du bruker det:
Dispatcher.BeginInvoke (() = > {txtResult.Text = "Dette er resultatet";})

Du bare må passere en handling som trenger å bli henrettet i brukergrensesnittet tråden som en parameter for den BeginInvoke () metoden i Dispatcher klassen. I den forrige prøven, er handlingen defineres ved hjelp av en anonym metode

Tips:.. Anonyme metoder kalles slik fordi de ikke har et bestemt navn, de rett og slett definere operasjonene som skal utføres < .no>

Dispatcher er ikke nødvendig når du arbeider med async og venter mønster fordi det sørger for at selv om operasjonen er utført i en av de frie tråder tilgjengelig i tråden bassenget, er resultatet alltid tilbake i UI tråden.

Navigasjon

Et annet viktig begrep å lære når du utvikler en Windows Phone programmet er navigasjon. I de fleste tilfeller vil søknaden bli laget av forskjellige sider, så du trenger en måte å bevege seg fra en side til en annen.

Rammen har en innebygd navigasjonssystem, som kan styres ved hjelp av NavigationService klasse .
private void OnGoToPage2Clicked (objekt avsenderen, RoutedEventArgs e) {NavigationService.Navigate (ny Uri ("/Pages /Page2.xaml", UriKind.Relative));}

Navigasjonssystemet gir, i hver side, to hendelser som kan administreres for å avskjære navigasjons hendelser: OnNavigatedTo () utløses når du flytter fra en annen side til den gjeldende siden; OnNavigateFrom () utløses når du flytter fra gjeldende side til en annen side. En annen viktig side hendelse som kan tegnes er Loaded, som utløses når siden er helt full. Det er vanligvis brukes til å laste inn data som må vises på siden
offentlig delvis klasse Mainpage:. PhoneApplicationPage {public Mainpage () {InitializeComponent (); Lastet + = MainPage_Loaded; } Void MainPage_Loaded (objekt avsenderen, RoutedEventArgs e) {Debug.WriteLine ("siden er lastet"); } Beskyttet ride void OnNavigatedTo (NavigationEventArgs e) {base.OnNavigatedTo (e); } Beskyttet ride void OnNavigatedFrom (NavigationEventArgs e) {base.OnNavigatedFrom (e); }}
Passing Parametere til en annen side

Et felles krav når du arbeider med navigasjon er å passere en parameter til en annen side, for eksempel en master /detalj scenario der du velger et listeelement i master siden og vise detaljene i en ny side

Navigasjons rammeverket tilbyr en innebygd måte å passere enkle parametre som strenger og tall som er arvet direkte fra Internett verden:. spørrestrengparametere. De er lagt direkte til nettadressen til siden der du ønsker å omdirigere brukeren, som vist i følgende eksempel:
private void OnGoToPage2Clicked (objekt avsenderen, RoutedEventArgs e) {NavigationService.Navigate (ny Uri ("/Pages /Page2.xaml?id=1 ", UriKind.Relative));}

Du vil være i stand til å hente parameter i landingssiden ved hjelp av OnNavigatedTo hendelsen og NavigationContext klasse, som i følgende eksempel:

beskyttet ride void OnNavigatedTo (NavigationEventArgs e) {if (NavigationContext.QueryString.ContainsKey ("id")) {int id = int.Parse (NavigationContext.QueryString ["id"]); MessageBox.Show ("The id er" + id); }}

NavigationContext klassen tilbyr en samling kalt QueryString, som inneholder alle tilgjengelige parametere. Du vil være i stand til å få verdien ved hjelp av sin nøkkel (som er parameteren navn).

I noen tilfeller, enkle parametere er ikke nok. Noen ganger må du bestå komplekse objekter til en annen side. Hoved /detalj scenario er, også i dette tilfelle, er et godt eksempel. I mange situasjoner, til riktig befolke detaljsiden, trenger du tilgang til hele objektet som er valgt i listen.

En god tilnærming til dette er å passere detaljsiden en vanlig parameter som kan brukes til å identifisere det valgte element, som en unik identifikator. Deretter, i OnNavigatedTo hendelseshåndterer på detaljsiden, legger elementet med den mottatte identifikator fra datainnsamling (som kan være en database eller en ekstern tjeneste).

Manipulere Navigation Stack

Hvert program har sin egen navigasjons stack, som er en liste over sider som brukeren har beveget seg gjennom mens du bruker programmet. Hver gang brukeren navigerer til en ny side, er den lagt til stakken. Når brukeren går tilbake, er den siste siden fra stabelen fjernet. Når en side er igjen i bunken og brukeren trykker på tilbakeknappen, er programmet lukkes.

NavigationService klassen tilbyr noen måter å manipulere stabelen. I begynnelsen er det en bestemt egenskap kalt BackStack som er en samling av alle sidene i bunken. Når vi diskuterer Fast App Resume senere i denne artikkelen vil vi se en av de tilgjengelige metodene for å manipulere stabelen. RemoveBackEntry (), som fjerner den siste siden fra bunken

En annen viktig metode er GoBack ( ), som omdirigerer brukeren til forrige side i bunken. Formålet er å unngå å skape sirkulære navigeringsproblemer i programmet.

Bildet nedenfor viser et eksempel på sirkulær navigasjon og hvordan å rette det opp. La oss si at du har et program laget av to sider, en hovedside og en innstillingsside. Du velger å bruke Naviger () metoden i NavigateService klassen for hver navigasjon. Brukeren navigerer fra hovedsiden til innstillingssiden, og igjen til hovedsiden.

Problemet her er at hver gang du ringer Naviger () metoden, legger du til en ny side til navigasjons stabelen. Når brukeren er på hovedsiden og trykker på tilbakeknappen, forventer han eller hun til å avslutte programmet. I stedet, den andre gangen, vil brukeren bli omdirigert til siden Innstillinger siden forrige navigasjon lagt på siden av stabelen.

Den riktige tilnærmingen er å bruke GoBack () -metoden. I stedet for å legge til en ny side i bunken, rett og slett omdirigeringer denne metoden brukeren til den forrige. Resultatet vil være den samme brukeren, fra innstillingssiden, blir tatt tilbake til hovedsiden-, men siden det ikke er noen sider som er lagt til stakken, vil programmet oppfører seg som forventet. Hvis brukeren trykker på tilbakeknappen, vil applikasjonen bli stengt

Avskjære navigasjons. Den UriMapper Class

Senere i serien vi skal håndtere ulike situasjoner der programmet er åpnet med en spesiell Uri, for eksempel ved hjelp av tale API eller deling av data.

I disse tilfellene, vi kommer til å bruke et navigasjonssystem funksjon kalt UriMapper, som er en klasse som kan fungere som en middelaldrende mann i hver navigasjon operasjon. Når brukeren navigerer fra en side til en annen (start siden kan være også være telefonens startskjermen), er klassen i stand til å fange opp det og omdirigere brukeren til en annen side hvis det er nødvendig.

For å opprette en UriMapper -basert klasse, bare legge til en ny klasse til prosjektet. Det har å arve fra UriMapperBase klassen. Det vil kreve at du implementere MapUri () metoden, som er påberopt under navigasjonen, som vist i følgende eksempel:
public class UriMapper: UriMapperBase {public override Uri MapUri (Uri uri) {string tempUri = HttpUtility. UrlDecode (uri.ToString ()); if (tempUri.Contains ("/FileTypeAssociation")) {//Administrer den valgte filen. returnere nye Uri ("/Pages /FilePage.xaml", UriKind.Relative); } Else {return uri; }}}

MapUri () metoden tar i kilde Uri og må returnere den nye Uri å omdirigere brukeren. I forrige prøven, vi sjekket om kilden Uri inneholdt en bestemt streng (i dette tilfellet, er det en som tilhører datadeling scenario vi vil se senere i denne serien). Bekreftende fall omdirigere vi brukeren til en bestemt side av programmet som er i stand til å håndtere situasjonen; ellers har vi ikke endre navigasjonsstrømmen ved å returnere den opprinnelige Uri.

Når du har opprettet en UriMapper klasse, må du tilordne den til UriMapper eiendommen av RootFrame objekt som er deklarert i den App.xaml.cs filen. Du må utvide regionen kalt Phone søknad initialisering (som vanligvis er skjult), og endre InitializePhoneApplication () metode som i følgende eksempel:
private void InitializePhoneApplication () {if (phoneApplicationInitialized) tilbake; //Opprett rammen, men ikke sett det som RootVisual ennå; dette gjør at //splash skjermen for å være aktiv inntil søknaden er klar til å yte. RootFrame = new PhoneApplicationFrame (); RootFrame.UriMapper = new UriMapper (); RootFrame.Navigated + = CompleteInitializePhoneApplication; //Handle navigasjonsfeil. RootFrame.NavigationFailed + = RootFrame_NavigationFailed; //Håndtak null forespørsler om å avskjære backstack. RootFrame.Navigated + = CheckForResetNavigation; //Sikre vi ikke initialisere på nytt. phoneApplicationInitialized = true;}
Programlivssyklus

Mobile applikasjoner har en annen levetid enn tradisjonelle desktop-applikasjoner på grunn av deres ulike behov, som strømstyring og ytelsesoptimalisering. Den tradisjonelle multitasking tilnærming som du opplever i Windows ikke passer godt til mobil opplevelse: den nødvendige makt ville tappe batteriet svært raskt. Pluss, hvis du åpner for mange programmer, kan du lider store ytelsesproblemer som vil forringe brukeropplevelsen

Følgende figur forklarer livssyklusen Microsoft har innført for Windows Phone applikasjoner for å tilfredsstille de fastsatte krav.

Når et program er i gang, kan det bli suspendert når som helst. For eksempel kan brukeren trykke på Start-knappen eller trykk på en varsling for å åpne et annet program. I dette tilfellet, er programmet "frosset" (den sovende tilstand); det er bevart i minnet, men alle kjører tråder og operasjoner er stanset. I denne statusen, er programmet du bruker systemminnet, men CPU er gratis. På denne måten kan andre programmer bruker de tilgjengelige ressursene uten lidelse ytelsesproblemer.

Når brukeren bestemmer seg for å gå tilbake til programmet (ved å bruke Tilbake-knappen eller oppgave switcher), er dens eksempel restaurert fra minnet og tidligere tråder og operasjoner er startet på nytt.

Hvis brukerne spille med sin enhet i lang tid, for mange programmer kan bli åpnet, og det vil ikke være nok minne til å holde andre programmer suspendert. I dette tilfellet, kan operativsystemet begynner å "drepe" lengre-kjøring av programmer for å frigjøre minne for de nylig åpnede applikasjoner-eldre apps er flyttet inn i en tombstoned tilstand. Å gi brukerne den samme glatt opplevelse som når apps er bare suspendert, utviklere har muligheten til å spare staten av programmet når det er tombstoned og gjenopprette det senere. Når brukerne åpner en tombstoned app, vil de finne programmet i nøyaktig tidligere tilstand, som om det aldri er blitt stengt.

tombstoning erfaring var den eneste som er tilgjengelig i Windows Phone 7, men det ofte ført til en dårlig brukeropplevelse. Fordi app ble drept, programmet alltid nødvendig å starte fra scratch, forårsaker lengre lastetider. I Windows Phone 7.5, Microsoft introduserte Fast Søknad Bytte konsept som har blitt oversatt til dagens livssyklus, hvor apps blir satt i en sovende tilstand og blir drept bare hvis det er nødvendig.

Basert på denne informasjonen, kan vi forstå at programmer ikke er i stand til å kjøre i bakgrunnen-når et program er suspendert, er alle sine kjører operasjoner kansellert. Senere i denne serien, vil vi se på tilgjengelige teknikker for å utføre enkelte operasjoner selv når programmet ikke er i gang.

Som en utvikler, du blir ikke varslet av operativsystemet når et program tombstoned. Dette er grunnen, i skjemaet vist ovenfor, kan du se at de sparer staten operasjonen er gjort hver gang programmet er suspendert. Du vil alltid måtte forholde seg til det, siden du ikke vil vite på forhånd om din app vil bli tombstoned.

I stedet gjenopprettingen er gjort bare hvis programmet har blitt tombstoned. Når programmet er i en sovende tilstand, er hele prosessen lagret i minnet, så det er ingen tap av data når programmet er gjenopprettet.

Siden tombstoning ikke er deterministisk, og tilbyr Visual Studio en måte å teste den. Som standard blir programmer flyttet til sovende tilstand når suspendert. Du kan endre dette ved å høyreklikke på prosjektet og velger Egenskaper. I Debug seksjonen finner du Tombstone ved deaktivering mens debugging alternativet. Når det er valgt, vil søknader alltid tombstoned når de er suspendert, slik at du kan teste at alt fungerer fint og ingen data går tapt i dette scenariet.

Kontrollere Life Cycle

Du kan kontrollere søknaden livsløps takket være PhoneApplicationService klasse, som er erklært i App.xaml filen som en levetid objekt
. < Application.ApplicationLifetimeObjects > < shell: PhoneApplicationService Lansering = "Application_Launching" Closing = "Application_Closing" Aktivert = "Application_Activated" Deaktivert = "Application_Deactivated" /> < /Application.ApplicationLifetimeObjects>

Som du kan se, er PhoneApplicationService klassen registrert for å administrere fire forskjellige hendelser som er tilgjengelig i App.xaml.cs filen:

Application_Launching startes når programmet starter for første gang

Application_Closing startes når programmet er helt. lukket. Det skjer bare når brukeren trykker på tilbakeknappen i programmets hovedsiden.