だいたい47度

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

PageTop

In App Purchase開発前に知っておきたかったこと

アプリ内課金を実装すべくIn App Purchaseを実装していたのですが、コードよりも機能理解のところで引っかかりました。例えば、どの段階で開発に入れるのか、どんな情報はアプリ側で用意しどんな情報はStore側で持つべきか、シミュレータと実機テストの違いは何か、などです。どうせ忘れるのでメモします。

今回作成した課金アイテムは、消費型(Consumable)と非消費型(Non-Consumable)をそれぞれ1つずつです。両方共アプリ内に最初から入れておき、フラグ管理する形にしています。

In App Purchase開発に必要な準備
まず、Appleに開発者登録してあることが必要です。Xcodeを落としただけでなく、すでに年会費も払ってアプリを挙げる権利を持っていることが必要です。

また、Appleと金銭授受契約を結んでいることが必要です。無料アプリ+課金だとしても、有料アプリを売るときに必要な契約を結ぶ必要があります。事前に他アプリで契約していれば特に問題ないです。

アプリ自体は完成している必要はありません。課金アイテムを登録するためには、該当アプリがiTunes Connectに登録されている必要がありますが、バイナリファイルを置く必要もなく、説明やスクリーンショットもとりあえず適当で構いません。それらはあとで修正しましょう。bundleIdは変えられないのできちんとしたものを書いておきましょう。アプリがPrepare for Upload状態になっていればよいです。

基本的には以上ですので、アプリの開発は全然進んでなくても問題ないわけですね。

課金アイテム自体の登録は難しくないです。iTunes ConnectのManage Your Applicationから該当アプリを選択し、Manage In-App Purchasesを選択すればOK。スクリーンショットをあげろと言われますが、あげなくてもテスト環境ではテストできます。

課金アイテムの値段はいつ取得するか
課金アイテムの値段情報はStoreから受け取って使うほうがよいです。課金アイテムはAppleの指定した値段のいずれかで売るわけですが、この値段はレートによって変わりますので、勝手にアプリ側に「85円」とか書いてしまうと後で困ります。逆にStoreから値段を受け取って表示していれば、Storeの値段を低くするだけで勝手に反映されるようになるので楽になります。

幾つかアプリを見てみたのですが、値段を購入処理の最終確認まで表示しないアプリが多いようです。購入ボタンを押す前から画面に値段を表示しているアプリも有るには有りましたが、オフラインで表示をみても値段が変わらないので、おそらくベタ書きしているのだと思います。

購入処理の最終確認は、プログラミングしなくても勝手に表示されます。「◯◯をXX円で購入しますか?」というポップアップが自動的に作成されるのです。ここは金銭単位も含めた言語対応をしてくれるので便利です(課金アイテムの名称(◯◯)だけは自分で登録しておく必要があります)。

結局、課金アイテムの値段はStoreに登録するだけで、アプリ側では使用しないことが多いようです。僕も値段表示は全て最終確認ダイアログだけにしてしまい、アプリ側では特になにもしていません(Storeから帰ってきたデータの中身を標準出力して確認するときだけSKProductのpriceを呼んでいます)。

同じ議論で、課金アイテム名称も特にアプリ側では使っていません。そのため、Storeへの問い合わせは購入ボタンをタップしてから初めて行うように実装しています。

シミュレータと実機テストの違い
いくつかの記事ではシミュレータではIn App Purchaseはテストできないとありましたが、普通にできます。iTunes Connectでテストユーザを登録した後、シミュレータで購入処理を走らせ、テストユーザのIDを打ち込むと普通に買えます。Restoreのテストもできます。

では、何がシミュレータでできないかというと、テストユーザの切り替えができないです。なんでできないんだろう……。面倒くさいです。

追記:シミュレータでもテストユーザ切り替えができました。「iOSシミュレータ>コンテンツと設定をリセット」でユーザ情報が消えるので再度別ユーザでログインできます。ただ、セーブデータも消えるので相変わらず面倒くさいと言えば面倒くさいです。

処理待ちを実装する
考慮から抜けがちなのですが、InAppPurchaseの処理は結構時間がかかります。その間にボタンをタップされまくると多重に処理が走って非常に面倒です。

そのため、一時的に画面を処理待ち状態にする必要があります。同時に、処理が終わったらそれを解除する必要があります。僕はInAppPurchaseの処理はSingletonにまとめているので、そのSingletonにdelegateを渡して、購入処理終了後(もしくは失敗後)に解除処理を呼び出すようにしています。

ややこしいことに画面の処理待ち解除が走らない可能性があります。処理待ち中に画面遷移できないように実装していても、アプリ自体を止められてしまった場合、アプリを再起動直後に処理が走るかもしれないのです。その場合、処理待ち解除の対象はnilかもしれません。

よって、処理待ち解除にはnil対応をいれることと、購入処理自体は処理待ち状態のクラスには持たせないことが重要です。

何をテストすべきか
この項目は意外と難しいです。In App Purchaseはアプリ内に留まらない処理になるため、テスト範囲が広くなります。たとえば、購入処理中に接続を切った場合にどう復旧させるかなどがテストに入ってきます。

困っていたのですが、Tech-GymさんのApp Storeのアプリ内課金のテストパターンが良い感じです。

僕は「ネットワークがないとき」の検出を忘れていました。これに関してはAppleのサンプルクラスのひとつReachabilityがいけています。バージョンが古いとretValがエラーになったりします。

Reachability *internetReach = [Reachability reachabilityForInternetConnection];
NetworkStatus netStatus = [internetReach currentReachabilityStatus];
if (netStatus == NotReachable) {
//接続できてない
} else {
//接続できてる
}

あとはリストア処理がないとリジェクトされるよ、ってのも大事ですね。リストアは非消費型を作ったので必要でした。リストア処理ボタンが必要なので、最初から考えてデザインしないといけないですね。

iPhone&Androidアプリ内課金プログラミング完全ガイド (Smart Mobile Developer)iPhone&Androidアプリ内課金プログラミング完全ガイド (Smart Mobile Developer)
(2012/11/16)
佐藤 航陽、加藤 勝也 他

商品詳細を見る
関連記事
スポンサーサイト

PageTop

コメント


管理者にだけ表示を許可する
 

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。