Share
Denne opplæringen er den første i en tredelers serie om å jobbe med push-varslingsfunksjonene i iOS 3.0 +. Den vil dekke alt du trenger for å få push-varslinger som fungerer i appen din: registrerer deg for varsler, konfigurerer appen din i IOS-leveringsportalen, sender varsler til Apples Push Notification Service (APNS) og håndterer dem i appen din.
I denne opplæringen vil vi opprette en demo-app kalt Poke. Det vil tillate deg å "poke" brukere via push varslingsvarsler. Selv om det uten tvil ikke er en god bruk av tjenesten, vil denne opplæringen lære deg grunnleggende om hva du trenger å vite for å komme i gang.
Mange stasjonære applikasjoner bruker bakgrunnsprosesser for å kontinuerlig gi brukerne oppdatert informasjon. Disse bakgrunnsapplikasjonene implementerer vanligvis en trekkdesign - de poller aktivt en server for endringer i deres data. Det er ikke uvanlig at flere av disse programmene kjører på datamaskinen din, kobler seg til en rekke tredjeparts servere.
Selv om dette ikke kan være et problem på en stasjonær maskin med mye ledig minne og prosessering gjennomstrømning og en uendelig strømforsyning, blir denne metoden raskt et problem på en mobil enhet med en mye mer begrenset mengde av alle tre.
Med push-varsler, introdusert i iOS 3.0, har Apple jobbet rundt disse begrensningene med en push-basert design. I stedet for å tvinge appen din til å forbli åpen og stadig spørre etter oppdateringer som i pull-modellen, lytter iOS i stedet i stedet for oppdateringer og gir beskjed om appen din når de ankommer. Resultatet er redusert prosessor-, minne- og batteriforbruk. I tillegg, i stedet for hver app som kobler til sin egen server, opprettholdes en enkelt vedvarende forbindelse mellom iOS-enheten og APNS-en.
Som angitt i diagrammet ovenfor, kobler du til tjeneren med push-varsler til APNS i stedet for sluttbrukerens enhet. Når data som en bestemt bruker er interessert i, sender serveren din en melding til APNS som vil varsle brukeren. Brukeren kan da bestemme hva han skal gjøre med den informasjonen (dvs. handle på det nå eller vent til senere).
Merk: Appen din må kanskje faktisk laste ned noen eller alle de endrede dataene fra serveren din, men forskjellen er at brukerens enhet ikke har bortkastet prosesseringssykluser, batterilevetid og nettverksbåndbredde, og spør serveren hvert 15. minutt om det er noe nytt. Vi kommer inn på flere detaljer om dette i et senere segment.
Push meldinger arbeid over alle nettverkstilkoblinger, og det er ingen ekstra kostnad (oppkrævet av Apple) for deg som utvikler å legge til denne flotte funksjonen i appene dine.
I de nylig utgitte retningslinjene for App Store har Apple lagt ut en rekke regler om tjenesten. De fleste er sunn fornuft, men du vil kanskje se på dem hvis du ikke allerede har det.
I et nøtteskall er dette den grunnleggende app-arbeidsflyten for push-varsler:
Vi vil dekke hvert element på listen mens vi går gjennom denne serien.
Det er tre grunnleggende krav til Apple Push Notification Service:
Som nevnt tidligere belaster Apple ikke utviklere for å bruke denne tjenesten. Tjenesten gir imidlertid ingen form for frontend fra hvilken du kan sende varsler - du må ha din egen server som kobles til Apples servere og sender pusher, og det kan være hosting og andre avgifter knyttet til prosessen.
En rekke tredjepartstjenester har skjæret opp for å løse dette problemet. Disse tjenestene fungerer som mellommann mellom deg og APNS - de håndterer konfigurering av SSL-tilkoblingen til APNS og viser vanligvis en API som du kan bruke for å enkelt sende push. Noen har selv en webfrontendat som du kan bruke til å sende meldinger raskt uten å måtte skrive en kode. I denne serien bruker vi Urban Airship, hovedsakelig på grunn av deres brukervennlige og gode priser.
Sertifikatet identifiserer appen din til tjenesten, og brukes til å etablere den sikre forbindelsen mellom serveren din og APNS. Disse sertifikatene genereres (gratis) i IOS Provisioning Portal, og instruksjoner om hvordan du gjør det er gitt nedenfor i trinn 5.
Dette er også dekket i detalj i trinn 5 nedenfor. La oss grave inn.
Åpne Xcode og opprett et nytt iPhone-prosjekt. For denne opplæringen bruker vi den enkle "Vis-baserte applikasjon" -malen for iPhone og vil nevne prosjektet "Poke".
Siden denne delen av opplæringen vil fokusere hovedsakelig på meldingene du får, vil vi ikke bruke noen tid på å konfigurere visningen vår for å vise noen form for nyttig informasjon enda. Vi henter det i tredje tredelingen. I stedet la vi hoppe rett inn i å registrere appen vår med Apple Push Notification Service.
For at appen din skal motta push-varsler, må den først fortelle Apple Push Notification Service hvilke typer meldinger den ønsker å motta. Appen din kan støtte enhver kombinasjon av følgende tre typer (oppført i rekkefølge minst til mest påtrengende):
Fordi varsler tvinge brukeren til å stoppe hva han gjør for å samhandle med dem, anbefaler Apple sterkt at de brukes sparsomt. Ikke misbruk brukerne dine med varsler (eller noen form for push-melding, for det saks skyld) - de vil enten deaktivere push notifications til appen din eller bare slette appen din helt og holdent.
For denne delen av opplæringen vil vi fokusere på varsler. I siste avdrag vil vi komme tilbake og eksperimentere med de to andre.
La oss gå videre og informere iOS om at vår app vil motta varslingsvarsler.
Åpne opp PokeAppDelegate.m (eller hva appdelegenten din heter), og oppdatere programmet: didFinishLaunchingWithOptions: tilbakeringing for å se slik ut:
- (BOOL) søknad: (UIApplication *) søknad didFinishLaunchingWithOptions: (NSDictionary *) launchOptions // Register for alert notifications [søknadsregisterForRemoteNotificationTypes: UIRemoteNotificationTypeAlert]; // Legg til visningskontrollørens visning til vinduet og skjermen. [window addSubview: viewController.view]; [window makeKeyAndVisible]; returnere JA;
Vær oppmerksom på at vi bare sender UIRemoteNotificationTypeAlert, fordi alt vi ønsker å motta akkurat nå, er varsler. Hvis du vil motta andre varsler, fortsett og legg til dem med bitvis eller:
[...] Typer: UIRemoteNotificationTypeAlert | UIRemoteNotificationTypeBadge];
Med disse endringene til vår appdelegate begynner operativsystemet å registrere seg hos Apple Push Notification Service. Hvis det lykkes, vil det sende et søknad: didRegisterForRemoteNotificationsWithDeviceToken: melding til app-delegaten din med enhetstokenet; Hvis det mislykkes, vil det sende et søknad: didFailToRegisterForRemoteNotificationsWithError: melding. Ideelt sett bør du implementere begge deler.
Legg til følgende to metoder for appens delegat for å håndtere de to mulige resultatene for registrering:
- (ugyldig) søknad: (UIApplication *) søknad didRegisterForRemoteNotificationsWithDeviceToken: (NSData *) deviceToken // TODO: Pass token til serveren vår NSLog (@ "Vi har registrert deg for push notifications"); - (ugyldig) søknad: (UIApplication *) søknad didFailToRegisterForRemoteNotificationsWithError: (NSError *) feil // Informer brukeren om at registrering mislyktes NSString * failureMessage = @ "Det oppstod en feil under forsøk på \ registrere for push notifications."; UIAlertView * failureAlert = [[UIAlertView allok] initWithTitle: @ "Feil" melding: failureMessage delegate: null annullerButtonTitle: @ "OK" otherButtonTitles: null]; [failureAlert show]; [failureAlert release];
Vi kommer tilbake til suksess tilbakeringingen i et senere segment - for øyeblikket logger det bare en rask melding. Vår feiloppringing informerer brukeren om feilen. Merk at registreringen vil alltid mislykkes på iPhone Simulator, da det ikke støtter push notifications. For å teste koden riktig må du bruke en faktisk enhet.
Nå som vi har en grunnleggende app opprettet på slutten, la vi gå over til Apples side av ting og få alt satt opp i IOS Provisioning Portal.
Hvis du allerede er et betalende medlem av iOS Developer Program, logger du på iOS Dev Center og klikker koblingen til høyre for å gå til IOS Provisioning Portal. Hvis du ikke er medlem, kan du registrere deg for $ 99 her.
Det første du må gjøre, er å sørge for at du allerede har konfigurert kontoen din med de nødvendige utvikler sertifikatene, og har lagt til enhetene dine. Instruksjoner for å gjøre dette er utenfor omfanget av denne opplæringen, men Apple gir en oppsettassistent samt videoer og andre ressurser for å gå gjennom prosessen. Ta en titt på "Hjem" delen av portalen for mer info.
Det neste trinnet er å opprette en ny app-ID. For å kunne knytte ordene riktig til tjenesten med et bestemt program, gjør Apple Push Notification Service ikke støtte apper med en "wildcard" bundleidentifikator (dvs. en identifikator med en etterfølgende stjerne, for eksempel com.acme. *). Årsaken er at push-tjenesten må kunne identifisere den spesifikke appen som pushen tilhører, men wildcard-identifikatorer tillater deg å bygge flere apper med samme provisjonsprofil. Så hvis du allerede har en jokertegnidentifikator satt opp for utvikling, må du opprette en ny for denne appen for å aktivere push notification support. Hvis app-ID-en din ikke bruker en jokertegn-ID, kan du hoppe over dette trinnet.
Klikk på knappen "Ny app ID" øverst til høyre. Fyll ut appens informasjon og klikk på "Send" -knappen.
Finn din nyopprettede (eller allerede eksisterende) App ID i listen og klikk på "Konfigurer" -linken til høyre. På siden som kommer opp, sjekk "Aktiver for Apple Push Notification service."
Hvis "Aktiver for Apple Push Notification service" ikke vises, er App-ID-en din trolig ikke konfigurert riktig. Gå tilbake til forrige trinn, og kontroller at du ikke har oppgitt en jokertegn-ID.
Du vil legge merke til at det er to sertifikater oppført - en for utvikling og den andre for produksjon. APNS har testservere og liveproduksjonsservere. Hver bruker og krever et annet SSL-sertifikat fra klienten. Testservere kan brukes til å sende pushes til apper som er bygget med utviklingsprovisjonsprofiler; Produktionsserverne kan brukes til å sende push til apper som er bygget med distribusjonsprovisjonsprofiler (Ad Hoc, In House eller App Store bygger).
For nå trenger vi ikke å bekymre oss for mye om forskjellen, men dette vil komme til spill i neste avdrag når vi begynner å sette opp vår konto hos Urban Airship.
Som vi for tiden skal jobbe med en utviklingsbygg av vår app, klikker du på "Konfigurer" -knappen for Development Push SSL-sertifikatet. Følg instruksjonene i boksen som ser ut til å opprette en underskriftsforespørsel om sertifikat, og klikk deretter på Fortsett.
Velg din nylig genererte CSR ved å klikke "Velg fil", og klikk deretter "Generer" for å generere SSL-sertifikatet.
Du bør se en fremdriftsmåler og deretter følgende bekreftelse:
Klikk på "Fortsett", og du vil bli tatt til nedlasting og installering. Vi kommer inn på hva vi skal gjøre med dette sertifikatet i den andre delen av denne opplæringen, men nå går du videre og klikker "Last ned" for å laste ned det nye APNS-klientens SSL-sertifikat.
Deretter må vi opprette en provisjonsprofil for vår nye (eller eksisterende, ikke-jokertegn) App ID.
Merk: Hvis du allerede har opprettet en provisjonsprofil for den eksisterende app-IDen din, følger du med Apples lokale og pressemeldingsveiledning i forkant For å aktivere pushvarsler for den IDen må du endre profilen på en eller annen måte (dvs. endre navnet) slik at portalen vil regenerere den med de nødvendige pushrettighetene.
Du kan bekrefte at en profil har de riktige pushrettighetene ved å åpne den i en tekstredigerer. Det bør ha en aps-miljønøkkel:
Tilbake i IOS Provisioning Portal, velg "Levering" fra hovedmenyen til venstre. Klikk kategorien "Utvikling" og velg "Ny profil" -knappen. Skriv inn et beskrivende navn i feltet Profilnavn og velg sertifikatene for utviklerne som kan bruke denne profilen til å bygge apper. Hvis du registrerte deg som en person, vil bare ett sertifikat bli oppført (din); Hvis du har registrert deg som et selskap, kan det være flere enn en liste.
Velg App-IDen du opprettet i det tidligere trinnet (eller din eksisterende) fra App ID-listen, og velg de enhetene du vil teste appen din på fra listen nederst. Deretter klikker du på "Send" for å generere den nye provisjonsprofilen.
Etter noen minutter vil din profil bli utstedt, og en "Last ned" -knapp vil vises i kolonnen Handlinger til høyre (Du må kanskje oppdatere nettleseren din). Når det er gjort, klikker du på det for å laste ned den nye utviklingsprofilen din.
For å installere profilen din, dra den nylig lastede .mobilprovisjonsfilen til Xcode eller iTunes i Dock.
Gå tilbake til prosjektet ditt i Xcode.
Velg "Rediger aktivt mål" Poke "" fra Prosjekt-menyen. Naviger til fanen Egenskaper og skriv inn pakkeidentifikatoren du har konfigurert i IOS-leveringsportalen tidligere (i vårt tilfelle com.tutsplus.mobile.pushdemo).
Deretter bytt til fliken Bygg. Kontroller at konfigurasjonen som er valgt øverst, er Feilsøking. Finn kodesigneringsdelen i tabellen. Det andre elementet i listen skal være Kodesigneringsidentitet, og det bør ha ett barnobjekt, Enhver iOS-enhet. Denne innstillingen forteller Xcode hvilken provisjonsprofil som skal brukes til å signere appen din når du bygger for en iOS-enhet. Verdien for en hvilken som helst iOS-enhet bør være "iPhone-utvikler (for øyeblikket samsvarer med" iPhone-utvikler: [Ditt navn] "[...])."
Dette for øyeblikket valgte alternativet er den automatiske profilvelgeren. Det ser på appens bunt-ID (som vi angir i det siste trinnet) og finner provisjonsprofilen med en matchende ID (eller en jokertegn som samsvarer med). Mens du sikkert kan komme unna med å forlate dette alternativet som-er, prøver jeg vanligvis å minimere de potensielle kildene til kodesigneringsfeil ved å velge profilen jeg vil bruke manuelt.
Og det er det! Du har opprettet et nytt iPhone-prosjekt og konfigurert det for push-varsler! I neste avdrag begynner vi å snakke om serverens side av ting og hvordan du faktisk sender et trykk til den nylig opprettede appen din.
Accentsconagua