In-App Purchase Programming Guide----（六) ----Working with Subscriptions

標籤：des   style   blog   class   code   c   

 

Working with Subscriptions

Apps that use subscriptions have some additional behaviors and considerations. Because subscriptions incorporate an element of time, your app needs to have the appropriate logic to determine whether the subscription is currently active and what time periods the subscription was active in the past. Your app also needs to react to new and renewed subscriptions, and properly handle expired subscriptions. Figure 5-1 shows an example subscription timeline, including some of the complexities your app needs to handle.

使用訂閱(subscriptions)的應用有一些額外的行為和注意事項(considerations)。 因為訂閱包含時間元素，應用程式需要有適當的邏輯來決定訂閱當前是否處於活動狀態以及過去該訂閱活動的時間段。 應用程式還需要應對新的和更新的訂閱，並且需要正確地處理到期訂閱。 圖5-1 舉了一個訂閱時間表的例子，包括一些應用程式需要處理的複雜事項(complexities )。

Figure 5-1  Example subscription timeline

Calculating a Subscription’s Active Period

一、計算一個訂閱的活動期

Your app needs to determine what content the user has access to based on the period of time the subscription was active. Consider, for example, a user with a subscription to a magazine that publishes a new issue on the first day of each month, following the timeline shown in Table 5-1.

應用程式需要在訂閱處於活動狀態的期間內決定使用者訪問什麼內容。 舉個例子，一個使用者訂閱了一個雜誌，該雜誌在每個月的第一天發布新刊，5-1中的時間表：

Table 5-1  Timeline of a sample subscription表 5-1 一個樣本訂閱的時間表

Date	Event
February 1	February issue is published. It is not made available because the user has not yet subscribed. (It is made avaibalbe later, after the user subscribes.) 二月刊發布。使用者不可用，因為他還沒有訂閱(訂閱後就可以使用)。
February 20	User subscribes with a duration of one month. January issue is made available immediately. 使用者訂閱了一個月期限的雜誌。一月刊立即可以使用。
March 1	March issue is published. It is made available immediately because the user has an active subscription. 三月刊發布。使用者立即可以使用，因為它已經有一個活動的訂閱。
March 20	The user’s subscription automatically renews for another month. 使用者的訂閱自動續訂一個月。
April 1	April issue is published. It is made available immediately because the user has an active subscription. 四月刊發布。使用者立即可以使用，因為它已經有一個活動的訂閱。
April 20	The user prevents the subscription from renewing, ending the subscription period. 使用者結束了續訂。
May 1	May issue is published. It is not made available because the user’s subscription has lapsed. 五月刊發布。 使用者不可用，因為訂閱已經失效。
June 1	June issue is published. It is not immediately made available because the user’s subscription has lapsed. (It is made available later, after the user resubscribes.) 六月刊發布。使用者不可用因為訂閱已經失效(使用者重新訂閱就可以馬上使用)。
June 17	User resubscribes. June issue is made available immediately. 使用者重新訂閱。六月刊立即可用。
July 1	July issue is published. It is made available immediately because the user has an active subscription. 七月刊發布。使用者立即可以使用，因為它已經有一個活動的訂閱。

To implement this logic in your app, keep a record of the date that each piece of content is published. Read the Original Purchase Date and Subscription Expiration Date field from each receipt entry to determine the start and end dates of the subscription. (For information about the receipt, see Receipt Validation Programming Guide.) The user has access to all content published between each start and end date, as well as the content that was initially unlocked when the subscription was purchased. If the subscription lapsed, there will be multiple periods of time during which the subscription was active, and there will be pieces of content unlocked at the beginning of a subscription period.

要想在應用程式中實現該邏輯，保留一個關於每刊內容發布的日期記錄。 從每個收據項目中讀取初始購買日期和訂閱到期時期來決定訂閱的開始和結束日期。 (關於收據的更多資訊，請看 Receipt Validation Programming Guide.) 使用者可以訪問所有在開始日期和結束日期之間發布的內容以及它初次購買時解鎖的內容。 如果訂閱失效(lapsed),將由訂閱活動期間的多個時間期，以及在一個訂閱期的開始時又多刊內容解鎖。

Note: Don’t calculate the subscription period by adding a subscription duration to the purchase date. This approach fails to take into account the free trial period, the marketing opt-in period, and the content made available immediately after the user purchased the subscription.

注意：不要通過添加一個訂閱期間到購買日期中來計算訂閱期。 該方法沒有考慮到應用試用期，市場選擇期，並讓使用者購買了訂閱之後馬上解鎖內容。

 

Continuing the example from Table 5-1, the receipt would show the following start and end dates:

從表5-1開始繼續樣本，收據將顯示以下開始和結束日期：

• February 20 – March 20

• March 20 – April 20

• (The lapse from April 20 – June 17 is not recorded explicitly in the receipt.)

• June 17 – July 17

The user has access to the February and June issues because they were initially unlocked when the subscription was purchased or restarted.

使用者可以訪問二月和六月刊，因為它們時在訂閱被購買或重新訂閱時解鎖的內容。

The user has access to the March, April, June, and July issues because the subscription is active at those times.

使用者可以訪問三月，四月，六月以及七月刊，因為在這些時間訂閱是活動的。

Expiration and Renewal

二、到期和續訂

The renewal process begins with a “preflight” check, starting ten days before the expiration date. During those ten days, the App Store checks for any issues that might delay or prevent the subscription from being automatically renewed—for example, if the customer no longer has an active payment method, if the product’s price increased since the user bought the subscription, or if the product is no longer available. The App Store notifies users of any issue so that they can resolve it before the subscription needs to renew, ensuring their subscription isn’t interrupted.

續訂過程在到期日前10天開始預檢。 在那10天中，市集檢查任何可能導致自動續訂延遲或無法續訂的情況---比如，如果使用者沒有一個可用的支付方法，如果使用者購買了訂閱之後，產品價格升了，又或者如果產品已經不存在。 市集通知使用者任何問題，這樣他們就可以在續訂之前解決這些問題，以確保不會終止他們的續訂。

Note: Increasing the price of a subscription doesn’t disable automatic renewal for all customers, only for those customers whose subscription expires in the next ten days. If this change is a mistake, changing it back to the original price means no additional users are affected. If this change is intentional, keeping the new higher price causes automatic renewal to be disabled for the rest of your users in turn as they enter the ten-day renewal window.

 注意：提高訂閱價格並不會終止所有使用者的自動續訂，只要那些使用者的到期時間是在未來10天之內。 如果該價格改變是一個錯誤，把價格改回原來的價格並不會影響任何使用者。 如果是有意的提交價格，一直保留該新價格將導致依次進入10天續訂視窗的其他使用者不能進行自動續訂。

During the 24-hour period before the subscription expires, the App Store starts trying to automatically renew it. The App Store makes several attempts to automatically renew the subscription over a period of time but eventually stops if there are too many failed attempts.

在訂閱到期的前24個小時期間，市集開始嘗試自動續訂。 儘管市集在自動續訂期間會多次嘗試自動續訂，但是如果失敗次數太多則會終止自動續訂。

The App Store renews the subscription slightly before it expires, to prevent any lapse in the subscription. However, lapses are still possible. For example, if the user’s payment information is no longer valid, the first renewal attempt would fail. If the user doesn’t update this information until after the subscription expires, there would be a short lapse in the subscription between the expiration date and the date that a subsequent automatic renewal succeeds. The user can also disable automatic renewal and intentionally let the subscription expire, then renew it at a later date, creating a longer lapse in the subscription. Make sure your app’s subscription logic can handle lapses of various durations correctly.

儘管市集在它快要到期之前自動續訂來防止丟失任何訂閱。 但是，任然有可能丟失。比如，如果使用者的支付資訊已經失效，第一次續訂將失敗。 如果使用者一直不更新該支付資訊直到訂閱到期，在到期時間和下一次自動續訂成功之前這段時間將有一小段時間的丟失。 使用者也可以關閉自動續訂並故意讓訂閱到期，然後在以後續訂它，長期丟失訂閱。 請確定你的應用程式的訂閱邏輯能正確地處理不同時間的丟失。

After a subscription is successfully renewed, Store Kit adds a transaction for the renewal to the transaction queue. Your app checks the transaction queue on launch and handles the renewal the same way as any other transaction. Note that if your app is already running when the subscription renews, the transaction observer is not called; your app finds out about the renewal the next time it’s launched.

 當成功續訂之後，商店Kit把續訂交易添加到交易隊列中。應用程式在啟動時檢查交易隊列並且同處理其它任何交易一樣處理它。 注意如果在續訂時應用程式已經運行，那麼交易觀察者將不被調用；應用程式在下一次啟動時找到續訂記錄。

Cancellation

三、取消

A subscription is paid for in full when it’s purchased and can be refunded only by contacting Apple customer service. For example, if the user accidentally buys the wrong product, customer support can cancel the subscription and issue a refund. It’s not possible for customers to change their mind in the middle of a subscription period and decide they don’t want to pay for the rest of the subscription.

購買了一個訂閱後得全額付款，只有通過聯絡蘋果客服服務才能退款。 比如，如果使用者意外買錯了產品，客服中心可以取消該交易並退款。 使用者不能在一個訂閱周期中間改變注意不支付剩餘的訂閱。

To check whether a purchase has been canceled, look for the Cancellation Date field in the receipt. If the field has a date in it, regardless of the subscription’s expiration date, the purchase has been canceled—treat a canceled receipt the same as if no purchase had ever been made.

要想確認某次交易是否已經被取消，在收據(receipt)中尋找Cancellation Date(取消日期)欄位。 如果該欄位有日期，不管該訂閱的到期日期是什麼，該交易都已經被取消---取消交易就是跟一直沒有購買過一樣。

Depending on the type of product, you may be able to check only the currently active subscription, or you may need to check all past subscriptions. For example, a magazine app would need to check all past subscriptions to determine which issues the user had access to.

 根據產品類型，你或許只能檢查當前的活動交易，或者你可能需要檢查過去所有的交易。比如，一個雜誌應用需要檢查過去所有的交易來決定使用者訪問了那些期刊。

Cross-Platform Considerations

四、跨平台注意事項

Product identifiers are associated with a single app. Apps that have both an iOS and OS X version have separate products with separate product identifiers on each platform. You could let users who have a subscription in an iOS app access the content from an OS X app (or vice versa), but implementing that functionality is your responsibility. You would need some system for identifying users and keeping track of what content they’ve subscribed to, similar to what you would implement for an app that uses non-renewable subscriptions.

產品識別碼只能綁定到一個應用程式。同時有iOS和OS X版本的應用程式是不同的應用程式並分別帶有不同的產品識別碼。 你可以讓在一個iOS應用中購買了訂閱的使用者從OS X應用(或其它平台)訪問它購買的內容，但是這功能你應該自己實現。你會需要一些系統來識別使用者並保持跟蹤他們已經訂閱了什麼內容，類似於你會給一個no-renewable subscriptions(不可再生訂閱)應用程式實現什麼。

Letting Users Manage Subscriptions

五、讓使用者管理訂閱

Rather than needing to code your own subscription management UI, your app can open the following URL:

不需要你自己編碼實現自己的訂閱管理UI，你的應用程式可以開啟以下URL：

https://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/manageSubscriptions

Opening this URL launches iTunes or iTunes Store, and then displays the Manage Subscription page.

開啟該URL啟動iTunes 或者 iTunes商店，然後顯示管理訂閱頁面。

The Test Environment

6、測試環境

 

For the sake of testing, there are some differences in behavior between auto-renewable subscriptions in the production environment and in the test environment.

為了測試，自動再生訂閱在產品環境(production environment) 和 在測試環境(test environment)中的行為有所不同。

Renewal happens at an accelerated rate, and auto-renewable subscriptions renew a maximum of six times per day. This lets you test how your app handles a subscription renewal, a subscription lapse, and a subscription history that includes gaps.

更新發生在加速時，並且自動更新訂閱每天最多更新6次。 這樣讓裡測試你的應用程式如何處理一個訂閱更新，一個訂閱失效，以及一個包括缺口的訂閱曆史。

Because of the accelerated expiration and renewal rate, the subscription can expire before the system starts trying to renew the subscription, leaving a small lapse in the subscription period. Such lapses are also possible in production for a variety of reasons—make sure your app handles them correctly.

因為加速的到期和更新速度，訂閱可以在系統開始嘗試更新訂閱之前到期，在訂閱期間留下一個小失誤。 因為各種原因，這樣的失誤在產品中也同樣可能存在---請確保你的應用程式可以正確地處理它們。

下一頁      上一頁