前回、前々回とアプリ内課金の購入編とリストア編を取り上げてきました。

次はキャンセルの場合の処理です。WiFiCutterでは、購入したら別にキャンセルはできないのでいらんかなーと思っていたんですが、どうもクレジットカードがなんらかの原因で使えない場合はキャンセルが発生することがわかりました。
それが発生して教えてくれたのがtwitterで仲のよいフォロワーさんだったので助かりました。

やっぱりキャンセル処理も必要だなぁということで、実装してみました。例によって、テクブ本ベースです。まずは、静的なアプリ内課金テストを行ないました。Activityから注文処理を呼び出します。そのときに渡すアプリ内サービスIDを、テスト用のandroid.test.canceledにしておきます。

// paidはPreferencesオブジェクト
paid.setOnPreferenceClickListener(new OnPreferenceClickListener() {

    public boolean onPreferenceClick(Preference preference) {

    // キャンセルのテスト
    if (!mBillingService.requestPurchase(TEST_PURCHASE.CANCELED)) {
        Toast.makeText(WifiCutterPreferences.this,
            R.string.no_connected,
            Toast.LENGTH_LONG).show();
    }
    return true;
}

これを実装すると、偽物の購入画面が現われます。偽物のカードを選択して、購入を押すと、擬似的に購入処理が走りますが、キャンセルの疑似処理なので、キャンセルが発生します。

購入を押すと…

上の画像のように、注文が失敗します。これでキャンセルのブロードキャストが発生します。
PURCHASE_STATE_CHANGEDでJSONが送られてくるのですが、ordersのJSONArrayの中の注文処理のpurchaseStateが1になっています。purchaseStateは、0が購入、1がキャンセル、2が購入の払い戻しのようです（2は試してないけど）

{
    "nonce":******************************,
    "orders":[
        {
            "notificationId":"android.test.canceled",
            "orderId":"transactionId.android.test.canceled",
            "packageName":"com.okolabo.android.wificutter",
            "productId":"android.test.canceled",
            "purchaseTime":1321622270724,
            "purchaseState":1 // キャンセル
        }
    ]
}

BillingService.javaの、purchaseStateChangedメソッドで、購入もリストアもキャンセルもやることになります。テクブ本のサンプルだと、vp.purchaseStateの値をチェックしていないので、なんでも購入処理になってしまうので、vp.purchaseStateを比較して処理を分けます。

また、テクブ本ではメソッドの最後にPurchaseController.purchaseComplete();を実行していましたが、購入時とキャンセル時で表示されるトーストを変えるために、最後ではなくorder毎の処理の際にメッセージを出すようにしました（まぁ自分のアプリの場合は1注文しかないからという算段ですが。あまりよくないかも）。それに合わせて、PurchaseStateを引数に持たせるようにコールバックメソッドを修正しています（別に見習わなくてもいい部分です）

あ、PurchaseStateはテクブ本のConsts.java内に定義されているenumです。

// BillingService.java
    private void purchaseStateChanged(String signedData, String signature) {
        ArrayList<Security.VerifiedPurchase> purchases;

        // 受信したトランザクション情報の整合性を検証する
        purchases = Security.verifyPurchase(signedData, signature);
        if (purchases == null) {
            return;
        }

        // トランザクション情報を処理する
        ArrayList<String> notifyList = new ArrayList<String>();
        for (VerifiedPurchase vp : purchases) {
            if (vp.notificationId != null) {
                // トランザクションごとに通知IDを保持する
                notifyList.add(vp.notificationId);
            }
            // 制限を外す
            if (vp.productId.equals("android.test.canceled")) {
                if (vp.purchaseState == PurchaseState.PURCHASED) {
                    Log.d(TAG, "purchaseState == purchase");
                    purchase();
                } else if (vp.purchaseState == PurchaseState.CANCELED) {
                    Log.d(TAG, "purchaseState == cancel");
                    purchaseCancel();
                } else if (vp.purchaseState == PurchaseState.REFUNDED) {
                    Log.d(TAG, "purchaseState == refunded");
                    purchaseCancel();
                }
                // 画面の更新とトーストによる通知を行なう
                PurchaseController.purchaseComplete(vp.purchaseState);
            }
        }

        // トランザクション情報を取得できた場合は、CONFIRM_NOTIFICATIONSリクエストを送信する
        if (!notifyList.isEmpty()) {
            String[] notifyIds = notifyList.toArray(new String[notifyList.size()]);
            confirmNotifications(notifyIds);
        }
    }

purchaseStateの値を比較して処理を変えています。purchaseメソッドとpurchaseCancelメソッドはBillingService.java内に定義した購入処理とキャンセル処理です。これで、購入、キャンセル、リストアとある程度はできるようになるんじゃないかと思います。

一通り動作を確認したら、Activityの購入処理で渡していたアプリ内サービスIDをandroid.test.canceledから正規のIDに変更しておきましょう。これで、あとはマーケットに載せてテストアカウントでテストしてみて、大丈夫だったらOKです。

アプリ内課金のテスト方法についても説明してありますので、よかったらテクブ本を手に取ってみてください！(^O^)

Tweet

前回、Androidのアプリ内課金の購入編を書きました。
今回は、リストア編です。

アプリ内課金の課金アイテムは2タイプあります。

• Googleアカウントに紐づいて1度だけ購入するタイプ
• 何度でも購入できるタイプ

WiFiCutterで実装したのは、1度だけ購入するタイプです。このタイプの場合、1度買っていると、また買おうとすると「もう購入済みだよ！」と怒られてしまいます。WiFiCutterの初回リリース時点では、全然気にしてなかったのですが、twitterのフォロワーさんから、他の端末に入れたら買えないって言われたよと指摘を受けたので、リストアに挑戦することにしました。

で、リストアってどのタイミングで、どんな風に処理するのかが全然わからない。テクブ本にも載ってない…。Googleのサンプルを見たら、アプリの初回起動時にリストア処理をしていたので、初回起動かどうかのフラグを持っておいて、そのときのみ行なうのがよさそうです。
今回はテクブ本のソースに追加する形で実装したので、ソースを載せておきます。

リストアの場合は、Android Marketアプリに対して、RESTORE_TRANSACTIONSのリクエストを送ります。これは、ユーザの今までのアプリ内の購入履歴を問い合わせるためのリクエストです。今までの購入履歴を受け取り、それを元に、復元したりするわけですね。
RESTORE_TRANSACTIONSの場合は、ノンスが必要なので、ノンスを設定します。

BillingService.java内で実装したRestoreTransactionsクラス

/***
 * RESTORE_TRANSACTIONSリクエストを送信する
 */
class RestoreTransactions extends BillingRequest {
    long mNonce;

    @Override
    protected long run() throws RemoteException {
        // ノンスを生成する
        mNonce = Security.generateNonce();
        // 基本Bundleを作成する
        Bundle request = makeRequestBundle("RESTORE_TRANSACTIONS");
        request.putLong(Consts.BILLING_REQUEST_NONCE, mNonce);
        // MarketServiceに送信する
        Bundle response = mService.sendBillingRequest(request);
        // リクエストIDを返す
        return response.getLong(Consts.BILLING_RESPONSE_REQUEST_ID,
                Consts.BILLING_RESPONSE_INVALID_REQUEST_ID);
    }

    @Override
    protected void onRemoteException(RemoteException e) {
        super.onRemoteException(e);

        // 例外が発生したらノンスを削除
        Security.removeNonce(mNonce);
    }
}

// RESTORE_TRANSACTIONSリクエストを処理する
public boolean restoreTransactions() {
    return new RestoreTransactions().runRequest();
}

これを、Activity側のonCreateなど初回起動時に呼び出すわけですね。
適当なActivityのonCreateで初回だけ呼び出します。

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        SharedPreferences preferences = PreferenceManager.getDefaultSharedPreferences(this);
        // 初回起動か確認
        boolean isFirst = preferences.getBoolean("is_first", true);
        if (isFirst) {
            Editor editor = preferences.edit();
            editor.putBoolean("is_first", false);
            editor.commit();
            // まず、既にアプリを購入済みか確認する
            mBillingService = new BillingService();
            mBillingService.setContext(this);
            mBillingService.restoreTransactions();
        }
    }

これを呼び出したら、マーケットからPURCHASE_STATE_CHANGEDで購入履歴が送られてきます。形式は、購入時のJSONとほぼ同じですが、RESTORE_TRANSACTIONSの場合、notificationIdがありません。
notificationIdは、「購入によるアプリ側の処理がちゃんと行なわれた」ということをマーケットに通知するためのものなのですが（CONFIRM_NOTIFICATIONSで）、RESTORE_TRANSACTIONでは既に一度購入処理を行なっているので、マーケットに処理がうまくいった事を通知する必要がないので、ありません。

追記：実際に送られてきたJSONを書いときます。
（一部塗りつぶしてますが）

{
    "nonce":**************************,
    "orders":[
        {
            "orderId":"********************",
            "packageName":"com.okolabo.android.wificutter",
            "productId":"hoge",
            "purchaseTime":1321026274058,
            "purchaseState":0
        }
    ]
}

ordersがJSONArrayになっているので複数の購入履歴が一度に取れます。

PURCHASE_STATE_CHANGEDが送られた場合の処理は、既に実装済み（のはず）なので、あとは自動的に購入時の処理が行なわれます。何度でも購入できるアイテムなどの場合は、orderIdを比較するなりして、アイテムが増えないようにするべきでしょう。

テクブ本はタブレットアプリ開発ガイドと銘打っていますが、アプリ内課金などスマートフォン向けの実装も説明してあるので、ためになると思います（宣伝）！！

Tweet