转载

【译】自动更新订阅IAP浅谈（设置和测试）

本文由CocoaChina译者Leon（社区ID）翻译

作者：Jaz Garewal

原文： How to Set Up and Test an Auto-Renewable Subscription for an iOS App

转载请保留原文内容和所有链接。

自动更新的订阅是iOS内购形式的一种。它可以让app在一个时间段内提供内容或功能。我在之前的帖子中聊过自动更新订阅类型的IAP的准则，还聊过Apple以后可能做出的改进。现在让我们来看一下如何实际地在App中设置并测试自动更新的订阅。

在iTunes Connect后台设置自动更新的订阅

事实上，实现自动更新的订阅的流程和其他IAP并没有什么不同。有许多关于其他类型IAP的教程，比如：这一篇，主要讲的是非更新的IAP类型（你可以直接跳到教程中段，讲"添加订阅到你的产品列表中"）。设置自动更新订阅和非自动更新订阅的不同之处在于：自动更新订阅的每个订阅周期都在一个IAP实体中设置，而非自动更新订阅的每个订阅周期都需要单独创建一个产品（比如3个月订阅、6个月订阅等），每个周期都有针对的一个product ID。

在App中实现自动更新的内购项目

我们发现，使用IAP helper类来实现自动更新订阅式内购是最好的选择，这和实现其他类型的内购，在策略上并无不同。但是，自动更新订阅式内购对收据（receipt）管理有着额外的要求，我们可以再创建特定的helper类，来分别处理这方面的逻辑。这样，helper类就可以处理各种各样的内购项目，而不局限于自动更新式订阅内购。在该教程中，简洁起见，我们把所有的方法都放在同样的一个IAP helper类中。而在实际操作中，我们建议把收据管理的代码放在单独的类中。考虑到收据交换的过程中，会涉及到私钥，也可能将这部分的逻辑放到server处理。稍后我们会具体讲解。

对于IAPHelper类来说，我们需要import StoreKit的framework，并声明其遵循SKProductsRequestDelegate和SKPaymentTransactionObserver协议：

import UIKit import StoreKit  class IAPHelper: NSObject, SKProductsRequestDelegate, SKPaymentTransactionObserver

然后声明初始属性（后面我们再添加其他属性）：

var productID:NSSet = NSSet(object: "string") var productsRequest:SKProductsRequest = SKProductsRequest() var products = String : SKProduct

在App中，IAPHelper需要成为一个单例。在Swift 1.2中，有个简洁的做法，比Objective-C中的dispatch_once方式更简单。

static let sharedInstance = IAPHelper()

很简单吧，Objective-C中的单例实现相当繁琐，而使用Swift，单例简洁到超乎想象。

现在属性都准备好了，让我们看看方法的实现。

首先，我们需要从App Store上请求产品的标识，然后启动产品请求。因此，需要如下的public方法：

func requestProductsWithProductIdentifiers(productIdentifiers: NSSet) {  let productIdentifiers:NSSet = NSSet(objects: "com.ourApp.monthly", "com.ourApp.annually")  productsRequest = SKProductsRequest(productIdentifiers: productIdentifiers as Set) productsRequest.delegate = self; productsRequest.start() }

设置了SKProductsRequest的delegate后，还需要一个方法从respose中提取信息，实现以下的delegate方法：

func productsRequest(request: SKProductsRequest!, didReceiveResponse response: SKProductsResponse!) {  if let productsFromResponse = response.products as? [SKProduct] {      for product in productsFromResponse {     products[product.productIdentifier] = product     } } }

现在，准备工作已经做好了，需要通过IAPHelper的shareInstance，调用requestProducts方法。

首先，我们需要添加一个新的属性--一个闭包。通过它传递购买的状态，根据状态，再进行特别处理。闭包有一个Bool参数（true表示成功，false表示失败），还有可选的String类型参数，在购买失败时，可以传递一些错误信息。

var purchaseCompleted: ((Bool, String?) -> Void)

购买产品的第一步，要通过一个方法获取购买的请求，比如点击一个按钮，来启动订阅的购买。

func beginPurchaseFor(productIDString: String, purchaseSucceeded:(Bool, String?) -> Void) { if SKPaymentQueue.canMakePayments() {      if let product: SKProduct = products[productIDString] {              purchaseCompleted = purchaseSucceeded         var payment = SKPayment(product: product)         SKPaymentQueue.defaultQueue().addTransactionObserver(self)         SKPaymentQueue.defaultQueue().addPayment(payment);     } else {         purchaseSucceeded(false, "Product /(productIDString) not found")              }  } else {     purchaseSucceeded(false, "User cannot make payments") } }

通过第一行的方法签名可以看到，第二个参数是作为回调方法来使用的，它和我们的purchaseCompleted属性一样。

方法中，我们先验证该设备是否可以进行IAP购买，如果可以，进一步验证是不是有一个productID和传入的匹配。若验证都通过，就设置purchaseSucceeded参数到purchaseCompleted属性，这样就可以将状态通过purchaseCompleted属性进行回传。接下来，我们创建一个SKPayment对象，并将self（我们的IAPHelper实例）设置为交易观察者（transaction observer），然后将payment添加到default的支付队列（payment queue）中。

上述过程中，如果有一项检查失败（如设备不允许内购或者product ID不匹配），我们都可以通过purchaseSucceeded回调传递false的状态，并附上错误的详细信息（如"产品（代码xxx）不存在"或者"用户不允许进行内购买"）。通过这些，再判断下一步的处理。

假定产品购买成功，得通过一个方法来监听购买的响应事件。在这里，需要实现SKPaymentTransactionObserver协议的paymentQueue方法。但是这里我把详细说明分成两部分，首先，看看成功购买的处理：

func paymentQueue(queue: SKPaymentQueue!, updatedTransactions transactions: [AnyObject]!) { for transaction: AnyObject in transactions {      if let trans:SKPaymentTransaction = transaction as? SKPaymentTransaction {         switch trans.transactionState {             case .Purchased:             SKPaymentQueue.defaultQueue().finishTransaction(trans)             if let receiptURL = NSBundle.mainBundle().appStoreReceiptURL where             NSFileManager.defaultManager().fileExistsAtPath(receiptURL.path!)  { if let purchaseSuccessCallback = purchaseCompleted {                     purchaseSuccessCallback(true, nil)                 }                             self.isPurchasing = false            self.receiptValidation()     } else {         if !isRefreshingReceipt {             self.isPurchasing = false             isRefreshingReceipt = true             let request = SKReceiptRefreshRequest(receiptProperties: nil)             request.delegate = self             request.start()                          if let _ = purchaseCompleted {                              purchaseCompleted**(true, nil)             }         }     }         break

假定购买过程顺利，我们高兴地得到了"已购买"状态，不用再去纠结标准IAP实现的细节。在上面的代码中你可以看到，我们需要那个收据信息。交易成功后，app可以通过appStoreReceiptURL得到用户的本地收据地址，如果可以得到收据的话，我们就可以继续进行下一步receiptValidation，这是设置、管理用户订阅的前提。在这个时间点，我们通过purchaseSuccessCallBack属性回调的信息有：bool类型的true值，表明购买已成功；nil的error message。这些好消息将被发送给IAPHelper的使用者，供其后期处理。

如果，万一，购买成功，但是还是得不到收据信息，我们可以通过新建SKReceiptRefreshRequest的方式来在后面踢一脚。

这里我们先跳过paymentQueue，看一下SKReceiptRefreshRequest的requestDidFinish delegate方法。

func requestDidFinish(request: SKRequest!) {     if let appStoreReceiptURL = NSBundle.mainBundle().appStoreReceiptURL where    NSFileManager.defaultManager().fileExistsAtPath(appStoreReceiptURL.path!) {         if  NSFileManager.defaultManager().fileExistsAtPath(appStoreReceiptURL.path!) {          self.receiptValidation()                  if let purchaseSuccessCallback = purchaseCompleted {                      purchaseSuccessCallback(true, nil)                      }      } } else {     if let purchaseSuccessCallback = purchaseCompleted {         purchaseSuccessCallback(false, "Cannot find receipt")     } } }

当在requestDidFinish方法中获得响应时，我们可以检查appStoreReceiptURL路径上是否有相关文件存在。若存在，我们通知那些正在等待回调的对象，告知它们购买已经成功，同时，可以继续进行收据的有效性验证。

如果这时还是无法找到收据，接着还是得返回错误的处理方法，传递false的Bool值，还有"无法找到收据"的错误信息--我们的IAPHelper在哭诉。有点像虚拟的收银机被卡住了，无法打印。这样，相关的对象可以处理这些IAPHelper收集的错误。

哦，这个话题太沉重了，我们来看点高兴的。

接下来，看看如果我们的paymentQueue相关的delegate方法受到"Failed"状态，该如何处理。什么？不是说高兴的事么？我感觉世界都变得阴暗起来了。

不管怎样，让我们继续完成我们的func paymentQueue(queue: SKPaymentQueue!, updatedTransactions transactions: [AnyObject]!)方法吧：

       case .Failed:                 self.isPurchasing = false                      if let _ = purchaseCompleted {                              var errorMessage: String?                                      if let _ = transaction.error {                         errorMessage = transaction.error.localizedDescription                      }                  purchaseCompleted(false, errorMessage)                               }         SKPaymentQueue.defaultQueue().finishTransaction(trans)         SKPaymentQueue.defaultQueue().removeTransactionObserver(self)         break                 default:        break                    }        }     } }

这么说，方法失败了？这不是Apple的API吗？它运转正常，顺风顺水，但还是失败了。一定是打开方式不对。。。接下来，退回去，看着镜子，想想该对Apple大神做个什么表情。手腕上的Apple Watch已经不见了，你知道是怎么回事。

生气归生气，还是得看看错误处理。收到错误后，先通过localizedDescription拿到本地化的错误信息。将false和这个错误信息都回调回去（满满的都是泪）。接下来告诉SKPaymentQueue.defaultQueue()支付战役已经结束，我们输了。

以上内容将贯穿整个自动更IAP的实现过程。下面我们来看看为何我们需要收据信息，并学习如何进行处理。

自动更新IAP的订阅管理

在深入研究代码之前，让我们先来理解一下自动更新IAP中订阅管理的工作原理，看看它对App的意义在何处。

Apple并没有在iOS系统中提供任何关于订阅详情的API或REST接口，也没有提供可以查看订阅更新或者取消的回调方法。它只提供了一个API：当你传递用户本地的收据和一个"shared secret"（共享秘钥，在iTunes Connect后台创建）时，返回一个包含用户购买历史的JSON数据，它里面就包含了订阅的详细信息。

我们需要通过某种方式来持续检测订阅，通过周期性的获取这个JSON数据，解析并查看其中的过期时间是否改变，以此来检测订阅是否更新或者取消。如果过期时间已经改变，则订阅被更新；如果过期时间未改变，且当前已经超过了过期时间，则可视为订阅未被更新。这种情况下，可以假定订阅已经被取消（稍后可以通过解析返回数据，获得取消日期--cancellation date，来做进一步判定），也可以认为从Apple返回的支付信息出现错误。不管是哪种情况，都可以认为当前的订阅是无效的，对于这个用户来说，App中的订阅内容是不可用的。

以上逻辑可以在本地处理，也可以自己设置服务器，或者使用公开的后端服务，比如Parse。

说的够多了，上代码！

错了，现在还不到写代码的时候，首先，需要在iTunes Connect后台创建shared secret。先跳转到app的IAP设置部分，在IAP列表下面，你会看到"View or generate a shared secret"，点击即可：

【译】自动更新订阅IAP浅谈（设置和测试）

好了，现在可以看看收据处理的代码了。

第一个方法是：

func receiptValidation() {  var error: NSError?      if let receiptPath = NSBundle.mainBundle().appStoreReceiptURL?.path where     NSFileManager.defaultManager().fileExistsAtPath(receiptPath), let receiptData  = NSData(contentsOfURL:      NSBundle.mainBundle().appStoreReceiptURL!), let receiptDictionary = ["receipt- data" :      receiptData.base64EncodedStringWithOptions(nil), "password" : "your shared  secret"], let requestData =      NSJSONSerialization.dataWithJSONObject(receiptDictionary, options: nil,  error:&error) as NSData! {          let storeURL = NSURL(string:  "https://sandbox.itunes.apple.com/verifyReceipt")!         var storeRequest = NSMutableURLRequest(URL: storeURL)         storeRequest.HTTPMethod = "POST"         storeRequest.HTTPBody = requestData                  let session = NSURLSession(configuration:  NSURLSessionConfiguration.defaultSessionConfiguration())          session.dataTaskWithRequest(storeRequest, completionHandler: { (data:  NSData!, response: NSURLResponse!,         connection: NSError!) → Void in                     if let jsonResponse: NSDictionary =  NSJSONSerialization.JSONObjectWithData(data, options:            NSJSONReadingOptions.MutableContainers, error: &error) as?  NSDictionary, let expirationDate: NSDate =              self.expirationDateFromResponse(jsonResponse) {                            self.updateIAPExpirationDate(expirationDate)            }        })     } }

方法中声明了optional类型的NSError变量。接下来是温习Swift 1.2中optional类型的chaining capabilities的好机会。按照链式的结构，先判断是否存在appStoreReceiptURL（在购买完成时，我们已经验证过了这个属性，但是Swift中，多一层检查，就多一重保障）。接下来，检查这个path下是否有文件存在，如果存在的话，就通过该文件创建receiptData对象。然后，再填上shared secret，就创建了一个receiptDictionary JSON数据。

上述过程完成后，就可以用requestData创建NSMutableRequest。

在本例子中，我们通过沙箱URL来验证收据，在实际的环境中，你需要把"sandbox"换成"buy"。

我们将requestData数据发送给Apple，等待它对completionHandler的回调。回调收到后，继续通过optional chain方式检查返回数据：如果第一部分（这里就是data转到JSON）存在的话，就用expirationDateFromResponse方法在里面找到expiration date数据。

进展顺利的话，我们就可以在适当的时机处理该过期时间--检查该时间和我们之前存储的是否一致（如果一致，表明订阅已更新），若过期时间等于或者早于当前日期，则意味着，订阅未更新，很可能已经被取消，可以通过JSON数据中的Cancellation Date进一步检查。

现在我们来创建expirationDateFromResponse，从JSON返回数据中解析过期时间：

func expirationDateFromResponse(jsonResponse: NSDictionary) → NSDate? {     if let receiptInfo: NSArray = jsonResponse["latest_receipt_info"] as? NSArray {           let lastReceipt = receiptInfo.lastObject as! NSDictionary              var formatter = NSDateFormatter()       formatter.dateFormat = "yyyy-MM-dd HH:mm:ss VV"       let expirationDate: NSDate =  formatter.dateFromString(lastReceipt["expires_date"] as! String) as NSDate!       return expirationDate    } else {           return nil           } }

这个方法中，先看看"latestreceiptinfo"的key是否对应NSArray类型的数据。如果有的话，我们从数组中获取最后一个对象，再从这个对象中查找key"expires_date"对应的对象，将其转换成NSDate类型。上述过程无误的话，就可以返回expirationDate对象。过程中出错的话，就直接返回nil。

接下来，我们来学习如何测试自动更新订阅IAP。

测试自动更新类IAP

完成收据验证代码只是第一步，问题是如何验证我们的验证代码？答案是：测试。你的代码依赖于外部的模块（IAP服务器），而你无法控制，只能通过一些工具来进行测试。

之前提到过，有两个URL可以用来验证收据，一个针对测试环境，另外一个针对实际环境。沙箱模式下购买自动更新订阅类IAP和测试其他类型的IAP过程类似。只需要在iTunes Connect后台创建沙箱测试账户（Users and Roles功能下），可以创建多个测试账户，以备测试之需。然后就可以用沙箱账户在设备上完成内购。

测试自动更新类IAP时，有一个不同之处：该购买是有周期的。订阅会于5次更新后作废。看到这里你肯定会想："等等，要是我设置了每月的订阅，要测试过期得等到5个月后？"实际上，自动更新的IAP在沙箱环境下，周期是会加速的，更新是按分钟或小时计算。如果你要测试一月的订阅，更新周期是5分钟。因此要测试过期（5次更新后），等待25分钟即可。

【译】自动更新订阅IAP浅谈（设置和测试）

另外，需要注意的一点是：在测试环境下，订阅并不是每次都自动更新。我估算大概有三分之一的概率，月度订阅会在5分钟后被标记一次，然后，就直接过期，并不会被自动更新。记得我提醒过你多创建几个测试账户吗？那就是为了方便在测试订阅更新时使用。要是你需要测试过期处理的代码，就一直用过期的那个账户，这样就可以将等待时间减少到原来的五分之一。

也就是说，在测试一周自动更新订阅时，每次都等15分钟并不明智。另外，如何测试订阅取消？坏消息是，你无法测试。当前，测试环境的订阅无法手动进行取消。因此，最好的方式是：创建多个沙箱测试账号，用一个先测试，再用其他测试。等第一个快要过期时，切换过去测试。