2013年7月22日月曜日

Google Play In-App Billing テスト方法

続きの続き。Google PlayのIAB(In-App Billing)のテストの話を乗せときます。
あまり載せることがないので、基本的には オフィシャル の内容ほぼそのままです。

Google Playのアプリ内課金テストではAmazonのIAPのようなテストアプリは使いません。同様の機能をPlayStoreが既に備えています。また、本番環境でのテストをする方法も既に用意されています。

２つのテスト方法
Google Play には、アプリ内課金の実装テストに役立つ２つの機能が用意されています。
  1. サンドボックステスト
    • 予めテスト用に予約されたアイテムIDを使って、所定のレスポンス時のテストを行える。
  2. 実購入テスト
    • Google Playを通じて実際の購入と同じ環境でアプリ内課金を行うことができる。こちらはGoogle Playへの通信を行い、実際にGoogle Walletへの取引が発生する。尚、テストではこの課金はキャンセルされ実際の請求は発生しない。

どちらのテスト方法もアプリを公開する前に行うためのテストですが、それぞれ役割が違います。
  • サンドボックステストは、主にアプリ内課金機能の単体テストレベルで利用します。
  • 実購入テストは、公開前の結合・システムテストレベルで行うテストに利用します。

この２つのテスト方法を利用するには以下の条件があります。
  • テストにはPlayStoreアプリが必要になるため、実端末でしか行えない。
    （エミュレータ不可）
  • 端末はAndroid 1.6以上かつ、PlayStoreアプリのVersion 2.3.4以上が必要。
    Android 3.0の場合は、MyApps Version 5.0.12以上が必須環境となります。

テストできるアプリ内課金種類
　テストとして購入できるアプリ内アイテムは、「アプリ内管理アイテム(買切り型アイテム)」と、「消費するアプリ内管理アイテム」の２つです。「Subscription」のテスト購入はできません...残念。

サンドボックステスト
　予約されている所定のアイテムIDを使ってアプリ内課金処理の実装をテストできます。このテストでは、実装が正しくGoogle Playからのレスポンスを処理し、署名を検証できることを確認できます。

各予約済みアイテムIDを使用して購入リクエストを行うと、Google Playがそれぞれ特定のレスポンスを返してくれます。もちろん課金は発生しません。尚、このテスト方法では支払方法を指定することはできません。
また、サンドボックステストを行うためにAPKをアップロードしたり、アプリ内で販売するアイテムリストを公開する必要はありません。

予約済みアイテムID
サンドボックステストでは、以下４つの予約済みアイテムIDを使ってテストをすることができます。
  1. android.test.purchased
    購入成功レスポンスを返します。署名の検証テストのためにJSON文字列とレスポンスに署名が含まれています。
  2. android.test.canceled
    購入処理中にエラーが検知された・購入がキャンセルされた時のレスポンスを返します。これは登録されているクレジットカードが無効だった場合やユーザー操作により購入がキャンセルされた時に返されるレスポンスです。
  3. android.test.refunded
    払い戻されたときのレスポンスを返します。
    払い戻しはGoogle Play In-App Billingサービスから行うことはできません。 払い戻しは、販売者自身のGoogleWalletから行う必要があり、Google Walletから払い戻しが行われた 通知を受けた後、Google Playからアプリへ通知されます。
    払い戻し処理に関する詳細は、「 Handling IN_APP_NOTIFY messages 」と「 In-app Billing Pricing 」を参照してください。
  4. android.test.item_unavaliable
    リクエストされたアイテムIDが、公開しているアプリ内アイテムリストに存在しなかった場合のレスポンスを返します。
　いくつかの予約済みアイテムIDを使用したサンドボックステストでは、レスポンスに署名を返すことができます。レスポンスに署名含まれるパターンは以下の表のとおりです。

過去にAPKを公開済み APKをドラフトアプリとしてアップロード（非公開） アプリを実行しているユーザーアカウント レスポンスに署名が含まれるか？
No No Any 非署名
No No 開発者アカウント 署名
Yes No Any 非署名
Yes No 開発者アカウント 署名
Yes No テストアカウント 署名
Yes No Any 署名

サンドボックステストの手順
　サンドボックステストを行うために特別必要な手順はありません。
  1. テストする端末にアプリをインストールします。
  2. 開発者Google アカウントでログインします。
  3. テストする端末のPlayStoreまたはMyAppsアプリのバージョンが必要なバージョンであることを確認して下さい。
  4. テストするアプリで予約済みプロダクトIDを使用してアプリ内課金を行う。

実購入テスト
　サンドボックステストで動作確認がとれたら、実際にアプリ内購入を行ってテストしましょう。このテストは、アプリをリリースする前に、実際のGoogle Playと通信を行った本番環境で課金を行います。Google Walletにも課金処理が走りますが、予めテストアカウントを指定しておくことにより当該テストアカウントの取引を自動的にキャンセルすることで実際の課金無しに本番環境でテストすることができます。

Note:
実購入を行うテストアカウントは端末上に設定されている必要があります。端末に複数アカウントが設定されていた場合、アプリ内課金を行う際はダウンロードしたアカウントへ課金が発生します。ダウンロードしたユーザーアカウントが端末上に設定されていなかった場合は、メインのユーザーアカウントで購入しようとします。

※ここではGooglePlayのデベロッパーアカウントを持っている必要があります。デベロッパー登録には25US$を支払う必要があります。また支払のためのクレジットカードも必要です。

実購入テストの設定
『テストアカウント』の設定
　公開前のアプリをダウンロードし、実購入テストを行えるアカウントを設定する必要があります。テストアカウントの設定方法はデベロッパーコンソールにて以下の手順で設定します。 In-App Billing V3を利用している場合、ここで設定したアカウントだけがテスト購入できるアカウントとなります。
  1. 左メニューの「Settings」を選択します。
  2. 表示されたページ内の「Account details」を選択します。
  3. 表示されたページ内の「License Testing」セクションにある 「Gmail accounts with testing status」テキストボックスへテストアカウントとして設定するアカウントのGMailアドレスを入力してください。
  4. 入力後は、必ず「Saved」で保存してください。
設定完了後、15分以内に設定内容が反映されます。繁栄されればそのアカウントでドラフトアプリのアプリ内課金が利用可能になります。

※尚、テストアカウントに開発者アカウントは設定できません。
　（GoogleWallet上、自分から購入することができないため。）

Android端末に設定されているメインアカウントの変更方法
　公式的にはファクトリーリセット（工場出荷状態へ戻す）し、セットアップ時またはシステム設定から再度メインアカウントを登録する必要があります。端末によっては異なる方法でもできるという話がありますが、オフィシャル的にはこれが一番？みたいですので面倒でも課金処理周りですから手堅く一度リセットして設定しましょう。

実購入テストの実施
アプリ内課金の購入テストを行うには以下の手順に従ってください。
  1. テスト対象アプリのAPKファイルをデベロッパーコンソールへアップロードします。
    （未公開のままでOK）
    • アップロードするAPKファイルは、リリース用のKeyStoreで署名されている必要があります。
  2. アプリ内で販売するアイテムリストを作成・公開する。
    • アプリ内で販売するアイテムがデベロッパーコンソール上で「公開」状態になっていることを確認して下さい。
  3. Android端末にアプリをインストール
    • デベロッパーコンソールで設定したテストアカウントが設定されている端末へアプリをインストールします。
    • PlayStoreアプリ または MyAppsアプリのバージョンが最新または対応バージョンであることを確認して下さい。
  4. アプリ内でアイテムを購入する。（テストの実施）
※デバイスでテストするAPKとアップロードしたアプリのバージョンNo.は一致している必要があります。

　お金がらみの機能でバグ出すとレビュー欄が荒れるので、本番環境を使ってしっかりテストしたいところ。 欲を言えば、Subscriptionのテストが簡単にできる機能も欲しいところです。あっちのテストの方が色々面倒なんで。
投稿者 時刻: 0 件のコメント:
ラベル: , , , ,

2013年7月16日火曜日

ファイル共有サービス『CoreDrive』 レビュー

「ねこじゃらし」さんが提供しているファイル共有サービス「 CoreDrive 」を試してみたのでレビュー。

≪メリット≫
  • ブラウザ上で 様々な形式のファイル をプレビュー表示できる。
  • 期限やパスワードを設定して共有ができる。
  • ファイル別にメッセージをやりとりできる。
    これは少し斬新な機能かも。しかし、多人数でメッセージのやりとりが頻繁に行われた場合見辛くなること請け合い。
  • 専用Clientソフトが不要。全てブラウザより閲覧・アップロード可能。
    これは、DropboxやPogoplugなんかでも同じですね。 ただ、スマートフォンからの操作であれば専用アプリがあった方が操作性が良いと思います。
  • facebookアカウントでの共有が可能。

≪デメリット≫
  • (無料プランの場合) １ファイルの最大容量に250MB制限が付き、
  • (無料プランの場合) アップロードファイル数の制限が50ファイルまで。
  • 通知メールがうざい。
    ボード(ファイルを区分するためのフォルダ的なもの)の 新規作成、リネーム、削除、ボードへの他ユーザーの招待、 招待のキャンセル、参加拒否、ボードからの脱退といった アクションでメールによる通知が行われる。 メールの振り分け設定で処理しておかないと すぐにメールであふれてしまう。 この設定は今のところ変更できない模様。
  • 現段階で、iPhone/スマートフォンの専用アプリがなくスマホでもブラウザからアクセスすることになるが、サイトを表示してみてもスクロールなどが不自然でかつ、表示崩れを起こす場面もあり使い勝手に少々難あり。

≪総評≫
現段階では、Dropbox, SugarSyncやPogoplugといったメジャーなクラウドストレージサービスには及ばないものの、 PicasaやFlickrより限定的に、かつ写真や動画以外のドキュメントを共有したい場合には有効なサービスなのではないでしょうか。

利用シーンとしてパっと思いついたのは、イベントなどで限定された期間内で参加メンバーへ告知・資料を公開する場合です。イベントなどでは期間や参加者が限られるので、パスワードをメンバーに伝達しておき公開しているボードの期限をイベント期間で限定してしまえばイベント後にはアクセスできなくする事ができて便利です。

逆に、ビジネスシーンでこのサービスを利用しようとはあまり思えないのも事実。
有料会員になっても、共有ファイル数が10倍にしかならない。ファイル容量が無くても１カウント取られるのが痛いです。

受けた印象としては、現段階ではビジネスでゴリゴリ使うというよりも、 SNSの機能の拡張としてこのサービスを利用するのがいいのかなと感じました。
年内にはwindows、OSX、iOSやAndroidなどに対応した クライアントが出てくるらしいので今後に期待。
投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2013年7月12日金曜日

Subscription - In-App Billing

前回の「In-App Billing Version 3 概要」の続きで、In-App BillingにおけるSubscriptionについての記事です。技術的な話というよりもSubscriptionを売るときに考えなきゃならない事がメインです。公式サイトのSubscriptionページを解釈して書いてます。

Subscriptionって？
定期的（毎月または年間）に自動更新され課金が発生するアプリ内課金アイテムの種類です。有料会員用コンテンツへのアクセス権や、期間で課金したい機能などの販売に利用できます。

他のアプリ内課金アイテムと同様にアプリ内にて販売でき、もちろんアプリにて直接取引を行う必要はありません。GooglePlayがGoogleWalletを通して統一された課金手続きにより処理します。これは、ユーザーへ一貫した購入フローを提供するためです。

外部サービスのSubscriptionの使用
アプリ内に既存の外部サービスSubscription加入者を作成することもできます。
  • ウェブサイトなどで既にSubscriptionを販売していて、アプリからそのSubscriptionを購入しているかどうかを判断するためにアプリに独自のビジネスロジックを追加することができます。
  • 必要があれば、多くの異なるアプリ間で共有できる横断的なサブスクリプションも実装できます。例えばあなたの全アプリ、ゲームまたは他のコンテンツへアクセスするための月会費・年会費としてのSubscriptionを販売することも可能です。これを実装するためには、あなたのアプリにて有効なSubscriptionを判断しコンテンツへのアクセスを許可させるビジネスロジックを追加する必要があります。

販売者の責務
サブスクリプションの販売者は、ユーザーが有効なサブスクリプションによってコンテンツ・機能を利用する権利を有している限り該当コンテンツ・機能を提供し続けなければなりません。これを行わなかったり、有効なサブスクリプションやコンテンツ・機能を削除するなどして利用できなくした場合は処罰の対象となります。

詳細については、 公式サイトのポリシードキュメント を参照してください。

アイテムの属性設定
販売するSubscriptionアイテムはデベロッパーコンソールにて設定できます。Subscriptionアイテムには、以下の属性を設定できます。
  • 課金種別：Subscriptionに設定
  • Subscription ID：Subscriptionの識別ID
  • 公開状態：未公開／公開
  • 言語：Subscriptionを表示するためのデフォルト言語
  • タイトル：Subscriptionアイテムのタイトル
  • 説明：Subscrptionの詳細説明
  • 価格：１Subscription当たりの契約価格
  • 期間：毎月 or 毎年
  • 自動更新の可否：可／不可

デベロッパーコンソールのアイテムを追加して構成する方法の詳細は こちらの公式ページ を参照してください。

価格設定
Subscriptionの作成時に任意の通過で価格を設定できます。ただし、各Subscriptionは0以上の価格を設定する必要があります。また、同じコンテンツに対する価格の違う複数のSubscriptionも作成できます。
（例えば、年間購読の場合は毎月よりも割り引かれた価格を設定するなど）

【注意】
　Subscriptionの価格を変更する場合、新しい価格のSubscriptionを新規作成し、アプリでその新しいSubscriptionを提供するようにしてください。そうすることで既に購入しているユーザーは元の価格のSubscriptionで課金されたまま、新しいユーザーは新しい価格のSubscriptionで課金されます。

自動継続
Subscriptionは、デベロッパーコンソールにて以下のどちらかの期間で自動継続を設定できます。
  • 毎月―初回購入後、毎月購入日にSubscriptionを自動継続して課金します。
  • 毎年―初回購入後、毎年購入日と同じ日にSubscriptionを自動継続して課金します。
Subscriptionでは、設定した金額で無期限に自動継続されます。
Subscriptionが継続された時、GooglePlayがユーザーへ課金を行いメールでその旨を通知します。課金期間は購入日に基づいてSubscriptionの設定期間により計算されます。また、自動継続された際の請求は購入時と同じ支払方法になります。（クレジットカード支払やキャリア課金など）

試用期間
タダ(無料)で有料機能をお試しできる期間を設定することができます。
  • Subscriptionへ試用期間を設定するためにアプリを変更する必要はありません。デベロッパーコンソールのSubscriptionアイテムの設定で試用期間を設定することができます。
  • 試用期間を設定する場合、最低でも7日以上の日数を設定する必要があります。
  • 設定した試用期間を過ぎた場合、自動的にそのSubscriptionは設定されている本来の金額で契約されます。
  • 販売者は、いつでもSubscriptionの試用期間を変更できます。しかし、既に試用期間中のSubscriptionを持っているユーザーに対しては期間の変更は適用されません。
  • 試用期間はSubscriptionアイテム毎に個別に設定できます。
試用期間は0円の課金を行うことで実現しています。試用期間中は無料なので請求は発生しませんが、GooglePlayが0円のSubscriptionを購入したことをユーザーへ電子メールで通知します。

ユーザーは必要があれば任意のタイミングでSubscriptionをキャンセルできます。

解約について
In-App Billing APIに解約機能はありません。よってアプリ内からSubscriptionの解約は行えません。Subscriptionの解約は、PlayStoreアプリから行います。

解約されたSubscriptionの扱い

有効期間中にユーザーがSubscriptionを解約しても、払い戻しはされません。
その代りに、キャンセルされても購入したSubscriptionの期間が終了するまでキャンセルされたSubscriptionであっても有効なままとなります。

いくつかのケースでは、解約のためにユーザーが直接連絡する必要があるケースがあります。また、必要に応じてサーバーAPIを使用して直接ユーザーのSubscriptionをキャンセルすることができます。

アプリのアンインストール
ユーザーがサブスクリプションを購入したアプリをアンインストールしようとした場合、PlayStoreアプリが有効なサブスクリプションが存在することをユーザーに通知します。
  • ユーザーがアプリのアンインストールを続行した場合
    • アプリは削除されますがサブスクリプションは有効なまま課金も継続されます。（※アプリのアンインストール時に自動的にサブスクリプションがキャンセルされませんのでご注意ください。）
  • ユーザーがアンインストールをキャンセルした場合
    • アプリとサブスクリプション両方とも残ります。
※ユーザーは、PlayStoreアプリのMy Apps画面よりいつでも関連するサブスクリプションをキャンセルすることができます。

払い戻し
　Google Playでは払い戻し画面を用意していないので、返金を要求する場合は直接連絡を頂く必要があります。払い戻しの要求を受けた場合、そのユーザーのサブスクリプションをキャンセル、または既にキャンセルされている事を確認する為にサーバーAPIを使用できます。

しかし、GooglePlayはキャンセルされたサブスクリプションにおいても期間中はサブスクリプションが有効であるとみなしている事に留意してください。サブスクリプションをキャンセルし払い戻されたユーザーであってもそのキャンセルされたサブスクリプションの期間中はコンテンツへのアクセスができます。

【重要】
キャンセルされたサブスクリプションの一部払い戻しは、現時点で対応していません。


取引手数料
  • 一般にGooglePlayの条件は、GoogleWalletの標準的な支払方法を通じてのみアプリ内サブスクリプションを販売できます。
  • GooglePlayに公開するアプリにおいて、サブスクリプションを販売するためにはIn-app Billingのトランザクションを処理する必要があり、GooglePlayとアプリの外での購入手続きへのリンクを提供することはできません。条件とポリシーに関する詳細については、 公式サイトのポリシー を参照してください。
  • サブスクリプションの購入にかかる取引手数料は一般的なアプリ内課金の手数料(取引金額の30%)と同じです。

注文番号
特定Subscriptionの取引を追跡するために、GoogleWalletは全ての基本マーチャント注文番号を再発行を提供します。 以下のように基本注文番号の末尾に整数を付加することによって、連続したSubscriptionの取引を表します。 
12999556515565155651.5565135565155651 (基本販売者注文番号)
12999556515565155651.5565135565155651..0 (初期購入注文ID)
12999556515565155651.5565135565155651..1 (最初の定期的購入注文ID)
12999556515565155651.5565135565155651..2 (2回目の定期購入注文ID)
Google Playの注文コードフィールドに注文番号が含まれています。
In-App Billing Version 3では、INAPP_PURCHASE_DATA JSONフィールドに、Version 2では、PURCHASE_STATE_CHANGED に含まれています。

購入トークン
Subscriptionの支払がGoogle Walletで承認された後、In-App Billing APIを通じてGooglePlayから購入トークンを取得できます。

この購入トークンは、デバイス上に保存したり、バックエンドサーバへ渡すことができ、Google Playが提供しているHTTPベースのAPI "Purchase State API " を利用してバックエンドサーバからリモートでサブスクリプションを検証したり、キャンセルするために利用できます。

以上。
投稿者 時刻: 0 件のコメント:
ラベル: , , , , , , ,

2013年7月4日木曜日

In-App Billing Version 3 概要

いまさら感はありますが、Google Play Store アプリ内課金サービスである In-App Billing Version 3でSubscriptionが対応された為、おさらい的にOverviewから自分なりの解釈を加えて説明資料を残しておきます。

Google Play Store In-App Billing とは
Android アプリに対して課金機能を提供するAPI。
  • Play Store アプリを経由しGoogle Walletを通じて課金処理を行ってくれます。 さらに、アプリ内で購入するための決済処理UIも提供してくれます。
  • 課金する商品（アイテム）の設定を行うための管理機能は、 デベロッパーコンソール（ http://play.google.com/apps/publish ）にて提供されています。
  • ※ Developer Consol への登録はアプリを公開したりするサイト・サービスです。 登録には25 USドルが必要になります。
Version 3 の新しい機能
  1. 購入情報がキャッシュされるようになった
    • Play Store アプリが端末内で購入情報をキャッシュするようになりました。
      これで、購入情報取得リクエスト時にすごい待たされることもなくなる？
  2. やっと Subscriptionに対応した
    • Version 3 の新機能というよりは、最近(?)やっとついた機能です。
      Version 3 が出て暫く経っても Subscriptionに関してはVersion 2でしか 対応してなかったのですが、対応されたようです。よかったよかった。。。

取り扱える課金種類
In-App Billing サービスを利用して販売できるアイテム種類は以下の３つです。
基本、AmazonのIn-App Purchasingと変わりませんが、少々取扱いが違います。 　
  • アプリ内管理アイテム
    1. 非消費型-アプリ内管理アイテム
      買い切り型アイテム。 広告非表示機能とか有料版アップグレードなどの類のもの。 買ったらその機能を使用する権利を永続的に保持できるアイテム。
    2. 消費型-アプリ内管理アイテム
      使ったらなくなるアイテムのことです。 例えば、ゲーム内の通貨や燃料、行うごとに課金されるコンテンツなどが該当します。 アイテム数もGoogle Play サーバ上で購入した数を管理しており、 消費する際には消費することもGoogle Playへ通知する必要があります。
  • サブスクリプション
    毎月または年間期間単位で、アプリ内のコンテンツ、サービス、または機能を 販売することできるアプリ内課金アイテム種別の１つです。
    他のアプリ内管理アイテムと同様に、デベロッパーコンソールから サブスクリプションアイテムを設定して、アプリ内から販売できます。

一般的なアイテム購入までの処理フロー図
公式サイトの説明から少し独自に変えてあります。
  1. バージョン確認リクエスト
    端末にインストールされているPlay StoreアプリがIn-App Billing API Version 3に 対応しているか確認するために、”isBillingSupported()”リクエストを送信します。
    リクエストが成功した場合、サポートしている or 非サポートの情報を返します。

  2. 購入情報取得リクエスト
    ユーザーの購入履歴や購入情報詳細を照会するには、"getPurchases()"リクエストを送信します。 リクエストが成功した場合、Google Playから「レスポンスコード」、「購入済みアイテムのリスト」、 「購入情報リスト」、「署名リスト」、「トークン情報」を含むバンドルを返します。

  3. アイテム詳細取得リクエスト
    デベロッパーコンソールで設定した、アプリ内で購入可能なアイテムの詳細を Google Playを通して取得できます。アイテムのIDを指定して"getSkuDetails()"リクエストを送信し、 成功するとGoogle Playはアイテムの「タイトル」、「説明」、「アイテム種別」、 「価格」を含むバンドルが返します。

  4. 購入リクエスト
    購入手続きUIを起動するためのインテントを取得するため、 購入対象となるアイテムのIDを指定して、"getBuyIntent()"リクエストを送信します。 リクエストが成功するとGoogle Playから、アイテム購入用UIを起動するための Pending Intentを含むバンドルが返されます。

  5. 購入用UI起動～購入手続き
    • [4.購入リクエスト]で取得したアイテム購入用UIを起動します。
      購入処理はPlay Storeアプリにて行われるので、 アプリは"startIntentSenderForResult()"メソッドでこのインテントを起動し、 購入処理結果を、"onActivityResult()"で受け取る必要があります。
    • "onActivityResult()"へ返される情報には、購入された/キャンセル、 エラーが発生したを示すレスポンスコード、購入詳細情報、 開発者の秘密鍵で署名された購買データの署名が含まれます。
消費可能アプリ内管理アイテムの消費処理フロー図
消費可能アイテムの所持数(購入された数)は、Google Play にて管理しています。
アイテムの使用（プロビジョニング）する前に、Google Playに消費リクエストを送信しアイテムが正常に消費されたことを確認する必要があります。
この手順は、消費リクエストを送信する前にアプリが停止してたり、ネットワーク接続待ちをしている可能性があるため事前に必要です。

...とりあえずここまでが概要です。次はSubscriptionについて書きたいと思います。
投稿者 時刻: 0 件のコメント:
ラベル: , , , , ,
登録: 投稿 (Atom)