[go: nahoru, domu]

Google では 4 月 9 日(木)、六本木ヒルズにおいて、Google のテクノロジーにフォーカスした開発者向けイベントを開催いたします。本イベントでは、Google のエンジニアや Google Developer Expert が、Googleの開発プラットフォーム、API、SDK、ツールなどの活用方法をご紹介します。

■イベント概要
【イベント名】 Google Developers Summit Tokyo 2015
【日程】 2015 年 4 月 9 日(木) 9:30 - 17:00 (開場: 9:00)
【場所】六本木アカデミーヒルズ、東京都港区六本木 6-10-1 六本木ヒルズ森タワー
【定員】300 名

プログラムの一部のご紹介

  • 多様化するデバイス環境から考えるユーザー体験とエコシステム
  • ユーザーを魅了するネイティブアプリ経済圏の広がり 〜 モバイル、ウェアラブル、リビングルーム
  • Google Cloud Platform で知る Google クラウドの「Google らしさ」
  • Introduction of Material Design
  • Mix Channel でマテリアルデザインを活用した事例
  • Android Wear でのアプリ開発手法
  • Service Worker で作る最新モバイル Web エクペリエンス
  • App Indexing を使って検索結果からアプリへ
  • Android TV で実現するリビングルームでのアプリ体験
  • Uplevel with Google Play Games
  • Firebase によるリアルタイムモバイル開発

※プログラムは予告なく変更させていただく可能性があります。予めご了承ください。

本イベントの詳細および参加のお申し込みは、こちらのサイトをご覧ください。
※定員に達したため参加登録は終了いたしました。

ご参加いただける方には、参加証を 4 月 6 日(月)より順次ご登録頂いたメール アドレス宛にお送りする予定です。

それでは、みなさまのご参加を、心よりお待ち申し上げております。

Posted by 鈴木拓生 Developer Relations Team

[この記事は Greg Hartrell、Google Play ゲーム、シニア プロダクト マネージャーによる Android Developers Blog の記事 "New Tools to Supercharge Your Games on Google Play" を元に、荒木が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

今では誰もがゲームのできる端末を持っています。実際、世界 190 ヶ国以上で 10 億人を超える Android ユーザーのうち、3/4 以上が日常的にゲームをしています。つまりゲーム デベロッパーにとって、世界規模でユーザーを募り、アプリの開発をビジネスとして成功させるまたとないチャンスと言えます。Google は過去数年にわたり、Google Play で提供されるアプリやゲームのデベロッパーに対して 70 億ドル(約 8 千億円)以上の投資を行ってきました。

Google の Developer Day のゲーム デベロッパー カンファレンス(GDC)では、ゲームをさらに充実させる Google Play ゲームや AdMob の新しい機能の数々を公開しました。これらの新しい機能によって、ゲーム開発におけるさらに優れた基準や収益化の手法が提供されていきますので、ご注目ください。

より優れた基準とプレイヤーのニーズへの対応

“Player Analytics のおかげで BombSquad に足りないところを分析し、間違った方向を修正し、結果として作りたいゲームを作って経済的に成功できるところまでたどり着くことができました”
BombSquad 開発者、Eric Froemling
Google Play Games は、ゲーム デベロッパーが作品をユーザーに届けることをサポートするサービスです。このサポートの一環として Player Analytics を提供しています。Player Analytics では、ビジネスの成功に対する総合的な基準を提示し、ゲーム内でのプレイヤーの動きを分析する優れたレポートを提供しています。今後数週間のうちに Google Play デベロッパー コンソールで公開されるこのツールの新しいリリースを使えば、個人デベロッパーでも大規模な開発者集団でも、自身のゲームのユーザーがどのようにゲームを進め、支払い、親しんでいるかについての詳細を ARPPU やユーザーごとのセッション数などの重要な指標を元に確認し、日ごとの売上目標を設定するサポートを受けることができます。

BombSquad はサンフランシスコにある個人のゲーム スタジオで作成されたゲームですが、Player Analytics ベータ テスト中に受けたデザイン変更のアドバイスに従うことで、Google Play でのユーザー 1 人あたりの収益を倍以上にすることに成功しています。

広告を最適化して収益をあげる

ゲームのパフォーマンスを最適化した後は、ユーザーごとに適した収益化の手法を構築することが重要です。これが今回、AdMob プラットフォームで次の 3 つの重要なアップデートを行う理由でもあります。
  • Native Ads: 現在はベータ版として機能が限定されていますが、ゲーム デベロッパーが Google 広告からアプリに広告を表示できるようになります。表示する広告はカスタマイズしてゲームのデザインに沿った形でユーザーに提示できます。Atari は RollerCoaster Tycoon 4 Mobile などの既存のゲームを刷新する方法を探しており、この新しい機能を使ってより効果的にゲームのファンを増やす方法を模索しています。
  • In-App Purchase House Ads Beta: ゲーム デベロッパーが無料で、アプリ内購入の収益を伸ばすことができます。AdMob では、どのユーザーがアプリ内購入をしやすいかを予測できるようになり、デベロッパーはそうしたユーザーにカスタマイズしたテキストを表示したり、売り出し中のアイテムを強調して表示したりできます。現在はベータ版ですが、今後数週間のうちにすべての AdMob アカウントで使用できるようになります。
  • Audience Builder: ゲームの使用状況に応じて、ユーザーのリストを作ることができる便利なツールです。ゲーム デベロッパーはこのリストを元に対応していくことで、ゲームをさらにおもしろくし、最終的にはアプリの収益を伸ばしていくことができます。

"Atari は幅広いゲーム ユーザーを対象におもしろいゲームを作っています。Google のパートナーとして、Native Ads ベータ版に参加する最初のゲーム会社になれて光栄です。このツールによって、ゲームをさらにおもしろくしながら同時に収益化するサポートが受けられます"

Atari、最高執行責任者、Todd Shallbetter

Google が促す新しいゲーム体験

昨年 Google は、リビング ルームの Android として大画面でゲームを楽しむことができる Android TV のサービスを開始しました。Sony、TPVision/Philips、Razer などのパートナーから、SmartTV やマイクロ コンソールなどの協力を受け、OEM のエコシステムはより大きく成長しています。

Google ではさらに Nearby Connections API の提供を開始し、Android TV でさらにダイナミックにゲームを楽しむことができるようにします。こちらは Google Play サービスで近日中に公開する予定です。この新しいプロトコルを使うと、テレビでプレイ中のゲームを近くのスマートフォンやタブレットにシームレスにつなげて、セカンド スクリーンとして制御できるようになります。Beach Buggy Racing は複数のプレイヤーで競える Android TV の面白いレースゲームですが、今年の夏のリリースで Nearby Connections の採用を予定しています。Google ではさらに多くのマルチプレイヤー ゲームの協力を募っており、携帯端末をセカンド スクリーン コントロールとして活用してリビング ルームでさらにゲームを楽しめるようにしていきたいと考えています。

昨年 6 月の Google I/O において、バーチャル リアリティ(VR)をさらに身近なものにすることを目標に、Google Cardboard の公開も行いました。これは単なる厚紙をスマートフォンと組み合わせて使用するだけのものですが、ゲーム デベロッパーがさらに独特で迫力のあるゲームを作成する機会を提供します。Android 版、Unity 版の各 Cardboard SDK によって、さらに容易にバーチャル リアリティのアプリを作成でき、また既存のアプリをバーチャル リアリティ化することができます。


Posted by Yuichi Araki - Developer Relations Team

[この記事は Timothy Jordan、デベロッパー アドボケートによる Android Developers Blog の記事 "Building for Android Wear: Depth and Flexibility" を元に、萩倉が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Android Wear では、最近とても多くのアップデート進化がなされているため、概要をまとめてこちらでお伝えします。その進化はまだ終わっておらず、今後さらに多くの機能が追加されていきますので、ここで説明するのは現時点での概要です。Android Wear の開発を始めるうえでもそのまま続けるうえでも、その画期的な使い心地を実現するための参考にしてください。

Android Wear プラットフォームでは、奥行き(depth)と柔軟性(flexibility)を強調しています。使い慣れた API を使用して、便利で高性能な、アイデアに富んだアプリを Android が組み込まれた時計で実行できます。Android の基本的な考えに則り、カスタム ウォッチ フェイスの作成など、ユーザーの使用感が変わるような変更を自由に行うことができます。そうした変更は主に、アプリ、ウォッチ フェイス、通知の 3 つのカテゴリで行えます。

アプリ

Android Wear で作成されるアプリは時計で直接実行され、走った距離の計測からバスを待つ間の息抜きまで、携帯端末でできることとほぼ同じことができます。フィットネスや音楽アプリなどは、携帯端末への接続すら必要ありません。携帯端末とウェアラブル端末でデータを移行したり、おもしろくて柔軟な UI を作成したりするためのライブラリも提供されています。次のような優れた機能を使うことができます。


機能 ドキュメント
全画面でのタッチ操作によるアクティビティ Creating Custom UIs for Wear Devices
通知とカスタム アクション UI Patterns for Android Wear
カスタム ウォッチ フェイス Creating Watch Faces
丸い端末や四角い端末向けのレイアウト Creating Custom UIs for Wear Devices
OpenGL Displaying Graphics with OpenGL ES
センサー
  • アクセレロメーター(Accelerometer)
  • ジャイロスコープ(Gyroscope)
  • コンパス(Compass)
  • バロメーター(Barometer)
  • 心拍センサー(Heart rate sensor)
SensorManager
触感 Vibrator
マイクロフォン AudioRecord
音声アクション Adding Voice Capabilities
GPS Detecting Location on Android Wear
オフラインでのデータ保存 / 音楽 Transferring Assets
メディア再生コントロール MediaSessionMediaController
Android 5.0 API 21 でのフレームワーク Android 5.0 APIs
スタンドアロン アプリや同期されたアプリ Sending and Syncing Data

ウォッチ フェイス

カスタム ウォッチ フェイスを作成すれば、ユーザーの個人的な端末で際立つ UI 要素を使うことができます。シンプルな API ですばやくウォッチ フェイスを構築でき、パーソナライズも柔軟に行えます。つまり、Android プラットフォームの奥行きと柔軟性によって、美しく独特な機能がユーザーに提供されます。

開発工程はまずデザインから始まりますが、自分のデザインを簡単に Android に適用できます。Watch face API の主要機能として onDraw メソッドがありますが、そちらを使えばキャンバスで思い描いたデザインを高フレームレートで描くことができ、流れるようなアニメーションを実現できます。これは、時計がインタラクティブ モードであれば完全な忠実さで行うことができます。

アンビエント モードのときは、より控えめにウォッチ フェイスを描画します。その他の環境設定でも、お使いのデザイン応じた UI 要素を用いるように設定できます。さまざまな基礎機能が提供されていますので、あとはユーザーの想像力だけです。月の満ち欠け、気象情報、フィットネス データなども追加できます。こうした機能は、時計職人からは「コンプリケーション」(複雑なもの)と呼ばれますが、Android ではそれほど複雑ではありません。時刻と同じように、データがあればそれをキャンバスに描くだけです。

通知

Android Wear の通知はウェアラブル開発のはじめの一歩と言えます。Android アプリで通知を作成した場合、身につける時計端末でもそのまま動作します。通知に何らかのアクションを加えている場合、ウェアラブルではさらに効果的です。これらもそのまま動作します。スタック、ページ、音声応答など、ウェアラブルに特有の機能を使うことで、腕時計で通知をより豊かに表現できます。

Android プラットフォームの機能や柔軟性のおかげで、Android Wear でもさらに快適な使い心地が実現します。使い始めれば、ユーザーに素晴らしい UI を届けられます。同時に、時計の種類や、時計を身につける人々と同じように多種多様な操作性で、そのエコシステムを築いていくこともできます。


詳細についてはビデオドキュメントををご覧ください。また、Android Wear のデベロッパー コミュニティでご意見などもお待ちしています。Android Wear で皆さんが作成する、かつてない作品に出会うのを楽しみにしています。

Posted by Takeshi Hagikura - Developer Relations Team

[この記事は 2015 年 3 月 2 日に Ian Lake、デベロッパー アドボケートが Android Developers Blog に投稿した "Google Play services 7.0 - Places Everyone!" を元に、荒木が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Play サービス 7.0 の公開と、より良いアプリを作成するための新しいツールをご紹介します。このリリースでは、ロケーション設定の改善、位置情報設定の新しい API、新しいフィットネス データ、AdMob と Google アナリティクスの自動統合、Google Play ゲーム、その他多数の機能が盛り込まれています。

ロケーション設定ダイアログ

FusedLocationProviderApi には複数のセンサーが備えられ最適な位置情報を提供できるようになっていますが、アプリが受信する位置情報の正確性は依然として端末で有効な設定の種類(GPS、wifi、機内モードなど)に大きく左右されます。Google Play サービス 7.0 では、正常に LocationRequest が処理されるために必要なロケーション設定が有効であるかどうかを確認する標準的なメカニズムが導入されています。ロケーション設定に変更が必要な場合、アプリを開いたままユーザーがワンタッチで設定を変更できるようになります。
たとえば Google マップに位置情報の設定ダイアログを組み込んだことで、正しい位置情報を使用できるユーザーの数が劇的に増加したように、この API を使えば特にアプリの操作性に位置情報が極めて重要な場合に、ユーザーの使い心地が大幅に改善されます。

Places API

位置情報は単に緯度と経度だけではありません。新しい Places API では、Google のデータベースからその場所やビジネスの情報を簡単に入手できます。組み込みの Place Picker によって、ユーザーが現在の位置についての情報やその場所に関連した情報、たとえば場所の名前、住所、電話番号、ウェブサイトなどを簡単に得られるようになります。
アプリで独自の UI にする場合、getCurrentPlace() API を使えばユーザーの現在位置周辺の情報が返されます。また、アプリでの検索速度を早めるオートコンプリート予測も備えています。
加えて、addPlace() API を使えば場所を手動で追加してユーザーの現在地を通知できます。どんな場所にいても新しく発見したお気に入りの場所を共有することが可能です。
さらに、Places API はクロス プラットフォームに対応しています。まもなく iOS ベータ プログラムにも対応しますので、モバイル プラットフォーム全体でまったく同じようにアプリを使えるようになります。

Google Fit

Google Fit を使えばフィットネス アプリを簡単に作成できます。フィットネス専用の API を使うことで、現在位置や移動するスピードなどのセンサーデータを取得したり、アクティビティ データを集めて Google Fit のオープン プラットフォームに保存したり、それらのデータを自動的に集積してユーザーのフィットネス データを 1 つのビューに表示したりできます。
Google Play サービス 7.0 では、ご利用の GoogleApiClient に送った以前の Fitness.API は、次のような Google Fit Android APIs の優れた API セットに置き換えられます。
  • SensorsApi で生のセンサー データを取得する SENSORS_API
  • RecordingApi でデータを保存する RECORDING_API
  • HistoryApi でデータの挿入、削除、読み込みを行う HISTORY_API
  • SessionsApi でセッションを管理する SESSIONS_API
  • BleApi を使って Bluetooth Low Energy (BLE) 端末と通信する BLE_API
  • ConfigApi でカスタム データ タイプや Google Fit 設定を操作する CONFIG_API
この変更で Google Fit のメモリ使用量が大幅に減少し、アプリをバックグラウンドで実行できるようになります。Google Play サービスの以前のバージョンで作成されたアプリにも引き続き対応しますが、今回の変更を最大限に活用するため、Google Fit アプリの再構築を強くお勧めします。
すべてのデータをそろえれば、今回の変更のメリットを実感していただけるでしょう。Google Fit ではさらに 既存のデータタイプを増やし、体脂肪率や睡眠データも追加しています。

Google Mobile Ads

昨年 AdMob の Google アナリティクスのサービスを開始して以来、AdMob と Google アナリティクスを組み合わせて使うことで、ユーザーが実際にアプリをどのように使用しているか詳しく分析できるようになりました。今回の新しいリリースによって、Google Mobile Ads SDK を実装すれば自動的に Google アナリティクスが統合され、ユーザーやセッションの数、セッションの時間、アプリが実行されたオペーティング システム、端末のモデル、位置情報、自動の画面レポート機能などを、一切の追加の開発作業をせずに使うことができるようになります。
加えて、広告リクエストの先読み機能(バッテリー使用の軽減と待ち時間の短縮)や MRAIDv2 への適合など、数々の改善が組み込まれています。

Google Play ゲーム

ゲーム デベロッパー カンファレンス(GDC)で発表したように、Google Play のゲームがさらに充実する新しいツールを提供します。Google Play サービス 7.0 に含まれる Nearby Connections API を使うと、テレビでプレイ中のゲームを近くのスマートフォンやタブレットにシームレスにつなげて、セカンド スクリーンとして制御できるようになります。

App Indexing

App Indexing を使用すると、ネイティブ アプリへのディープ リンクが Google 検索結果に表示されるようになり、Google インデックスに登録されたアプリをウェブサイトと同じように扱えるようになります。今回のリリースでは従来の view()/viewEnd()action()/end() フローが 1 つの start()end() API に統合され、App Indexing API の操作がさらに簡単になります。

GoogleApiClient の変更

GoogleApiClient は、Google API にアクセスする共通のエントリ ポイントとして使用できます。今回のリリースでは、GoogleApiClient の Google OAuth 2.0 トークンを修正し、Google API にアクセスするためのサーバー認証コードの要求がさらに簡単になります。

SDK 近日公開

数日中に Google Play サービス 7.0 の公開を予定しています。公開時にはこのブログへの投稿やドキュメントを発行してお知らせしますので、お楽しみに。公開されたらぜひお試しください。
Google Play サービスや利用可能な API の詳細については、Android デベロッパー サイトの Google サービスのセクションをご覧ください。

Posted by Yuichi Araki - Developer Relations Team

[この記事は William Denniss, Product Manager, Identity and Authentication による Google Developers Blog の記事 "Reminder to migrate to OAuth 2.0 or OpenID Connect" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google は過去数年間に渡って、ClientLoginOAuth 1.0 (3LO)AuthSubOpenID 2.0 のサポートが 2015 年 4 月 20 日をもって終了することをお知らせしてきました。こうした従来の古いプロトコルから脱却し、最新のインターネット標準である OAuth 2.0 や OpenID Connect のサポートに集中することで、セキュリティを向上し、開発上の煩雑さ減らすことができます。

これらの新しい標準規格に移行するもっとも簡単な方法は、Google Sign-in SDK を使うことです(移行についてのドキュメントをご覧ください)。Google Sign-in は OAuth 2.0 や OpenID Connect をインフラストラクチャの基盤とし、インターフェース 1 つでウェブ、Android、iOS に対して認証と認可のフローを行うことができます。

古い仕様を使っているアプリケーションはサポート終了日までに移行を行わない場合、Google に接続できなくなります(ログインもできなくなる可能性があります)。サービスが問題なく継続できるよう、サポート終了までに移行を完了してください。

移行を行うにあたっては、以下をご確認ください。
アプリケーションの移行に関する技術的なご質問は、Stack Overflow のgoogle-oauthgoogle-openid タグで投稿してください。

3LO とは 3-legged OAuth を意味します。3LO では、同意を行うエンドユーザーが存在します。これとは異なり、2-legged (2LO) は組織規模でのポリシー コントロール アクセスとしてエンタープライズの認証プロセスに対応しています。OAuth1 の 3LO と 2LO フローはどちらもサポートが終了します。

Posted by Eiji Kitamura - Developer Relations Team

Push API を使ったプッシュ通知や、Cache API を使ったページロードの高速化およびオフライン機能など、これまでウェブブラウザでは不可能とされてきたことを可能にする Service Worker を使ったウェブアプリ開発のハッカソンを開催します。

今回のイベントでは、最初に Service Worker での開発に必要な知識をご紹介するセッションを行います。また、実際に Service Worker の開発に携わった Google エンジニアがチューターとして参加し、みなさんのハッキングをお手伝いします。

イベント内容

名称:Service Worker ハッカソン
日時:2015 年 4 月 4 日(土) 9:30 - 19:00 (受付 9:00 - 10:00)
場所:Google 東京オフィス 六本木ヒルズ森タワー
会費:無料
定員:50名
主催:Google
ハッシュタグ:#serviceworker
利用テクノロジー:Service Worker, Cache API, Push API, Web Manifest, Web Notification, Fetch, Streams

* ランチおよび、懇親会で軽食を提供する予定です。

注意事項

  • 当日使われる PC はご自身で準備をお願いします。
  • Android の場合は Chrome Beta、デスクトップの場合は Chrome Beta / Dev または Chrome Canary を予めインストールしておいてください。iOS は未対応です。

申し込み方法

申し込みフォームよりお申し込みください:
http://goo.gl/forms/XsZ9K7ujcM

お申し込みの受付期間は、3 月 26 日(木)までとなります。ご参加いただける方には、参加証を 3 月 27 日(金)より順次ご登録いただいたメールアドレス宛にお送りする予定です。

多くの皆様のご参加をお待ちしております。


Posted by Eiji Kitamura - Developer Relations Team

[この記事は 2015 年 2 月 26 日に Mugur Marculescu、Product Manager が Google Developers Blog に投稿した記事 "Introducing gRPC, a new open source HTTP/2 RPC Framework" を元に、山口が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google は本日( 2 月 26 日)、リモート プロシージャ コール処理の新しいフレームワークである gRPC をオープンソース化します。このフレームワークは BSD ライセンスで、最近承認された HTTP/2 標準に基づき、一般的なプログラミング言語やプラットフォームにおける効率的で拡張性豊かな API やマイクロサービスの作成をサポートしています。Google では、長期的な HTTP/2 に対するコミットメントの一つの現れとして gRPC の使用を既に開始しており、gRPC エンドポイントを通じて数多くの正式なサービスを公開しています。

ここ数年、Google は基盤システムやテクノロジーの開発を通じて世界中のマイクロサービスに対する巨大なエコシステムを支えてきました。Google の各国データセンターのサーバーでは毎秒数百億ものコールが処理されています。この規模ではナノセカンド(10 億分の 1 秒)が重要になり、効率性、拡張性、信頼性が Google の API を構築するうえでの鍵になります。

gRPC は、分散システム構築における Google の長年の経験を元に開発されています。Google はこのフレームワークを通じて、デベロッパーの皆さんに高い処理能力と CPU 効率を備えた遅延の少ない最新の手法を提供したいと考えています。gRPC を使えばデータセンター広範にわたり、またモバイルアプリ、リアルタイム通信、インターネット接続されたあらゆる端末、API などにおいても大規模分散システムを築くことができます。

HTTP/2 標準を基盤とすることで、双方向ストリーミングやフロー制御、ヘッダー圧縮、TCP 接続 1 つに対する多重リクエスト、など多くのことが可能になります。こうした機能を使うことで、モバイル端末で使用されるデータ量を低減してバッテリーの寿命を長持ちさせ、クラウドで実行されるサービスやウェブ アプリケーションの動作を軽快にすることができます。

デベロッパーにとっては、よりレスポンシブでリアルタイム性を備えたアプリを作成できるようになり、適応性やウェブ通信の効率を向上させることができます。この機能の詳細については、FAQ をご覧ください。

gRPC と同時に、Protocol Buffers (プロトコル バッファー)の新しいバージョンもリリースします。これはパフォーマンスに優れたオープン ソースのバイナリ シリアライズ プロトコルで、サービスの定義やクライアント ライブラリの自動生成を容易に行うことができます。新しい機能が追加された Proto 3 は以前のバージョンより簡単に使用でき、サポートする言語が増えたほか Proto から JSON への標準マッピングを備えています。

プロジェクトは C、C++、Java、Go、Node.js、Python、Ruby に対応しており、Objective-C、PHP、C# のライブラリを現在開発しています。すぐにでも GitHub リポジトリ からフォークして、プル リクエストの送信を開始できます。また、ドキュメントもご確認ください。メーリング リストFreenode の IRC #grpc チャンネル も是非ご覧ください。StackOverflow“grpc” タグの質問もご確認いただけます。

Google は gRPC プロジェクトにおいて、Square やその他の企業、団体と協力しています。このテクノロジーがウェブをさらに進歩させていくことを、また皆さんからのご協力やご意見、ご尽力によってプロジェクトがさらに発展していくことを楽しみにしています。

Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Eunice Kim, Product Manager, Google Play による Android Developers Blog の記事 "Creating Better User Experiences on Google Play" を元に、松内が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Play は開発者の方向けに、人々の心をつかむアプリを開発してビジネスを成長させるためのプラットフォームを提供しています。開発者の皆さんが世界中のユーザーとつながるお手伝いをするには、ストア上でよりアプリを見つけてもらいやすくする必要があります。そこで本日、皆さんにより良い体験を提供するための新しい施策をいくつかご紹介します。

業界標準に基づいたグローバルなコンテンツレーティング制度

本日より、Google Play のアプリやゲームを年齢別にレーティングする新しい制度を導入します。お子さん、ティーンエージャー、大人のそれぞれにどのようなコンテンツが適しているのかは、お住まいの国によって考え方が異なります。この新しい制度により、開発者の皆さんはアプリを正しいオーディエンスのためにより的確に分類することができます。業界のベストプラクティスに従い、より文化的にふさわしいコンテンツレーティングを提供できるため、ユーザーの方それぞれに合ったコンテンツを見つけてもらいやすくなります。

これから開発者の皆さんは、いくつかのアンケート項目に回答することで、アプリやゲームに対して客観的なコンテンツレーティングを得ることができます。この新たなレーティング制度は、International Age Rating Coalition (IARC) と参加団体※1による公式レーティングに基づいています。特定のレーティング機関によってカバーされていない国や地域については、一般的な年齢別のレーティングが適用されます。このプロセスは迅速で自動的であり、無料で開発者に提供されます。今後数週間かけて、世界中のユーザーの方がこの新しいシステムに基づいたアプリやゲームを楽しんでいただけるようになります。

※1 Entertainment Software Rating Board (ESRB), Pan-European Game Information (PEGI), Australian Classification Board, Unterhaltungssoftware Selbstkontrolle (USK) and Classificação Indicativa (ClassInd) など


Google Play で今後もアプリの配信を継続するためには、デベロッパー コンソールにログインし、アンケートへの回答を完了させる必要があります。入力を済ませていないアプリは「レーティングなし」と表示され、特定の地域やユーザーに対してブロックされる可能性があります。今年の 5 月からは、新規、既存を問わず、すべてのアプリは公開前にこのプロセスを完了させる必要があります。

ユーザーを守るためのアプリ審査

数ヶ月前、Google Play ではコミュニティの保護とアプリカタログの改善のために、アプリの事前審査を開始しました。この新しいプロセスは、デベロッパー プログラム ポリシーに違反しているアプリを早期に特定する専門家のチームによって運営されています。Google Play では、迅速なイノベーションとイテレーションの文化を大切にしています。これからも開発者の方が、申請から数時間以内(数日や数週間ではなく)に製品を市場に送り出すことができるようサポートしていきます。実際のところ、このシステムの運用開始後も特に変化に気づかなかった開発者の方も多いことでしょう。

この仕組みにさらに透明性を持たせるため、公開ステータスを確認できるページに改善を施しました。開発者の方は今後、アプリが却下あるいは停止された理由の詳細を知ることができ、小さなポリシー違反であれば簡単に修正し再度申請することができます。

過去1年間で開発者の方は Google Play で合計 70 億ドル以上の収益を上げました。これからもエコシステムが成長し、革新を起こしていくことを楽しみにしています。今後も、開発者コミュニティがビジネスを成長させるために必要なツールやサービスを作り続けていきます。

Posted by Ryosuke Matsuuchi - Developer Relations Team

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

Google は昨日、Android Lollipop プラットフォームのアップデート版である Android 5.1 を公開しました。Android 5.1 では安定性が増し、さらに使いやすい通知機能やパフォーマンスの改善が盛り込まれています。この Lollipop アップデートの一環として、Android 5.1 をサポートし、開発やテストを行うことができる Android 5.1 SDK (API レベル 22)もリリースしています。

Android 5.1 の新機能

Android 5.1 では、開発者向けの新しい API がいくつか導入されています。今回追加される主要な API では、複数の SIM カードをサポートしています。これは Android One 搭載端末が流通している多くの地域でとても重要です。これによって Android One 搭載端末のユーザーは複数の携帯キャリアをより自由に変更できるようになり、用途や地域に合わせて最適な方法でネットワーク通信を管理できるようになります。開発者はこの機能を活用して、アプリの機能を拡張できます。
一般ユーザー向けの新しい機能に加えて、Android 5.1 では Android for Work のサポートをさらに充実させることで企業向けの機能も強化しています。

Android 5.1 は Android One などの互換端末で複数の SIM カードをサポート

Android SDK のアップデート

Android 5.1 ではまず、新しいプラットフォームと 新しい API をサポートするよう、Android SDK ツールがアップデートされています。この SDK には Android 5.1 エミュレータのシステム イメージが含まれています。これによって最新の機能や API を使ってアプリを開発してテストできます。現在使用している SDK は Android StudioAndroid SDK Manager を使ってアップデートできます。

開発者向けの新しい API の詳細については、API の概要をご覧ください。

Nexus 端末にも順次展開

今後数週間のうちに次の Nexus 端末に対して Android 5.1 アップデートを展開していきます。Nexus 4、Nexus 5、Nexus 6、Nexus 7 (2012)、Nexus 7 (2012、3G)、Nexus 7 (2013)、Nexus 7 (2013、3G/LTE)、Nexus 9、Nexus 9 (LTE)、Nexus 10、Nexus Player

次のステップ

すべての Android リリースの場合と同様に、できるだけ早く新しいプラットフォームでアプリをテストすることをお勧めします。この SDK に含まれる Android 5.1 システム イメージとエミュレータを使って、すぐにでも始められます。あるいは Android 5.1 の Nexus のイメージをダウンロードしてお手元の Nexus 端末にシステム イメージをフラッシュすることも可能です。
まだアプリをマテリアル デザインにアップデートできていない方、Android WearAndroid TVAndroid Auto でアプリがどのように動作するかまだ試していない方は、今回の Android 5.1 SDK アップデートですべてお試しいただけます。

Posted by Yuichi Araki - Developer Relations Team

[この記事は John Mellor、Michael van Ouwerkerk と ‘appiest Software Engineers による Chromium Blog の記事 "Chrome 42 Beta: Push Notifications, Promoting Add to Home Screen and ES6 Classes" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

最新の Chrome ベータ版チャンネル リリースでは、ES6 クラスのサポートなど複数の新しい機能が含まれており、さらに迫力のあるウェブ アプリケーションの作成をサポートします。明記されていないかぎり、下記の変更は Android、Windows、Mac、Linux、Chrome OS、それぞれに対応する Chrome に適用されます。

プッシュ通知

この機能によって、ページが閉じられた後でもユーザーへの通知をプッシュできるようになります。もちろん、ユーザーが明示的に許可した場合にかぎります。新しい Push API では、Google Cloud Messaging を使ってデベロッパーがリモートで Service Worker を起動することができます。起動したら Service Worker は任意の JavaScript を実行することができます。ただしこのリリースでは、少なくともユーザーが見られる通知を表示する必要があります。


[ホーム画面に追加] のおすすめ

Chrome 32 から Android ユーザー向けに、新しいメニューアイテムを使ってお気に入りのウェブサイトのショートカットをホーム画面に追加する機能が導入されました。今回のリリースでは、高品質のウェブ アプリを頻繁に使用しているユーザーに対してバナーを表示し、タップ 1 回でそのサイトをホーム画面に追加できるようになります。


この新しい機能を活用するには、そのサイトがホーム画面から起動した際にユーザーに適切なエクスペリエンスを提供している必要があります。この基準は今後、デベロッパーやユーザーからのフィードバックに基づき随時更新されていきますが、現時点では、ウェブ アプリ マニフェストを用意すること、すべてのコンテンツで HTTPS が使用されること、Service Worker を使って少なくとも一部の機能がオフラインでも動作することが挙げられます。

ES6 Class

JavaScript の prototype ベースの継承に対応することは簡単ではありません。また、多くのライブラリでクラスをエミュレートする独自のパターンが導入されていますが、JavaScript 自体はネイティブでクラスを記述する方法を提供していません。
ES6 class では、JavaScript に標準化された class 構文を提供し、この問題を解決しています。新しい構文は Chrome 42 から、strict モードで書かれた JavaScript で使用可能になります。

'use strict';

class Polygon {
    constructor(height, width) {
        this.name = 'Polygon';
        this.height = height;
        this.width = width;
    }

    sayName() {
        log('Hi, I am a ', this.name + '.');
    }
}

let p = new Polygon(300, 400);

その他のアップデート

  • デベロッパー ツールで cubic bezier 関数を視覚的に編集できるようになり、簡単にアニメーションの動きを理解して変更できるようになります。
  • AJAX リクエストに、Promise ベースの新しい標準仕様を備えた Fetch API を、Window コンテキスト、Shared Worker、Dedicated Workers で使用できるようになりました。
  • OfflineAudioContext インスタンスの startRendering メソッドが、Promise を返すようになりました。これによって、オーディオのレンダリングが終了したときに Promise が resolve され、Web Audio API.を使って動作するウェブ アプリのデザインを、よりシンプルにすることができます。
  • AudioBufferSourceNode.buffer は 2 回以上セットできなくなりました。これにより、新しい source が始まる際に制御不能に陥る事態を避けることができます。
  • ChromeOS で screen.orientation がサポートされ、デバイスの傾きが大きく変化した際、DeviceOrientationEvent を発火するようになりました。
  • このリリースには、Encrypted Media Extensions のプレフィックスがつかない最新版の実装が含まれています。これでメディア サイトが著作権管理システムを探してやり取りすることができるようになります。
  • 新しいコンテンツ設定を利用することで、主要でないプラグインを電力消費を抑えるために自動的に停止できるようになります。デベロッパーはこの機能をオンにして、コンテンツに応じてどのように作用するかをテストできます。
いつものように chromestatus.com/features で Chrome のデベロッパー機能の概要を確認してください。また、さらに頻繁なアップデートが必要な場合は、+Google Chrome Developers のサークルをご確認ください。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Hoi Lam、Android Wear デベロッパー アドボケートによる Android Developers Blog の記事 "Making a performant watch face" を元に、萩倉が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

優れたパフォーマンスは誰もが喜びます。素晴らしいウォッチ フェイスのアイデアが浮かんだら、公開するそのウォッチ フェイスが細部にまで注意されているか確認しましょう。

ウォッチ フェイスは、キャンバスを操作する onDraw メソッドを中心に処理されます。これは非常に柔軟にデザインできることを意味しますが、その一方でパフォーマンスにも注意が必要になります。このブログ記事では、サンタ トラッカーのウォッチ フェイスを最適化していく過程を通じて、主にパフォーマンスの向上について説明していきます。fps の数値を 18 fps から 42 fps へと 2 倍以上にすることで、アニメーションのサブピクセルがなめらかに表示されるようになります。

開始時点 - 18 fps

このサンタ ウォッチ フェイスは、ビットマップが何層も重ねられて最終的な画像を形成しています。各層には、下から上まで次のような画像が並んでいます。
  1. 背景(固定)
  2. 中心に向かって移動する雲
  3. 時間の目盛り(固定)
  4. サンタとそりの画像(固定)
  5. サンタの腕 - 時針と秒針
  6. サンタの頭(固定)
これらの画像をそれぞれ実際に見ていきます。

大きな画像はパフォーマンスを低下させる(+14 fps)

大きさを変えたり回したりする場合は特に、画像のサイズは Wear アプリケーションのパフォーマンスにとってきわめて重要です。無駄なピクセル領域(下図のサンタの腕など)は、よく見られる誤ったアセットの使い方です。

修正前: 584 x 584 = 341,056 ピクセル修正後: 48 x 226 = 10,848 ピクセル(97% 減少)
最終画像を構成する各層の画像について、それぞれ同じ大きさにすれば細かい位置の調整は必要ありませんので、そうしたいと思うのは当然です。ただ上図のサンタの腕と同じように、このやり方では問題を生じます。腕が正しい場所に位置する一方で、透過的なものであっても画像のサイズは増加し、メモリのフェッチ時にパフォーマンスの問題が生じます。デザイン チームとの協力のもと、付け加えたり動かしたりする部分だけを画像から切り抜いて使ったとしても、各パーツが 1 つの層を構成するということはシステムに自動的に認識されます。

もとの画像は全画面の大きさであるため、たとえほとんどの領域が透明であっても、システムはすべてのピクセルの影響を確認しなければならず、処理にかかる負荷は増加します。スペースを小さくすることで、きわめて大きなパフォーマンスの向上が見込めます。両方の腕の画像を修正すると、サンタ ウォッチ フェイスのフレームレートは 10 fps 向上して 28 fps になります(fps 56% 上昇)。同様に、サンタの顔と体のレイヤーをクロップすることで、4 fps (fps 22% 上昇)改善されます。合計 14 fps、かなりの改善と言えます。

ビットマップを結合する(+7 fps)

時計の目盛りの層は雲の層の上部に重ねるのが理想ですが、雲の層は透過的ですので、目盛りの層を下部においても見かけ上はあまり変わりません。そのため、目盛りの層と背景の層を結合できるということになります。
+
2 つのビューを結合することで、それらをアルファブレンドする処理の時間がなくなり、重要な CPU の処理時間の低減にもつながります。パフォーマンスを向上するには、アルファブレンドされるリソースをできるかぎり折りたたんでまとめることが効果的です。2 つの全画面ビットマップを結合することで、7 fps 向上します(fps 39% 上昇)。

アンチ エイリアスとフィルタ ビットマップ フラグ - どちらが有効か(+2 fps)

Android Wear を搭載した時計は、さまざまな形状やサイズで存在します。そのため、ときにはビットマップを画面に表示する前に、画像のサイズの変更が必要になることもあります。ただし、ビットマップをなめらかに表示するためにどの方法を用いるべきかが明確でない場合もあります。canvas.drawBitmap では、Paint オブジェクトを用いる必要があります。ここでは、2 つの重要なオプション、 anti-alias (アンチ エイリアス)と FilterBitmap (フィルタ ビットマップ)を設定します。以下、それぞれについて説明します。
  • アンチ エイリアスは、端が透明なビットマップに対しては効果がありません。多くの場合、Paint オブジェクトを作成する際、アンチ エイリアスのオプションはデフォルトのオンのままになっています。しかし、このオプションはベクター オブジェクトに対してのみ効果があります。ビットマップに対しては、画像の曲線部で角張った端をぼやけさせるために使われますが、端のピクセルが透明である場合(ほとんどのウォッチ フェイスではそうですが)、なにも変化しません。左下の図はアンチ エイリアスをオンにしたもの、右下の図はオフにしたものです。あまり変わりはありませんので、アンチ エイリアスオプションをオフにすることは、パフォーマンスの向上に有効であるといえます。アンチ エイリアスをオフにすると、さらに 2 fps (fps 11% 上昇)改善します。
  • 他のオブジェクトの上層にあるすべてのビットマップ オブジェクトで、フィルタ ビットマップをオンにします - このオプションは、drawBitmap がコールされる場合、端をなめらかにします。ビットマップのサイズを変更する Bitmap.createScaledBitmap のフィルタ オプションと似ていますので混同しないよう注意が必要です。どちらの設定も、オンにする必要があります。下図はサンタの腕の拡大図です。左の図はフィルタ ビットマップをオフにしたもの、右の図はオンにしたものです。

onDraw のループで負荷のかかる呼び出しを取り除く(+3 fps)

onDraw は、ウォッチ フェイスでもっとも重要な関数呼び出しです。すべてのドローアブル フレームで呼び出され、終了するまで実際の描画プロセスは実行されません。そのため onDraw メソッドはできるかぎり軽く効率よく実行されることが重要です。次に示すのは、デベロッパーが直面する、回避可能な共通の問題の例です。
  1. 重くて共通するコードを事前計算関数に移す - たとえば R.array.cloudDegrees を共通して要求している場合、その処理は onCreate で行うようにして onDraw ループでは参照のみにします。
  2. onDraw で同じ画像変換を繰り返さない - 実行時に画面サイズに合わせてビットマップのサイズを変更する処理は共通のものですが、onCreate.では行うことができません。onDraw で繰り返しビットマップのサイズを変更せずに済むように、幅と高さがわかる場合は onSurfaceChanged を上書きして画像のサイズを変更します。
  3. onDraw にオブジェクトを割り当てない - オブジェクトを割り当てるとメモリ領域が激しく消費され、ガベージ コレクションが引き起こされます。結果としてフレーム レートが低下します。
  4. Android Device Monitor などのツールを使って CPU パフォーマンスを解析する - onDraw は短い時間で定期的に実行されることが重要です。
上記のようなことに注意すると、レンダリングのパフォーマンスが劇的に向上します。

最初のバージョンでは、サンタの onDraw ルーティンに次のような不適切なコードが含まれていました。
int[] cloudDegrees = 
    getResources().getIntArray(R.array.cloudDegrees);
これではあらゆる呼び出しでリソースから int 配列が読み込まれ、高い負荷がかかります。この行を削除することで、さらに 3 fps 向上します(fps 17% 上昇)。

サブピクセルのなめらかなアニメーション

上記の対処の結果 fps は 44 となりますが、冒頭で述べた数値 42 fps とはまだ異なっています。その理由は、canvas.drawBitmap の制限から生じています。このコマンドでは、浮動する左上部詰めの配置設定がなされていますが、後方互換性のため純粋に翻訳されたものであれば、API は実際には整数のみに対応します。結果として、雲はピクセル全体を 1 単位として移動することになり、不自然な動きのアニメーションになります。サブピクセルをなめらかにするには、雲を事前に回してからサンタに移動させるのではなく、実際に描画して回転させる必要があります。この回転動作の負荷として 2 fps がかかります。アニメーションがなめらかなサブピクセルで実現されるため、余分な負荷がかかってもその価値はあります。

修正前 - 高速だが不自然な動き
for (int i = 0; i < mCloudBitmaps.length; i++) {
    float r = centerX - (timeElapsed / mCloudSpeeds[i]) % centerX;
    float x = centerX + 
        -1 * (r * (float) Math.cos(Math.toRadians(cloudDegrees[i] + 90)));
    float y = centerY - 
        r * (float) Math.sin(Math.toRadians(cloudDegrees[i] + 90));
    mCloudFilterPaints[i].setAlpha((int) (r/centerX * 255));
    Bitmap cloud = mCloudBitmaps[i];
    canvas.drawBitmap(cloud,
        x - cloud.getWidth() / 2,
        y - cloud.getHeight() / 2,
        mCloudFilterPaints[i]);
}
修正後 - 若干ゆっくりだがなめらかなサブピクセル
for (int i = 0; i < mCloudBitmaps.length; i++) {
    canvas.save();
    canvas.rotate(mCloudDegrees[i], centerX, centerY);
    float r = centerX - (timeElapsed / (mCloudSpeeds[i])) % centerX;
    mCloudFilterPaints[i].setAlpha((int) (r / centerX * 255));
    canvas.drawBitmap(mCloudBitmaps[i], centerX, centerY - r,
        mCloudFilterPaints[i]);
    canvas.restore();
}

左が修正前: 整数翻訳値による不自然なアニメーション。右が修正後: なめらかなアニメーション。


腕時計の質を高める

ウォッチ フェイスは Android Wear のなかでも、一番目立つ UI です。それを使ってどのような作品を作るかは、製作者次第です。腕時計の質を高めていきましょう。

Posted by Takeshi Hagikura - Developer Relations Team

Google は 3 月 8 日の国際女性デーにちなみ、テクノロジー業界で活躍する女性向けのイベント Women Techmakers を世界各地で開催しています。

Google 東京オフィスでも、3 月 28 日(土)に女性エンジニアやテクノロジー業界で活躍している女性向けにワークショップとネットワーキングのイベントを開催します。

本イベントでは、外部のエンジニアの方をお招きしたトークセッションやワークショップを実施します。ワークショップでは、Android WearWatch Face の Codelab あるいは Design Sprint のいずれかを事前に選択いただき、実機を使った開発やアイデアのブレインストーミングに参加していただきます。Google 社員のチューターが参加者の皆さんをサポートします。詳細は下記をご参照ください。

Android Wear Watch Face Codelab
Codelab では、2 時間のセッションで実際に Android Wear の Watch Face の作成手順を各ステップごとに見ていきます。Android Wear 搭載端末はこちらで用意しますので、開発に必要な PC (Mac あるいは Windows) をご持参ください。


Android Wear Design Sprint
Design Sprint とは Google Ventures がスタートアップ支援のために考案したプログラムで、新しいアプリケーションやサービスのアイデアを設計からプロトタイプに落とし込み、妥当性や効果の検証を行うものです。本ワークショップには、プログラミング経験は必要ありません。

当日のスケジュールは下記のとおりです。同じテクノロジーの分野で活躍する女性同士が交流できる機会となれば幸いです。多くの方の参加をお待ちしています。

イベント概要

■Women Techmakers 2015 at Google Japan
日程:2015 年 3 月 28 日(土)10:00 - 18:00
場所:Google 東京オフィス 六本木ヒルズ森タワー
定員:100 名
主催:グーグル株式会社
協力:Women Who Code Tokyo


■当日のアジェンダ

午前の部
10:00 - 10:30 : 受付
10:30 - 10:40 : ご挨拶
10:40 - 11:10 : キーノートスピーチ(グーグル株式会社 執行役員 営業本部長 仲條 亮子)
11:10 - 11:55 : トーク セッション
  • 岩尾 はるか (レッドハット株式会社 ストレージソリューションアーキテクト)
  • 小川 秀子 (Flask LLP, iOS App Developer)
  • 佐々木きはる (Webエンジニア フリーランス)
  • Himi Sato (Women Who Code Tokyo ・オーガナイザー)
  • Anja Austermann (Google ソフトウェア・エンジニア)
  • 安田 絹子 (Google ソフトウェア・エンジニア)
12:00 - 13:00 : ランチ

午後の部 : Codelab か Design Sprint を選択
13:05 - 15:05 : Android Wear Watch Face の Codelab
13:05 - 15:05 : Android Wear の Design Sprint
15:10 - 15:25 : 休憩
15:30 - 15:40 : 閉会の挨拶
15:45 - 17:00 : 懇親会


■申し込み方法

下記の申し込みサイト(英語)よりお申し込み下さい。
http://goo.gl/fcGmWp


■よくある質問

Q : Codelab を行う上で必要な機材等はありますか?
A : 開発をする上で必要になる PC (Mac あるいは Windows) をご持参下さい。

Q : Codelab と Design Sprint のワークショップの参加が申し込みサイトで見つからないのですが?
A : ワークショップへの参加方法については、改めてメールでご連絡いたします。

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

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

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

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

■IWD2015 - Women Techmakers By GDG Kyoto
日程:2014 年 3 月 14 日(土)13:00 - 17:30
場所:KRP町家スタジオ
定員:23 名
主催:GDG 京都
後援:京都リサーチパーク株式会社
詳細:http://goo.gl/3BeuOe


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