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

People API を公開しました。ユーザーの同意を得た上でこの API を使うと、連絡先のデータを取得することができます。以前であれば、デベロッパーはユーザー プロファイルを取得するために Google+ API、連絡先を取得するために Contacts API というように、複数回の呼び出しを実行する必要がありました。このたび発表する People API は、最新のプロトコルとテクノロジーを使用しており、GData プロトコルを使用していた Contacts API に取って代わるものです。

たとえば、ユーザーがプライベートの連絡先リストに何人かの情報を格納していた場合、この API を呼び出すことによって、(ユーザーが同意した場合)リンクされているすべてのプロファイルがマージされた連絡先のリストを取得することができます。ユーザーが関連するスコープを承認すると、その結果が people.connections.list オブジェクトとして返されます。リストに含まれている各人のオブジェクトには、resourceName プロパティが含まれます。このプロパティは people.get を呼び出して、その人物に対する追加のデータを取得するために使用できます。

API は HTTP および JSON を使用しているので、標準的な HTTP クライアントであれば、どのようなものでもリクエストの送信や応答の解析が可能です。ただし、アプリケーションは API へのアクセス権限を得なければならないので、サービスへのアクセスに必要な認証情報を取得するために、Google デベロッパー コンソールにプロジェクトを作成しなければなりません。実行しなければならないステップについては、 ここを参照してください。Google API やデベロッパー コンソールにまだ慣れていない場合は、まずこのビデオシリーズを見て知識を深めておけば、すぐに追いつけます。

接続して認証を受けると、以下のように(Java 向けの Google API クライアント ライブラリを使って)ユーザーの連絡先を取得することができます。

 ListConnectionsResponse response =   
     peopleService.people().connections().list("people/me").execute();  
 List<Person> connections = response.getConnections();  

people.connections.list メソッドの詳細を記述したドキュメントは、ここから参照できます。

必要なスコープが承認されている場合、連絡先のリストには、すべてのユーザーの社会的なつながりに関する詳細情報が含まれます。そのユーザーが連絡先スコープしか承認しなかった場合は、連絡先情報のみが返されます。

Person の各アイテムは resource_name と関連付けられているので、次の簡単な呼び出しを行うだけでその人物に関する追加データにアクセスできます。
Person person = peopleService.people().get("resourceName").execute();
この API 呼び出しの詳細については、ここを参照してください。

新しい People API を使用すると、複数のソースおよび API からデータをマージして 1 つのデータソースに統合することができます。さらに、ユーザーが許可した場合は、自宅の住所や電話番号、プライベート メールアドレス、誕生日など、以前には取得できなかったデータにもアクセスできます。

こうした機能やデータが新たに利用可能になり、既存のデータにも簡単にアクセスできるようになったことによって、次世代のクールなウェブやモバイル アプリを作り出そうという皆さんの意欲はかきたてられることでしょう。その結果、皆さんのアプリのユーザーや、そのユーザーが影響を及ぼす人々に喜んでいただけることを願っています。People API の詳細については、ここから公式ドキュメントを参照してください。

Posted by Eiji Kitamura - Developer Relations Team

Google は 3 月 8 日 国際女性デーに合わせて、テクノロジー業界で活躍する女性が、情報交換したり学び合ったりするためのイベント Women Techmakers を世界各地で開催します。

Google 東京オフィスでも、3 月 19 日(土)に開催します(本イベントは主に日本語で行われます)。
Google は 3 月 8 日 国際女性デーに合わせて、テクノロジー業界で活躍する女性が、情報交換したり学び合ったりするためのイベント Women Techmakers を世界各地で開催します。

Google 東京オフィスでも、3 月 19 日(土)に開催します(本イベントは主に日本語で行われます)。



wtm_blog_square.png
テクノロジーを軸に、さまざまな方面でキャリアを築いている女性をお招きしたトークセッションや、発展し続ける最新のウェブ機能を体験できるワークショップを実施します。事前に選択いただくワークショップでは、実機を使った Progressive Web App の Codelab または Design Sprint というアイデアのブレインストーミングのいずれに参加ただけます。お申込方法、当日のスケジュールは下記をご確認ください。
世界各地で、同じテクノロジーの分野で活躍する女性同士が交流できる機会となれば幸いです。
wtm.png

■Women Techmakers 2016 at Google Japan 

日程:2016 年 3 月 19 日(土)10:00 - 17:00
場所:Google 東京オフィス 六本木ヒルズ森タワー
定員:100 名
主催:グーグル株式会社

■当日のスケジュール

午前の部
10:00 - 10:30 : 受付
10:30 - 10:40 : ご挨拶
10:40 - 11:10 : キーノート Xinmei Cai(Google ソフトウェア エンジニア)
11:10 - 11:55 : 外部の講演者を招いたトーク セッション
  • 平 愛美 (フリーランス)
  • 大場 寧子 (株式会社万葉)
  • よしこ (Goodpatch, Inc.)
  • 藤原 香織 (Google ソフトウェア エンジニア)
12:00 - 13:00 : ランチ

午後の部 : 2 つのセッションから選択
13:05 - 15:05 : セッション A : Progressive Web Apps Codelab
13:05 - 15:05 : セッション B : Design Sprint
15:10 - 15:25 : 休憩
15:30 - 15:40 : 閉会の挨拶
16:00 - 17:00 : 懇親会

■申し込み方法

Women Techmakers のサイトよりお申し込みください。
※本イベントの一次募集は 3 月 5 日 23 時 59 分までになっております。

■よくある質問

Q : Codelab に参加する上で必要なスキルや機材などはありますか?
A : ある程度の Web 開発経験(HTML,  CSS,  Javascript)が必要です。また、開発をする上で必要になる PC(Chrome 47 以上をインストールした Mac あるいは Windows)をご持参ください。

Q : 本イベントは女性限定のイベントでしょうか?
A : 女性の方向けのプログラムとなっていますが、イベントの趣旨に賛同してくださる方であればどなたでも参加可能です。

Q : 交通費や宿泊費のサポートはありますか?
A : 交通費等は参加者の方のご負担となります。

Q : ドレスコードは?
A : ドレスコードはありません。過ごしやすい服装でお越しください。

なお、東京以外でも、GDG コミュニティの皆さんによるイベントが開催される予定です。ご興味がある方は Women Techmakers のサイトをご覧ください。多くの方からのお申し込みをお待ちしております。


■ IWD 2016 - Women Techmakers in Kyoto
日程:2016 年 4 月 2 日(土)13:00 - 18:00
場所:amu-Kyoto
定員:20 名
主催:GDG 京都
詳細:https://gdgkyoto.doorkeeper.jp/events/40923


グーグル株式会社 Women Techmakers 運営チーム

[この記事は同期サムライ Josh Karlin による Chromium Blog の記事 "Chrome 49 Beta: CSS custom properties, background sync with service workers, and new ES2015 features" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
[この記事は同期サムライ Josh Karlin による Chromium Blog の記事 "Chrome 49 Beta: CSS custom properties, background sync with service workers, and new ES2015 features" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

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

CSS カスタム プロパティ

最近のモダンなウェブサイトには、値の繰り返しを含む CSS ファイルを使用しているものがあります。たとえば、1 つのカラースキーム内の 2~3 色をページ全体で再利用する手法です。このようなデータを変更するのは手間もかかり、作業ミスも発生しやすくなります。変更が必要な箇所が、1 つまたは複数の CSS ファイル全体に散らばっているからです。この事態を改善するため、Chrome で CSS Custom Properties がサポートされるようになります。これによって、外部フレームワークを使用せずに CSS 内部でプロパティ変数を定義できるようになります。デベロッパーはドキュメント内の好きな場所で var() 関数を使って、Custom Property を参照することができます。

Custom Property の変更により、ウェブサイト内の複数のコンポーネントを更新可能

CSS Custom Properties は、Shadow Root をまたいで継承されます。したがって、内部のことが分からなくても、外観に微調整を加えたりテーマを設定したりする「Style  API」を提供する Web Component を実現できます。Polymer ライブラリではこのプラットフォーム機能を使って、コンポーネントのカスタマイズを簡略化しています。

Service Worker で Background Sync

ユーザーがサイトに滞在する時間がきわめて短く、そのサイトで行った変更がネットワークに送信される前に別のサイトに移動した場合、サイトでローカルの変更を反映しきれなかったり、同期に失敗したりすることがありました。たとえば、メール クライアントを使っていたユーザーが「送信」をクリックしてすぐに別のサイトに移った場合、送信中のメッセージが消失することがあります。新たに追加される Background Sync API は、ネットワークの信頼性を高めるためのものです。Service Worker は、スケジュールを作成してそのデバイス上での変更を反映するための 1 回限りの同期を実行します。これは、デバイスが次回ネットワークに接続するときに実行され、該当サイトが開かれているかどうかにはよりません。

ECMAScript 2015 サポートの改善

ES2015 仕様(ES6)は、大幅な変更が加わった JavaScript の最新仕様です。これによって、読みやすくて強力でメモリ利用効率の高いアプリケーション ロジックを書くことができるようになります。最新バージョンである Chrome の V8 エンジンでは、JavaScript ES2015 の機能の 91% がサポートされています。分割代入(destructuring)や関数のデフォルト パラメータを指定できるようになるため、配列やオブジェクトからデータを抽出したり、関数パラメータにデフォルト値を設定する際にボイラプレート コードを回避できるようになります。Proxy オブジェクトや Reflect API を使用すると、たとえばプロパティの検索や割り当てなど、以前は制御できなかった動作をカスタマイズすることができます。また、最新バージョンの Chrome では、strict(厳格)モードの外でも class などのブロックレベルの構造や let が 利用できるようになっています。

keygen および application/x-x509-user-cert

<keygen> エレメントは、HTML フォームの一部として使用してキーペアを生成することができます。これはユーザー セキュリティを強化するためのものですが、<keygen> と、MIME タイプが「application/x-x509-user-cert」のユーザー証明書が送信されると、それが悪用されてユーザーのセキュアな通信が阻害されたり、使用しているデバイスの機能への干渉が発生したり、同意なしにユーザーの行動が追跡されたりする恐れがあります。その対応として、<keygen> はデフォルトで空の文字列を返すようになります。また、MIME タイプ「application/x-x509-user-cert」で送信されたユーザー証明書は、自動的にダウンロードされたりインストールされることはなくなります。

今回のリリースのその他の機能


細かな変更

  • Chrome の CSP (Contents Security Policy) で、‘script-src http:’ が HTTP と HTTPS の両方に一致するようになります。これによって、デベロッパーがセキュアなリソースまで不用意に拒否することを防ぐことができます。
  • Fetch API の Enum、Request.modenavigate モードがサポートされるようになります。これによって、より正確に仕様に準拠するようになります。
  • 属性セレクターのマッチング処理で、大文字と小文字の違いを無視するオプションがサポートされます。
  • 'rel=noopener' を指定することで、オープン元のページを明示しないポップアップを作成できるようになります。
  • addEventListener() と removeEventListener() の最初の 2 つの引数が必須となります。また、ディクショナリの構文を使って "capture" オプションを指定できるようになります。これによって、より正確に仕様に準拠するようになり、柔軟性も向上します。
  • Chromium の TLS で、標準化バージョンの ChaCha-Poly1305 暗号スイートがサポートされます。
  • Navigator の仕様に含まれなくなっている Navigator.getStorageUpdates() が削除されます。
  • MouseEvent.webkitMovementX/Y は、プレフィックスなしのバージョンで置き換えられ、削除されます。
  • initTouchEvent は、より正確に仕様に準拠するため、TouchEvent コンストラクタで置き換えられます。initTouchEvent は廃止予定となります。Chrome 53 で完全に削除される予定です。
  • Object.observe() は、標準化の対象に含まれなくなったため廃止予定となります。将来のリリースで削除される予定です。
  • getComputedStyle(e).cssX の動作は、公式の仕様に含まれなくなったため、廃止予定となります。
  • RTCPeerConnection のレガシー メソッドの一部の非標準的な使用方法は廃止予定となります。これによって、Promise ベースの WebRTC 仕様の実装を利用できるようになります。
  • Document.defaultCharset は、より正確に仕様に準拠するため、廃止予定となります。
Posted by Eiji Kitamura - Developer Relations Team

[この記事は デベロッパーアドボケート、Joanna Smith と Google Privacy Team、Giles Hogben による Android Developers Blog の記事 "Marshmallow and User Data" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
[この記事は デベロッパーアドボケート、Joanna Smith と Google Privacy Team、Giles Hogben による Android Developers Blog の記事 "Marshmallow and User Data" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Android 6.0 (Marshmallow) では、アプリでユーザー データを適切に取り扱えるよう、いくつかの変更が加えられています。その目的は、デベロッパーが適切な動作をするアプリを簡単に作れるようにすることです。Marshmallow の普及は進みつつあるため、ぜひこの点に挑戦していただきたいと考えています。

本稿は、 実行時 パーミッションとハードウェアの識別子について、ユーザーの信頼を得るために考慮するべき事項を中心に説明しています。また、アプリの開発において目指すべき点を分かりやすく説明している 新しいベストプラクティス のドキュメントも紹介します。

パーミッションの変更

Marshmallow では、 パーミッションの許可を得るタイミングがインストール時から実行時に変更されています。 これは SDK 23 以降で強制的に適用される変更なので、Android 6.0 を対象とするすべてのアプリとすべてのデベロッパーに影響します。アプリはいずれ更新しなければなりませんが、更新は注意深く行う必要があります。

実行時パーミッションとは、アプリが実際に機密性の高い情報を使用するタイミングで、アクセスのパーミッションを要求することです。こうすることで、アプリがそのパーミッションをなぜ要求するのか、その場でユーザーに説明を提示することができるようになります。これまでのように、インストール前に要求する可能性のある情報を全部長々と提示する必要はなくなるので、ユーザーを不安にさせません。

またパーミッションはグループに分類することもできるようになったので、ユーザーは技術的な難しい専門用語を理解していなくても、内容を理解したうえでパーミッションを与えるかどうかの判断を下すことができます。決定権をユーザーにゆだねることで、ユーザーはパーミッションを与えないこともできますし、以前に付与したパーミッションを取り消すこともできます。したがって、アプリ側で特に注意が必要な点は、拒否される可能性のあるパーミッションが必要な API 呼び出しに注意することと、パーミッションが拒否されてもそれ以外のアプリの機能を使い続けることができるようにエラー処理を工夫することです。

識別子の変更点

ユーザーの信頼を得るにあたってもう 1 つ重要な点は、入力されたデータを適切に処理する必要があることです。Marshmallow では、アプリのデベロッパーに許可していたデータへのアクセスが一部無効になっています。これは、デベロッパーが直接データにアクセスすることを防ぐためです。

最もわかりやすいのは、 ローカルの WiFi や Bluetooth の MAC アドレスへのアクセスが禁止されたことです。 WifiInfo オブジェクトの getMacAddress() メソッドと、BluetoothAdapter.getDefaultAdapter().getAddress() メソッドは、今後どちらも 02:00:00:00:00:00 という値を返すことになります。

ただし、 Google Play サービスではインスタンス ID が提供されており、デバイスで実行中のアプリケーションの各インスタンスは、この ID で区別します。インスタンス ID は、リセットできない端末固有のハードウェア ID に代わる信頼性の高い ID を提供します。インスタンス ID は、端末を出荷時の設定に戻すことでリセットできます。インスタンス ID のスコープは、アプリのインスタンスです。詳細については、Google Developers サイトのインスタンス ID とはを参照してください。

次のトピック

ユーザーがあなたのアプリを信頼するかどうかは、アプリの外観とそれを見た印象によって大きく左右されます。パーミッションや識別子の処理を誤ると、開発者が望んでいない、または意図していないトラッキングが行われるリスクが高まるので、ユーザーはそのアプリに対して、ユーザーに対する配慮に欠けているという印象を持つ恐れがあります。そこで、適切に動作するアプリの開発をサポートするため、以下のドキュメントを新たに公開しました。このドキュメントを活用すると、ユーザーにとって適切な動作のアプリであるかどうかをデベロッパー自身が確認することができます。
それでは、引き続きアプリ開発をお楽しみください。ユーザーがあなたのアプリを気に入ってくれますように。またそれが、あなたのアプリのレビューの評価値に反映されますように。

Posted by Yuichi Araki - Developer Relations Team

[この記事は Google Cloud Platform、テクニカル プログラム マネージャー Vijay Subramani による Android Developers Blog の記事 "Retirement of certain Google search APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

2011 年、Google は次の API を廃止することを 発表しましたGoogle Patent Search API ...
[この記事は Google Cloud Platform、テクニカル プログラム マネージャー Vijay Subramani による Android Developers Blog の記事 "Retirement of certain Google search APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

2011 年、Google は次の API を廃止することを発表しましたGoogle Patent Search APIGoogle News Search APIGoogle Blog Search APIGoogle Video Search APIGoogle Image Search API

Google はこれらの API を 3 年間(以上)サポートしてきましたが、 2016 年 2 月 15 日をもって運用を停止となりました。

代替には Custom Search API の利用をご検討ください。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Marcelo Camelo, Software Engineer による Geo Developers Blog の記事 "Changes and quality improvements in Google Places API Search" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ]

Google Places API の検索結果に対して maps.google.com 上の情報をもっと正確に反映してほしいと思っていた方は多いことでしょう。そこで、このたび、Google Places API と Google マップの検索機能を統合しました。これによって、Google マップと Google Places API の検索結果の整合性が高まり、API の検索品質も向上します ...
[この記事は Marcelo Camelo, Software Engineer による Geo Developers Blog の記事 "Changes and quality improvements in Google Places API Search" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ]

Google Places API の検索結果に対して maps.google.com 上の情報をもっと正確に反映してほしいと思っていた方は多いことでしょう。そこで、このたび、Google Places API と Google マップの検索機能を統合しました。これによって、Google マップと Google Places API の検索結果の整合性が高まり、API の検索品質も向上します。

今回の変更では、Google Places API Web Service および JavaScript ライブラリの検索対象となるプレイスのタイプを限定する機能にも仕様変更が加えられました。2016 年 2 月 16 日に、これまでタイプ限定パラメータであった types は、新たに、type という検索パラメータに置き換わります。これによる影響が生じるのは、周辺検索テキスト検索レーダー検索のリクエストに types パラメータを指定している場合です。

この新たな検索機能はタイプ限定検索と似ていますが、指定できるタイプはリクエスト 1 件ごとに 1 つのみとなります。

2017 年 2 月 16 日までは、types パラメータに複数のタイプを指定(例: types=hospital|pharmacy|doctor)した場合でも有効な検索結果が得られますが、2017 年 2 月 17日から、複数のタイプ指定がされた検索リクエストはサポートされなくなります。今後は単一のタイプのみを指定していただくことを推奨します。

type による検索の利用はごく簡単です。テキスト検索リクエストの例を以下に示します。
https://maps.googleapis.com/maps/api/place/textsearch/json
?type=airport
&location=-33.87,151.21
&radius=5000
&key=<YOUR_API_KEY>

さらに、サポートされるタイプのリストにも一部変更が加えられました。2017 年 2 月 16 日から、プレイス検索 establishment(施設)、food(食料品店)、health(健康)、general_contractor(建設会社)、finance(金融業)、place_of_worship(礼拝所)の各タイプを指定することができなくなります。ただし、これは検索で指定することができなくなるという意味であり、これらのタイプのプレイスが検索結果に表示されなくなったり、詳細情報が取得できなくなるわけではありません。

Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps Solution Architect, Google Maps API for Work

モバイル端末からインターネットを利用する機会は増えつづけており、  Google 検索もモバイル端末からの利用がデスクトップからよりも 多くなってきています。一方、現在のモバイル インターネットは、特にスピードの面において、必要な情報を求めるユーザーの期待に応え切れていないという現実があります。この状況を改善するため Google は業界各社の協力のもと、昨年 10 月にオープンソース プロジェクトである Accelerated Mobile Pages (AMP) プロジェクトを 発足しました。

以来、モバイル インターネットの向上という共通課題のもとに、多くの企業が AMP プロジェクトに参加し、新たな AMP カスタムタグや AMP ページの公開を含む進化が続いています。そして本日より、Google は AMP ウェブページをモバイル検索に導入いたします。日本の対応パートナーは日々増えておりますが、本日の時点で、朝日新聞、映画.com、zakzak、THE PAGE、産経ニュース、SankeiBiz、SANSPO.COM、シネマトゥディ、日刊スポーツ、BLOGOS、毎日新聞、マイナビニュース、レスポンスの 13 メディアが対応しています。これにより、日本語の主要記事においても素早くアクセスと高速表示が可能となりました ...
モバイル端末からインターネットを利用する機会は増えつづけており、  Google 検索もモバイル端末からの利用がデスクトップからよりも多くなってきています。一方、現在のモバイル インターネットは、特にスピードの面において、必要な情報を求めるユーザーの期待に応え切れていないという現実があります。この状況を改善するため Google は業界各社の協力のもと、昨年 10 月にオープンソース プロジェクトである Accelerated Mobile Pages (AMP) プロジェクトを発足しました。

以来、モバイル インターネットの向上という共通課題のもとに、多くの企業が AMP プロジェクトに参加し、新たな AMP カスタムタグや AMP ページの公開を含む進化が続いています。そして本日より、Google は AMP ウェブページをモバイル検索に導入いたします。日本の対応パートナーは日々増えておりますが、本日の時点で、朝日新聞、映画.com、zakzak、THE PAGE、産経ニュース、SankeiBiz、SANSPO.COM、シネマトゥディ、日刊スポーツ、BLOGOS、毎日新聞、マイナビニュース、レスポンスの 13 メディアが対応しています。これにより、日本語の主要記事においても素早くアクセスと高速表示が可能となりました。

これらの AMP 対応されたページはどのように Google 検索に表示され、どうして瞬時にモバイルブラウザで表示されるのでしょうか。次の図で説明します。


ニュース記事を提供しているメディアやコンテンツ提供者が、これまでのモバイル向けのウェブページに加えて、AMP HTML に準拠したウェブページを公開すると、Google のクローラーが AMP ページをキャッシュします。キャッシュされたコンテンツが検索クエリに関連が深いと判断された場合、検索結果にはキャッシュされたページの URL がリンクされます。検索結果に表示されたキャッシュ済みの AMP ページにユーザーがアクセスする場合には、キャッシュ済みのためコンテンツの取得までの時間が短く、また広告やアナリティクスといったタグは遅延読込されるため、記事の表示が瞬時に行われます。

すでに先日のブログポストで AMP ページの実装方法をご紹介しましたが、再度簡単に AMP ページの実装手順をご紹介します。なお AMP の仕様はまだ策定が進んでいる途中ですので、新規に対応される場合には常に GitHub にある最新の情報をご確認されることをおすすめします。

  1. AMP ページと正規版のページの URL の対応を検討する
    • 正規版の URL にパスを追加する 例) https://foo.com/article/amp/index.html
    • ファイル名に文字を追加する 例) https://foo.com/article/index.amp.html
    • URL パラメータを追加する 例) https://foo.com/article/index.html?amp
  2. AMP ページ設置予定の URL に Google のクローラーがアクセスできるようにする
    • robots.txt を確認する
    • 正規版のページのメタタグに nofollow 等がないようにする
  3. AMP HTML の仕様にしたがい、AMP ページを作成する
    • Required Markup の項目がすべてあるか確認する
    • Google の検索結果に表示されるためには schema.org に準拠したメタデータの付与が必要
  4. validator を用いて AMP ページが正しくマークアップされているかいずれかの方法で確認する
    • URL に #development=1 というフラグメントをつけて Google Chrome の開発者ツールで確認
    • node.js 製の validator をコマンドラインで実行して確認する
  5. Structured Data Testing Tool を使ってメタデータが正しく記述されているかを確認する
  6. Search Console の AMP レポートツール を使って AMP ページがインデックスされているか確認する
    • Google のクローラー側でエラーを検出した場合はこちらでレポートされるのでよく確認する

AMP プロジェクトはオープンソース プロジェクトであり、いまも多くの方々から多くの新機能や改善点がソースコードや Issue Tracker を通じて実装・提案され、随時取り入れられています。ぜひ Google 検索で AMP のスピードを体感してみてください。皆様の AMP プロジェクトへの参加と AMP ページのご対応を楽しみにお待ちしております!

Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Google Play チーム、Lily Sheringham による Android Developers Blog の記事 "Android Developer Story: Travel app Wego, increases monthly user retention by 300% with material design" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

シンガポールに本社を置く Wego は、航空券やホテルの手配ができる、東南アジアや中東のユーザーに人気のオンライン旅行サービスを開発した企業です。同社は 2014 年初めに Android アプリをリリースし、現在では Wego アプリ ユーザーの 62% 以上が Android を利用しています。Wego はAndroid本来の性質を生かすことで、一貫性があって操作しやすいユーザーエクスペリエンスを提供するため、マテリアル デザインを使って、アプリのデザインをこのほど一新しました ...
[この記事は Google Play チーム、Lily Sheringham による Android Developers Blog の記事 "Android Developer Story: Travel app Wego, increases monthly user retention by 300% with material design" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

シンガポールに本社を置く Wego は、航空券やホテルの手配ができる、東南アジアや中東のユーザーに人気のオンライン旅行サービスを開発した企業です。同社は 2014 年初めに Android アプリをリリースし、現在では Wego アプリ ユーザーの 62% 以上が Android を利用しています。Wego はAndroid本来の性質を生かすことで、一貫性があって操作しやすいユーザーエクスペリエンスを提供するため、マテリアル デザインを使って、アプリのデザインをこのほど一新しました。

マテリアル デザインを導入した結果、このアプリの月間の再訪ユーザー数は300% 増となったばかりか、アンインストール率は 25%も減少しました。この成果について、Wego の共同創設者で CEO の Ross Veitch 氏とスタッフが語ったこちらの動画をご覧ください。


マテリアル デザインAndroid Studio の使い方、Google Play で成功する方法については、新しいガイド "Secrets to App Success on Google Play"(Google Play でのアプリ成功の秘訣)をご覧ください。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Android プロダクト マネージャー Jamal Eason による Android Developers Blog の記事 "Android Studio 2.0 - Beta" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
[この記事は Android プロダクト マネージャー Jamal Eason による Android Developers Blog の記事 "Android Studio 2.0 - Beta" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Android Studio 2.0 は、正式な Android IDE の最新リリースです。ビルドのパフォーマンスとエミュレータのスピードに重点を置き、アプリの開発環境を改善します。今回のアップグレードの注目点は、コードの変更を速やかに編集し、表示できる Instant Run や、さらに高速になった Android エミュレータなどの新機能を備えた Android Studio 2.0 です。最終リリースの準備期間中は、ベータ リリース チャンネルで Android Studio 2.0 ベータ版をダウンロードできます。Android Studio 2.0 リリースには、次のような多くの新機能が実装されています。
  • *ベータ版でアップデート* Instant Run - 速やかなコード編集とアプリ開発サイクルを実現します。
  • *ベータ版でアップデート* Android エミュレータ - ほとんどの実際のデバイスより高速で、新しいユーザー インターフェースを装備した新しいエミュレータです。
  • *ベータ版でアップデート* Google App Indexing の統合とテスト - App Indexing をアプリに追加することで、ユーザーのリピート率を向上します。Android Studio 2.0 のファースト プレビューでは、インデックス コード スタブをコードに追加できました。ベータ リリースでは、IDE だけでアプリの URL リンクのテストと検証を行えるようになりました。
  • 高速 ADB - Android Studio 2.0 を使用すると、Platform-tools 23.1.0 で提供されるアップデートされた Android デバッグ ブリッジ(ADB)によりファイルのインストールとプッシュ速度は最大 5 倍になります。
  • GPU Profiler プレビュー - グラフィックを多用するアプリケーションの OpenGL ES コードを視覚的にステップ実行することができ、アプリやゲームを最適化できます。
  • IntelliJ 15 の統合 - Android Studio は、効率的なコーディング プラットフォームである Intellij に基づいています。IntelliJ の新機能をここでご確認ください。

下の Android Studio Tool Time ビデオの最新の回をご確認ください。主要な機能について説明しています。


Android Studio 2.0 ベータ版の新機能

Instant Run

11 月に最初の Instant Run プレビューが発表されました。今回の最新のベータ リリースでは、コールド スワップと呼ばれる新機能が導入されています。

Android Studio 2.0 の Instant Run を使用すると、アプリを Android 端末または Android エミュレータで実行しながら、素早くアプリのコードを変更できます。Android Studio 2.0 では、コードを変更するたびにアプリ全体の再ビルドと再デプロイを待つ必要がなく、コードの増分やリソースの変更のみの増分的なビルドとプッシュを試行します。行ったコードの変更によっては、変更の結果を 1 秒以内に確認することも可能です。最新の Gradle プラグイン('com.android.tools.build:gradle:2.0.0-beta2’)を使用するようにアプリをアップデートするだけでこの機能を利用でき、時間を節約できます。他にコードを変更する必要はありません。プロジェクトが Instant Run を使うよう正しく設定されている場合、ツールバーの [Run] ボタンの横に稲妻のマークが表示されます。


Instant Run ボタン

Android Studio 2.0 は、アプリを初めてコンパイルしてデバイスにデプロイする際に、バックグラウンドでコードを監視しており、それに基づいてどのようにコードやリソースを入れ替えるかを決定しています。Instant Run 機能は、次のスワップ方法のいずれかを使用して、ベスト エフォート ベースでアプリをアップデートします。
  • ホット スワップ - メソッドの実装(コンストラクタを含む)のみが変更された場合、変更はホット スワップされます。アプリは実行を継続し、新しい実装は次回のメソッドの呼び出し時に使用されます。
  • ウォーム スワップ - アプリのリソースが変更された場合、変更はウォーム スワップされます。これはホット スワップと同様ですが、現在のアクティビティが再起動する点が異なります。画面が一瞬消えるため、アクティビティが再起動したことが分かります。
  • *ベータ版の新機能* コールド スワップ - アプリ全体を迅速に再起動します。主に、クラス階層、メソッドのシグネチャ、スタティック イニシャライザ、またはフィールドの変更など、構造的なコード変更に対応します。コールド スワップは、API レベル 21 以上のターゲットにデプロイした場合に使用できます。

Instant Run は Android Studio 2.0 のファースト プレビューから大きく変更されており、より多くの種類のコードやリソースの変更に対応しました。さらに多くのコードの変更に対応できるよう、Android Studio の将来のリリースに向けて継続して改善される予定です。ご提案がある場合は、お気軽に機能リクエストをお送りください。また、Instant Run の詳細はこちらでご確認ください。


App Indexing

Android Studio 2.0 では、App Indexing のサポートがさらに簡単になりました。App Indexing を設定すると、Google 検索ユーザーはアプリを表示できます。これは、アプリのマニフェストで指定した URL パターンをインデックス化し、アプリからの API コールを使用して、アプリのコンテンツを既存ユーザーおよび新規ユーザーの両方に表示する仕組みです。特に、アプリ コンテンツの URL をサポートすると、ユーザーは自分のデバイスの Google 検索結果からこれらのリンクを直接開くことができます。
  • コード生成 - Android Studio 2.0 プレビューでは、AndroidManifest.xml またはアクティビティ メソッドを右クリック(または [Code] → [Generate…] → [App Indexing API Code] に移動)して HTTP URL スタブ コードをマニフェストとアプリ コードに挿入できる機能が導入されました。

  • *ベータ版の新機能* URL のテストと検証 - Android Studio 2.0 ベータ版では、組み込みの検証ツールで URL の結果の検証とチェックを行えるようになりました ([Tools] → [Android] → [Google App Indexing Test])。App Indexing の詳細については、こちらをご覧ください。


App Indexing API コードのアプリへの挿入



App Indexing のテスト



App Indexing のテスト結果


Android エミュレータ

*ベータ版でアップデート* このベータ リリースには、高速になった新しい Android エミュレータの修正と小規模な機能強化も含まれています。中でも便利なのは、エミュレータ ツールバーの回転コントロールのアップデートです。マルチ タッチがサポートされているため、ピンチやズームの操作を使用するアプリを簡単にテストできるようになります。マルチ タッチ機能を使用するには、キーボードの Alt キーを押しながらマウスを右クリックして、基準となる点の中心を指定するか、左マウス ボタンをクリックおよびドラッグしてズームします。



マルチ タッチによるピンチおよびズーム操作


今後について

Android Studio 2.0 は重要なリリースであり、ベータ リリースをチェックして新機能をワークフローに取り入れる絶好のチャンスです。ベータ リリースは品質の安定度にはほとんど問題がなく、バグはほとんど無いと思われます。しかし、一般的なベータ リリースと同様に、まだバグが存在している可能性があります。何らかの問題が見つかった場合はお知らせください。修正に取りかかります。Android Studio を既にご使用中の方は、ナビゲーション メニューからベータ チャンネルのアップデートを確認できます(Windows/Linux の場合は [Help] → [Check for Update]、OS X の場合は [Android Studio] → [Check for Updates])。ベータ版にアップデートすると、新しいバージョンの Android Studio と Android エミュレータにアクセスできるようになります。

Google+ で Android Studio 開発チームからの情報を常にチェックしてください。

Posted by Yuichi Araki - Developer Relations Team

[この記事は 主席科学研究者 Vincent Vanhoucke による Google Research Blog の記事 "Google Developers Blog: Teach Yourself Deep Learning with TensorFlow and Udacity " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

ディープ ラーニングは、近年、機械学習の分野で最も注目度が高いトピックの 1 つです。オープンソース プロジェクトとして Google ...
[この記事は 主席科学研究者 Vincent Vanhoucke による Google Research Blog の記事 "Google Developers Blog: Teach Yourself Deep Learning with TensorFlow and Udacity " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

ディープ ラーニングは、近年、機械学習の分野で最も注目度が高いトピックの 1 つです。オープンソース プロジェクトとして Google が最近リリースしたディープ ラーニング プラットフォームの TensorFlow の目的は、ディープ ラーニングの可能性を全世界の人々に届けることでした。1 月からのわずか数週間の間に 4,000 人以上のユーザーが GitHub 上で TensorFlow をフォークし、16,000 人以上の全世界の熱心なユーザーがこのプロジェクトに星マークをつけているということを知り、非常に感動しています。

より多くの技術者やデータ サイエンティストにディープ ラーニングを利用してもらうために、このたび Udacity と共同でディープ ラーニング コースを新しく立ち上げました。この短期集中コースでは、ディープ ラーニングを始めるために必要な基本ツールと語彙を学ぶことができます。そして、機械学習において最も一般的な問題についても取り上げ、紹介するツールを使って対処できるようにします。また同時に、インタラクティブな TensorFlow ノートブックを提供し、講座で紹介したコンセプトを直接 反映、実装できるようにします。
コースは 4 つの講座で構成されており、画像認識からテキスト分析までの幅広い問題に対応するために使用される、主要な構成要素を順に説明していきます。最初の講座は、機械学習に精通した人にはなじみのある基本に重点を置いており、データと実験プロトコルをセットアップし、単純な分類モデルでトレーニングを行います。2 番目の講座は、最初の講座に続く形で構成され、最初に用いた単純なモデルを、より深くより強力にする仕組みを説明します。またその際に起こりうる拡張性にかかわるすべての問題を取り上げ、特に正則化とハイパーパラメータ チューニングについて説明します。3 番目の講座は、畳み込みネットワークに関するすべての事項と画像認識について、最後の 4 番目の講座では、一般的なテキストとシーケンスのモデルおよび、埋め込みと再帰型ニューラルネットワークについて説明します。コースを終えたときには、自分のマシン上でこれらの多様なモデルを実装し、その知識をご自身の問題を解決するために応用できるようになっているでしょう。

本コースの目的は、機械学習ファンに対し、ディープ ラーニング手法で現実の興味深い問題を解決する近道を提供することにありました。このコースを共有できることを大変嬉しく思います。また、Udacity のオンラインコースデザイン・制作チームは素晴らしく、共同のコース制作は大変楽しいものでした。コースのさらなる詳細については、Udacity のブログ投稿コース概要をご覧ください。

また本コースは、現在行われている、オンライン学習とコミュニティサポートを組み合わせた Study Jams プログラムの対象コースの 1 つです。同じコースを受講している仲間とディスカッションをしながら受講を進めてみませんか。参加申し込みをご希望の方は、Study Jams 特設サイト参加登録から「[上級] Deep Learning (ud730)」コースをご選択のうえお申し込みください。


Posted by Takuo Suzuki - Developer Relations Team

[この記事は デベロッパー アドボケート、Laurence Moroney による Android Developers Blog の記事 "How Fabulous and Yummly grew with App Invites" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

2015 年 5 月にリリースされた App Invites は、アプリへの招待を実行し、共有を促進するための革新的なソリューションです。これまでに、この機能によってユーザーがアプリを見つけやすくなったと感じているという、とても喜ばしい結果が得られています。アプリに出会うきっかけは周りの人からの口コミだというユーザーが 52% である一方で、家族や友人から送られた App Invites は信頼するというユーザーは 92% にも達することが分かっています。この記事では、App Invites を使用してユーザー基盤を拡大している企業の成功事例をご紹介します ...
[この記事は デベロッパー アドボケート、Laurence Moroney による Android Developers Blog の記事 "How Fabulous and Yummly grew with App Invites" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

2015 年 5 月にリリースされた App Invites は、アプリへの招待を実行し、共有を促進するための革新的なソリューションです。これまでに、この機能によってユーザーがアプリを見つけやすくなったと感じているという、とても喜ばしい結果が得られています。アプリに出会うきっかけは周りの人からの口コミだというユーザーが 52% である一方で、家族や友人から送られた App Invites は信頼するというユーザーは 92% にも達することが分かっています。この記事では、App Invites を使用してユーザー基盤を拡大している企業の成功事例をご紹介します。

Fabulous は、デューク大学の先進後知恵センターで行われた研究から生まれたアプリです。このアプリは不適切な行動を慎み、健全な習慣を身に付けるための取り組みを始め、最終的にはユーザーが健全に幸福な暮らしを送ることを支援します。

ユーザーはアプリ内で App Invites を活用し、自分の体験を友人や家族と共有しています。 今や App Invites によるインストール数は、招待によってFabulous アプリをインストールした数全体の 60% を占めるまでになっています。共有ボタンのクリック数も、App Invites が使われるようになってから 10% 増加しています。Fabulous のユーザー維持率にも増加が見られ、App Invites 経由でインストールしたユーザーの場合、アプリの顧客生涯価値 (LTV) は 2 倍になっているとのことです。Fabulous はシンプルなユーザー エクスペリエンスを実現しました。SMS と電子メールを1 つのインターフェースに統合したので、他のユーザーとのレシピの共有の操作が簡単になりました。

さらに、App Invites 経由で獲得したユーザーは、他のチャンネル経由のユーザーよりも、アプリを使い続ける可能性が 2 倍になることも分かりました。

Fabulous の最高技術責任者(CTO)の Amine Laddhari 氏は、「App Invites の導入はほんの 2~3 時間で完了しましたが、自力で同様のソリューションを構築した際は数日かかりました。とても分かりやすかったです」とコメントしました。

Fabulous の事例詳細はこちらをご覧ください。


Yummly は料理作りという行為を、パーソナル化した共有可能な体験ととらえている、レシピ検索プラットフォームです。ユーザー基盤を広げ、Android プラットフォーム上で認知度を高めることが望まれていました。Yummly は、ユーザーがこのアプリを家族や友人に紹介できるよう App Invites を導入し、特定のレシピやディナーのアイデア、買い物リストを共有する機能も追加しました。

App Invites を使った場合のインストール率は、他の共有チャンネルに比較して約 60% 向上しました。 その上 Yummly は、Google Analytics とのシームレスな統合も活用しています。こうした統合機能を有し、招待の送信や承認、最終的なインストールの数といったデータを正確に追跡できる共有チャンネルは App Invites だけです。

Yummly のプロダクトマネージャーである Melissa Guyre 氏は、「App Invites の統合プロセスはシームレスでした。Google Analytics との連携による秀逸な追跡機能は、思いがけない特典でした」とコメントしました。

Yummly の事例詳細はこちらをご覧ください。

App Invites は Android と iOS に対応しています。App Invites をアプリに組み込む方法は g.co/appinvites をご覧ください。

Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Google Play デベロッパー マーケティング、Lily Sheringham による Android Developers Blog の記事 "New features to better understand player behavior with Player Analytics" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Play ゲーム サービスには、Google Play デベロッパー コンソールから利用できる無料のレポートツールである Player Analytics が含まれており、プレイヤーの進行、購入、ゲームからの離脱などの状況を把握できます。このたび、Play ゲームサービスでの実装例として、Player Analytics がどのようなものかをご覧いただけるようになりました ...
[この記事は Google Play デベロッパー マーケティング、Lily Sheringham による Android Developers Blog の記事 "New features to better understand player behavior with Player Analytics" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Play ゲーム サービスには、Google Play デベロッパー コンソールから利用できる無料のレポートツールである Player Analytics が含まれており、プレイヤーの進行、購入、ゲームからの離脱などの状況を把握できます。このたび、Play ゲームサービスでの実装例として、Player Analytics がどのようなものかをご覧いただけるようになりました。Zombie Highway 2(ゾンビハイウェイ 2)を開発した Auxbrain 社の協力を得て製作した、新しいサンプル ゲームを Google Play デベロッパー コンソールからお試しください。このサンプル ゲームは、実際のゲームから無作為に抽出して匿名化したデータを使用しており、告知したばかりの新機能をご利用いただけます。注:サンプルゲームにアクセスするには、Google Playデベロッパーアカウント が必要です。


予測アナリティクスを使用してゲームからの離脱を防止し、ユーザー維持につなげる

プレイヤーの行動をさらに深く理解するため、Player Analytics の Player Stats API が拡張され、予測機能が追加されました。離脱予測メソッドはプレイヤーがゲームから離れる、つまりプレイを中止する確率に関するデータを返します。このデータに基づいてコンテンツを作成することにより、プレイヤーをゲームに引き留めることができます。また、購入予測メソッドは、プレイヤーが何かを購入する確率を返します。その結果に基づいて、アプリ内購入に対する割引の提供や、広告の表示などを実施できます。


新しいファネル レポートでチャートを作成し、イベント シーケンスを可視化する

ファネル レポートを使用して、実績、購入、カスタム イベントなどの任意のイベント シーケンスからファネル チャートを作成できます。たとえば、チュートリアル内の手順(チュートリアル ステップ 1、ステップ 2、ステップ 3 など)ごとにカスタム イベントを記録し、どのステップでチュートリアルを終了したかをファネル レポートに明示できます。


コホート レポートで変更の効果や新規ユーザーによる累積値を計測し、比較する

コホート レポートを使用すると、セッション、累積購入額、カスタム イベントなどの任意のイベントについて、新しいユーザーのコホートによる累積イベント値と比較できます。これは、ゲームモデルを決定する際に、その影響を分析できる貴重な情報となります。たとえば、変更前にゲームを開始したユーザーと、変更後にゲームを開始したユーザーを考察できます。変更の効果を計測または比較できるため、ゲーム内ストアでアイテムすべてを 2 倍の価格に設定した場合、変更後にゲームを開始したセッションの累積数が、変更前にゲームを開始したユーザよりも多くなったか、少なくなったかを確認することもできます。


C++ および iOS SDK と Unity プラグインのアップデートによる Player Stats API のサポート

C++、iOS SDK、Unity プラグインがアップデートされ、基本的なプレイヤーの統計、購入、離脱の予測を含む Player Stats API がサポートされるようになりました。サンプル ゲームを確認し、Play Games Services の詳細をご覧ください。ゲーム開発会社 Auxbrain が明かす、Google Play ゲームサービスで成功するための秘けつもご覧いただけます。

Posted by Khanh LeViet - Developer Relations Team

[この記事は混在コンテンツと戦っている Emily Stark、Green Lock Whisperer、Lucas Garron による Chromium Blog の記事 "Introducing the Security Panel in DevTools" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Web プラットフォームは Service Worker など新たな API の登場によって、ますます強力なものになっています。セキュリティ リスクは常に懸念事項であり、こうした新機能の多くは 安全なオリジンの使用を求めています。HTTPS を利用すれば、ウェブサイトの信頼性が保たれ、ユーザーとの接続が確実に暗号化されるようになります。HTTPS のデプロイをさらに容易にするため、Chrome 48 ベータ版で ...
[この記事は混在コンテンツと戦っている Emily Stark、Green Lock Whisperer、Lucas Garron による Chromium Blog の記事 "Introducing the Security Panel in DevTools" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Web プラットフォームは Service Worker など新たな API の登場によって、ますます強力なものになっています。セキュリティ リスクは常に懸念事項であり、こうした新機能の多くは安全なオリジンの使用を求めています。HTTPS を利用すれば、ウェブサイトの信頼性が保たれ、ユーザーとの接続が確実に暗号化されるようになります。HTTPS のデプロイをさらに容易にするため、Chrome 48 ベータ版では DevTools(デベロッパー ツール)に新しくセキュリティ パネルを追加しました。このバージョンは、今後数日かけて幅広く展開を進める予定です。

このセキュリティ パネルには、ネットワーク リクエストごとの接続情報が表示されており、安全な接続を表す緑色のロックマークにならない場合には、どの接続エラーが原因なのかがすぐ分かります。ページのオーバービューには、次のような情報が一覧表示されています。

安全ではない TLS 接続のデバッグだけでなく、サブリソースの状態の簡単なチェックも可能です。サブリソースをクリックすると、その接続のセキュリティ状態のほか、証明書の詳細も分かります。

新しいセキュリティ パネルについては、 Google Developers の記事をご覧ください。TLS は初めてという方は、まず Web Fundamentals のデベロッパー向けリソースをお読みください。

Chrome にはセキュリティの向上に役立つ機能が今後も追加される予定ですので、ご期待ください。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Wolff Dobson、デベロッパーアドボケート による Android Developers Blog の記事 "Play Games Permissions are changing in 2016" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

私たちは、プレイヤーがサインインした際になぜか処理が円滑に進まなかったり、不必要にパーミッション要求を送信したりする頻度を減らすことができるように、段階を踏んで Games API を新しいモデルに移行する作業を進めています。新しい操作は次のようになります。
  • 一度端末上でサインインすれば、プレイするゲームごとに毎度サインインする必要はなくなります。
  • Google Play のゲーム サービスを利用する目的で、アカウントを Google+ へアップグレードする必要はなくなります。
  • 最初にサインインすれば、次に別のゲームをプレイするときに再びサインインする必要はありません。次のゲームへのサインインは、自動的に実行されます。
  • 注: Google Play の各ゲームアプリの設定で自動サインインをオフにすることもできます。
[この記事は Wolff Dobson、デベロッパーアドボケート による Android Developers Blog の記事 "Play Games Permissions are changing in 2016" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

私たちは、プレイヤーがサインインした際になぜか処理が円滑に進まなかったり、不必要にパーミッション要求を送信したりする頻度を減らすことができるように、段階を踏んで Games API を新しいモデルに移行する作業を進めています。新しい操作は次のようになります。
  • 一度端末上でサインインすれば、プレイするゲームごとに毎度サインインする必要はなくなります。
  • Google Play のゲーム サービスを利用する目的で、アカウントを Google+ へアップグレードする必要はなくなります。
  • 最初にサインインすれば、次に別のゲームをプレイするときに再びサインインする必要はありません。次のゲームへのサインインは、自動的に実行されます。
  • 注: Google Play の各ゲームアプリの設定で自動サインインをオフにすることもできます。
メリット:
  • ユーザーは最初にサインインすれば、原則として新しいゲームをプレイする際は、サインインの操作が不要になります。
  • 各ゲームでサインイン用の認証画面を用意する必要はありません。サインインはゲームの起動時に自動的に実行されます。

ユーザーのプライバシーを尊重し、本名が知られないように、プレイヤー ID の管理方法も、以下のとおり変更します。
  • 既存のプレイヤーの場合: Google+ ID でゲームにサインインしている場合は、その情報が引き継がれます(以前のドキュメントには「プレイヤー ID」と書かれている場合があります)。
  • 初めてゲームをプレイするプレイヤーの場合: ゲームは新規のプレイヤー ID を取得します。これは、以前使用していた ID とは別のものです。

発生する恐れのある問題

ゲームのサービスが中断したり、内容が変わったりすることはほとんどありません。ただしごくまれに、変更が必要なゲームもあります。

現時点で分かっている問題と、実際にその問題が発生した場合の解決策を以下に挙げます。

問題の一覧
  1. 不必要な Google+ のスコープの要求
    • 問題: ユーザーに確認を求める不要なポップアップ ウィンドウが表示される。
    • 解決策: どうしても必要にならない限り、スコープの追加を要求しない。
  2. Google Play のプレイヤー ID のゲーム以外の Google API への流用
    • 問題: 他のエンドポイントから有効なデータが返されない。
    • 解決策: Google Play のプレイヤー ID をゲーム以外の Google API に流用しない。
  3. サーバー上でのモバイル / クライアントのアクセス トークンの使用
    • 問題: アクセス トークンに必要な情報が含まれていない場合がある。
      • そもそも、このトークンは使用すべきではない。
    • 解決策: 新規の GetServerAuthCode API を使う。

以下で、各懸案事項について詳しく説明します。

問題: 不必要なスコープの要求

以前のバージョンのサンプルとドキュメントでは、次のように GoogleApiClient を作成していました。
 // Don’t do it this way!  
 GoogleApiClient gac = new GoogleApiClient.Builder(this, this, this)  
           .addApi(Games.API)  
           .addScope(Plus.SCOPE_PLUS_LOGIN) // The bad part  
           .build();  
 // Don’t do it this way!  

この場合、 plus.login スコープを個別にリクエストすることになります。 アプリが plus.login を要求すると、ユーザーに確認を求めるダイアログが表示されます。

解決策: 必要なスコープのみを要求する

GoogleApiClient を作成する処理から、不要なスコープと利用しない API を削除します。
 // This way you won’t get a consent screen  
 GoogleApiClient gac = new GoogleApiClient.Builder(this, this, this)  
           .addApi(Games.API)  
           .build();  
 // This way you won’t get a consent screen  

Google+ ユーザーの場合

各プレイヤーが実生活で使用している Google+ のソーシャル グラフ機能にアクセスする場合など、アプリで Google+ 固有の機能を使用する場合、新規ユーザーがゲームをプレイする際に Google+ のプロファイルが必要になります(サインインしている既存ユーザーが再度確認を求められることはありません)。

ゲームに Google+ アカウントが必要な場合は、そのゲームの Games.API 宣言部を以下のとおり変更します。
 .addApi(Games.API, new GamesOptions.Builder()  
                       .setRequireGooglePlus(true).build())  

この操作を実行すると、ゲームは必要なパーミッションまたはスコープを要求する処理を継続し、各プレイヤーが実生活で使用している Google+ のソーシャル グラフや実名のプロファイルも継続して使用できます。

問題: プレイヤー ID の別の ID への流用

Games.getCurrentPlayerId() API を呼び出すと、サインイン中のプレイヤーを識別するために使う識別子が返されます。

従来この値は、 Plus.PeopleApi.load などの他の API に渡すことができました。新しいモデルでは、この動作が変更され、 プレイヤー ID は、Games API のみで有効となります。


解決策: ID を流用しない

Games API( com.google.android.gms.games からアクセスするもの)は、すべてプレイヤー ID を使用します。また、このプレイヤー ID のみを使用している限り、新しく追加された ID に対する動作も保証されます。

問題: サーバー上でのモバイル / クライアントのアクセス トークンの使用

次のようなパターンが使われることがあります。
  • GoogleAuthUtil を使ってアクセス トークンを取得します。
  • このトークンをサーバーに送信します。
  • サーバー側で Google を呼び出し、認証を検証します。この処理で最もよく実行される方法は、https://www.googleapis.com/oauth2/v1/tokeninfo を呼び出して応答を待つことです。
そもそも、この処理を実行することは推奨されていません。また、スコープの変更後は、推奨の程度がさらに下がります。

上記の処理が推奨できない理由は次のとおりです。
  • アプリは、そのユーザーが現在使用しているアカウントを認識しなければならないので、GET_ACCOUNTS パーミッションを保持する必要があります。この仕様のために Android M (Marshmallow) では、アプリの実行時に連絡先へのアクセス許可を求められ、ユーザーは非常に煩わしい操作を強いられることになります。
  • tokeninfo エンドポイントの設計は、このユースケースにはあまり向いていません。本来はデバッグ用のツールとして設計されたもので、本番環境用の API ではありません。この API の使用には、将来的に制限が課せられる可能性があります。
  • 新しいモデルでは、トークンから user_id が返されない場合があります。たとえ 返された としても、その値は新しいプレイヤー ID と同じものではありません(上記の問題 2 を参照してください)。
  • トークンはいつ失効してもおかしくありません(アクセス トークンの失効時期は保証されていません)。
  • サーバー上でクライアント トークンを使う場合は、そのトークンが別のアプリケーションに授与されていないかどうかを確認するため、より多くの検証チェックが必要になります。

解決策: 新しく公開された GetServerAuthCode フローを使う

この解決策は広く知られており、基本的にはウェブでサーバー側の認証方式として推奨されているものと同じです。

  1. Google Play 開発者サービス SDK を最新バージョン(8.4.87 以降)にアップグレードします。
  2. サーバーのクライアント ID を作成していない場合は、作成します。
    1. Google デベロッパー コンソールにアクセスし、対象のプロジェクトを開きます。
    2. 左側のナビゲーションから [API Manager]、[Credentials] の順に選択します。
    3. [New Credentials]、[OAuth Client ID] の順に選択します。
    4. [Web Application] を選択し、このアプリケーションに覚えやすい名前を付けます。
    5. この時点で、このウェブ アプリケーションのクライアント ID には、サーバーのクライアント ID が割り当てられています。
  3. ゲーム側から、通常どおりの手順で GoogleApiClient に接続します。
  4. 接続の完了後、以下の API を呼び出します。
    1. Games.getGamesServerAuthCode(googleApiClient, “your_server_client_id”)
    2. もともと GoogleAuthUtil を使っていた場合は、おそらくバックグラウンドのスレッドで呼び出しているはずです。その場合、次のようなコードとなります。

 // Good way  
 {  
      GetServerAuthCodeResult result =   
           Games.getGamesServerAuthCode(gac, clientId).await();  
      if (result.isSuccess()) {  
           String authCode = result.getCode();  
            // Send code to server.  
   }  
 }  
 // Good way  


  1. 認証コードをサーバーに送信します。手順は以前とまったく同じです。
  2. サーバー上で、 https://www.googleapis.com/oauth2/v4/token への RPC を実行し、アクセス トークンの認証コードの受け渡しを行います。この処理には、 Google API クライアント ライブラリを使うことができます。
    1. サーバーのクライアント ID、サーバーのクライアント シークレット(サーバーのクライアント ID を作成したときにデベロッパー コンソールに表示されていたもの)、認証コードを送信する必要があります。
    2. 詳細はこちらをご覧ください。
    3. 実際には、  Google API クライアント ライブラリ を使えばこの処理を簡単に行うことができます。
  3. アクセス トークンの取得後、そのトークンを使って www.googleapis.com/games/v1/applications/<app_id>/verify/ を呼び出します。
    1. 認証トークンは、以下の形式でヘッダーに埋め込みます。
      1. "Authorization:OAuth <access_token>"
    2. この処理で返された値に、そのユーザーのプレイヤー ID が含まれています。このプレイヤー ID が正しい値です。
    3. このアクセス トークンは必要に応じて、サーバー間通信で利用することができます。
アクセス トークンが既にウェブ アプリに発行されている場合、この API はステータス コード「200」のみを返します。

まとめ

重要な点は、明示的に Google+ の機能に依存するゲームでない限り、何もする必要がないということです。API の機能に変更はなく、ただサインインの操作がよりスムーズになるだけです。

ただし、次の点は考慮する必要があります。
  • Google+ スコープを要求していながら実際には使用していない場合は、今後はその要求を中止することを推奨します。
  • クライアントのアクセス トークンをサーバーに送信している場合は、 getGamesServerAuthCode() を使うことを強く推奨します。
ありがとうございました。これからも面白いゲームを制作してください。

Posted by Yoshifumi Yamaguchi - Developer Relations Team

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

この記事は Android での Google Sign-In の使用方法と、世界トップクラスのセキュリティを Android アプリで活用する方法について紹介するシリーズの 第 3 回です。 第 1 回 ...
[この記事はデベロッパー アドボケート、Laurence Moroney による Google Developers Blog の記事 "Using Google Sign-In with your server" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

この記事は Android での Google Sign-In の使用方法と、世界トップクラスのセキュリティを Android アプリで活用する方法について紹介するシリーズの 第 3 回です。第 1 回ではデベロッパーの皆さんにもできるユーザー エクスペリエンスの改善方法を取り上げました。第 2 回ではGoogle Sign-In API をクライアント側で変更し、プログラミング作業を大幅にシンプルにする方法について詳しく紹介しました。

今回の記事では、Google Sign-In をバックエンドで使用する方法をご紹介します。これを使うと自分のデバイスでサインインし、バックエンド サーバー上のデータにアクセスするユーザーを安全に認証できます。

サーバーでの認証情報を使用する

まず、ユーザーがアプリにサインインする際に何が起きるか見てみましょう。アプリにはバックエンド サーバーにアクセスするための認証も必要です。次のシナリオで考えてみましょう。ユーザーの自宅などへ食品を届けるアプリを開発したとします。ユーザーがアプリにサインインすると、アプリはユーザーの識別情報を取得します。ユーザーの住所とお気に入りはサーバーのデータベースに保存されます。

サーバーのエンドポイントが何らかの認証システムで保護されていない場合、攻撃者はユーザーの電子メールアドレスを推測するだけで、簡単にユーザーのデータベースを読み取ったり、書き込んだりできます。


図 1.第三者が偽の電子メールでサーバーにアクセス可能


これはユーザー エクスペリエンスが悪いというだけではなく、顧客データが盗まれ、悪用されるというリスクの問題でもあります。これを防ぐため、ユーザーがアプリにサインインする際に Google からトークンを取得し、このトークンをサーバーに渡すようにします。サーバーは、このトークンが本当に Google がそのアプリの正規ユーザー宛てに発行したものかどうかを確認します(オーディエンス設定に基づいて実行します。下図参照)。この時点でサーバーは、サインインしようとしているのがこのアプリの正規ユーザーであり、不正な攻撃者ではないことを確認できます。その後、サーバーは要求された詳細情報を返します。


図 2.第三者の偽のトークンを拒否する

このステップを見てみましょう。

ステップ 1: Google にサインインすると、Android アプリは ID トークン(*)を取得します。こちらはこのプロセスの一例です。これを実行するには、GoogleSignInOptions オブジェクトを作成するときに requestIdToken メソッドを呼び出します。

 GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)  
         .requestIdToken(getString(R.string.server_client_id))  
         .requestEmail()  
         .build();  
これには、サーバーのクライアント ID を取得する必要があります。この方法についての詳細は、こちらをご覧ください(ステップ 4 を参照)。

Android アプリで取得されたトークンは、HTTPS でサーバーに POST できます。次にサーバーはトークンを認証します。

(*)ID トークンは JSON Web Token であり、RFC7519 で定義されています。これは二者間の要求を安全に表現するためのメソッドであり、業界標準として公開されています。

ステップ 2: サーバーは Android クライアントからトークンを受け取ります。次にサーバーは、Google API Client ライブラリで提供されているメソッドを使用してこのトークンを認証します。このトークンが Google によって発行されたものであること、そして対象オーディエンスがこのサーバーであることが認証されます。

サーバーは GoogleIdTokenVerifier クラスを使ってトークンを認証し、その後、要求された識別情報データを抽出します。「sub」フィールド(getSubject() メソッドで取得する)では、安定した文字列識別子を取得できます。これを使用すれば電子メールアドレスが変更された場合でもユーザーを認証でき、データベースでユーザーを特定できます。ID トークン フィールドには他にも、名前、電子メールアドレス、写真へリンクされた URL などが利用できます。提供されたライブラリを使用してトークンを確認できる、Google App Engine でテスト済みのサーブレットのサンプルはこちらから入手できます。これらのライブラリを使えば、ネットワーク呼び出しがなくても、トークンをローカルで認証できます。

 GoogleIdTokenVerifier verifier = new GoogleIdTokenVerifier.Builder(transport, jsonFactory)  
      // Here is where the audience is set -- checking that it really is your server  
      // based on your Server’s Client ID  
      .setAudience(Arrays.asList(ENTER_YOUR_SERVER_CLIENT_ID_HERE))  
      // Here is where we verify that Google issued the token  
      .setIssuer("https://accounts.google.com").build();  
 GoogleIdToken idToken = verifier.verify(idTokenString);  
 if (idToken != null) {  
      Payload payload = idToken.getPayload();  
      String userId = payload.getSubject();   
      // You can also access the following properties of the payload in order  
      // for other attributes of the user. Note that these fields are only  
      // available if the user has granted the 'profile' and 'email' OAuth  
      // scopes when requested. Even when requested, some fields may be null.  
      // String email = payload.getEmail();  
      // boolean emailVerified = Boolean.valueOf(payload.getEmailVerified());  
      // String name = (String) payload.get("name");  
      // String pictureUrl = (String) payload.get("picture");  
      // String locale = (String) payload.get("locale");  
      // String familyName = (String) payload.get("family_name");  
      // String givenName = (String) payload.get("given_name");  
GoogleAuthUtil を使用してバックエンドに渡すトークンを取得している既存アプリをお持ちの場合、上記のような最新の ID トークン認証を行うライブラリやシステムに切り替える必要があります。サーバー側でのベスト プラクティスを実現するための推奨事項は、今後の記事でご紹介する予定です。

この記事では、認証テクノロジーを使用して、ユーザーの本人認証を行う方法を説明しました。次回の記事では、Google Sign-In API を認証に使用して、ユーザーがアプリやバックエンド サービスから Google ドライブ などの Google サービスへアクセスする方法などを説明する予定です。

Google の認証テクノロジーについての詳細は、デベロッパー向け Google Identity Platform サイトをご覧ください。

Posted by Eiji Kitamura - Developer Relations Team

一昨日は、 Study Jams プログラム Android アプリ開発コースシリーズをご紹介しました。今日は、Google Play Service 関連のコースをご紹介します。この 5 コースは目安学習期間が 2 週間と短く、それぞれのサービスについて短期間で学べるのが特徴です。Android アプリ開発者として、スキルアップを図りたい方にお勧めのコースです。

Google Location Services on Android【中級】
最適なモバイル経験を提供するためには、位置や状況にあわせてアプリをより良いものにすることが不可欠です。このコースでは、Location/Context API を活用して、位置情報に基いたアプリを作る方法を学びます。Fused Location Providerを使った実装、ユーザーが何をしているかを知ることができる Activity Recognition、 拡張現実でも利用されるGeofence について解説します。【目安学習期間】 2 週間
Google Analytics for Android【中級】
世界のどこで人々はこのアプリを利用しているのか、そして彼らはどのような時にアプリを利用するのか。このコースでは、利用状況に関するデータを Google Analytics に送信し、そのデータを分析する方法について学びます。合わせて、Google タグマネージャの利用方法も解説します。【目安学習期間】 2 週間
Monetize Your Android App with Ads【中級】
このコースでは、AdMob を利用してアプリをマネタイズする方法を学びます。なお、このコースを最大限に活用するには、Android アプリケーションの開発経験を持っている必要があります。
【目安学習期間】 2 週間
Add Google Maps to your Android App【中級】
モバイル デバイスで用いる地図は、近年、私たちの日常生活を大きく変え、私たちはいつでもローカルな地図から世界地図までを道一本に至るまで見ることができるようになり、3D の画像 で主要都市を飛び交うことも可能になりました。Android 開発者として地図機能をビルド、または拡張したいと考えている方におすすめのコースです。【目安学習期間】 2 週間
Add Google Sign-In to your Android Apps【中級】
このコースでは、Google Identity Platform の利用方法を学びます。Google Identity Platform を利用することによって、ユーザーのクレデンシャルを利用したサインインを許可したり、アクセス許可を承諾したデータへのアクセスの方法を学びます。サンプルアプリから、皆さんのアプリにこのサービスを拡張する方法も紹介します。【目安学習期間】 2 週間
一昨日は、Study Jams プログラム Android アプリ開発コースシリーズをご紹介しました。今日は、Google Play Service 関連のコースをご紹介します。この 5 コースは目安学習期間が 2 週間と短く、それぞれのサービスについて短期間で学べるのが特徴です。Android アプリ開発者として、スキルアップを図りたい方にお勧めのコースです。

Google Location Services on Android【中級】
最適なモバイル経験を提供するためには、位置や状況にあわせてアプリをより良いものにすることが不可欠です。このコースでは、Location/Context API を活用して、位置情報に基いたアプリを作る方法を学びます。Fused Location Providerを使った実装、ユーザーが何をしているかを知ることができる Activity Recognition、 拡張現実でも利用されるGeofence について解説します。【目安学習期間】 2 週間
Google Analytics for Android【中級】
世界のどこで人々はこのアプリを利用しているのか、そして彼らはどのような時にアプリを利用するのか。このコースでは、利用状況に関するデータを Google Analytics に送信し、そのデータを分析する方法について学びます。合わせて、Google タグマネージャの利用方法も解説します。【目安学習期間】 2 週間
Monetize Your Android App with Ads【中級】
このコースでは、AdMob を利用してアプリをマネタイズする方法を学びます。なお、このコースを最大限に活用するには、Android アプリケーションの開発経験を持っている必要があります。
【目安学習期間】 2 週間
Add Google Maps to your Android App【中級】
モバイル デバイスで用いる地図は、近年、私たちの日常生活を大きく変え、私たちはいつでもローカルな地図から世界地図までを道一本に至るまで見ることができるようになり、3D の画像 で主要都市を飛び交うことも可能になりました。Android 開発者として地図機能をビルド、または拡張したいと考えている方におすすめのコースです。【目安学習期間】 2 週間
Add Google Sign-In to your Android Apps【中級】
このコースでは、Google Identity Platform の利用方法を学びます。Google Identity Platform を利用することによって、ユーザーのクレデンシャルを利用したサインインを許可したり、アクセス許可を承諾したデータへのアクセスの方法を学びます。サンプルアプリから、皆さんのアプリにこのサービスを拡張する方法も紹介します。【目安学習期間】 2 週間


Study Jams への参加をご希望される方は、こちらからお申し込みください。

Posted by Takuo Suzuki - Developer Relations Team

[この記事は Sarah Clark、Google デベロッパー トレーニング プログラム マネージャーによる Android Developers Blog の記事 "Get ready for Javascript “Promises” with Google and Udacity" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

フロントエンド ウェブ デベロッパーは、一般的な「非同期」リクエストを使う際、いくつもの困難に直面します。URL の取得やファイルの読み込みといったこれらの非同期リクエストは、とくに複数のアクションを連続して行う場合に複雑なコードになりがちです。デベロッパーが非同期リクエストをもっと簡単に使えるようにするには、どうすればよいでしょうか。

JavaScript Promises は非同期コードを簡略化する新しいツールで、コールバックやイベント ハンドラーが絡み合ったコードを次のようにシンプルで分かりやすくします。

fetch(url).then(decodeJSON).then(addToPage)...
[この記事は Sarah Clark、Google デベロッパー トレーニング プログラム マネージャーによる Android Developers Blog の記事 "Get ready for Javascript “Promises” with Google and Udacity" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

フロントエンド ウェブ デベロッパーは、一般的な「非同期」リクエストを使う際、いくつもの困難に直面します。URL の取得やファイルの読み込みといったこれらの非同期リクエストは、とくに複数のアクションを連続して行う場合に複雑なコードになりがちです。デベロッパーが非同期リクエストをもっと簡単に使えるようにするには、どうすればよいでしょうか。

JavaScript Promises は非同期コードを簡略化する新しいツールで、コールバックやイベント ハンドラーが絡み合ったコードを次のようにシンプルで分かりやすくします。

fetch(url).then(decodeJSON).then(addToPage)...

Promise は Service WorkerFetch APIQuota ManagementFont Load EventsWeb MIDIStreams など、多くの新しいウェブ標準として使用されています。


Google は Udacity と共同で Promises のオンライン コースを開発し、公開しました。これは、約 1 日で完結する短時間のコースで、Promises を使ってライブデータの読み込みと表示を行う「Exoplanet Explorer」アプリの構築が体験できます。Fetch API の使い方も学べるので、このコースを終えれば、XMLHttpRequest とはお別れです。

この短期コースはシニア ウェブ デベロッパー Nanodegree コースの 必須科目でもあります。Nanodegree コースの受講は有料ですが、本コースを単体で受講する場合は無料です。どちらかのコースを受講して、コードをよりシンプルに、信頼性を高くする方法を本日から学びませんか。

無料コースのお申し込みはこちらから。

※ 無料コースのご受講は、Udacity の受講を推進する Study Jams プログラムの一貫となります。上記の Study Jams 申し込みフォームに必要事項をご記入いただき、参加コースを「[上級] JavaScript Promises (ud898) 」としてご登録ください。その後、Udacity コース申し込みリンクをお送りします。 

Posted by Takuo Suzuki - Developer Relations Team

先日 紹介した Study Jams プログラムでは、多彩なコースを受講することができます。おすすめのコースの 1 つが、Android アプリ開発コースシリーズです。初級から上級までの3コースがあります。

Android アプリを構築する方法を学びたいがプログラミングは初めてという方、もしくはプログラミング経験はあるけれど、Android アプリの構築は初めてという方を対象としています。このコー​​スでは、2 つの簡単なアプリケーションを作成します。Android アプリ開発者になるためのスタートとしてこのコースはきっと役に立つでしょう。3 レッスン +  2 演習から構成されます。【目安学習期間】4 週間
Android の基礎を、理論と実践の両面から学ぶことで、優れたアプリを構築するスキルを習得することができます。6 レッスン +  1 プロジェクトを通じて、ステップバイステップで Android アプリを開発するための最良の方法を実践的に学びます。Java、またはその他のオブジェクト指向プログラミング言語(例: C++、Objective C 、Pythonなど)の経験が 1 年以上ある方を対象としています。【目安学習期間】10 週間
Advanced Android App Development【上級】


このコースでは、中級コース「Developing Android Apps」で作成したお天気アプリ「Sunshine」を利用して、Android アプリの製品化プロセスを学びます。Android のアプリ品質ガイドライン、マテリアルデザイン、イメージのハンドリング、プロファイリングなどについても触れます。Android の開発者として、ユーザーに利用してもらえる製品レベルのアプリを作るための方法を学ぶことができます。少なくとも1〜2年のJava の経験および Android アプリの開発経験が必要です。【目安学習期間】6 週間
先日紹介した Study Jams プログラムでは、多彩なコースを受講することができます。おすすめのコースの 1 つが、Android アプリ開発コースシリーズです。初級から上級までの3コースがあります。

Android アプリを構築する方法を学びたいがプログラミングは初めてという方、もしくはプログラミング経験はあるけれど、Android アプリの構築は初めてという方を対象としています。このコー​​スでは、2 つの簡単なアプリケーションを作成します。Android アプリ開発者になるためのスタートとしてこのコースはきっと役に立つでしょう。3 レッスン +  2 演習から構成されます。【目安学習期間】4 週間
Android の基礎を、理論と実践の両面から学ぶことで、優れたアプリを構築するスキルを習得することができます。6 レッスン +  1 プロジェクトを通じて、ステップバイステップで Android アプリを開発するための最良の方法を実践的に学びます。Java、またはその他のオブジェクト指向プログラミング言語(例: C++、Objective C 、Pythonなど)の経験が 1 年以上ある方を対象としています。【目安学習期間】10 週間
Advanced Android App Development【上級】


このコースでは、中級コース「Developing Android Apps」で作成したお天気アプリ「Sunshine」を利用して、Android アプリの製品化プロセスを学びます。Android のアプリ品質ガイドライン、マテリアルデザイン、イメージのハンドリング、プロファイリングなどについても触れます。Android の開発者として、ユーザーに利用してもらえる製品レベルのアプリを作るための方法を学ぶことができます。少なくとも1〜2年のJava の経験および Android アプリの開発経験が必要です。【目安学習期間】6 週間


なお、初級コースには日本語字幕がついています。スマートフォンでもなじみのある Android アプリ。この機会に、アプリ開発に挑戦してみませんか。

Study Jams への参加をご希望される方は、こちらからお申し込みください。

Posted by Takuo Suzuki - Developer Relations Team

[この記事は Nathan Martz、Google Cardboard プロダクト マネージャーによる Android Developers Blog の記事 "Spatial audio comes to the Cardboard SDK" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

人間は、消防車が近づいて来る音から飛行機が上空を通過する音まで、あらゆる方向からの音を感じています。先月から、Unity および Android 用の Cardboard SDK に 3D オーディオ機能のサポートが追加され、仮想現実(VR)アプリでも現実のようなオーディオ体験ができるようになりました。必要なのは、スマートフォンと一般的なヘッドフォン、そして Google Cardboard だけです ...
[この記事は Nathan Martz、Google Cardboard プロダクト マネージャーによる Android Developers Blog の記事 "Spatial audio comes to the Cardboard SDK" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

人間は、消防車が近づいて来る音から飛行機が上空を通過する音まで、あらゆる方向からの音を感じています。先月から、Unity および Android 用の Cardboard SDK に 3D オーディオ機能のサポートが追加され、仮想現実(VR)アプリでも現実のようなオーディオ体験ができるようになりました。必要なのは、スマートフォンと一般的なヘッドフォン、そして Google Cardboard だけです。

現実の音を再現

多くのアプリは、左右それぞれのスピーカーから音声を再生する方式による、3D オーディオの簡易版を用いますが、今回の SDK のアップデートでは、人間が実際に音を聞いているのと同じ方法で、アプリがサウンドを作り出せるようになります。たとえば、
  • 聞き手の頭部の生理機能と仮想的な音源の位置の両方を考慮して、ユーザーに聞こえる音を調整します。たとえば、右側から来る音は、ユーザーの左耳にはわずかに遅れ、高周波域要素が少なくなって届きます(高周波音は、通常、頭蓋骨により減衰されるため)。
  • 音質の向上につながる仮想環境のサイズや素材を指定できるので、狭い宇宙船内での会話と、巨大な地下の洞窟内での会話との違いを(仮想であることに変わりはありませんが)明確に表現できます。

最新のスマートフォンに最適化

今回のアップデートは、パフォーマンスに配慮して設計しました。アプリに 3D オーディオ機能を追加しても、プライマリ CPU (アプリの大部分の作業が行われる場所)への影響は最小限です。以下の 2 つの方法で、これらの結果を実現しました。
  • モバイル CPU(例:SIMD インストラクション)に対して最適化されており、オーディオのリアルタイム計算は別のスレッドで実行するため、処理のほとんどはプライマリ CPU 以外で行われます。
  • サウンドの忠実性を各サウンドごとに制御できるので、重要なサウンドには多くの処理能力を割り当て、それ以外の音声には割り当てを少なくするよう調節できます。

シンプルなネイティブ アプリ連携

この SDK の新しいオーディオ機能を導入するのは実に簡単です。Unity デベロッパーは Android、iOS、Windows、OS X 上にサウンドスケープを作り出す、多彩なコンポーネントを利用できるようになり、Android アプリのデベロッパーは、シンプルな Java API を利用して、仮想サウンドと環境をシミュレーションできるようになります。

デベロッパー向けサンプル アプリで 3D オーディオを体験


Android サンプル アプリ(デベロッパーの参照専用)の体験版を使用して、Cardboard デベロッパー向けサイトのドキュメントを読み、3D オーディオを今すぐ実感してください。デベロッパーの皆さんが創り出す新しいエクスペリエンスを見る(そして聴く)のを楽しみにしています。

Posted by Eiji Kitamura - Developer Relations Team

Addy Osmani は Twitter のフォロワー数 10 万人を誇るフロントエンド界隈の有名人で、 Google の Staff Engineer です。 JavaScript デザインパターンの執筆者としてご存知の方も多いかもしれません。 TodoMVCWeb Starter KitYeomanMaterial Design Lite といったオープンソースプロジェクトに携わってきました。そんな彼は、数多くの開発に役立つツールを使い分けることでも有名で、 Totally Tooling Tips ...
Addy Osmani は Twitter のフォロワー数 10 万人を誇るフロントエンド界隈の有名人で、 Google の Staff Engineer です。JavaScript デザインパターンの執筆者としてご存知の方も多いかもしれません。TodoMVCWeb Starter KitYeomanMaterial Design Lite といったオープンソースプロジェクトに携わってきました。そんな彼は、数多くの開発に役立つツールを使い分けることでも有名で、Totally Tooling Tips というビデオシリーズも公開しています。

今回はそんな彼が普段使っているツール類についてインタビューしましたのでご紹介します。ぜひみなさんの開発環境の参考にして下さい。

OS / Hardware は何を使っていますか?

El Capitan の Mac をメインで使ってます。最近は、週の半分 Windows も使っています。Microsoft Surface Pro 3 の Windows 10 です。
ブラウザはすべてのチャンネルの Chrome、Firefox の Stable と Nightly、Opera も Stable と Next、Safari と WebKit Nightly を使っています。Mac の VM には Windows 7、8.1、10 を入れて、なるべく多くのバージョンの IE と Edge を試せるようにしています。

Mac で使っているツール類を教えてもらえますか?

Alfred

Alfred は欲しい物をすぐに探せるプロダクティビティツールです。ショートカットを設定することでアプリケーションのコントロールができたりします。プラグインに巨大なエコシステムがあって、例えば Zeno Rocha のプロジェクト alfred-workflows で便利なプラグインを多数ダウンロードすることができます。
SublimeText のプラグインはもちろん、Package Managers では、npm、bower、gulp などのパッケージやプラグイン、CanIUse など、手先の操作でいろんなものを検索して利用することができます。他にも Colors で色のプレビューをしたり、Dashドキュメントを検索したりといったこともできます。

Spotlight / Flashlight

Alfred の代替として最近注目しているのが Spotlight です。Spotlight は Mac 標準の検索ツールで、Yosemite で Apple が大幅な機能追加をしたことで、Alfred の基本的な機能と同程度であれば、これで十分使えます。Flashlight というアプリを使えば、Spotlight にプラグインアーキテクチャを持ち込むことができるので、ウェブサイト内を検索をしたり、ノートを取ったり、リマインダーを設定したりといったことが Spotlight 内でできるようになります。

BetterTouchTool

BetterTouchTool は Mac 用のトラックパッドで、ジェスチャーをカスタマイズできるツールです。例えば 2 本指で横にスワイプするジェスチャーで Chrome のような特定のアプリを起動するといった用途に使うことができます。Yosemite のデフォルト設定よりもパワフルなのが特徴です。

Spectacle

最近はウィンドウ管理も重要になってきています。小さな画面を有効に活用するためには、画面をうまく分けたいですよね。そんな時に使えるのが Spectacle です。キーボードショートカットと組み合わせて使うことが多いのですが、みんなが使いたいようなオプションは大体揃っています。画面の左右半分に表示したいとか、そんな場面に便利です。

Sip

私はデザインすることもあるのですが、アプリやデモ、プレゼンテーションなどで適切なカラーパレットを使う必要があります。システムワイドで使えるカラーパレットツールとして使っているのが Sip です。最後に使った色のセットを覚えておいてくれるところが便利です。また、設定項目がたくさんあって、どんな色の組み合わせをデフォルトにしたいのかを選ぶことができます。今となっては Chrome 本体の DevTools が Color Picker 機能を提供しているので、以前と比べて使う機会は減りましたが、それでも便利なツールです。

Sketch + Framer.js

プロトタイピングとデザインをするのに使っているのは、Bohemian Coding の Sketch です。複数アートボード、ベクター、SVG 出力、グリッドなどのサポートが充実しているため、Framer.js と合わせて愛用しています。Framer.js は CoffeeScript に似たハイレベル言語を使ってモーションプロトタイプが作れるツールです。実はこれ、Google のデザイナーの間でもすごく人気で、広く使われています。例えばこの Material Design Contacts のサンプルアプリを見てみると、ただのプロトタイプにも関わらず、ブラウザでスクロールの動作を試すことができます。Framer.js がコピーペーストできるコードを生成してくれるわけではありませんが、デザイナーはこれをデベロッパーに渡すことで、最終的なコードを書いてもらうことができます。

Dr.Cleaner

たくさんのアプリを立ち上げていると、メモリ不足が問題になることがあります。TrendMicro が提供している無料の Dr.Cleaner を使えば、メモリとディスクの使用量を最適化してくれます。

Mou

ブログポストを書く時、Markdown アプリの Mou を使っています。Mou はシンプルな UI で、片側にソース、もう片側にプレビューを表示します。コードのハイライト機能もあります。HTML、PDF へのエクスポートにも対応していて、Tumblr にもポストできます。私はこれでポストを Google Drive や Dropbox に保存しています。もちろん GitHub Flavored Markdown にも対応しています。

ImageOptim

開発者ならフル解像度の画像を受け取るケースが多いと思います。ビルドプロセスでデバイスに合わせた解像度の最適化ができるのがもちろん良いのですが、ちょっとだけ試したい場合もありますよね。そういった時に使うのが ImageOptim です。PNGOut や PNGCrush、OptiPNG など、最新のツールもサポートしています。

Chrome Extension は何を使っていますか?

SnappySnippet

SnappySnippet は DOM から直接 CSS や HTML を抜き出すことができる拡張機能です。例えばあるページにとても素敵なボタンがあって、それがどうやって作られているのか知りたいと思ったとします。そんな時にこれを使って DOM ノードを選択すると、再現するのに必要な CSS と HTML を抜き出してくれる、というわけです。また、JSBin のような別サーバーへの送信機能もサポートされています。

DOMListener

TodoMVC のテストに DOMListener が大活躍しています。これは DOM の変更点を監視、ブラウズ、フィルタすることができる拡張機能です。DevTools の Timeline  で変更点を監視するのによく似ていますが、DOMListener では同じことを DOM の変更に対して行うことができます。例えばシングルページアプリケーションで 新しい UI ピースを挿入したり、新しいビューを差し込んだりした場合、どんな DOM コンテントが追加されたのか、スタイルやテキストコンテントが追加されたのか、確認したり、フィルターすることもできます。これによりデバッグが非常に簡単になります。問題が発見できたら、DevTools に戻ってくる、というワークフローはとても便利です。

The Great Suspender

これはある意味私の生活を変えた拡張機能です。Chrome チームが消費メモリーの最適化に取り組んでいることはご存知と思います。作業は順調に進んでいるようですが、そうしている間にも、私のようにタブを大量に使う人間にとっては、これらのタブを消す必要があります。そこで役立つのが The Great Suspender です。
これはタブを一定時間後に自動的に一時停止することで、Chrome のメモリや GPU のフットプリントを削減してくれるツールです。例えば 50 個のタブが開いていたとしても、実際に同時に使うのは 2 〜 3 個です。この拡張機能はそういったタブを軽量のプレースホルダーページに置き換え、Chrome が表示する必要のないページを見せないことでメモリーの消費を抑えてくれるものです。そしてバッテリーにも優しい。使い続けたいタブに戻ると、リロードするリンクが表示され、その URL に戻ることができます。
この拡張機能に何より感謝しているのは、そういったタブに自分が滅多に戻らないということを教えてくれたことです。ページを開いても、実際に自分がそこに戻ることは非常に少ないということに気付かせてくれました。

Page Ruler

Page Ruler は Polymer チームの同僚がおすすめしてくれた拡張機能です。あるページを開いていて、何かのサイズを測りたい場合は、クリックしてエリアを選択するだけ。画面下部にバーが表示されて、幅や高さ、上下左右位置といった様々なサイズ情報を教えてくれます。もちろんガイドを表示するかも選ぶことができます。


全二回のインタビューの前編として、今回はツール編をお届けしました。後編は開発環境編として、エディタやプラグイン、シェルについてのインタビューをお届けします。


Posted by Eiji Kitamura - Developer Relations Team