2013年8月1日木曜日

Android 4.3 と 開発者ツールのアップデート

　Android Jelly-Beanが4.3へアップデートされてました。
新しいNexus7に搭載積まれるらしいですが、既存Nexus (4/7/10)とGalaxy Nexus HSPA+にも既にアップデート展開されているようです。

　アナウンスでは、新しいAndroid 4.3 (コードネームはJelly-Beanのまま)と、開発者ツールであるAndroid NDK (R9)、旧バージョンのAndroid OS搭載端末へ新しいバージョンの機能をサポートするためのAndroid Support Library (R18)もリリースされました。（気が付けばAndroid SDK Managerにアップデートが通知されてました。）

　NDK(R9)には、Android 4.3で追加されたOpenGL ES 3.0 API と Android 4.3 API へのネイティブアクセスがサポートされたようです。
また、気になるSupport Library (R18)ではついにAction Bar APIがサポートされました。これでAndroid 2.1端末においてもAction Barが使えるようになりますか。え？もうAction Bar Sherlockで実装してるから要らない？

　その他トピックとしては、RTL言語のテキスト処理をサポートするBidiFormatterユーティリティの追加、ViewPager初期レイアウト処理時処理変更、同じくViewPagerが誤ってTYPE_VIEW_SCROLLEDイベントを取りこむ問題の修正、DrawerLayoutとSlidingPaneLayoutにてプロジェクトコードが編集されている間、例外を投げないよう修正、ExploreByTouchHelperの追加、Google Cast 開発者向けプレビューのサポートをする新しいV7 mediarouter Libraryの追加、RenderScriptのAndroid 2.2サポート...etc　まぁ色々機能修正・強化されましたと。サポートライブラリがあると、どうしても下位互換を考えなければならなくなるのである程度切ってくれてもいいんですがね。
肝心のAndroid 4.3は何が新しくなったかというと、大きくは以下の点が新しくなったとのこと。

  • OpenGL ES 3.0のサポート
    より綺麗な2D＆3Dグラフィックスを使ったゲームを作れるようになりましたと。
    GLSL ESシェーディング言語の新バージョン、高品質ETC2/EACテクスチャ圧縮...etc。NDK(R9)から利用できます。 端末のグラフィックスハードウェアに依存するので注意が必要との事です。使う予定はありませんが。

  • Bluetooth SMART のサポート
    低消費電力通信規格「Bluetooth Low Energy」に対応。
    最新のAndroid (4.3のこと) を実行しているBluetooth Smart Ready対応端末では、事実上全てのBluetooth対応製品と互換性があるってことになるらしい。前から持ってたキーボードやヘッドフォンから、Pebbleなどのスマートウォッチまで対応できると。
    bluetooth.comにも記事が掲載されています。
    Blutooth SmartのネイティブサポートがAndroid 4.3に組み込まれているから 開発者はリソースと開発時間を節約するために単一のAndroid Bluetooth APIを利用できる。

  • 制限付きプロファイルのサポート
    タブレット用のマルチユーザー機能にさらに、制限付きプロフィールがサポートされました。
    所有者（管理者？）が、ユーザーに対してきめ細かい制限をかけることができるようになりました。 例えばアプリの課金機能は子どもに使わせない...とか。
    もちろんアカウントの権限管理は法人顧客相手にも有用な機能なので、今後は権限を意識したアプリ開発も必要になるということですね。

  • 最適化された位置情報とセンサー
    Google PlayサービスのロケーションAPIを最適化し、バッテリー使用量を最小限にしました。
    • ハードウェアジオフェンシング
      デバイスのハードウェアで位置測定を行います。ソフトウェアでの位置計測に比べて電力効率が良くなります。 デバイスが移動中の場合などに、Google PlayサービスのロケーションAPIはこの最適化を活用して バッテリー消費を抑えます。（要対応ハードウェア）
    • Wi-Fiスキャン専用モード
      バッテリー節約と位置精度向上のために、Wi-Fiネットワークに接続せずにスキャン状態を保つことができます。 位置情報サービスのためにWi-Fiに依存するアプリはユーザーにこの設定を有効にするよう依頼することができます。 このWi-Fiスキャン専用モードはハードウェア依存しないAndroid 4.3プラットフォームの機能です。

  • 新しいメディア機能
    • Modular DRM Framework
      Modular DRM Frameworkの追加により、簡単に独自ストリーミングプロトコルをMPEG-DASHに統合することができる。
    • VP8 Encoder
      内臓されているVP8エンコードフレームワークへネイティブAPIからアクセスできるようになりました。
    • サーフェスからのビデオエンコーディング
      OpenGL ES surfaceからのストリームをバッファコピーすることなく直接エンコーダーに送れる。
    • メディアマルチプレクサ
      Mpeg4-Audio StreamとVideo Streamを1つのMpeg4に結合する新しいメディアマルチプレクサのAPIが使用できる。
    • リモートコントロールクライアント
      Android 4.0以降メディアプレイヤーと同等のアプリケーションは、 デバイスロックスクリーン、ノティフィケーションおよびBluetooth機器から リモートコントロールクライアントを通じて再生コントロールができましたが、 これからはリモートコントロールクライアントを通して、再生中のプログレス表示と特定の再生位置に ジャンプするコマンドを受け取る事ができるようになりました。

  • 美しいアプリケーションを構築する為の新しい方法
    • Notificationへのアクセス
      新しいAPIを使ってアプリがユーザーパーミッションを得てnotificationのストリームを観察し、 Bluetooth機器にnotificationを表示するなど、ユーザーが望む任意の方法でnotificationを通知することができます。 また、ユーザーはアプリがnotificationへのアクセスの有効・無効を任意に切り返ることができます。
    • オーバーレイの表示
      基礎レイアウト構成を乱すことなく透明なオーバーレイをトップビューおよび ビューグループの上に一時的に作成することができます。 もういちいち透過Activityで表示しなくてもいいってことですかね。
    • Optical boundsレイアウトモード
      新しいレイアウトモードです。
    • カスタム回転アニメーションタイプ
      デバイスを回転させたときのウィンドウのアニメーション種類を定義できます。 jump-cut、cross-fade、または標準のウィンドウ回転のいずれかをウィンドウプロパティに設定できます。 ウィンドウはフルスクリーンで、他のウィンドウに覆われていない場合に指定されたアニメーションを使用します。
    • スクリーンオリエンテーションモード
      端末が回転している場合にアプリが適切な向きで表示されているか確認するためのに Activityに新しいOrientationモードを設定できます。他にも、アプリは現在の向きに画面をロックするための 新しいモードも使用することができます。これは、ビデオを撮影しながら回転を無効にしたいカメラを使 用したアプリケーションの場合に便利です。
    • クイックレスポンスを処理するインテント
      任意のアプリでクイックレスポンスを処理できる新しいPublic Intentが導入されました。
      クイックレスポンスとは、電話に出たり、端末のロック解除をしなくてもテキストメッセージで応答できる機能です。 このメッセージングを任意のアプリで行うことができるようになりました。 アプリは、Intentを監視し、メッセージングシステムを介して発信者へメッセージを送る事ができます。

  • インターナショナルユーザーのサポート
    RTL言語に関する機能が改善され、サポート範囲が広がったと。詳細は省略。
    Support LibraryにもRTL言語のサポートが入ってたのでより国際言語対応しますという流れなのでしょうか。 開発者向けオプションの疑似ロケール機能を使って、簡単に違う地域のロケール・言語をエミュレートできるので ローカライゼ―ションテストに役立ちます。

  • アクセシビリティ と UIオートメーション（自動化）
    Android 4.3以降、キーボードショートカット、ジェスチャー入力によるナビゲーションなどの重要な イベントをアクセシビリティサービスで監視し、フィルタリングすることができます。 サービスでは、システムまたは他のアプリへイベントが通知される前に必要に応じて処理を行うことができます。 Android 4.3のAccessibilityフレームワークに構築された新しいUI自動化フレームワークは、 ユーザーの操作をシミュレートし、画面内容のプロパティを取得することによってデバイスのUIとやり取りを行うことができます。 UI自動化フレームワークを使用すると、基本的な操作、画面の回転、入力イベントの生成、スクリーンショットの取得など 多くの操作を行うことができます。 これは、複数のアプリケーションにまたがるアクションまたは処理手順を含む 実際のユーザーシナリオを想定したテストを自動化するためのパワフルな方法です。

  • エンタープライズとセキュリティ
    • WPA2-エンタープライズネットワーク向けのWi-Fi設定
      WPA2エンタープライズアクセスポイントへ接続するために必要なWi-Fiの資格情報を設定することができるようになりました。
      開発者は、企業内で使用される認証方式のための拡張認証プロトコル(EAP)とカプセル化されたEAP(Phase2)認証情報を設定する ための新しいAPIを使用することができます。 Wi-Fiへのアクセスと設定を変更するパーミッションを持つアプリは、 EAP(Phase2含む)認証方式の様々な認証資格情報を設定することができます。
    • SELinuxでAndroid sandboxの強化
      UIDベースのアプリケーションサンドボックスを強化するためにSELinuxの Linuxカーネルの強制アクセス制御 (MAC:Mandatory access control)システムを使っています。 これは、潜在的なセキュリティの虚弱性に対してOSを保護します。

  • キーチェーンの機能強化
    ルート証明書の管理を行う KeyChain APIが機能強化されました。

  • Android Keystore Provider
    APIを使用して、アプリがユーザーとの対話なしに他アプリや他ユーザーから使用されないキーを作成、 保存しキーストアに追加することができます。キーストアは端末外へのエクスポートはできません。

  • アプリからのsetuidを制限
    /systemパーティションはzygote -spawned processesによりnosuidにマウントされており、 アプリからのsetuidコマンドの実行を防ぎます。 これは、潜在的なセキュリティの虚弱性によるrootへの攻撃を減らします。

  • 新しいパフォーマンス解析ツール
    • Systraceの機能強化
      アプリのパフォーマンスを解析するために、より多くの情報を収集することができるようになりました。 ガベージコレクション、リソースの読込やその他ハードウェア、カーネル、Dalvik VMからのトレースデータを収集できます。
    • GPUプロファイルの画面表示
      開発者向けオプションから設定を変更することにより、GPUのプロファイルを画面に表示できます。

  • StrictMode warning for file URIs
    アプリ間で ”file://”プロトコルを使ってファイルを共有させようとした場合、 適切な権限がないと警告されるようにポリシー制約が変わったようです。
    アプリ内で"file://"って使うの普通？
　記事が長くなってしまいましたが、機能強化、セキュリティアップデート、利便性向上…と純粋なアップデートだったと思います。
画面の2D&3D描写の改善や、タッチ時の処理速度低下の低減など、ユーザーが直に触れる部分も改善されているようなので今後のAndroidに益々期待です。

尚、記事内で内容に間違いがあった場合はご指摘頂けると大変助かります。
誤字脱字の指摘も大歓迎です。
投稿者 時刻: 0 件のコメント:
ラベル: , , ,

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 件のコメント:
ラベル: , , , , ,

2013年6月4日火曜日

Amazon Android アプリストアがオープン

　今日（2013/6/4）より、Kindle Fire / Kindle Fire HD、PC、Mac、Android OS搭載のスマートフォン、タブレットからアプリやゲームを購入できる「Amazon Androidアプリストア」がAmazon.co.jp にてオープンしたとのこと。

以前より、Amazon.comなどでは展開されているサービスですね。

これでPCでAmazonアプリストアでアプリを探して購入しておけば、端末でも購入したアプリをインストールできるようになりました。やり方は…

  • Kindleなら
    • 「アプリ」から「クラウド」を開いてPCで購入したアプリをタップでアプリをインストールできます。
  • Androidなら
    • 「Amazonアプリストア」アプリで、メニューボタン→「マイアプリ」画面を開き
      「クラウド」を選択、アプリの横に表示されるダウンロードボタンをタップしてインストールが可能。（※表示されない場合は「リフレッシュ」をタップして再読込を行う。）

　開発者的には、PCからでも見れるから「Amazon.co.jp」を訪れる多くのお客様に売れるようになったということとと、Amazonアプリストアの自分のアプリ詳細ページへのリンクすることができるようになりました。

PC・ブラウザ用のアプリ詳細ページへのリンクURL

  http://www.amazon.co.jp/gp/product/[ASIN番号]/ref=mas_pm_[アプリ名]

ちなみに Amazonアプリストアで開けるURL...

  http://www.amazon.com/gp/mas/dl/android?p=[パッケージ名]&ref=mas_pm_[アプリ名]
（ブラウザで開いたらAmazon.comの商品詳細ページに飛んでしまいましたが、アプリで開くと日本語のアプリ詳細ページが表示されました。）

※ASIN番号 (Amazon Standard Item Number)：商品を識別する10桁の番号

詳細は、Trademark Guidelines の "Linking Instructions" に記載されています。

Amazonアプリストア…流行るかなぁ？
投稿者 時刻: 0 件のコメント:
ラベル: , , , , , ,

2013年5月31日金曜日

無料のGitプライベートリポジトリが利用できる "gitBREAK"

　株式会社ビズリーチが提供しているcodebreak;(コードブレイク)にて、Gitリポジトリの無料ホスティングサービス「gitBREAK」サービスを提供開始したとの事で早速登録してみました。

codebreakサイトURL（http://www.codebreak.com/)

■すごいところ：

  • プライベートリポジトリが無料
  • プライベートリポジトリの数が無制限
  • 共有可能ユーザー数も無制限
  • サイトが日本語

無料でプライベートリポジトリが作れるサービスとしては、
Bitbucket (http://www.atlassian.com/ja/software/bitbucket/overview) 
もありますが、こちらは 無料プランだと共有できるユーザーは5人までの制限が付きます。

無料で制限なしなんて素晴らしいサービスだ！
などと浮かれて登録したら思ったよりゴールまでの道のりが長く大変でした。

注意点としては、この「gitBREAK」は "codebreak;"のサービスの一環であるということ。

codebreak;（コードブレイク） とは...
　『コードブレイクは、IT・Webエンジニアのコラボレーションを支援する、エンジニア限定のサイトです。』 （コードブレイクのページ (https://www.codebreak.com/contents/about/) より引用）
要約すると、職業としてのプログラマやシステムエンジニアなどのIT屋さん限定だとのことです。

　私はcodebreak;を利用するのが初めてなので、codebreak;のアカウント作成から行ったのですが、gitBreakのフル機能を使うには、アカウントにレジュメを入力しなければならないとのこと。
　そのレジュメを記入した上で審査され、審査通過して初めて上記の素晴らしい無制限サービスを享受できるのです。レジュメの審査には３営業日程かかるとのことですが、レジュメの審査が通らない内は以下の制限付きサービス内容で我慢するしかありません。

■レジュメ審査通過前のサービス内容

  • パブリックリポジトリ数：無制限
  • プライベートリポジトリ数：１個　-->レジュメ承認されたら無制限に
  • 使用可能容量：200MB　-->審査後も変更なし。

　このレジュメ入力作業が大変です。特に職務経歴書の形式がここと違った場合、転職活動する気分でレジュメを再作成していくことになります。これがとても面倒です。

そしてここまで来て気が付きました。「容量：200MB」だということに。
足りない…。そこは無制限じゃないんだ。。。
Bitbucketは容量無制限なので気にしていなかった。

どうもこの使用可能容量を増やすためには 100MB増やす為に１人の codebreak;への招待が必要だという記述があります。（最大紹介数10人 = 100MB x 10人 = 最大1GB 増やせる。）
この招待は、した側もされた側も両方に100MB入るのとのことです。

■結論

　確かに0円でプライベートリポジトリを作成できます。ただ、Bitbucketのソレとは明らかに何か違う「無料」でした。 「0円でGitリポジトリを複数持ち、かつ大勢のユーザーと共有したい。でも公開はできない。」という場合は今のところgitBREAK一択なのではないでしょうか。しかし、いかんせん容量が小さいのがネックです。（招待できる人がいるなら別ですが。。。）
投稿者 時刻: 0 件のコメント:
ラベル: , , , , , , , , , ,
登録: 投稿 (Atom)