iPhone SDK In-App Purchases

Denna iPhone SDK-handledning är den första i en multipart-serie om att sälja produkter och tjänster "in-app" med Store Kit-ramen. Förvänta dig att lära dig fördelarna och begränsningarna för att använda funktionen In App Purchase, de steg som krävs för att registrera betald in-app-innehåll med Apple Inc., hur du ställer in en enkel butiksfront och skillnaden mellan den inbyggda produktmodellen och serverns produktmodell för distribution av innehåll och orderuppföljning.

1. Förkvalificera ditt innehåll

En av de mest kraftfulla funktionerna som släpptes med iPhone SDK 3 är möjligheten att bearbeta "in app" -köp. Eftersom App Store hanterar betalningsbehörighet och bearbetning på dina vägnar gör den här funktionen betydligt enklare försäljning av virtuella varor eller tjänster, eftersom utvecklare kan fokusera på att skapa och sälja bra innehåll istället för mer traditionella e-handelsuppgifter som kryptering och lagring av kreditkortsnummer eller hantera kreditkortsgrupper. Användning av inköpsfunktionen i appen kommer också att effektivisera checkoutprocessen för användare eftersom de helt enkelt behöver ange sitt Apple-användarnamn och lösenord för att godkänna transaktionen med sitt iTunes-konto.

Naturligtvis kommer dessa fördelar med en prissättning: Apple kommer behålla 30% av försäljningen, som de gör på alla direkta App Store-inköp. Om du väljer att använda App Store som din betalningsportway måste du också följa följande affärsregler som fastställts av Apple:

  • Inga fysiska eller verkliga tjänster tillåts.
    Tyvärr, men matvaror, t-shirts och bilvaskar kan för närvarande inte säljas som inköp i app.
  • Virtuell valuta är inte tillåten.
    Apple tillåter inte för närvarande att skapa en virtuell ekonomi med en direkt mellanliggande valuta.
  • Produkter eller tjänster som köpts inom din ansökan måste nås och användas inom din ansökan.
    På samma sätt som begränsningen av att sälja verkliga varor hindrar detta utvecklarna från att sälja saker som kuponger eller erbjudanden som kan lösas in utanför appen.
  • Inget förtal, hattal, pornografi eller spel.
  • Apple har publicerat följande lista över godkända kategorier:
  • Innehåll
    Inkluderar digitala böcker, tidskrifter, foton, konstverk, spelnivåer, speltecken och annat digitalt innehåll som kan levereras inom din ansökan.
  • Funktionalitet
    Produkter låser upp eller utökar funktioner som du redan har levererat i din ansökan. Till exempel kan du skicka ett spel med flera mindre spel som kan köpas av användaren.
  • tjänster
    Tillåt din applikation att debitera användare för engångstjänster, till exempel rösttranskription. Varje gång tjänsten används är ett separat köp.
  • Prenumerationer
    Ge tillgång till innehåll eller tjänster på ett längre sätt. Till exempel kan din ansökan erbjuda månad tillgång till finansiell information eller till en onlinespelportal. Du bör definiera en rimlig förnyelsesfrekvens för att undvika störningar för användare med oväntade påminnelser. Var medveten om att du är ansvarig för både spårning av abonnemang och förnyelse av fakturering. App Store övervakar inte abonnemangsperioden och erbjuder inte en automatisk faktureringsmekanism.

2. Skapa ett nytt Xcode-projekt och Importera Store Kit Framework

Store Kit Framework ger den kraft och funktionalitet som du ska använda för att utveckla dina inköp i app. Även om ramverket själv inte faktiskt tillåter din användares betalningar, fungerar det som en bro mellan din ansökan och Apple, så att du enkelt kan skicka och ta emot meddelanden från iTunes App Store.

Ta en titt på följande illustration från Apple Inc. för att bättre förstå detta koncept:

Öppna Xcode och skapa ett nytt iPhone-projekt, välj "Visa baserat program" som standardprogramtyp. Namn ansökan "InAppDemo" eller sätt in en mer kreativ titel du väljer.

Högerklicka på mappen "Ramar" i rutan Grupper och filer och välj Lägg till -> befintliga ramar. Hitta StoreKit.framework och klicka på "Add."

För att kunna använda ramverket i vårt projekt måste vi lägga till det i vårt projekt siktkontrollklass. Expand "Classes" -mappen och klicka på InAppDemoViewController.h.

Bara under kommandot "import UIKit" lägger du till den här raden:

 #importera  

Din ansökan bör nu kunna utnyttja Store Kit Framework-funktionaliteten.

3. Registrera Premium-innehåll med Apple Inc.

Varje virtuell produkt eller tjänst som du vill sälja i app måste registreras hos Apple och tilldelas en unik produktidentifierare. Överraskande genereras dessa identifierare i iTunesConnect, inte i utvecklarprogramportalen.

För nya applikationer presenterar detta det klassiska problemet "kyckling eller ägg". För att kunna bygga ditt köpprojekt i app måste du generera produktidentifierare, men eftersom produktidentifierare endast kan skapas via iTunesConnect måste din ansökan redan ha skickats in för offentliggörande.

Lösningen på detta dilemma är att gå igenom processen för att skicka in din ansökan för granskning av Apple, men välj rutan "Ladda upp ansökan binär senare" när du kommer till fliken "Ladda upp". Detta kommer att placera din ansökan i tillståndet "Väntar på uppladdning", vilket är vad du vill för att undvika en formell granskning av din ansökan medan du fortfarande integrerar och konfigurerar dina inköp i appen.

Logga in på ditt iPhone-utvecklarkonto och navigera till iPhone Provisioning Portal för att påbörja processen att skicka in en testapplikation. Om du inte redan är medlem i iPhone Developer Program, måste du registrera dig här.

Efter att du loggat in på provisionportalen väljer du fliken "App IDs". Klicka på "Nytt app ID".

Du måste ange ett vanligt namn och en unik buntidentifierare. Det vanliga namnet kommer att användas för att identifiera detta App-ID inom provisionportalen och Bundle Identifier är en unik identifierare för din aktuella applikation binära. När du utvecklar en applikation som använder inköp i appen måste du använda en fullständig Bundle Identifier. Inga "vilda kort" ID är tillåtna.

Klicka på Skicka. Du kommer att tas tillbaka till huvudsidan för App ID-id.

Hitta ditt nyskapade App ID i listan och klicka sedan på "Configure" länken till höger om det.

På skärmen "Konfigurera app ID" markerar du kryssrutan bredvid "Aktivera i app-inköp" och klickar på "Klar" -knappen:

Du borde nu ha ett unikt app-ID som du kan använda för att börja utveckla inköpsfunktionen med appen med.

Du kommer nu att skapa en testapplikation, så lämna programportalen och logga in på ditt iTunesConnect-konto på itunesconnect.apple.com.

En gång i ditt konto, välj alternativet "Hantera program" och välj sedan "Lägg till nytt program" längst upp till vänster på panelen.

Gå igenom de skärmbilder som presenteras för att lägga till en ny applikation, och se till att du markerar kryssrutan "Lägg till applikation binär senare" på fliken "Ladda upp". I processen kommer du sannolikt att behöva ladda upp en slumpmässig testbild för 512x512-logotypen och Primärskärmdumpen.

När du har slutfört din inlämning av dummy kommer du tillbaka till iTunesConnect-programhanteringsens målsida. Välj den ansökningsinsändning du just skapat och välj sedan "Hantera i app-inköp."

För att lägga till ditt första objekt, välj "CREATE NEW" från den övre vänstra knappen.

Du kommer nu att bli ombedd att välja den buntidentifierare som dina inköp i appen kommer att associeras med. Välj den unika Bundle Identifier du skapade tidigare i den här handledningen och klicka på "Fortsätt". Om du följer stämningen strängt, är paketidentifieraren att välja "com.mobiletuts.inapppurchasedemo."

Du kommer nu att presenteras med en uppsättning alternativ för prissättning på skärmen "Skapa ny app köp". Som anges i hjälpverktygetipsen är "Referensnamn" för att identifiera ditt inköpsbud i iTunesConnect-sökresultat och "Produkt-ID" kommer att användas för att identifiera din ansökan i iTunesConnect-rapporter.

Apple uppmanar dig att välja mellan "Innehåll", "Funktionalitet", "Tjänster" och "Prenumerationer" när du överväger de möjliga kategorierna för dina erbjudanden i appen, men när det gäller att faktiskt skicka dem till affären tvingas du att identifiera din app med en av tre helt nya typer.

Som beskrivs av Apple Inc. är dessa typer:

  • Förbruknings:
    Produkter måste köpas varje gång användaren behöver den föremålet. Till exempel är tjänster vanligen implementerade som förbrukningsvaror.
  • Icke-förbrukningsartiklar:
    Produkter får endast köpas en gång av användare. När en icke-förbrukningsbar produkt har köpts är den alltid tillgänglig på alla enheter som är associerade med den användarens iTunes-konto. Store Kit-leverantörer stöder för att återställa icke-förbrukningsbara produkter på andra enheter.
  • Prenumerationer:
    Dela attribut av både förbrukningsbara och icke-förbrukningsbara produkter. Som en konsumtionsprodukt kan en prenumeration köpas flera gånger; Det här låter dig implementera din egen förnyelsemekanism i din ansökan. Dock måste prenumerationer ges på alla enheter som är associerade med en användare. I App Purchase förväntar sig abonnemang att levereras via en extern server som du tillhandahåller. Du måste tillhandahålla infrastruktur för att leverera prenumerationer på flera enheter.

Välj den som är tillämplig för din erbjudande typ eller "Förbrukningsbar" om du följer denna handledning strikt. Observera att när denna typ är inställd kan den inte ändras vid en senare tidpunkt, så välj klokt.

Därefter ställer vi anbudspriset, vilket görs genom att välja en prisnivå snarare än att direkt ange ett värde. In app Purchase Price-tiersystemet är detsamma som det direkta köpskattesystemet som presenterades när du ursprungligen laddar upp din ansökan, men om du vill granska dina alternativ igen klickar du på texten "See Pricing Matrix" till höger om rullgardinsmenyn.

Fortsätt och välj "Tier 1" för priset eller vilken nivå som matchar ditt erbjudande. Var noga med att kolla rutan "Cleared for Sale", även om du inte är redo att starta din ansökan. Den här rutan måste kontrolleras för att kunna felsöka och testa din kod.

Fältet "Display Detail" -fältet gör att du enkelt kan styra lokalisering. Välj det eller de språk du vill lista ditt erbjudande i och lägg till ditt anpassade visningsnamn och beskrivning. En meningsfull och specifik beskrivning krävs av Apple för granskningsgodkännande.

För tillfället kan du hoppa över skärmdumpfältet eftersom det bara är en guide för Apple-anställdas granskning av din produkt. Klicka på "Spara ändringar" för att registrera detta erbjudande med Apple. Upprepa denna process för att lägga till ytterligare föremål till salu "i app."

Denna handledning kommer att använda följande generella data för våra erbjudanden, men gärna vara så kreativa som du vill att du ska infoga din egen:

Produkt 1 | Förbrukningsartiklar | com.mobiletuts.inappdemo.1 | Nivå 1
Produkt 2 | Förbrukningsartiklar | com.mobiletuts.inappdemo.2 | Nivå 2
Produkt 3 | Förbrukningsartiklar | com.mobiletuts.inappdemo.3 | Nivå 3

4. Bygg din butiksfront

När du har registrerat dina premiumprodukter med iTunesConnect, är du redo att börja integrera dessa erbjudanden i din app. För syftet med denna handledning använder vi en enkel UITableView för att visa vår produktlista.

Gå till huvudfilen för din huvudprogram för applikationsvisning, i det här fallet InAppDemoViewController.h, och ändra koden så att den ser ut så här:

 #importera  #importera  @interface InAppDemoViewController: UIViewController  NSMutableArray * productIdentifierList; NSMutableArray * productDetailsList; IBOutlet UITableView * productDisplayTableView;  @property (nonatomic, behåll) NSMutableArray * productIdentifierList; @property (nonatomic, behåll) NSMutableArray * productDetailsList; @property (nonatomic, behåll) UITableView * productDisplayTableView; @slutet 

Array productIdentifierList lagrar de produktidentifierare som vi skapade i steg 3 som strängar, medan productDetailsList lagrar lokaliserad produktinformation som tillhandahålls av App Store och faktiskt visas för användaren.

Gå nu till klassimplementeringsfilen, InAppDemoViewController.m och syntetisera de variabler du bara deklarerade i din headerfil:

 @implementation InAppDemoViewController @synthesize productIdentifierLista, productDetailsList, productDisplayTableView; 

Obs! Funktionen viewDidLoad, och initiera din datakälla:

 - (void) viewDidLoad productDetailsList = [[NSMutableArray alloc] init]; productIdentifierList = [[NSMutableArray alloc] init]; för (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 applikation i verkligheten vill vi aldrig sätta denna inkodningskod i ViewDidLoad-metoden eftersom den kommer att köras i huvudtråden och låsa applikationsgränssnittet kort medan data hämtas. Vi använder viewDidLoad här endast för demonstration.

Från linje 6 skapar vi en för loop för att iterera över det antal objekt vi vill visa. Eftersom vi använder ett gemensamt namngivningsschema för våra produktidentifierare kan vi skapa flera objekt på flugan utan att behöva skriva ut varje identifierare för hand. Observera att det här mönstret kan förbättras ytterligare med viss Internetprogrammering: din produktidentifieringslista skulle helst laddas från en extern server för att du ska kunna dynamiskt lägga till eller ta bort produkter utan att trycka ett nytt binärt genom App Store varje gång.

Från linjen 10 introduceras vi till vårt första Store Kit Framework-objekt, SKProductsRequest. Det här objektet används för att skicka en lista över produktidentifierare till App Store för att få tillbaka en lista över lokaliserad produktinformation och exakt produktprisinformation. Denna dynamiska lokalisering och produktsamlingsteknik möjliggör mycket större flexibilitet än att koda dessa attribut i hand.

På rad 12 ställer vi in ​​begäran om delegat som Store Kit Framework kommer att ringa efter att ha mottagit ett resultat. Kopiera och klistra in följande kod för att överensstämma med detta delegatprotokoll:

 -(void) productsRequest: (SKProductsRequest *) begäran didReceiveResponse: (SKProductsResponse *) svar [productDetailsList addObjectsFromArray: response.products]; [productDisplayTableView reloadData];  - (void) requestDidFinish: (SKRequest *) begäran [request release];  - (void) request: (SKRequest *) begäran didFailWithError: (NSError *) fel NSLog (@ "Misslyckades att ansluta till fel:% @", [error localizedDescription]);  

ProductRequest-metoden kallas efter att listan över produkter har hämtats från App Store, och vi tilldelar den listan över produktobjekt från App Store till vår productDetailsList array för senare användning. De andra två protokollmetoderna fungerar som förväntat.

Nu går vi vidare till att konfigurera UITableView som ska användas för att visa vår produktinformation. Börja med att ställa in din nib-fil i Interface Builder. Expanda mappen "Resurser" i panelen Grupper och filer och dubbelklicka på filen InAppViewController.xib för att öppna gränssnittsbyggaren.

Dra i biblioteket Ruta ett UITableView-objekt till fönstret In App Demo View Controller. Högerklicka på UITableView i fönstret och anslut dataSource och delegera till filens ägare. Högerklicka sedan på Filens Ägare och anslut productDisplayTableView med UITableView-objektet. Spara och stäng spetsen.

Gå tillbaka till din implementeringsfil för kontroller, InAppDemoViewController.m.

Klistra in i följande rader för att uppfylla UITableViewDelegate och UITableViewDataSource protokollkraven:

- (NSInteger) tableView: (UITableView *) tableView numberOfRowsInSection: (NSInteger) sektionen return [self.productDetailsList count];  - (UITableViewCell *) tableView: (UITableView *) tableVisa cellForRowAtIndexPath: (NSIndexPath *) indexPath static NSString * GenericTableIdentifier = @ "GenericTableIdentifier"; UITableViewCell * cell = [tableView dequeueReusableCellWithIdentifier: GenericTableIdentifier]; om (cell == nil) cell = [[[UITableViewCell-allokering] initWithFrame: CGRectZero reuseIdentifier: GenericTableIdentifier] autorelease];  NSUInteger row = [indexPath row]; SKProduct * thisProduct = [productDetailsList objectAtIndex: row]; [cell.textLabel setText: [NSString stringWithFormat: @ "% @ -% @", dennaProduct.localizedTitle, thisProduct.price]]; returcell;  

Det mesta av detta är standardkod för att visa text i UITableView-celler. Observera dock att vi skapar en förekomst av SKProduct, thisProduct, för att hämta produktdata för den aktuella raden, och att vi enkelt kan hämta lokaliserad produktinformation från objektets medlemmar. Mer information om alla tillgängliga ledamöter finns i den officiella Apple SKProduct-referensen.

Du bör nu kunna kompilera och köra din ansökan, men det finns en fångst: I App Store kan inköp endast testas på en faktisk enhet, så du måste skapa och installera en provisioningprofil för denna applikation för att testa koda.

När du har installerat din provisioningprofil och konfigurerat Xcode, bygg och kör programmet på din enhet. En grundläggande tabellvy med produkttitlar är för enkel för din verkliga världsapp, men skönheten i In App Purchase-systemet är att butikshöljet är helt upp till dig. I framtida handledning i denna serie skapas ett mer avancerat gränssnitt. Under tiden sträck din kreativitet och använd vilken design du vill visa upp dina produkter!

5. Välj en distributionsstrategi

Innan du börjar godkänna transaktioner och säljer nytt innehåll till dina användare, ta en stund att tänka på hur det nya innehållet ska levereras. Store Kit-ramverket tillåter dig att enkelt godkänna ett köp, men du är ensam när det gäller orderuppfyllelse. Den inbyggda produktmodellen och serverns produktmodell är de två primära designmönster som du kan välja för att se till att dina användare får vad de betalar för.

Inbyggd produktmodell

Med den inbyggda produktmodellen kan allt som en användare får köpa redan ingå i programmet när den laddas ner först. Det här innehållet är låst eller dolt för användning tills efter det att ett köp i app har gjorts, varav erbjudandet blir användbart.

Följande diagram från Apple Inc. illustrerar den inbyggda produktmodellen:

Server Produktmodell

I serverns produktmodell trycks innehållet dynamiskt på användarens enhet vid inköpet från en server under din kontroll. I serverns produktmodell måste du lägga till ytterligare steg för att verifiera att transaktionskvittot som mottagits från klientenheten är giltigt och du kan också behöva konfigurera en mekanism för att identifiera dina användare för att försäkra att prenumerationer och andra icke-förbrukningsbara produkter kan fortfarande tillgänglig från någon iPhone OS-enhet som inköpsanvändaren äger, och inte bara från enheten som de ursprungligen köpte varan på (detta är ett affärskrav från Apple). Du är också ansvarig för att förhandla nätverksanslutningen för att överföra det som kan vara en stor mängd text- eller multimediedata.

En av de främsta fördelarna med serverns produktmodell är att den låter dig sälja en mycket stor mängd innehåll på begäran samtidigt som den ursprungliga nedladdningsstorleken för din ansökan är liten. Det är också mycket snabbare att skapa och leverera nytt premiuminnehåll till din app eftersom du inte behöver trycka en ny applikation binär via iTunes Store för att kunna erbjuda nya objekt till salu.

Följande diagram från Apple Inc. illustrerar serverns produktmodell:

Som du kan se är den inbyggda produktmodellen den enklare av de två designmönstren. Det är lättare att implementera och underhålla, men saknar kraften vid leverans på begäran. Serverproduktmodellen är mycket mer komplex men låter dig skapa nytt innehåll med större flexibilitet och snabbhet, och även för att hålla din applikationsstorlek lutad genom att bara ge stora hämtningar efter behov.

Både den inbyggda produktmodellen och serverns produktmodell kommer att beskrivas i detalj i framtida delar av denna serie.

Nu är det en bra tid att överväga båda dessa distributionsmodeller och bestämma vilken som passar bäst för din ansökan.