Google Developers Japan: 3月 2016

Google Play でゲームビジネスを成長させる：ゲームのパラメータ管理、動画の録画、ストリーミングへの広告掲載など

2016年3月30日水曜日

[この記事は Google Play ゲーム、プロダクトマネージャー、Morgan Dollard による Android Developers Blog の記事 "Grow your games business on Google Play: Game parameters management, video recording, streaming ads, and more" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
Read More

世界 190 か国からアクセスしてくるモバイルゲーマーに支えられ、Google Play ゲームを通して、活発で多様性にあふれたコミュニティが誕生しました。プレイヤーのエンゲージメント（ゲームの滞在時間）は、伸びる一方です。インストール数が 100 万を超えたゲームの本数は、この 1 年で 50％増となっています。

先日開催された「ゲームデベロッパーズカンファレンス」（GDC）の「デベロッパーズデイ」で、私たちはここで、あらゆる規格の端末に対応する、開発者向けの新しいプラットフォームと広告ツールを発表しました。世界中から集まったこのカンファレンスの参加者に情報を届けることで、ゲーム業界の成長を加速させることが狙いです。ゲームデベロッパーがアプリを構築し、ユーザーベースを拡大させて収益を伸ばすのを支援するための全機能を、以下で詳しく説明します。

Google Play ゲームをプレイヤーにとって、より楽しい場所にする

今年 2 月、私たちはゲーマー ID を導入しました。プレイヤーの皆さんがゲーム上の「ペルソナ」を作って保存できるようにするためです。また、Google Play ゲームのサインインプロセスも簡素化して、プレイヤーの皆さんが、より早くゲームにアクセスできるようにしました。さらにゲームのソーシャル機能をより強化してもっと楽しいものになるよう、プロダクトの改良にも取り組んでいます。より多くのプレイヤーがより長くゲームを続けたくなるような改良を目指しています。その一例として、「ゲーマーフレンド」の仕組みがあります（近く開始予定です）。Google Play のゲームアプリの中から、プレイヤーが友人を招待したり交流したりできるようになります（Google+ アカウントは必要ありません）。

さらに Google Play 上の新しいコレクション、「インディコーナー」も始める予定です。これは独立系のデベロッパーが開発した、すばらしいゲームを取り上げて紹介するコーナーです。独立系デベロッパーが作ったゲームで、このコーナーで取り上げてほしい、すごいものがあったら、ぜひ g.co/indiecornersubmission にアクセスして教えてください。私たちは、ゲームの操作体験の質と、そのデベロッパーの Google Play ゲームサービスの利用状況が他の模範となるかどうかを検討し、紹介に値する最高のゲームを選びます。

Google Play ゲームサービスの強力な新機能でゲームをさらに成長させる

今年の 1 月、私たちは Google Play ゲームサービスに関する無料のレポートツールである Player Analytics の新しい機能を公開しました。これによってプレイヤーの進行、購入、ゲームからの離脱などの状況を把握できます。本日は、向こう数か月以内に公開予定の新しいツールについて、その一部を先取りして、以下に紹介します。

ゲームパラメータの管理： ゲームパラメータの管理について、ゲームの進行状況やゲーム上でやり取りする通貨などのパラメータを更新する際、APK に変更を加えたりアプリを再度提出したりする必要はありません。デベロッパーコンソールまたは Google Play Developer API から、仮想グッズや仮想通貨を最適化することができるようになります。

Google Play のデベロッパーコンソールを使ったゲームパラメータの管理

ビデオ録画 API： アプリ画面の録画が簡単にできるようになります。ごく簡単な手順で、録画を YouTube に投稿して友達とその動画を共有することもできます。また、ライブストリーミング機能も追加する予定です。したがって、皆さんの華麗なプレイを YouTube からリアルタイムで放送することもできるようになります。

予測アナリティクス： Player Stats API に予測アナリティクス機能が追加されたので、どのグループのプレイヤーが頻繁に購入しているか、ゲームから離脱しそうなグループはどれか、などの状況を把握できます。また、新しい予測機能が、近日中に追加されます。向こう 30 日間に購入が見込まれるプレイヤーの人数と、そのプレイヤーが多額の購入をする確率です。この予測が可能になると、予測によって特定したプレイヤーについて、購入額やエンゲージメントが増えるように、エクスペリエンスをあらかじめ微調整することもできるようになります。ここから

Player Stats API の情報を入手してください。

「ユーザーの画面に広告を表示しなければ、アプリ内課金（IAP）トランザクション数が、15% は増加するのではないか」– Avetis Zakharyan、Underwater Apps CEO

広告のフォーマットとターゲットを一新して上質のゲーマーを特定、維持、収益化する

ゲームをアピールしてユーザーをとにかく増やすことは大切です。しかし肝心なのは、あなたのゲームのファン、つまり、そのゲームに何度もアクセスしてプレイを続けてくれる人たちを増やすことです。そこで本日私たちは、ゲームデベロッパーの皆さんがアピールの規模を拡大して、簡単にゲームのファンを増やせるように、新しい機能を発表しました。

お試しプレイ検索広告： 私たちは数週間後に、ユーザーにあなたのゲームを試用プレイしてもらう新しい方法を公開する予定です。これは新しい広告のフォーマット、「お試しプレイ検索広告」（Search Trial Run Ads）で、Google 検索でゲームを検索したときに有効になります。検索結果上で [TRY NOW] をタップすると、そのゲームを最長 10 分間プレイすることができて、ゲームを気に入った場合はフルバージョンをダウンロードできます。この広告は、スマートフォンユーザーが WiFi 接続しているときだけ表示されます。このフォーマットを使うと、インストール後に長時間ゲームを楽しんでくれそうなユーザーをインストールに誘導することができます。

SGN 社のゲーム「Panda Pop」のお試しプレイ検索広告

横長画面対応の動画広告： Google ディスプレイネットワークでモバイルアプリに表示される動画広告の 80% 以上は縦長画面で表示されますが、実際の広告は横長画面用に制作されている場合も珍しくありません。私たちは数週間以内に、横長画面のフルスクリーンで長所を最大限に活用する、横長画面対応の動画広告を公開します。横長画面対応の動画広告を導入すると、クリックスルー率もコンバージョン率も大幅に向上することがわかっています。これによってインストール 1 回あたりのコストが下がり、より多くのインストールにつながります。
ゲームサービスのアクティブユーザーのターゲティング： 数週間以内に、Android アプリ向けに、新しいタイプのユーザーターゲティングを展開する予定です。直近の 30 日間にゲームを 30 分以上プレイしたユーザー、またはGoogle Play ゲームを導入しているゲームをプレイしたユーザーを対象として、広告を表示できるようになります。

AdMob を使ってゲームの収益を増やす

AdMob とは、アプリ内広告によって世界中のゲームデベロッパーが収益を最大化するのを支援する仕組みです。私たちは GDC で、AdMob メディエーションによって収益を増やすのを支援する、新しい方法を発表しました。報酬付き広告という手法は、ゲームの収益化を実施する際によく使われるものの 1 つです。ユーザーは、広告を見るのと引き換えに、アプリ内で何かの報酬を得ます。AdMob メディエーションを使うと、多数の広告プロバイダーが提供している報酬付き動画広告をアプリに導入できるので、あなたのアプリを簡単に収益化することができます。現在までにサポートしているネットワークやプラットフォームには、AdColony、AppLovin、Chartboost、Fyber、Upsight、Vungle などがありますが、これ以外にも随時続々と追加されています。

この件および広告に関する詳細は Inside AdWords ブログでご覧ください。

以上の取り組みは、私たちの今年 2016 年の計画のうち、ほんの一部に過ぎません。皆さんが以上のツールを活用してゲームを改善することで、より多くのユーザーを引き付け、事業と収益が拡大することを私たちは願っています。

Posted by Khanh LeViet - Developer Relations Team

Chrome 50 ベータ版: プッシュ通知の改良、宣言型プリロードなど

2016年3月29日火曜日

[この記事は通知の騎士、Peter Beverloo と Nicolás Satragno による Android Developers Blog の記事 "Push notification improvements and declarative preload" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、Mac、Windows 向けの最新の Chrome ベータ版に適用されます。

プッシュ通知の改善

サイトからプッシュ通知を使って、ネイティブアプリケーションと同じ方法でシステムレベルの通知をトリガーできるようになりました。プッシュ通知の初期バージョンでは、サーバーからの通知に対し、Service Worker が自ずから情報を取得することが前提でした。この仕様は、複数のメッセージが飛び交っている場合や、デバイスのネットワーク接続が不安定な場合にはうまく機能せず、問題の原因となっていました。最新バージョンの Chrome では、サイトで通知データのペイロードをプッシュメッセージに含むことができるようになるため、サーバーの確認は不要になります。ユーザーのプライバシーを保護するため、プッシュ通知のペイロードは暗号化しなければなりません。プッシュ通知のペイロードは Push API 仕様の一環であり、Firefox では既にサポートされています。

ペイロードに加えて、サイトはユーザーが通知をクローズしたことも検出できるようになります。これによってアナリティクスの精度が向上し、複数デバイスでの通知削除ができるようになりました。また、通知の外観を細かく設定できます。たとえば、カスタムのタイムスタンプや通知アクションのカスタムアイコンの設定などです。さらに通知の更新時に、デバイスがその通知を音やバイブレーションで知らせるか、無音のままにするかを指定することもできます。

Chrome 50 では、通知アクションにカスタムアイコンを使用できるようになりました

宣言型プリロード

ウェブページの中には、Chrome が複数の場所からリソースを読み込まないと、完全な形で表示できないタイプのものがあります。たとえば、サイズの大きな JavaScript ファイルには特殊なスタイルシートが必要な場合がありますが、その場合 Chrome 側では、いったん JavaScript を実行してみないと CSS も読み込む必要があるかどうかわかりません。Chrome では <link rel='preload'> 属性がサポートされます。今後デベロッパーは、あらかじめダウンロードしておくリソースを指定できるようになったので、ユーザーが意味の分かる状態のコンテンツを表示するまでの時間を短縮できます。

Chrome 50 でプリロードを実行してページを読み込んだ状態（左）と、プリロードができない Chrome 49 でページを読み込んだ状態（右）

今回のリリースに追加されたその他の機能

HTMLMediaElement.play() は promise を返すようになり、自動再生が失敗しても対処しやすくなりました。
HTMLCanvasElement.toBlob() を使って、canvas 要素の画像を BLOB ファイルとして保存できるようになりました。
Chrome で ImageBitmap オブジェクトの作成をサポートします。これによって canvas 要素へ非同期で迅速に書き込むことができるようになりました。
AbsoluteDeviceOrientation でデバイスの向きの絶対値を取得できるようになり、これまでの DeviceOrientation は磁力計を使わない相対値を返すようになりました。これで、VR で頭の動きを追跡する際、近くにある金属物によってずれが発生するのを防ぐことができます。
DOMTokenList に「サポートトークン」機能が追加されました。これによってデベロッパーは、サンドボックスオプションやリンクの関係が含まれている要素を検出できるようになりました。
FormData オブジェクトはウェブフォーム用のデータをプログラムで作成するものですが、サイトでこれを使うと、値の書き込みだけでなくデータの精査や書き換えもできるようになります。
ES2015 Unicode の正規表現フラグ uがサポートされました。正規表現シンボルとして有名な @@match、@@replace、@@search、@@split のほかにこのフラグが加わり、デベロッパーは正規表現で、より精密なマッチングパターンを指定できるようになります。
サイトで音声や映像のストリーム再生が途切れないようにバッファを取得できる、SourceBuffer.mode 属性や「sequence」オプションがサポートされました。
プレゼンテーションの接続をより確実に制御できるようになる、PresentationConnectionCloseEvent と PresentationConnectionCloseReason がサポートされました。廃止予定の PresentationConnection.onStateChange の代わりに、これらを使ってください。
どこにもフォーカスが置かれていない状態でユーザーが Tab キーや Shift+Tab キーを押した場合、当該サイトでフォーカスが置かれるべき最初のターゲットをサイトで制御できるようになりました。
ウェブアニメーションの仕様への準拠度を改善するため、Cancel イベントと Animation.id がサポートされました。pause() はアイドル状態ではなく一時停止状態を利用します。なお、キーフレーム内のキー名にダッシュを許容する仕様は廃止予定です。
Web Audio の BiquadFilter ノードのパラメータ自動化は、これまで 128 フレームごとに評価していましたが、サンプルフレームが現れるたびに評価する仕様に変更されました。これによって、レゾナントフィルタの除去がより円滑になります。
Chrome は TLS バージョンのフォールバックのサポートを終了します。このバージョンのフォールバックを攻撃者が悪用すると、すべてのサイトに対して強制的に旧バージョンの TLS を利用させる設定に変更することができるからです。

細かな変更

Chrome の TLS で X25519 曲線がサポートされました。これによって、暗号化がより簡素かつ高速になります。
-webkit-background-composite は標準化の対象外になり、また利用度も低いため削除されました。
SVGZoomEvent は Chrome 上では何も動作をしませんが、より正確に仕様に準拠するため、廃止されました。
RTCPeerConnection のメソッドである createOffer() と createAnswer() は、promise ベースの実装を有効にするので廃止されました。
<link rel='subresource'> は、上記のとおり<link rel='preload'> で置き換えるので廃止されました。
XMLHTTPRequestProgressEvent は、より正確に仕様に準拠するため、ProgressEvent で置き換えられ、削除されました。
Document.defaultCharset 属性は、より正確に仕様に準拠するため、削除されました。
KeyboardEvent.prototype.keyLocation は、より多くのブラウザでサポートされている KeyboardEvent.prototype.location で置き換えられ、削除されました。
SVGElement.offset* メソッドは、より正確に仕様に準拠するため、HTMLElement 以外の全要素から削除されました。

Posted by Eiji Kitamura - Developer Relations Team

Android デベロッパーストーリー: Daeri Soft、Google Play ゲームサービスによって事業を世界規模に拡大

2016年3月28日月曜日

フリースタイル野球2 など、マルチプレーヤー対応のオンライン対戦ゲームで知られる韓国のゲームデベロッパー、 Daeri Soft は 2008 年に設立されました。今では 1 日当たりのダウンロード数が全世界で 1300 万回を数えるほどになりました。地域別の内訳は、15％がアメリカ、韓国、日本、台湾の 3 地域の合計が 28％となっています。

Google Play ストアでは表示アイコンの変更ができるので、Daeri Soft がストア内のアプリの表示方法を工夫したところ、アプリのダウンロード数が 200％以上増加しました。この成果について、同社の CEO である Dael Yu 氏が語った、こちらの動画をご覧ください。Dael Yu 氏はさらに、世界中のサーバーをサポートし、世界規模でプレーヤー同士の適切な組み合わせを実現できる機能を持つ Google Play ゲームサービスを同社がどう活用したかについても、詳しく語っています ...Read More

フリースタイル野球2 など、マルチプレーヤー対応のオンライン対戦ゲームで知られる韓国のゲームデベロッパー、Daeri Soft は 2008 年に設立されました。今では 1 日当たりのダウンロード数が全世界で 1300 万回を数えるほどになりました。地域別の内訳は、15％がアメリカ、韓国、日本、台湾の 3 地域の合計が 28％となっています。

Google Play ストアでは表示アイコンの変更ができるので、Daeri Soft がストア内のアプリの表示方法を工夫したところ、アプリのダウンロード数が 200％以上増加しました。この成果について、同社の CEO である Dael Yu 氏が語った、こちらの動画をご覧ください。Dael Yu 氏はさらに、世界中のサーバーをサポートし、世界規模でプレーヤー同士の適切な組み合わせを実現できる機能を持つ Google Play ゲームサービスを同社がどう活用したかについても、詳しく語っています。

Google ではデベロッパーガイド、Secrets to App Success on Google Play（Google Play でアプリを公開して成功を収めるための秘けつ）を公開しています。このドキュメントで Google Play ゲームサービスについての知識を深めて、あなたのゲーム事業の成長につなげてください。

Posted by Hidenori Fujii, Google Play

V8 で WebAssembly を試験運用開始

2016年3月24日木曜日

[この記事は WebAssembly カウボーイ、Seth Thompson による V8 JavaScript Engine の記事 "Experimental support for WebAssembly in V8" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

WebAssembly の包括的な概要と、将来コミュニティでどのようにコラボレートされるかについては、Mozilla Hacks ブログの記事「A WebAssembly Milestone（WebAssembly のマイルストーン）」を参照してください。

Google、Mozilla、Microsoft、Apple そして W3C の WebAssembly コミュニティグループは 2015 年 6 月以降、ウェブのための新しいランタイムおよびコンパイルターゲットである WebAssembly の設計、仕様決定、実装 [1][2][3][4] に精力的に取り組んできました。WebAssembly は、コンパクトなバイナリ形式でエンコードされるように設計された、低レベルでポータブルなバイトコードであり、メモリに影響を及ぼさないサンドボックス環境内でネイティブコードとほぼ同じ速度で処理されます。これまで築いてきたテクノロジーの進化を体現するものとして、WebAssembly はウェブプラットフォームと密接に統合されるだけでなく、ネットワーク経由のダウンロード速度を向上させ、JavaScript の低レベルのサブセットである asm.js よりも速くインスタンス化することができます。

3 月 15 日より、V8 JavaScript エンジンと Chromium プロジェクトで WebAssembly が利用できるように、試験運用機能として実験的にサポートが開始されました。V8 で WebAssembly を試すには、バージョン 5.1.117 以降の d8 を起動し、コマンドラインで --expose_wasm フラグを指定してください。または、Google Chrome Canary 51.0.2677.0 以降を起動し、chrome://flags#enable-webassembly と入力することで WebAssembly 実験機能をオンにする方法もあります。ブラウザを再起動すると、WebAssembly モジュールを生成して実行する API を公開する JavaScript コンテキストから、新規の Wasm オブジェクトが利用できるようになります。Mozilla および Microsoft の協力により、互換性のある WebAssembly が 2 種類実装され、Firefox Nightly および Microsoft Edge の非公開ビルドでそれぞれ動作します（下記に示したビデオのキャプチャ画像を参照してください）。

WebAssembly プロジェクトのウェブサイトでは、3D ゲームで使われるランタイムのデモが公開されています。WebAssembly をサポートするブラウザでは、デモページは WebGL やそれ以外のウェブプラットフォームの API を利用する wasm モジュールを読み込んで起動し、対戦型ゲームをレンダリングします。それ以外のブラウザでは、同じゲームの asm.js バージョンにフォールバックして動作します。

https://webassembly.github.io/demo/

V8 の WebAssembly 実装は内部的に、既存の JavaScript 仮想マシン（VM）のインフラ、特に TurboFan コンパイラーをできるだけ再利用するように設計されています。WebAssembly デコーダは特殊な設計となっていて、型チェック、ローカル変数のインデックス、関数の参照、戻り値、同一パス内の制御フローの構造でモジュールを検証します。その後、デコーダは TurboFan のグラフを作成しますが、このグラフはさまざまな最適化パスで処理され、最終的には、最適化された JavaScript と asm.js 向けのマシンコードを生成する同一のバックエンドによって、マシンコードに変換されます。今後の数か月で、チームはコンパイラーのチューニング、並行処理、コンパイル方法の改良など、V8 実装の起動時間の改善に集中して取り組む予定です。

当面のところ 2 つの変更が計画されていますが、これが実現すると、デベロッパーの操作が大幅に改善されるでしょう。WebAssembly は、一般的なテキストで表現されるため、デベロッパーは WebAssembly バイナリのソースを他のウェブスクリプトやリソースと同じ方法で参照することができます。また、現在プレースホルダーとして使われている Wasm オブジェクトの設計が一新されるので、JavaScript から WebAssembly モジュールを生成したり参照したりするための、より強力で慣用的なメソッドやプロパティを提供できるようになります。

V8 および WebAssembly チームは、安定したランタイムのリリースを目指して、前出のブラウザベンダーとの協力関係を今後も継続し、コミュニティを拡大させていきます。また、私たちは、将来の WebAssembly の機能（マルチスレッド、動的リンク作成、ガベージコレクションとファーストクラス DOM との統合など）の開発計画も立てており、また WebAssembly の LLVM バックエンドおよび Emscripten から C、C++、およびそれ以外の言語をコンパイルするためのツールチェーンも引き続き開発していきます。今後も設計や実装プロセスの改善を続けていきますので、時々確認してくだされば幸いです。

Posted by Yoshifumi Yamaguchi - Developer Relations Team

Apps Script のメールサービスに対する変更

2016年3月23日水曜日

[この記事は Google Apps Script プロダクトマネージャー、Saurabh Gupta による Google Apps Developers Blog の記事 "Change to Mail Service in Apps Script" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Apps Script でメールを送信するには、2 つの方法があります。1 つは MailApp の sendEmail メソッドで、もう 1 つは GmailApp の sendEmail メソッドです。この 2 種類のメソッドの違いの 1 つは、MailApp の sendEmail メソッドでは、デベロッパー自身が Gmail ユーザーでなくても使用できることです。たとえば、Google Apps を使っているので、Gmail ではなく Apps Script を代わりに使っているユーザーがいるとします。このユーザーは MailApp でメールを送信することはできますが、GmailApp で送信することはできません。

2016 年 9 月 13 日以降、一般の無料 Google アカウントを利用しているユーザー（コンシューマー）、Google Apps for Education のユーザー、および Google Apps（無償版）のユーザーが Apps Script のメールサービスでメッセージを送信する場合は、Gmail へのアクセスが必須となります。コンシューマーは、Google アカウントで端末にサインインすれば、Gmail を利用することができます。ただし、この場合、Gmail が Google アカウントのプライマリアドレスになることに注意してください。Google Apps ドメインの管理者（Google Apps for Education および無償版のみが対象）は管理コンソールを使って、ドメイン全体の Gmail を有効にすることができます。

この変更のために、既存のコードを更新する必要はありません。MailApp は引き続き利用できます。ただし、Gmail にサインアップしていることを確認してください。このような変更がデベロッパーに深刻な影響を及ぼす場合があることは承知していますが、デベロッパーの皆様に配慮しながら、変更プロセスを慎重に進めていきます。

Posted by Eiji Kitamura - Developer Relations Team

Google Cast 対応アプリケーションへのアナリティクスの導入

2016年3月22日火曜日

[この記事は Google Cast サーバー基盤チームのソフトウェアエンジニア、Chris Dolan による Google Developers Blog の記事 "Introducing Analytics for Google Cast Applications" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Cast 対応アプリケーションのデベロッパーである皆さんは、アプリケーションにアクセスしているデバイスの数、それらのデバイスが開始しているセッションの数、それらのセッションがコンテンツを再生する時間数などを把握したいと思うことがあるでしょう。その場合、これまでは、自力でその情報を得るための仕掛けを実装しなければなりませんでした。しかし、もうその必要はありません。上記のデータはすべて Google Cast デベロッパーコンソールから直接参照できるようになりました。

この機能を試すには、まず通常どおりにデベロッパーアカウントでデベロッパーコンソールにログオンします。[Applications] テーブルで、[Statistics] 列に追加されている [View] リンクをクリックしてください ...Read More

キャプション: アプリケーションのページでは、個々のアプリに対して [View] リンクが表示されるようになりました

アナリティクスページには、各メトリックへのタブ、時間の経過によるメトリックの値の変化を示すインタラクティブなグラフ、直近の 1 日のデータを示すテーブルなどが記載されています。[Devices] タブにはアプリを起動した Cast 対応デバイスの数、[Sessions] タブにはアプリの Cast セッションの数、[Avg. Playback] タブにはアプリ（*）の 1 セッションあたりのメディア再生時間の平均値がそれぞれ示されます。

アナリティクスページにはタブ、グラフ、データのテーブルが表示されます

各タブのデータは、総計、国別、送信者のプラットフォーム別などのように、値の尺度を変えて表示することができます。特定の国やプラットフォームの値を参照するには、テーブル上で参照したい列を単純にクリックします。各タブのデータは 1 日 1 回のペースで更新され、これらの値の総計は 1 週間（7 日）、2 週間（14 日）、4 週間（28 日）の周期で集計されます。集計の周期を切り替えるには、画面右上に表示されている期間ピッカーから使用する周期を選択してください。

皆さんがこうしたアナリティクスから、Google Cast アプリケーションの利用状況に関する知見を得て、アプリケーションの改善に活用されることを願っています。詳細については、デベロッパードキュメントを参照してください。
* メディアの再生機能がないアプリについては、メディア再生時間の平均値は表示されません

Posted by Eiji Kitamura - Developer Relations Team

Google Play で成功を手にする: アプリのデベロッパーがゲームから学べること

2016年3月17日木曜日

[この記事は Google Play 事業開発マネージャー、Matteo Vallone による Android Developers Blog の記事 "Find success on Google Play: What app developers can learn from games" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

（より多くのアプリデベロッパーに情報を伝えることで、Google Play でのビジネスを支援できるよう、この記事はこちらのウェブサイトで先行公開されました – Ed.）

フリーミアムアプリとゲーム事業の間には、事業として成功させるという点では、多くの共通点があります。しかしながら、コンソールゲームの歴史から、ユーザーはアプリよりゲームに支払いをすることに、より慣れています。さらにモバイルゲームでは、ユーザーに合わせて、幅広い価格設定の「仮想グッズ」を容易に提供できます。つまり、ゲームのデベロッパーは、どのようにユーザーの初期体験や、コンバージョン、生涯価値（LTV）を改善できるかを学ぶ機会がずっとありました。では、アプリのデベロッパーはゲームのデベロッパーから何を学べるでしょうか。成功したゲームのデベロッパーから得たベストプラクティスと知見の中で、アプリ開発でも大いに活用できそうなものをご紹介します。

ゲームのデベロッパーの手法を学んで、アプリも成功を目指しましょう。

1. 新規ユーザー獲得に投資する前に、ユーザー維持率を最適化する

ユーザー維持率は王様です。ユーザー維持率はコンバージョンの増加に寄与します。ゲームのデベロッパーにとって、ユーザー維持率は、ゲームの品質とゲームがユーザーにとって魅力的であるかの重要な指標です。

ほとんどの場合、ゲームのデベロッパーは、ベータテストのコミュニティやテスト用の市場で「先行公開」を実施します。このフェーズの間に、チュートリアルの完了率、難易度、コンバージョン数といった具体的な項目を詳しく調査し、ユーザー維持率を最適化するための調整を行います。Google アナリティクスのコホート分析レポートを使うと、デベロッパーはユーザー維持率を追跡することができます。ユーザー維持率が満足いくものになると、デベロッパーは本格的なアプリの公開に踏み切り、ユーザー獲得のための投資を開始します。

2. 徐々にエンゲージメントを高めユーザーを保つ

ユーザー維持には、インストール直後の 1 週間が最も重要です。ユーザーはたくさんのアプリをインストールして試し、最初の数日間で、どのアプリを使い続けるかを決めます。もし、その期間残ることができれば、あなたのアプリはユーザーが日々使うアプリの一部になる可能性が高いと言えます。

段階的にユーザーのエンゲージメントを高める、簡単な方法がいくつかあります。主要な機能を紹介することに加え、そのアプリがユーザーにとって、どれほど価値があるか説得力のあるストーリーを提示することが大切です。そして、見つやすい場所に、ユーザーがすぐに価値を感じる機能を配置します。

これは、すべての場合にあてはまる方法はでありません。適切なソリューションを見きわめるために、デベロッパーはまず、どのようなユーザーフローにすればユーザー維持率を高められるかについて仮説を立て、A / B テストを実行し、その仮説が妥当であるか、修正が必要があるかを確認する必要があります。たとえば、サインインの処理をユーザーフローの中で後回しにすれば、ユーザー維持率が高まると考えるかもしれません。しかし、同時に、長期間のエンゲージメントを判定する指標（アップロードされた写真や閲覧された記事の数など）が何かという点にも注意し、アプリ利用開始時のフローの変更が長期指標へ与える影響を測定するする必要があります。

通常、アプリの導入の最適化に着手する場合、次の原則がよいスタート地点になります。

煩雑な手順のセットアップをユーザーに強いるより、アプリをすぐに使ってもらえる方法を追求してください。
アカウントの登録、ビデオのアップロード、友達の検索など、「アクティベーションが必要な瞬間」は、少しずつ出すようにしましょう。
最初にユーザーに求めることは最小限にし、より細かいことはユーザーがアプリの機能を必要とした時に求めるようにしましょう。
パーミッションはユーザーに対するサービスとして扱いましょう。たとえば、ユーザーに登録をしてほしい場合には、先に、登録をすることでアプリからより多くの価値が得られることを示してください。そのようにすることで、ユーザー体験はより個人的なものとなります。

この例では、アプリ「OkCupid」でアプリへの導入フローをいくつか試した結果、最もエンゲージメントが高かったバージョンでは、7 日間ユーザー維持率が 20 パーセント以上も向上しました。

最後になりますが、ユーザーに購入を求める前に、ユーザーがアプリの価値を確実に理解できるようにしてください。ゲームのデベロッパーは、限られた日数または回数の中で製品の一部または全ての機能を、無料でユーザーに体験してもらう、ということをとてもうまく行っています。

Google アナリティクスのユーザーフローレポートは、ユーザーがアプリをどのように使っているか（または使っていないか）を分析する際にとても役立ちます。このレポートを使うことにより、ユーザーがアプリ内をどのような経路で利用し、どこで離脱したかを知ることができます。これにより、アプリ内の潜在的な問題点を見つけることができます。

3. 適切なユーザーに適切なサービスを提供する

ユーザーにアプリ内購入を促すための戦略を立案する際は、アプリ内の購買行動の違うグループを理解することが重要です。

まず、どのように購入を行うかと購入金額によって、ユーザーのグループを見分けるところから始めましょう。ユーザーの年齢別かもしれませんし、インストール時に利用するチャネル別、あるいはアプリ内の行動別かもしれません。こうしたユーザーグループの発見と定義には、Google アナリティクスのセグメントの作成を使います。次に、ユーザーにアプリ内購入を勧める内容とタイミングを、ユーザーの購買行動にあわせて調整します。たとえば、購入するユーザーの割合が高く、1 回の購入額も大きいけれども、購入頻度が低いという傾向があるグループに対しては、アプリ内の有料機能をバンドルするようにします。

4. ユーザーが購入する可能性が高い時にアプリ内購入を勧める

ユーザーが購入をする確率が高くなるのは、購入の操作がスムーズな場合、そして、購入によりどのように価値が増すかがわかる場合です。なので、次をお勧めします。

ユーザーが必要な時、または、欲しいと感じる時にユーザーに購入を促します。そして、なぜ購入することが妥当であるかを説明します。
購入の操作は、ユーザーがアプリの利用中に最小限のタップで完了できるように、できるだけ簡単な設計にしましょう。たとえば、適切な画面のフッターに「アップグレード」ボタンを追加します。

アプリ「TomTom」は、無料サービス期間が終了するまでのカウントダウンを追加しました（移動した距離でカウントされる）。カウンター画面には、ワンタップで有料機能にアップグレードできる、アプリ内購入のボタンが含まれています。

優秀なゲームデベロッパーと同様に、TomTom のデベロッパーは、テストと分析を絶えず繰り返し、ユーザーの心をつかんで離さないような優れたユーザー体験の構築を重視しています。第一印象は大切です。アプリ利用開始時に、ユーザーがすぐにアプリの重要性を理解し、簡単に使えるようにする必要があります。そして、収益を生み始める必要があります。アプリ内購入を実行しやすくすることに十分配慮することが肝心です。

私が「Google Playtime 2015」で開催したセッション「アプリに応用できるゲームのルール」（The rules of games, for apps）は、こちらからご覧になれます。このセッションではアプリのデベロッパーは、ゲームのベストプラクティスやデベロッパーの実例を学ぶことができます。

また、「Google Playtime 2015」の他のセッションでは、Google Play でビジネスを成功に役立つツールやベストプラクティスについてご覧になれます。

Posted by Ryuichi Hoshi - Developer Relations Team

Google Cloud Messaging: 現状のまとめ

2016年3月16日水曜日

[この記事はデベロッパーアドボケート、Laurence Moroney による Google Developers Blog の記事 "Google Cloud Messaging: State of the Union " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]Read More

[この記事はデベロッパーアドボケート、Laurence Moroney による Google Developers Blog の記事 "Google Cloud Messaging: State of the Union " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Cloud Messaging（GCM）は、複数種類のデバイスが混在する環境でのメッセージの送受信を実現する、シンプルで信頼性の高い基盤です。

Android 端末、iOS 端末、ウェブブラウザなど、さまざまなプラットフォームの端末に対して GCM が配信するメッセージの件数は、1 日当たり 1500 億件を超えています。メッセージの送信にあたっては、次のような多彩なテクニックが応用されます。

デバイスの均一化。端末はすべて、一意の登録トークンを持っているので、これで区別します。アプリからデバイスにアクセスする場合、たとえば GCM を使って 1:1 のチャットを行うアプリを構築したとすると、端末を特定する場面でこのトークンを使います。

デバイスのグループ化。これによって、複数種類の端末を 1 つのグループとして扱うことができます。近頃のユーザーは 1 人で複数種類のデバイスを所有していることが多く、たとえば携帯電話とタブレット端末を同時に使うというのは、ごく一般的なシナリオです。GCM のデバイスグループを使うと、あるユーザーが所有するすべての端末にメッセージを送信できます。また必要に応じて、端末のどれかでメッセージを却下すると、他でも却下される機能をアプリに実装することもできます。

トピック。これは、あるテーマに関心を持つユーザーをグループ化するものです。ユーザーが、あるトピックを購読するように端末を設定したとします。このとき、そのトピックに対してメッセージが送信されると、トピックを購読しているユーザーはそのメッセージを受信します。1 つのトピックを購読するユーザー数について、特に制限はないので、メッセージを送信する側は、そのメッセージを購読するユーザーの人数を意識する必要はありません。このブログの配信の際にも、ユーザーエクスペリエンスの向上を狙って、トピックを活用した優れたシナリオを複数採用しています。

メッセージ配信の信頼性については、Google 社内の調査によると、ほとんど（95％）の通知メッセージは、接続先のデバイスに 250 ms 以内に配信されていることが分かっています。ただし、ネットワーク接続は、携帯通信会社、ルーター、ローカルのネットワーク接続状況など、さまざまな要因の影響を受けます。実際に、帯域幅の費用を抑えるため、原則的に 1 日の中でごく限られた時間だけ携帯端末による通信を実行しているロケールも存在します。このシナリオに従う場合でも、ユーザーはデータ通信をリアクティベートしたタイミングで通知を受信することができます。

GCM を使ったアプリの構築を支援するためのリソースは、これまでにも多数公開しています。サーバーと接続する Android アプリを PHP で構築する手順を段階を追って説明している、このビデオをご覧ください。また、GitHub のこのページでは、オープンソースの「GCM Playground」を公開しています。これは Google Cloud Platform 上で稼働する、サーバーの実装のサンプルです。

また iOS ユーザーにもメッセージを届けられるように、クライアント側のコードを変更することなく既存の基盤を移行させ、iOS 端末に通知を送信する API を新たに公開しました。この新しいバッチインポート APIは、APNs のデバイストークンを iOS オーディエンスから集めて GCM にインポートし、GCM 経由で直ちに通知を送信するものです。さらに InstanceID API を使えば、APNs のデバイストークンをインポートしてから、GCM トピックを購読しているユーザーに対し、関心グループの情報に基づいて、通知を効率的に拡散させることもできます。そしてこの場合も、クライアント側のコードへの変更は一切不要です。

このプラットフォームの拡大と進化は今後も継続します。新しい機能が順次追加される予定ですのでご期待ください。

Android および iOS 向けのクイックスタートなど、Google Cloud Messaging の詳細は、こちらをご覧ください。

Posted by Yoshifumi Yamaguchi - Developer Relations Team

デベロッパー向け日本語 YouTube チャンネル "Google Developers Japan" のご紹介

2016年3月15日火曜日

Google Japan Developer Relations チームでは、デベロッパーのみなさまに役立つ新たな技術情報の収集チャネルとして、日本語専用の YouTube チャンネル Google Developers Japan を開設しました。ぜ ...Read More

Google Japan Developer Relations チームでは、デベロッパーのみなさまに役立つ新たな技術情報の収集チャネルとして、日本語専用の YouTube チャンネル Google Developers Japan を開設しました。ぜひチャンネル登録してお楽しみ下さい。

この YouTube チャンネルでは

Google Developers や Android Developers で公開された、既に日本語字幕の付いた英語の動画配信
日本語で制作された技術解説動画配信
イベントでの講演のライブ配信
イベントでの講演動画のアーカイブ配信

などを予定しています。また、今後制作される英語の動画についても、継続的に翻訳して配信していく予定です。

さっそく先日の Google for Mobile の講演動画を公開していますので、その中からいくつかご紹介します。

マテリアルデザインでよりよいユーザー体験を実現しよう

マテリアルデザインを活用することで、異なる端末間の画面に統一感が得られ、ユーザー体験が飛躍的に向上します。これにより収益の向上やアプリの改善が期待されます。マルチスクリーン時代のアプリデザインのポイントをマテリアルデザインの考え方とともに紹介します。

高品質 Android アプリ実装ヒント集〜ゴミアプリと言わせないために

Google Playではアプリの評価と収益性の相関は明らかです。ユーザーの高評価を得られるアプリとは。成功するアプリとは。ユーザー評価から問題点を取り上げ、具体的な資料とノウハウを混じえて解決策を提案します。

スマートフォン体験を一歩先へ〜プログレッシブウェブアプリの作り方

Chrome for Androidなどのモバイルウェブはアプリ以上に閲覧されています。ウェブの特性を生かしながらネイティブアプリに近いユーザー体験を提供するプログレッシブなウェブアプリの作り方をService Worker、Cache APIのプログラミング例を混じえて解説し、事例の解決策を提案します。

ユーザーとコンテンツの距離を縮めよう〜コンテキストアウェアなアプリケーション

コンテンツに達するまでのステップは１ステップ重なる毎に20%のユーザーが、ステップに要する時間が1秒を超えると更に離脱が始まります。ユーザーをつなぎとめるアプリにするため、ユーザーとコンテンツの距離を縮める手法をステップの高速化とプッシュ通知の活用の両面から解決策を提案します。

最後に、既にお気付きと思いますが、本日より本ブログのデザインも一新いたしました。デベロッパーのみなさまが日本語のブログおよび動画コンテンツで、効率的に新たな技術を学び、これまでよりさらに素敵なサービスを開発されるのを楽しみにしています。

Posted by Eiji Kitamura - Developer Relations Team

Google Play の評価・レビュー機能の新しいツールをご紹介します

2016年3月11日金曜日

[この記事は Google Play プロダクトマネージャー、Fergus Hurley による Android Developers Blog の記事 "New tools for ratings & reviews on Google Play to engage and understand your users" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

毎日、数多くのユーザーが Google Play でアプリの評価とレビューをしています。機能リクエストから技術的問題まで、評価とレビューからはユーザーが好むもの、好まないものについて豊富な情報が得られます。2013 年から、Google Play ではレビューに返信できるようになっており、アプリに強い関心を抱いているユーザーと直接やりとりするチャンネルになっています。デベロッパーからは、Android では他のプラットフォームよりも素早くユーザーフィードバックに対応できるため、このチャンネルは貴重だという声が届いています。アプリのエクスペリエンスを高め、評価点を高くできるように、Google Play デベロッパーコンソールにはこの数カ月で、評価やレビューの分析や管理を向上させる数多くの改善が行われています ...Read More

評価・レビュー機能の改善点

デベロッパーコンソールの専用ページ上で、評価とレビューを確認できる機能を追加しました。

Google Play デベロッパーコンソール上の新しい評価ページ

評価の時間変化の確認: 評価の日単位、週単位、月単位での変化を確認したり、アプリの新バージョンのリリースにともなう変化を簡単に見つけることができます。
評価の内訳: 国や言語、デバイスの種類、アプリのバージョン、Android のバージョンといった項目別に評価の内訳を確認できます。

Google Play デベロッパーコンソール上の新しいレビューページ

レビューのハイライト: ハイライト機能では、アプリのレビューに共通して書かれているテーマを確認できます。これは、Play Store でユーザー向けに表示されるハイライトと同じものです。レビューのハイライトは、十分な数のレビューがある場合に表示され、アプリの最新のユーザーエクスペリエンスを反映するよう、定期的に更新されています。
端末のメタデータ: ユーザーがレビューで言及している問題をより簡単に確認し、デバッグを行えるように、RAM や CPU、ディスプレイのサイズといったデバイス情報を確認できるようになっています。
レビューのテキスト検索: レビューのテキスト内を検索して、特定のトピックやキーワードについてユーザーがどう言っているかを確認できます。
レビューへの返信と更新: デベロッパーがレビューに返信すると、レビューを投稿したユーザーには電子メールで通知されます。また、ユーザーがそのレビューや評価を更新した際に、デベロッパーが電子メールで通知を受け取れるよう、事前に設定することも可能になりました。

評価やレビューを最大限に活用しているデベロッパーの事例

Aviary の Photo Editor は、シンプルさと直観的な使いやすさを重視した写真編集アプリです。Aviary は、評価・レビュー機能やその他の Android の機能を使ってユーザーとの定期的な対話を行いつつ、他のプラットフォームよりも 2 倍から 3 倍速いペースでビルドをリリースすることが可能になっています。

Glu Mobile は Racing Rivals や Cooking Dash 2016、そして近々登場する Taylor Swift といったゲームで知られるモバイルゲーム企業です。評価・レビュー機能は、Glu Mobile がユーザーを引き込み、フィードバックを集めて、ユーザー満足度を管理するのに役立っています。Glu Mobile の CEO の Niccolo de Masi は、「Google のレビューハイライト機能のおかげで、ゲームの機能の中でどんなものが好まれ、どんなものが好まれていないかかが一目でわかるようになりました。レビューの傾向をモニターし、通知に注意を配り、ゲームについてのレビューに返信するようにしています」と語っています。デベロッパーコンソールの評価・レビュー機能を活用するうえで、Glu Mobile が気をつけているポイントをいくつか紹介します。

レビューへの返信: Google Play デベロッパーコンソール上で、自分のゲームのユーザーレビューに返信します。返信する際には、ユーザーの問題解決の手助けをしたり、ユーザーからの機能提案を検討していることを伝えるようにします。前向きな対応を受けたユーザーは、評価点を上げる可能性があります。
検索機能の活用: すべてのレビューを対象にした検索機能が使えるようになっています。また評価点や言語、アプリのバージョン、デバイスの種類などさまざまな項目による検索フィルターを利用できます。この機能を使うと、たとえば、新たに追加したコンテンツに対するユーザーのフィードバックを探すことができます。
フィードバックへの対応: ユーザーからの返信があったり、レビューが更新された場合には、デベロッパーは通知を受け取れるようになっています。問題についての情報を得たらすぐに、改善に向けた作業を開始できます。ユーザーから好意的なフィードバックがあった場合には、コミュニティと協力して満足度の高いユーザーを自分たちのアプリのファンにしましょう。
時間変化の分析: ゲームをアップデートした場合にユーザー満足度がどの程度改善したかを詳しく知るために、評価の時間変化を分析します。この機能を使うことで、最近の機能アップデートやバグ修正がユーザー満足度の向上につながったかどうかが分かります。
重要なテーマの特定: Google Play では、ユーザーがゲームについて言及したレビューのハイライトが自動的に表示されます。これによって、短時間でレビューを分析し、ユーザーフィードバックを理解できます。

ユーザーとの関係性を深め、アプリを向上させるのにこうしたツールが役立つことを期待しています。評価とレビューの閲覧と管理について、より詳しい情報を知るにはデベロッパーコンソールのヘルプセンターをご覧ください。ビジネスの成功と成長に役立つツールやベストプラクティスについてさらに知るには、Google Play で The Secrets to App Success をダウンロードしてください。

Posted by Ryuichi Hoshi - Developer Relations Team

Android N デベロッパープレビューのご紹介：API とツールについて

2016年3月10日木曜日

[この記事は Dave Burke, VP of Engineering による Android Developers Blog の記事 "First Preview of Android N: Developer APIs & Tools" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

本日、次期 Android N のデベロッパープレビューを公開しました。例年とは異なり、今年はプレビューを大幅に早くリリースしました。「Work in Progress」版の公開を前倒しすることで、開発者からのフィードバックを取り込む時間をより多くするためです。またこれにより、今年の夏には端末メーカーに最終リリースを提供することが可能になるため、今まで以上に早く、最新の Android を搭載する新端末の開発をスタートできます。N リリースおよび新端末へ向けた、アプリ開発者の皆さまからのフィードバックをお待ちしております ...Read More

以下、本日公開の Android N デベロッパープレビューに含まれる機能のうち、一部の代表的なものをご紹介します。機能は今後も追加されていく予定です。

マルチウィンドウ

N 以降を対象としたアプリでは android:resizableActivity と呼ばれる新しいマニフェスト属性が利用可能になります。この属性を true にセットすることで、スマートフォンやタブレットで画面分割モードでアクティビティを起動することができるようになります。また、アクティビティの最低ディメンションを指定することで、ユーザーがそれより小さなサイズでアクティビティ画面を表示することがないように制限することができます。マルチウィンドウ環境でのライフサイクルの変更は、ランドスケープモードからポートレートモードに切り替える場合と同様です。加えて、テレビのようなピクチャーインピクチャーモードにすることができるため、動画を再生するアプリにも対応できます。これを利用する場合は android:supportsPictureInPicture を true にセットしてください。

ダイレクトリプライ通知

もともと Android Wear 向けに追加された RemoteInput notification API がスマートフォンやタブレットでも利用できるようになります。RemoteInput API を利用すれば、ユーザーは通知を離脱することなく、受信したメッセージに素早く、簡単に返信することができます。詳しくはこちらをご覧ください。

通知のグループ化

N では Notification.Builder.setGroup() メソッドを使って、例えばメッセンジャーアプリの個別のメッセージのような、同じアプリからの通知をグループ化できるようになります。グループ化された通知は 2 本指ジェスチャーや拡大ボタンを押すことによって、個別の通知に展開することができます。詳しくはこちらをご覧ください。

省電力化

待機中端末のバッテリー消費を抑えるため、Marshmallow において Doze モードを追加しました。N リリースにおける Doze モードは、さらにスクリーンオフ時のバッテリー消費も節約します。緊急度の高い通知に GCM の “High priority” メッセージを利用するなど、あなたのアプリが Doze モードに対応していれば追加で作業をする必要はありません。もしまだの場合は、こちらから始めて下さい。また N リリースでは、より多くのデバイスでスムーズに動作するよう、バックグラウンド作業の効率化によって使用メモリ量を抑える Project Svelte への注力を引き続き行っています。バックグラウンド作業に JobScheduler を利用している場合には問題ありませんが、もし、そうではない場合にはこの機会に変更を行ってください。また、開発者の皆さんをさらにサポートするため、JobScheduler の機能を強化しました。コンテントプロバイダーの変更に対応する際などには JobScheduler を利用できるようになります。

Java 8 言語をサポート

Android に Java 8 言語機能を追加します。Android の Jack compiler では、ラムダなどといった代表的な Java 8 機能の多くを使用することができ、Gingerbread までさかのぼった Android バージョンをサポートしています。新しい機能では、ボイラープレートコードを削減することができるようになります。たとえば、イベントリスナーを提供する際、ラムダで匿名の内部クラスを置き換えることが可能です。また、デフォルトの静的メソッドや Stream、関数型インターフェースといった Java 8 言語機能も N 以降利用可能になります。Jack では、Java 言語のトラッキングをより密接に扱い、後方互換性を高めていく予定です。

プレビューを試すには

N デベロッパープレビューには、正規版 Android エミュレーター、Nexus 6、Nexus 5X、Nexus 6P、Nexus Player、Nexus 9、Pixel C でのテスト用システムイメージを含むアップデート SDK が含まれています。

この最初のプレビューリリースはデベロッパーのみなさまのみを対象にしたものであり、日常的な利用やエンドユーザーの利用を想定したものではありません。N デベロッパープレビューシステムイメージは、当プレビュープログラム期間中に随時更新される予定です。また、最終版が近付きましたら、エンドユーザーのみなさまにもお試し頂けるようにする予定です。

また今回は、新しい Android Beta Program を使うことで、お持ちの開発用端末で N リリースをテストすることがとても簡単になります。本日より、g.co/androidbeta からお持ちの Android 端末を N デベロッパープレビューにアップデートすれば、以後継続して Over-the-Air（OTA）経由で更新を受け取ることが可能です。

N デベロッパープレビューについてより詳しくはこちらをご覧ください。より多くのご意見・ご要望を取り込めるようにするためにも、ぜひお早めに作業の開始、およびフィードバックのご提供をお願いいたします。

Posted by Eiji Kitamura - Developer Relations Team

Android Support Library 23.2 を公開

2016年3月9日水曜日

[この記事はデベロッパーアドボケート、Ian Lake による Android Developers Blog の記事 Android Support Library 23.2" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Android Support Library についてまず知っていただきたいことは、それが単一のライブラリではなくライブラリの集合体であることです。それぞれが後方互換性や追加の機能を提供しています。バージョン 23.2 では既存の多くのライブラリに新機能が追加され、またいくつかの新しいサポートライブラリも追加されました。

ベクタードローアブルとアニメーション付きベクタードローアブルのサポート

ベクタードローアブル ...Read More

ベクタードローアブルとアニメーション付きベクタードローアブルのサポート

ベクタードローアブルを使用すると、複数の PNG 画像のアセットを XML で定義された 1 つのベクターグラフィックに置き換えることができます。これまでは Lollipop 以降のデバイスでしか使用できませんでしたが、新しい 2 つのサポートライブラリ support-vector-drawable と animated-vector-drawable により、VectorDrawable と AnimatedVectorDrawable の両方が使用できるようになりました。

Android Studio 1.4 ではビルドの時点で PNG を生成することで、ベクター型ドローアブルを限定的にサポートしていました。サポートライブラリを活用して容量を節約するには、この機能を無効化する必要があります。そのためには、build.gradle ファイルに vectorDrawables.useSupportLibrary = true を追加します。

 // Gradle Plugin 2.0+  
 android {  
   defaultConfig {  
     vectorDrawables.useSupportLibrary = true  
    }  
 }

この新しい属性は、Gradle プラグインのバージョン 2.0 にのみ存在します。Gradle 1.5 を使用している場合は、代わりに以下を使用してください。

 // Gradle Plugin 1.5  
 android {  
   defaultConfig {  
     generatedDensities = []  
  }  

  // This is handled for you by the 2.0+ Gradle Plugin  
  aaptOptions {  
    additionalParameters "--no-version-vectors"  
  }  
 }

VectorDrawableCompat は API 7 以降、AnimatedVectorDrawableCompat は API 11 以降のすべてのデバイスで使用できます。Android のドローアブルのロード方法が原因で、ドローアブル ID を読み込む場所（XML ファイルなど）によっては、ベクター型ドローアブルをロードできない場合があります。しかし、AppCompat で新しいベクター型ドローアブルを使いやすくする多くの機能が追加されています。

まず、ImageView（または ImageButton や FloatingActionButton などのサブクラス）と AppCompat を使用すると、新しい app:srcCompat 属性を使用してベクター型ドローアブル（や android:src で使用できる他のドローアブル）を参照できます。

 <ImageView  
  android:layout_width="wrap_content"  
  android:layout_height="wrap_content"  
  app:srcCompat="@drawable/ic_add" />

また、実行時にドローアブルを変更している場合は、以前と同じ setImageResource() メソッドを使用できます。この点に変更はありません。ベクター型ドローアブルをアプリに統合するには、AppCompat と app:srcCompat を使用するのがもっとも確実です。

Lollipop 以前では、app:srcCompat の外側にあるベクター型ドローアブルは直接参照できませんでした。しかし、AppCompat では、StateListDrawable、InsetDrawable、LayerDrawable、LevelListDrawable、RotateDrawable のような別のドローアブルコンテナから参照されているベクター型ドローアブルをロードできます。この迂回方法により、通常はベクター型ドローアブルに対応していない TextView の android:drawableLeft 属性などにベクター型ドローアブルを使用できます。

AppCompat の DayNight テーマ

アプリ全体にベクターグラフィックを使用できるようになった点は AppCompat の大幅な変更点ではありますが、さらに本リリースでは、新しいテーマ Theme.AppCompat.DayNight も追加されました。

API 14 以前で DayNight テーマやその派生テーマ DayNight.NoActionBar、 DayNight.DarkActionBar、DayNight.Dialog などを使用すると、Light に相当するテーマのみが使用されます。API 14 以降のデバイスでは、アプリでこのテーマを使用すると、Light テーマと Dark テーマの両方を簡単にサポートできるようになり、「夜間」には Light テーマから Dark テーマに効率よく切り替わります。

デフォルトでは、「夜間」かどうかはシステム値（UiModeManager.getNightMode() から取得）と一致するかどうかで判断していますが、AppCompatDelegate のメソッドを使用すると、この値を上書きできます。静的メソッド AppCompatDelegate.setDefaultNightMode() を使用して（プロセスが再起動されるまで）アプリ全体にデフォルトを設定するか、getDelegate() から AppCompatDelegate を取得し、setLocalNightMode() を使用して現在のアクティビティまたはダイアログのみを変更することができます。

AppCompatDelegate.MODE_NIGHT_AUTO を使用すると、時刻や（アプリに位置パーミッションがある場合は）最後に取得した場所を使用して、自動的に昼と夜のモードを切り替えます。MODE_NIGHT_NO は Dark テーマを強制的に使用しないように設定し、MODE_NIGHT_YES は常に使用するように設定します。

色をハードコードすると、テキストやアイコンが見にくくなる場合も多いので、DayNight テーマを使用する際は、アプリを十分にテストする必要があります。標準の TextAppearance.AppCompat スタイルを使用してテキストや色をテーマから取得している場合（android:textColorPrimary など）は、使用しているテキストや色は自動的にアップデートされます。

ただし、夜間モード用に特別にリソースをカスタマイズしたい場合は、AppCompat は night 修飾子が付いたリソースフォルダーを使い回すようになっているため、必要なすべてのリソースをカスタマイズできます。標準色を使用するか、AppCompat の着色機能を活用すれば、このモードをもっと簡単に適用できるようになります。

Design サポートライブラリ: Bottom Sheet

Design サポートライブラリでは、さまざまなマテリアルデザインのパターンの実装を提供しています。本リリースでは、アプリに Bottom Sheet を簡単に追加できるようになりました。

BottomSheetBehavior を CoordinatorLayout の子 View に適用する（app:layout_behavior="android.support.design.widget.BottomSheetBehavior" を追加する）と、タップを検出して自動的に 5 つの状態間を遷移させることができます。

STATE_COLLAPSED: この折り畳まれた状態がデフォルトで、画面の最下部にレイアウトの一部のみを表示します。高さは app:behavior_peekHeight 属性（デフォルト値は 0）で制御できます。
STATE_DRAGGING: ユーザーが Bottom Sheet を上下に直接ドラッグしているときの中間的な状態です。
STATE_SETTLING: View のドラッグが終わってから最終的な位置が確定するまでの短い時間です。
STATE_EXPANDED: Bottom Sheet が完全に展開された状態で、Bottom Sheet 全体が表示されている（高さが CoordinatorLayout に含まれる高さ未満の場合）、または CoordinatorLayout が完全に Bottom Sheet で覆われているかのいずれかです。
STATE_HIDDEN: デフォルトでは無効化されており（app:behavior_hideable 属性で有効化できます）、有効化すると Bottom Sheet を下にスワイプして、完全に非表示にできます。

Bottom Sheet 内にスクロール可能なコンテナを配置する場合、ネストされたスクロールをサポートしているもの（NestedScrollView または RecyclerView など）である必要があります。

状態変化についてのコールバックは BottomSheetCallback を利用できます。

 // The View with the BottomSheetBehavior  
 View bottomSheet = coordinatorLayout.findViewById(R.id.bottom_sheet);  
 BottomSheetBehavior behavior = BottomSheetBehavior.from(bottomSheet);  
 behavior.setBottomSheetCallback(new BottomSheetCallback() {  
    @Override  
    public void onStateChanged(@NonNull View bottomSheet, int newState) {  
      // React to state change  
    }  
      @Override  
      public void onSlide(@NonNull View bottomSheet, float slideOffset) {  
       // React to dragging events  
   }  
 });

BottomSheetBehavior を使えば常に表示される Bottom Sheet を作ることができます。本リリースには BottomSheetDialog と BottomSheetDialogFragment も含まれており、モーダルな Bottom Sheet のユースケースに対応できます。AppCompatDialog や AppCompatDialogFragment を該当する Bottom Sheet 版に置き換えるだけで、ダイアログを Bottom Sheet スタイルに変更できます。

Support v4: MediaBrowserServiceCompat

Support v4 ライブラリは、サポートライブラリの大部分の基盤として機能します。このライブラリには（多くの独自機能とともに）新バージョンのプラットフォームで導入された多くのフレームワーク機能の下位実装も含まれます。

本リリースでは、以前リリースされた MediaSessionCompat クラスに MediaBrowserServiceCompat と MediaBrowserCompat を追加しており、さらに堅牢なメディア再生が可能です。これによって、最新 API（Marshmallow に追加されたものも含みます) の機能を提供する互換ソリューションが API 4 以降のデバイスすべてで使えるようになり、Android Auto での音声再生、Android Wear のメディアからの参照、メディア再生サービスと UI を結びつける標準インターフェースを簡単に提供できるようになりました。

RecyclerView

RecyclerView ウィジェットは、リストやグリッドの作成に役立つ高度で柔軟性の高い基本機能で、アニメーションもサポートしています。本リリースでは、LayoutManager API に面白い新機能が追加されました。それが、自動サイズ調整機能です。これによって、RecyclerView をコンテンツのサイズに応じてサイズ変更できるようになります。つまり、以前はできなかった RecyclerView の寸法値に WRAP_CONTENT を使用することができるようになっています。すべてのビルトイン LayoutManager が自動サイズ調整機能に対応しています。

この変更により、ご使用のビュー項目のレイアウトパラメータの再確認が必要となります。（スクロール方向の MATCH_PARENT など）以前は無視されていたレイアウトパラメータが反映されるようになっています。

ビルトインの LayoutManager を継承せず、カスタムの LayoutManager を使用している場合、これはオプトイン API になります。setAutoMeasureEnabled(true) を呼び出し、メソッドの Javadoc に詳しく記載されているとおり、細かな変更を加える必要があります。

RecyclerView は子要素をアニメーションさせますが、自分の境界の変更はアニメーションしません。RecyclerView の境界を変更した時にアニメーションさせたい場合は、Transition API を使用します。

カスタムタブ

カスタムタブを使用すると、アプリのルックアンドフィールを保ったまま、シームレスにウェブコンテンツに遷移できます。本リリースでは、ボトムバーにアクションを追加して、ウェブコンテンツとともに表示できるようになりました。

新しい addToolbarItem() メソッドを使用して、アクションをボトムバーに追加できます。追加できるアクションは、現在のところ、最大で 5 つ（MAX_TOOLBAR_ITEMS）までです。セッションの開始後には、setToolbarItem() でアクションをアップデートすることができます。以前の setToolbarColor() メソッドと同様に、setSecondaryToolbarColor() メソッドでボトムバーの背景色をカスタマイズできます。

Android TV の Leanback

Leanback ライブラリには、TV 向けに最適化された多くの標準コンポーネントが含まれており、簡単に Android TV 対応のアプリを作成することができます。GuidedStepFragment は本リリースで大幅に改善されました。

一番わかりやすい変更点は、アクションボタンに 2 列目が実装されたことでしょう（この列には、onCreateButtonActions() をオーバーライド、または setButtonActions() を呼び出してボタンを追加できます）。使用できる GuidedActions の一覧をスクロールしなくてもアクションを完了できるようになり、操作が簡単になりました。

GuidedActions については、多くの新機能が実装されています。たとえば、記述を編集できるようになり（descriptionEditable() を使用）、ドロップダウン形式でサブアクションを実行できるようになり（subActions() の使用）、GuidedDatePickerAction が導入されるなど、入力操作がかなり改善されました。

これらのコンポーネントを使えば、本当に必要なときにユーザーから情報を取得しやすくなります。

今すぐ入手

Android Support Library バージョン 23.2 は、SDK Manager および Android Studio から入手できます。すべての新機能と今後提供されるバグの追加修正をご活用ください。いつもどおり、バグレポートは b.android.com から送信してください。Android Development Google+ community に参加して、他のデベロッパーと交流してください。

Posted by Yuichi Araki - Developer Relations Team

analytics.js 向け Autotrack のご紹介

2016年3月8日火曜日

[この記事は Philip Walton、デベロッパープログラムエンジニアによる Google Developers Blog の記事 "Introducing Autotrack for analytics.js " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]Read More

[この記事は Philip Walton、デベロッパープログラムエンジニアによる Google Developers Blog の記事 "Introducing Autotrack for analytics.js " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Analytics 公開当初の頃と比べ、ウェブは大きく変化しました。当時は、ほとんどのウェブサイトは個別ページから構成されており、あるページから別のページに移動するためには、リンクをクリックしてページ全体をリクエストする必要がありました。そのため、ほとんどのサイトでは、JavaScript のトラッキングスニペットが 1 つあれば、大多数のユーザーの操作を追跡できました。

しかし昨今のウェブは、当時に比べるとずっと複雑で変化に富んだものになっています。旧来の静的なウェブサイトだけでなく、機能満載のウェブアプリケーションも存在します。ユーザーが実行する操作は、リンクのクリックやフォームの送信に限定されなくなり、「ページビュー」も、必ずしもページ全体を読み込むとは限らなくなっています。

ウェブがこのように変化を遂げる一方で、アナリティクスの実装はさほど変わっていません。Google Analytics ユーザーのほとんどは、デフォルトのトラッキングスニペットをコピーしてサイトのページに貼り付けるだけで満足しています。Google Analytics にはデフォルト以外の機能もたくさんあることは知っていながら、そういった機能を学ぶための時間はつい後回しになってしまうのです。

この問題への新たな解決策となるのが、analytics.js 向けの Autotrack です。Autotrack は、Google Analytics の機能を最大限に活用しますが、実装のための手作業は最小限で済みます。このツールは、今日のモダンなウェブのデータを追跡する基盤をデベロッパーに提供します。

機能

Autotrack ライブラリは、analytics.js プラグインの集合体であるため、ライブラリ全体をそのまま利用することも、必要なプラグインのみを選んで使用することも簡単にできます。以下のセクションでは、Autotrack が実現する機能をいくつか取り上げて説明します。

サイト外へのリンクとフォームの追跡

あるサイトで、ユーザーが別のページを指すリンクをクリックすると、通常はそのページが開いた際にページビューが送信されます。一連のページビュー情報が存在しているため、Google Analytics はユーザーが（どのページから）どのページに移動したのかをバックエンドで判断できます。ただし、ユーザーがクリックしたリンク先やフォームの送信先が外部ドメインだった場合、Google Analytics に対して個別に情報を提供しない限り、そのアクションは捕捉されません。

かつては、外部ドメインへのリンクやフォーム送信の追跡の実装は困難でした。ほとんどのブラウザでは、新しいページの読み込みを開始すると、現在のページ上の JavaScript の実行を停止するからです。Autotrack がこうした複雑な問題に対処するため、自由に外部ドメインへのリンクやフォーム送信の追跡が行えるようになります。

シングルページアプリケーション上の URL の変更追跡

コンテンツを動的に読み込み、History API を使って URL を更新するシングルページアプリケーションを構築している場合、デフォルトのトラッキングスニペットでは不十分です。デフォルトのトラッキングスニペットは、最初のページ読み込みだけしか追跡しません。たとえ、新しいコンテンツを問題なく読み込んだ際にページビューを送信するようにしても、まだ厄介な問題が発生する可能性があります。

Autotrack は History API を使用した URL の変更を自動的に検出し、それをページビューとして追跡します。トラッカーは更新された URL に同期されるため、それ以降のヒット（イベント、ソーシャルインタラクションなど）もすべて正しい URL に関連付けられます。

宣言型のイベントトラッキング

手作業で JavaScript のイベントリスナを書くよりも、明示的にイベントを HTML に追加する方が容易な場合があります。最も典型的な例は、単純なクリックイベントの追跡です。Autotrack では、マークアップにデータ属性を追加するだけでクリックイベントを追跡できます。

 <button data-event-category="Video" data-event-action="play">Play</button>

ユーザーが上記のボタンをクリックすると、対応するカテゴリやアクションとともに、イベントが Google Analytics に送信されます（オプションでラベルや値も含めることができます）。

メディアクエリのトラッキング

最近は、ほとんどのサイトでレスポンシブデザインが採用されており、ユーザーが使っているデバイスの画面サイズや機能に応じてページレイアウトが更新されるようになっています。メディアクエリを使ってページの外観や機能を変更する場合、メディアクエリの情報を取得することが重要です。そうすることによって、有効になっているメディアクエリに応じて使用方法がどう変わるのかをより深く理解することができます。

Autotrack を使用すると、使用されるメディアクエリの値のセットを取得できます。この値のセットは、カスタムディメンション経由で自動的に追跡されます。さらに、値が変化したことも追跡できます（メディアクエリを使ったトラッキングを実行する場合は、Google Analytics でカスタムディメンションを設定しなければならないことに注意してください。設定のプロセスはほんの数分で済みます。また、設定の手順は mediaQueryTracker プラグインのドキュメントで説明されています）。

以上で説明した機能は、Autotrack で実現できる機能のほんの一部です。すべてのプラグインの一覧とその使い方の説明は、Github にある Autotrack のドキュメントをご覧ください。

Autotrack の利用効果が期待されるサイトとは

Autotrack は誰でも利用でき、どんなサイトにも効果がありますが、このライブラリは主に、現在のアナリティクスの実装をカスタマイズしておらず、ここまでで説明したような機能を利用したいサイトのために設計されています。

現在デフォルトのトラッキングスニペットだけを使用している場合、Autotrack の利用を検討してみる価値があるでしょう。Google Analytics の実装に既にカスタマイズを加えている場合は、まずドキュメントを参照し、その実装と Autotrack の機能が衝突しないかどうか、二重にカウントされるデータがないかどうかを確認してください。

次のステップ

Autotrack を利用する際は、ドキュメントの「使い方」のセクションを参照してください。Autotrack がどのようなデータを捕捉するのかについて関心のある方は、Google Analytics Demos & Tools サイトを参照してください。このサイトは Autotrack を利用しており、このサイト自身に対して Google Analytics を実行したデータをグラフで表示しているページがあります。

さらに理解を深めたい場合は、Autotrack ライブラリを直接参照してください。これはオープンソースで、学習に役立つ、優れたリソースです。プラグインのソースコードにひととおり目を通せば、そこで analytics.js の高度な機能が多用されていることが理解できるでしょう。

最後に、この機能に関するフィードバックや提案があれば、遠慮なくお知らせください。バグや問題点は、Github から報告できます。

Posted by Eiji Kitamura - Developer Relations Team

Google サービスとサーバーとの間でのクレデンシャルの扱い方

2016年3月7日月曜日

[この記事は Laurence Moroney、デベロッパーアドボケートによる Android Developers Blog の記事 "Using Credentials between your Server and Google Services " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

本記事は、Google Sign-In に関するシリーズの第 4 回です。このシリーズは、Google Play サービス 8.3 の開始とともに投稿されたユーザーエクスペリエンスの改善に関する記事から始まりました。第 2 回の記事では、プログラミングモデルをより簡単にする、API の更新について取り上げました。また、前回第 3 回の記事では、バックエンドのサーバーで Google Sign-In を使ってユーザーを認証する方法をご紹介しました。

今回は、サインインしたアプリのサービスをユーザーが認可することによって、Google ドライブなどの Google API にアクセスできるようにする方法について説明します。

Google Sign-In を使うと、ユーザーが料理の写真を撮って Google ドライブに保存するというような、Google と連携するアプリを簡単に作成することができます。これを実現するには、サインイン後に API へのアクセスに必要なスコープを追加で要求します。通常、このアクセスは（最初のサインインと同時ではなく）必要に応じて要求します。つまり、ユーザーエクスペリエンスのベストプラクティスに従い、ユーザーが実行するアクションの最中（たとえば、オーダーした食事がテーブルに届き、アプリのユーザーが Google ドライブに保存するために写真を撮ろうとしたタイミング）に要求します。このタイミングでスコープを要求することで、アクセスが許可される可能性が最も高くなり、Android Marshmallow 6.0 のランタイムパーミッションモデルとも一致します。

このような連携を行う場合は、ユーザーがアプリを利用していなくても継続してサーバーがアクセスできるようにしたり、ユーザーが作成したデータを自身のデータベースに格納するといった目的で、サーバーのデータにアクセスすることが多くなります。このフローを図で示すと下記の図 1 のようになります。これには、すべてのプラットフォームで動作するという利点もあります。

図 1. クレデンシャルを使った Google サービスへのアクセス

実現するには、以下のステップを実行します。

ステップ 1 : サーバー認証のシナリオは第 3 回の記事で説明したので、このサンプルでは Android アプリの標準的なコードを示します。特に ServerAuthCodeActivity に注目してください。

 GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)  
      .requestScopes(new Scope(Scopes.DRIVE_APPFOLDER))  
      // The serverClientId is an OAuth 2.0 web client ID  
     // Details at: https://developers.google.com/identity/sign-in/android/?utm_campaign=android_discussion_server_021116&utm_source=anddev&utm_medium=blogstart step 4  
     .requestServerAuthCode(serverClientId)  
     .requestEmail()  
     .build();

実行するには、サーバーのウェブ クライアント ID が必要になります。取得方法についての詳細は、こちらをご覧ください（ステップ 4 を参照）。

実行すると、スコープ DRIVE_APPFOLDER が要求され、Google ドライブへのアクセスをアプリに許可するかを問うメッセージが表示され、Auth Code も要求されます。

サインインが成功すると、次のようにしてアカウントオブジェクトから Auth Code を取得することができます。

 if (result.isSuccess()) {  
     GoogleSignInAccount acct = result.getSignInAccount();  
     String authCode = acct.getServerAuthCode();  
 }

（ここで示したサンプルの onActivityResult からの引用です）

次に、この Auth Code を HTTPS POST を使ってサーバーに送信します。Auth Code の交換が終わると、ユーザーの Google ドライブにアクセスできる状態になります［重要：アクティブなユーザーによる正当な要求であることを保証するため、Auth Code は認証済みのリクエストでバックエンドに送信するようにしてください］。

ステップ 2 : GoogleAuthorizationCodeTokenRequest クラスを使い、サーバー上で Auth Code を Token と交換します。

 // Set path to the Web application client_secret_*.json file you downloaded from the  
 // Google Developers Console: https://console.developers.google.com/project/_/apiui/credential  
 // You can also find your Web application client ID and client secret from the  
 // console and specify them directly when you create the GoogleAuthorizationCodeTokenRequest  
 // object.  
 String CLIENT_SECRET_FILE = "/path/to/client_secret.json"; // Be careful not to share this!  
 String REDIRECT_URI = "/path/to/web_app_redirect" // Can be empty if you don’t use web redirects  
 // Exchange auth code for access token  
 GoogleClientSecrets clientSecrets =  
     GoogleClientSecrets.load(  
         JacksonFactory.getDefaultInstance(), new FileReader(CLIENT_SECRET_FILE));  
 GoogleTokenResponse tokenResponse =  
            new GoogleAuthorizationCodeTokenRequest(  
                new NetHttpTransport(),  
                JacksonFactory.getDefaultInstance(),  
               "https://www.googleapis.com/oauth2/v4/token",  
                clientSecrets.getDetails().getClientId(),  
                clientSecrets.getDetails().getClientSecret(),  
                authCode,  
                REDIRECT_URI)  
               .execute();  
 String accessToken = tokenResponse.getAccessToken();  
 String refreshToken = tokenResponse.getRefreshToken();  
 Long expiresInSeconds = tokenResponse.getExpiresInSeconds();  
 // You can also get an ID token from the exchange result if basic profile scopes are requested  
 // e.g. starting GoogleSignInOptions.Builder from GoogleSignInOptions.DEFAULT_SIGN_IN like the  
 // sample code as used here: http://goo.gl/0Unpq8   
 //  
 // GoogleIdToken googleIdToken = tokenResponse.parseIdToken();

続いて、GoogleTokenResponse から発行された Token を使い、GoogleCredential オブジェクトを作成します。

 GoogleCredential credential = new GoogleCredential.Builder()  
          .setTransport(new NetHttpTransport())  
          .setJsonFactory(JacksonFactory.getDefaultInstance())  
          .setClientSecrets(clientSecrets)  
          .build();  
 credential.setAccessToken(accessToken);  
 credential.setExpiresInSeconds(expiresInSeconds);  
 credential.setRefreshToken(refreshToken);

Refresh Token が利用可能で、ユーザーがサインインし直すことなく API にアクセスできるようにしたい場合は、StoredCredential を使って資格情報を保存し、再利用することができます。

ステップ 3: 取得した資格情報を使って、Google サービスにアクセスします。先ほどから挙げている食事のシナリオでいえば、運ばれてきた料理やレシートの写真を Google ドライブに保存したり、そこから取り出したりすることができます。これを行うには、たとえば次のようなコードを記述します。

 Drive drive = new Drive.Builder(new NetHttpTransport(),   
                                 JacksonFactory.getDefaultInstance(),   
                                 credential)  
       .setApplicationName("Auth Code Exchange Demo")  
       .build();  
 File file = drive.files().get("appfolder").execute();

今回は、サーバーから Google API を呼び出すことによって、ユーザーの Google Sign-In 資格情報を使用する方法について説明しました。この手法や Google Sign-In テクノロジーの詳細については、Google Identity Platform ウェブサイトにアクセスしてください。

Posted by Eiji Kitamura - Developer Relations Team

Google Play ゲームをプレイヤーにとって、より楽しい場所にする

Google Play ゲームサービスの強力な新機能でゲームをさらに成長させる

広告のフォーマットとターゲットを一新して上質のゲーマーを特定、維持、収益化する

AdMob を使ってゲームの収益を増やす

プッシュ通知の改善

プッシュ通知の改善

宣言型プリロード

今回のリリースに追加されたその他の機能

細かな変更

マテリアル デザインでよりよいユーザー体験を実現しよう

高品質 Android アプリ実装ヒント集 〜 ゴミアプリと言わせないために

スマートフォン体験を一歩先へ 〜 プログレッシブウェブアプリの作り方

ユーザーとコンテンツの距離を縮めよう 〜 コンテキストアウェアなアプリケーション

評価・レビュー機能の改善点

評価やレビューを最大限に活用しているデベロッパーの事例

マルチ ウィンドウ

ダイレクト リプライ 通知

通知のグループ化

省電力化

Java 8 言語をサポート

プレビューを試すには

ベクター ドローアブルとアニメーション付きベクター ドローアブルのサポート

ベクター ドローアブルとアニメーション付きベクター ドローアブルのサポート

AppCompat の DayNight テーマ

Design サポート ライブラリ: Bottom Sheet

Support v4: MediaBrowserServiceCompat

RecyclerView

カスタム タブ

Android TV の Leanback

今すぐ入手

機能

サイト外へのリンクとフォームの追跡

シングルページ アプリケーション上の URL の変更追跡

宣言型のイベント トラッキング

メディアクエリのトラッキング

Autotrack の利用効果が期待されるサイトとは

次のステップ

ラベル

ブログ アーカイブ

Feed

マテリアルデザインでよりよいユーザー体験を実現しよう

高品質 Android アプリ実装ヒント集〜ゴミアプリと言わせないために

スマートフォン体験を一歩先へ〜プログレッシブウェブアプリの作り方

ユーザーとコンテンツの距離を縮めよう〜コンテキストアウェアなアプリケーション

マルチウィンドウ

ダイレクトリプライ通知

ベクタードローアブルとアニメーション付きベクタードローアブルのサポート

ベクタードローアブルとアニメーション付きベクタードローアブルのサポート

Design サポートライブラリ: Bottom Sheet

カスタムタブ

シングルページアプリケーション上の URL の変更追跡

宣言型のイベントトラッキング

ブログアーカイブ