Denne iPhone SDK-opplæringen er den første i en flerartsserie om å selge produkter og tjenester "in-app" med Store Kit-rammen. Forvent å lære fordelene og begrensningene for å bruke funksjonen In App Purchase, trinnene som er nødvendige for å registrere innbetalt innhold i app med Apple Inc., hvordan du konfigurerer en enkel butikkfront og forskjellen mellom den innebygde produktmodellen og serverproduktmodellen for distribusjon av innhold og ordreutførelse.
En av de kraftigste funksjonene som er utgitt med iPhone SDK 3, er evnen til å behandle "i app" -kjøp. Fordi App Store håndterer betalingsautorisasjon og behandling på vegne av deg, gjør denne funksjonen vesentlig lettere salg av virtuelle varer eller tjenester, da utviklere kan fokusere på å skape og selge godt innhold i stedet for mer tradisjonelle e-handelsoppgaver som kryptering og lagring av kredittkortnumre eller behandle kredittkortpartier. Ved å bruke kjøpsfunksjonen i appen vil også strømlinjeforme betalingsprosessen for brukere, da de bare trenger å skrive inn sitt Apple-brukernavn og passord for å godkjenne transaksjonen med sin iTunes-konto.
Selvfølgelig kommer disse fordelene med en prislapp: Apple beholder 30% av salget, som de gjør på alle direkte kjøp av App Store. Hvis du velger å bruke App Store som betalingsgateway, vil du også kreve at du overholder følgende forretningsregler fastsatt av Apple:
Store Kit Framework gir strøm og funksjonalitet som du vil bruke til å utvikle kjøpene dine i appen. Selv om rammen selv ikke autoriserer brukerens betalinger, fungerer den som en bro mellom applikasjonen din og Apple, slik at du enkelt kan sende og motta meldinger fra iTunes App Store.
Ta en titt på følgende illustrasjon fra Apple Inc. for bedre å forstå dette konseptet:
Åpne Xcode og opprett et nytt iPhone-prosjekt, velg "View Based Application" som standard programtype. Navngi programmet "InAppDemo" eller sett inn en mer kreativ tittel du velger.
Høyreklikk på "Rammer" -mappen i panelet Grupper og filer, og velg Legg til -> Eksisterende rammer. Finn StoreKit.framework og klikk "Add."
For å bruke rammen i prosjektet, må vi legge til det i prosjektets visningskontrollklasse. Utvid mappen "Klasser" og klikk på InAppDemoViewController.h.
Bare under kommandoen "Import UIKit" legger du til denne linjen:
#importere
Din søknad skal nå kunne utnyttes av Store Kit Framework-funksjonaliteten.
Hvert virtuelt produkt eller tjeneste som du ønsker å selge i app, må være registrert hos Apple og tilordnet en unik produktidentifikator. Overraskende er disse identifikasjonene generert i iTunesConnect, ikke i Developer Program Portal.
For nye applikasjoner presenterer dette det klassiske "kylling-eller-egg" -problemet. For å kunne bygge opp kjøpsprosjektet din, må du generere produktidentifikatorer, men fordi produktidentifikatorer kun kan opprettes via iTunesConnect, må søknaden din allerede ha blitt sendt for publisering..
Løsningen på dette dilemmaet er å gå gjennom prosessen med å sende inn søknaden din til gjennomgang av Apple, men merk av for «Opplast søknad binær senere» når du kommer til «Last opp» -fanen. Dette vil plassere søknaden din i "Venter på opplasting" -tilstanden, som er hva du vil for å unngå en formell gjennomgang av søknaden din mens du fortsatt integrerer og konfigurerer kjøpene dine i appen.
Logg inn på iPhone-utviklerkontoen din og naviger til iPhone Provisioning Portal for å starte prosessen med å sende inn en testapplikasjon. Hvis du ikke allerede er medlem av iPhone Developer Programmet, må du registrere deg her.
Etter å ha logget inn på Provisioning Portal, velg fanen "App IDs". Klikk på "Ny app ID".
Du må skrive inn et felles navn og en unik pakkeidentifikator. Det vanlige navnet vil bli brukt til å identifisere denne App-IDen i Provisioning Portal, og Bundle Identifier er en unik identifikator for din faktiske applikasjon binære. Når du utvikler et program som skal brukes i app-kjøp, må du bruke en full pakkeidentifikator. Ingen "wild card" IDer er tillatt.
Klikk på send inn. Du vil bli tatt tilbake til hovedapp ID-siden.
Finn din nyopprettede App ID på listen, og klikk deretter "Konfigurer" -linken til høyre for den.
På skjermbildet "Konfigurer App ID" merker du av i boksen ved siden av "Aktiver i app-kjøp" og klikker på "Ferdig" -knappen:
Du bør nå ha en unik app-ID som du kan bruke til å begynne å utvikle innkjøpsfunksjonen i appen med.
Du vil nå opprette en testapplikasjonsinnlevering, så la programportalen og logg inn på iTunesConnect-kontoen din på itunesconnect.apple.com.
En gang i kontoen din, velg alternativet Administrer programmer, og velg deretter Legg til nytt program øverst til venstre på panelet.
Gå gjennom skjermbildene som presenteres for å legge til en ny applikasjon, og vær sikker på at du velger alternativet «Legg til søknad binært senere» i «Opplast» -fanen. I prosessen må du sannsynligvis laste opp et tilfeldig testbilde for 512x512-logoen og Primær skjermbilde.
Etter at du har fullført dummyopplegget, blir du tatt tilbake til iTunesConnect-programbehandlingens destinasjonsside. Velg søknadsinnleggelsen du nettopp har opprettet, og velg deretter "Administrer i app-kjøp."
For å legge til det første elementet, velg "CREATE NEW" fra øverste venstre knapp.
Du blir nå bedt om å velge pakkeidentifikatoren som kjøpene dine i appen vil bli knyttet til. Velg den unike Bundle Identifier du opprettet tidligere i denne opplæringen, og klikk "Fortsett". Hvis du følger veiledningen strengt, er pakkeidentifikatoren for å velge "com.mobiletuts.inapppurchasedemo."
Du vil nå bli presentert med et sett med muligheter for prising på skjermbildet "Opprett nytt i app". Som nevnt i hjelpverktøystipsene, er "Referansenavn" for å identifisere kjøpsbudet ditt i iTunesConnect-søkeresultatene, og "Produkt-ID" vil bli brukt til å identifisere programmet i iTunesConnect-rapporter.
Apple oppfordrer deg til å velge mellom "Innhold", "Funksjonalitet", "Tjenester" og "Abonnementer" når du vurderer de mulige kategoriene for tilbudene dine i appen, men når det gjelder å sende dem faktisk til butikken, blir du tvunget å identifisere appen din med en av tre helt nye typer.
Som beskrevet av Apple Inc., er disse typer:
Velg den som gjelder for tilbudstypen din eller "Forbrukbar" hvis du følger denne veiledningen strengt. Merk at når denne typen er angitt, kan den ikke endres på et senere tidspunkt, så velg klokt.
Deretter angir vi tilbudsprisen, som gjøres ved å velge en prisnivå i stedet for å legge inn en verdi direkte. In-App Purchase prismodell-systemet er det samme som det direkte kjøpsplattformssystemet som ble presentert ved opprinnelig opplasting av søknaden din, men hvis du vil vurdere alternativene dine på nytt, klikker du på "Se prissettingsmatrise" -teksten til høyre for rullegardinmenyen.
Gå videre og velg "Tier 1" for prisen eller hvilken tier som passer ditt tilbud. Pass på å sjekke boksen "Cleared for Sale", selv om du ikke er klar til å starte programmet. Denne boksen må kontrolleres for å feilsøke og teste koden din.
Feltsettet "Displaydetaljer" lar deg enkelt kontrollere å tilby lokalisering. Velg språket du vil oppgi tilbudet ditt, og legg til ditt egendefinerte visningsnavn og beskrivelse. En meningsfull og spesifikk beskrivelse kreves av Apple for gjennomgangsgodkjenning.
For nå kan du hoppe over skjermbildet feltet sett som det er rent en veiledning for Apple-ansattens gjennomgang av produktet ditt. Klikk på "Lagre endringer" for å registrere dette tilbudet med Apple. Gjenta denne prosessen for å legge til flere elementer til salgs "i app."
Denne opplæringen vil bruke følgende generiske data for våre tilbud, men vær så snill å være så kreativ som du ønsker å sette inn din egen:
Produkt 1 | Forbruksvarer | com.mobiletuts.inappdemo.1 | Nivå 1
Produkt 2 | Forbruksvarer | com.mobiletuts.inappdemo.2 | Nivå 2
Produkt 3 | Forbruksvarer | com.mobiletuts.inappdemo.3 | Tier 3
Etter at du har registrert dine premium-elementer med iTunesConnect, er du klar til å begynne å integrere disse tilbudene i appen din. I forbindelse med denne opplæringen bruker vi en enkel UITableView til å vise våre produktoppføringer.
Gå til headerfilen for hovedapplikasjonsvisningskontrollen din, i dette tilfellet InAppDemoViewController.h, og endre koden slik at den ser slik ut:
#importere#importere @interface InAppDemoViewController: UIViewController NSMutableArray * productIdentifierList; NSMutableArray * productDetailsList; IBOutlet UITableView * productDisplayTableView; @property (nonatomic, behold) NSMutableArray * productIdentifierList; @property (nonatomic, behold) NSMutableArray * productDetailsList; @property (nonatomic, behold) UITableView * productDisplayTableView; @slutt
Array productIdentifierList lagrer produktidentifikatorene vi opprettet i trinn 3 som strenger, mens productDetailsList lagrer lokalisert produktinformasjon som leveres av App Store og faktisk vises til brukeren.
Gå nå til implementeringsfilen for klassen, InAppDemoViewController.m, og syntetiser de variablene du nettopp erklærte i headerfilen din:
@implementation InAppDemoViewController @synthesize productIdentifierList, productDetailsList, productDisplayTableView;
Uncomment viewDidLoad-funksjonen, og initialiser datakilden din:
- (void) viewDidLoad productDetailsList = [[NSMutableArray alloc] init]; productIdentifierList = [[NSMutableArray alloc] init]; for (kort item_count = 1; item_count <= 3; item_count++) [productIdentifierList addObject:[NSString stringWithFormat:@"com.mobiletuts.inappdemo.%d", item_count]]; SKProductsRequest *request = [[SKProductsRequest alloc] initWithProductIdentifiers:[NSSet setWithArray:productIdentifierList]]; request.delegate = self; [request start]; [super viewDidLoad];
I en applikasjon i virkeligheten vil vi aldri sette denne innkjøpskoden i ViewDidLoad-metoden fordi den vil utføre i hovedtråden og låse programgrensesnittet kort mens du henter dataene. Vi bruker viewDidLoad her bare for demonstrasjonsformål.
Fra linje 6 oppretter vi en for-løkke for å lukte over antall elementer vi vil vise. Fordi vi bruker et felles navngivningsskjema for våre produktidentifikatorer, kan vi opprette flere elementer på fly uten å måtte skrive ut hver identifikator for hånd. Vær oppmerksom på at dette mønsteret kan forbedres ytterligere med noen internettprogrammering: produktidentifikasjonslisten din vil ideelt sett lastes fra en ekstern server for å tillate deg å dynamisk legge til eller fjerne produkter uten å trykke på et nytt binært gjennom App Store hver gang.
Fra linje 10 blir vi introdusert til vårt første Store Kit Framework-objekt, SKProductsRequest. Dette objektet brukes til å sende en liste over produktidentifikatorer til App Store for å motta en liste over lokalisert produktinformasjon og nøyaktig produktprisinformasjon. Denne dynamiske lokaliserings- og produktinnsamlingsteknikken gir deg mye større fleksibilitet enn å kode disse attributene i hånden.
På linje 12 stiller vi forespørselsdelegatet som Store Kit Framework vil ringe etter å ha mottatt et resultat. Kopier og lim inn følgende kode for å overholde denne delegatprotokollen:
-(void) productsRequest: (SKProductsRequest *) forespørsel didReceiveResponse: (SKProductsResponse *) respons [productDetailsList addObjectsFromArray: response.products]; [productDisplayTableView reloadData]; - (void) requestDidFinish: (SKRequest *) forespørsel [request release]; - (ugyldig) forespørsel: (SKRequest *) forespørsel didFailWithError: (NSError *) feil NSLog (@ "Kunne ikke koble til feil:% @", [feil lokalisertDescription]);
ProductRequest-metoden kalles etter at listen over produkter er hentet fra App Store, og vi tilordner den listen over produktobjekter fra App Store til vårt produktDetailsList array for senere bruk. De to andre protokollmetodene fungerer som forventet.
Nå fortsetter vi med å sette opp UITableView som vil bli brukt til å vise vår produktinformasjon. Begynn med å sette opp din nib-fil i Interface Builder. Utvid mappen "Ressurser" i panelet Grupper og filer, og dobbeltklikk filen InAppViewController.xib for å åpne grensesnittbyggeren.
Dra i biblioteket-panelet et UITableView-objekt til vinduet In App Demo View Controller. Høyreklikk UITableView i vinduet og koble dataSource og delegere til filens eier. Høyreklikk deretter Filens eier og koble productDisplayTableView med UITableView-objektet. Lagre og lukk spissen.
Gå tilbake til implementeringsfilen til kontrolleren din, InAppDemoViewController.m.
Lim inn i følgende linjer for å tilfredsstille UITableViewDelegate og UITableViewDataSource protokollkravene:
- (NSInteger) tableView: (UITableView *) tableView numberOfRowsInSection: (NSInteger) seksjon return [self.productDetailsList count]; - (UITableViewCell *) tableView: (UITableView *) tableView cellForRowAtIndexPath: (NSIndexPath *) indexPath statisk NSString * GenericTableIdentifier = @ "GenericTableIdentifier"; UITableViewCell * celle = [tableView dequeueReusableCellWithIdentifier: GenericTableIdentifier]; hvis (celle == nil) celle = [[[UITableViewCell alloc] initWithFrame: CGRectZero reuseIdentifier: GenericTableIdentifier] autorelease]; NSUInteger row = [indexPath row]; SKProdukt * thisProduct = [productDetailsList objectAtIndex: row]; [cell.textLabel setText: [NSString stringWithFormat: @ "% @ -% @", denneProduct.localizedTitle, thisProduct.price]]; returcelle;
Mesteparten av dette er standardkode for visning av tekst i UITableView-celler. Vær imidlertid oppmerksom på at vi lager en forekomst av SKProdukt, thisProduct, for å hente produktdataene for den nåværende raden, og at vi enkelt kan hente lokalisert produktinformasjon fra objektets datamedlemmer. Se den officielle Apple SKProduct-referansen for mer informasjon om alle tilgjengelige datamedlemmer.
Du bør nå kunne kompilere og kjøre søknaden din, men det er en fangst: I App Store-kjøp kan bare testes på en faktisk enhet, så du må opprette og installere en provisjonsprofil for dette programmet for å teste kode.
Når du har installert provisjonsprofilen din og konfigurert Xcode, må du bygge og kjøre programmet på enheten din. En grunnleggende tabellvisning med produkttitler er for forenklet for din virkelige verden-app, men skjønnheten i In App Purchase-systemet er at butikkhuden er helt opp til deg. I fremtidige opplæringsprogrammer i denne serien, vil et mer avansert grensesnitt bli opprettet. I mellomtiden strekke din kreativitet og bruk hva design du vil vise frem dine produkter!
Før du begynner å autorisere transaksjoner og selge nytt innhold til brukerne, ta et øyeblikk å tenke på hvordan det nye innholdet blir levert. Store Kit-rammeverket lar deg enkelt godkjenne et kjøp, men du er alene når det gjelder bestilling. Den innebygde produktmodellen og serverproduktmodellen er de to primære designmønstrene du kan velge mellom for å sikre at brukerne får det de betaler for.
Med den innebygde produktmodellen kan alt en bruker kan kjøpe allerede være inkludert i programmet når den lastes ned. Dette innholdet er låst eller skjult fra bruk til etter at et kjøp i appen er gjort, hvoretter tilbudet blir brukbart.
Følgende diagram fra Apple Inc. illustrerer den innebygde produktmodellen:
I serverproduktmodellen blir innholdet dynamisk presset til brukerens enhet på kjøpstidspunktet fra en server under din kontroll. I serverproduktmodellen må du legge til det ekstra trinnet for å bekrefte at transaksjonskvitteringen mottatt fra klientenheten er gyldig, og du må kanskje også sette opp en mekanisme for å identifisere brukerne for å sikre at abonnementer og andre ikke-forbruksvarer kan fortsatt tilgjengelig fra hvilken som helst iPhone OS-enhet som kjøperen eier, og ikke bare fra enheten de opprinnelig kjøpte varen på (dette er et forretningsbehov fra Apple). Du er også ansvarlig for å forhandle nettverksforbindelsen for å overføre det som kan være en betydelig mengde tekst- eller multimediedata.
En av de viktigste fordelene med serverproduktmodellen er at den lar deg selge en meget stor mengde innhold på forespørsel samtidig som den første nedlastingsstørrelsen på søknaden din er liten. Det er også mye raskere å lage og levere nytt premiuminnhold til appen din fordi du ikke trenger å trykke et nytt program binært gjennom iTunes Store for å kunne tilby nye varer til salgs.
Følgende diagram fra Apple Inc. illustrerer serverproduktmodellen:
Som du kan se, er den innebygde produktmodellen den enklere av de to designmønstrene. Det er enklere å implementere og vedlikeholde, men mangler kraften i levering på forespørsel. Serverproduktmodellen er langt mer kompleks, men lar deg lage nytt innhold med større fleksibilitet og fart, og også å holde applikasjonsstørrelsen stønn ved å kun gi store nedlastinger etter behov.
Både den innebygde produktmodellen og serverproduktmodellen vil bli dekket i detalj i fremtidige deler av denne serien.
Nå er det en god tid å vurdere begge disse distribusjonsmodellene og avgjøre hvilken som passer best for din søknad.