IAP苹果官⽅⽂档翻译超级详解
原⽂地址：
⼀、In App Purchase概览
Store Kit代表App和App Store之间进⾏通信。程序将从App Store接收那些你想要提供的产品的信息，并将它们显⽰出来供⽤户购买。
当⽤户需要购买某件产品时，程序调⽤StoreKit来收集购买信息。
Store Kit的API只是为程序添加In App Purchase功能的⼀⼩部分。你需要决定如何去记录那些你想要提交的产品，如何在程序中将商店功能展现给⽤户，
还要考虑如何将⽤户购买的产品提交。本章的剩余部分会展⽰整个流程。
Products
产品可以是任意⼀项你想要出售的特性。产品在iTunes Connect中被组织，这和你添加⼀个新的App是⼀样的。⽀持的产品种类共有四种：
1. 内容型。包括电⼦书，电⼦杂志，照⽚，插图，游戏关卡，游戏⾓⾊，和其他的数字内容。
2. 扩展功能。这些功能已经包含在App内部。在未购买之前被锁定。例如，你可以在⼀个游戏程序中包含若⼲个⼩游戏，⽤户可以分别来购买这些游戏。
3. 服务。允许程序对单次服务收费。⽐如录⾳服务。
4. 订阅。⽀持对内容或服务的扩展访问。例如，你的程序可以每周提供财务信息或游戏门户⽹站的信息。应该设定⼀个合理的更新周期，以避免过于频繁的
提⽰困扰⽤户。要记住：你将负责跟踪订阅的过期信息，并且管理续费。App Store不会替你监视订阅的周期，也不提供⾃动收费的机制。In App Purchase为创建产品提供了⼀种通⽤的机制，如何操作将由你负责。当你设计程序的时候，有以下⼏点需要注意：
1. 你必须提供电⼦类产品和服务。不要使⽤In App Purchase 去出售实物和实际服务。
2. 不能提供代表中介货币的物品，因为让⽤户知晓他们购买的商品和服务是很重要的。
通过App Store注册产品
每个你想要出售的产品都必须先通过iTunes Connect在App Store注册。你需提供产品的名称，描述，价格和其他在程序中⽤到的元数据。
需为产品指定唯⼀的标识符。当你的程序利⽤Store Kit和App Store通信时，会使⽤产品标识来取回产品的信息。如果⽤户购买某个商品时，程序可以⽤该标识来将产品标注为“已购买”。
App Store将前⾯提到过的产品种类简化为以下三种：
1. 消耗性商品。该类商品在需要时被单次购买。⽐如，单次服务。
2. ⾮消耗性商品。该类商品只需被某个⽤户购买⼀次，⼀旦被购买，和该⽤户iTunes 账户关联的设备都可以使⽤此商品。Store Kit为在多个设备上重新存储⾮消耗性商品提供了内置的⽀持。
3. 订阅类。订阅类商品拥有以上两种类型的特性。和消耗性商品⼀样，订阅类商品可以被多次购买；你可以在程序内部加⼊⾃⼰的订阅计划更新机制。另外，订阅类商品必须提供给和某⼀⽤户关联的所有设备。In App Purchase期望订阅类商品可以通过外部服务器交付。你必须为多个设备的订阅服务提供相应的⽀持。
关于注册产品的详细信息，请参考iTunes Connect Developer Guide⽂档。
我的合租美女老师交付⽅式
交付机制在程序In App Purchase的设计和实现种有很重要的意义。有两种基本的模型可以⽤来交付产品：内置类型（Built-in model）和服务器类型（Server model）。不管使⽤那种模型，你都需要维护产品列表，并保证当⽤户购买后，成功的交付产品。
1. 内置产品类型
使⽤这种模型。需要交付的产品已经在程序内部。这种⽅式通常⽤在⼀些被锁定的功能上。也可以⽤来交付在程序束（App Bundle）中的内容。该⽅式的⼀个重要的优点是你可以及时的给客户交付产品，⼤多数的内置产品应为⾮消耗性商品。
注意：In App Purchase不提供购买补丁的功能。如果需要更改app的bundle，你必须向App Store提交新的app版本。显微镜的使用方法
为了标识产品，程序要在bundle中存储产品的标识符。内置模式下，Apple建议使⽤plist来纪录产品的标识符。内容类应⽤可以使⽤折衷⽅式很⽅便的添加新的内容，⽽不改动程序本⾝。（原话为： Content-driven applications can use this to add new content without modifying the source for your application，不是很懂，感觉应该是说类似是⽤plist来管理产品列表，因此就不需要在添加新产品的时候改动程序了。再议。。。）
当成功购买产品后，程序应将锁定的功能解锁，提供给⽤户。解锁的最简单⽅式是修改程序偏好设置（Application Preferences）。当⽤户备份⼿机数据的时候，程序偏好设置也会随之备份。程序可能需要建议⽤户在购买产品后备份⼿机以免丢失购买的内容。
图1-2显⽰了交付内置型产品的流程。
1. 程序通过bundle存储的plist⽂件得到产品标识符的列表。
2. 程序向App Store发送请求，得到产品的信息。
3. App Store返回产品信息。
4. 程序把返回的产品信息显⽰给⽤户（App的store界⾯）
5. ⽤户选择某个产品
6. 程序向App Store发送⽀付请求
7. App Store处理⽀付请求并返回交易完成信息。
8. App获取信息并提供内容给⽤户。
使⽤这种⽅式，要提供另外的服务器将产品发送给程序。服务器交付适⽤于订阅、内容类商品和服务，因为商品可以作为数据发送，⽽不需改动程序束。例如，⼀个游戏提供的新的内容（关卡等）。 Store Kit不会对服务器端的设计和交互做出定义，这⽅⾯⼯作需要你来完成。⽽且，Store Kit不提供验证⽤户⾝份的机制，你需要来设计。如果你的程序需要以上功能，例如，纪录特定⽤户的订阅计划，你需要⾃⼰来设计和实现。
图1-3 展⽰了服务器类型的购买过程。
1. 程序向服务器发送请求，获得⼀份产品列表。
2. 服务器返回包含产品标识符的列表。
3. 程序向App Store发送请求，得到产品的信息。
4. App Store返回产品信息。
5. 程序把返回的产品信息显⽰给⽤户（App的store界⾯）
6. ⽤户选择某个产品
7. 程序向App Store发送⽀付请求
8. App Store处理⽀付请求并返回交易完成信息。
9. 程序从信息中获得数据，并发送⾄服务器。小组组名
10. 服务器纪录数据，并进⾏审(我们的)查。
11. 服务器将数据发给App Store来验证该交易的有效性。
12. App Store对收到的数据进⾏解析，返回该数据和说明其是否有效的标识。
13. 服务器读取返回的数据，确定⽤户购买的内容。
14. 服务器将购买的内容传递给程序。
Apple建议在服务器端存储产品标识，⽽不要将其存储在plist中。这样就可以在不升级程序的前提下添加新的产品。
在服务器模式下，你的程序将获得交易（transaction）相关的信息，并将它发送给服务器。服务器可以验证收到的数据，并将其解码以确定需要交付的内容。这个流程将在“验证store收据”⼀节讨论。
对于服务器模式，我们有安全性和可靠性⽅⾯的顾虑。你应该测试整个环境来避免威胁。《Secure C
oding Guide》⽂档中有相关的提⽰说明。
虽然⾮消耗性商品可以⽤内置模式来恢复，订阅类商品必须通过服务器来恢复。你要负责纪录订阅信息、恢复数据。
消耗类商品也可以通过服务器⽅式来纪录。例如，由服务器提供的⼀项服务，你可能需要⽤户在多个设备上重新获得结果。
要在程序内部显⽰“商店”，需要从App Store得到信息来购建界⾯。本章详细讲解如何从App Store获取产品信息。
向App Store发送请求
Store Kit提供了从App Store上请求数据的通⽤机制。程序可以创建并初始化⼀个request对象，为其附加delegate，然后启动请求过程。请求将被发送到App Store，在那⾥被处理。处理完成时， request对象的delegate⽅法将被异步调⽤，以获得请求的结果。图2-1显⽰了请求的数据模型。
如果程序在请求期间退出，则需要重新发送请求。
下⾯讲解请求过程中⽤到的类：
SKRequest
SKRequest为request的抽象根类。
SKRequestDelegate
SKRequestDelegate是⼀个protocol，实现⽤以处理请求结果的⽅法，⽐如请求成功，或请求失败。
发送获得产品信息的请求
程序使⽤products request来获得产品的信息。要完成这⼀过程，程序需创建⼀个request对象，其中会包含⼀个产品标识的列表。之前提到过，你的程序既可以内置产品列表，⼜可以通过外部服务器来获得。
当发送请求时，产品标识会传送到App Store，App Store将会返回本地化信息（这些信息事先已经在iTunes Connect中设置好了），你将使⽤这些信息来购建内置商店的界⾯（显⽰商品名，描述，等等）。图2-2显⽰了请求的过程。
SKProductsRequest
⽤来请求商品的信息。创建时，我们将需要显⽰的商品列表加⼊该对象。
SKProductsRequestDelegate
该protocol定义了处理App Store响应的⽅法。
SKProductsResponse
SKProductsResponse对象为App Store返回的响应信息。⾥⾯包含两个列表（当然是NSArray了）：⼀是经过验证有效的商品，
@property(nonatomic, readonly) NSArray *products
另外⼀个是⽆法被识别的商品信息：
@property(nonatomic, readonly) NSArray * invalidProductIdentifiers
有⼏种原因将造成商品标识⽆法被识别，如拼写错误（当然），被标记为不可出售（unavailable for sale），或是对商品信息的改变没有传送到所***** Store的服务器。（这个原因不是很清楚，再议）。
SKProduct
SKProduct对象包含了在App Store上注册的商品的本地化信息。
购买商品
当⽤户准备购买商品时，程序向App Store请求⽀付信息，然后App Store将会创建持久化的交易信息，并继续处理⽀付流程，即使⽤户重启程序，这个过程亦是如此。App Store同步待定交易的列表到程序中，并在交易状态发⽣改变时向程序发送更新的数据。
社保十五年能领多少钱收集⽀付信息
要收集⽀付信息，你的程序可以创建⼀个payment的对象，将它放到⽀付队列中，如图3-1所⽰。
1. ⼀个SKPayment的对象，包含了"Sword"的商品标识，并且制定购买数量为1。
2. 使⽤addPayment:⽅法将SKPayment的对象添加到SKPaymentQueue⾥。
3. SKPaymentmentQueue包含的所有请求商品，
4. 使⽤SKPaymentTransactionObserver的paymentQueue: updatedTransactions: ⽅法来检测所有完成的购买，并发送购买的商品。
5. 最后，使⽤finishTransaction:⽅法完成交易。
当payment的对象被添加到⽀付队列中的时候，会创建⼀个持久保存的transaction对象来存放它。当⽀付被处理后，transaction被更新。
程序中将实现⼀个观察者（observer）对象来获取transaction更新的消息。观察者应该为⽤户提供购买的商品，然后将transaction从队列中移除。
下⾯介绍在购买过程中⽤到的⼏个类：
SKPayment
要收集⽀付信息，先要了解⼀下⽀付对象。⽀付对象包含了商品的标识（identifier）和要购买商品的数量（quantity）（数量可选）。你可以把同⼀个⽀付对象重复放⼊⽀付队列，，每⼀次这样的动作都相当于⼀次独⽴的⽀付请求。
⽤户可以在Settings程序中禁⽤购买的功能。因此在请求⽀付之前，程序应该⾸先检查⽀付是否可以被处理。调⽤SKPaymentQueue的canMakePayments⽅法来检查。
健康证一天能办下来吗SKPaymentQueue
⽀付队列⽤以和App Store之间进⾏通信。当新的⽀付对象被添加到队列中的时候， Store Kit向App S
tore发送请求。 Store Kit将会弹出对话框询问⽤户是否确定购买。完成的交易将会返回给程序的observer对象。
SKPaymentTransaction
transaction对象在每次添加新的payment到队列中的时候被创建。 transaction对象包含了⼀些属性，可以让程序确定当前的交易状态。
程序可以从⽀付队列那⾥得到⼀份审核中的交易列表，但更常⽤的做法还是等待⽀付队列告知交易状态的更新。
经典 老歌SKPaymentTransactionObserver
在程序中实现SKPaymentTransactionObserver的协议，然后把它作为SKPaymentQueue对象的观察者。该观察者的主要职责是：检查完成的交易，交付购买的内容，和把完成后的交易对象从队列中移除。
在程序⼀启动，就应该为⽀付队列指定对应的观察者对象，⽽不是等到⽤户想要购买商品的时候。 Transaction对象在程序退出时不会丢失。程序重启时， Store Kit继续执⾏未完成的交易。在程序初始化的时候添加观察者对象，可以保证所有的交易都被程序接收（也就时说，如果有未完成的transactio
n，如果程序重启，就重新开始了，如果稍候再添加观察者，就可能会漏掉部分交易的信息）。
恢复交易信息（Transactions）
当transaction被处理并从队列移除之后，正常情况下，程序就再也看不到它们了。如果你的程序提供的是⾮消耗性的或是订阅类的商品，就必须提供restore的功能，使⽤户可以在其他设备上重新存储购买信息。
Store Kit提供内建的功能来重新存储⾮消耗商品的交易信息。调⽤SKPaymentQueue的restoreCompletedTransactions的⽅法来重新存储。对于那些之前已经完成交易的⾮消耗性商品，Apple Store⽣成新的，⽤于恢复的交易信息。它包含了原始的交易信息。你的程序可以拿到这个信息，然后继续为购买的功能解锁。当之前所有的交易都被恢复时，就会调⽤观察者对象的paymentQueueRestoreCompletedTransactionsFinished⽅法。
如果⽤户试图购买已经买过的⾮消耗性商品，程序会收到⼀个常规的交易信息，⽽不是恢复的交易信息。但是⽤户不会被再次收费。程序应把这类交易和原始的交易同等对待。
订阅类服务和消耗类商品不会被Store Kit⾃动恢复。要恢复这些商品，你必须在⽤户购买这些商品时，在你⾃⼰的服务器上记录这些交易信息，并且为⽤户的设备提供恢复交易信息的机制。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论