Google I/O 2015 の開催がいよいよ来月に迫ってきました。今年もサンフランシスコには世界中から開発者が集結します。そして、今年も世界各地で会場の様子をリアルタイムに視聴する I/O Extended イベントが開催されます。



I/O Extended は、開発者の皆さんが集まり、一緒に Google I/O のライブ ストリームを視聴するイベントです。すでに世界各地 100 箇所を超える場所で I/O Extended が企画されており、近くで開催される予定がない場合は I/O Extended オーガナイザー用の企画サイトを見て、自分で企画することも可能です ...
Google I/O 2015 の開催がいよいよ来月に迫ってきました。今年もサンフランシスコには世界中から開発者が集結します。そして、今年も世界各地で会場の様子をリアルタイムに視聴する I/O Extended イベントが開催されます。

＜I/O Extended とは＞

I/O Extended は、開発者の皆さんが集まり、一緒に Google I/O のライブ ストリームを視聴するイベントです。すでに世界各地 100 箇所を超える場所で I/O Extended が企画されており、近くで開催される予定がない場合は I/O Extended オーガナイザー用の企画サイトを見て、自分で企画することも可能です。
日本では、Google および 各地の Google Developer Group のみなさんが以下の会場で開催を予定しています （ 4 月 27 日時点 ）。各会場では他の開発者の皆さんと一緒に講演をお楽しみいただくことができます。また会場によっては、基調講演の前や後にライトニングトークやハンズオンも開催される予定ですので、各会場の詳細をご確認ください。

ライブ ストリームは英語のみですが、本ブログで掲載している会場ではセッションの日本語への同時通訳を提供します。


＜東京（六本木）会場の概要＞

名称: Google I/O Extended in Tokyo
主催: Google
会場: TOHO シネマズ 六本木ヒルズ
日時: 2015 年 5 月 28 日（木） 24:30 - 5 月 29 日（金）6:00（受付 5 月 28 日 24:15-）
会費: 無料
参加資格: Google I/O 2015 に興味のある 20 歳以上の方
定員: 200 名
中継: 英語/同時通訳: 日本語
※未成年者のご参加は保護者同伴であってもご遠慮ください。


＜京都会場の概要＞

名称: Google I/O Extended Kyoto （ Google I/O 2015 を町家で観る会）
日時:2015 年 5 月 28 日（木） 20:30 - 5 月 29 日（金）8:00 （受付 5 月 28 日 20:00 - 20:30）
主催: GDG 京都
協力: Google
後援: 京都リサーチパーク株式会社
会場: KRP 町家スタジオ (京都市上京区葭屋町通中立売上る福大明神町 128)
会費: 無料
参加資格: Google I/O 2015 に興味のある 20 歳以上の方
定員: 20 名


＜神戸会場の概要＞

名称: I/O Extended 2015 Kobe
主催: GDG 神戸
協力: Google
会場:BAR YUME-YA ZERO （神戸市中央区北長狭通 2 丁目 31 - 55）
日時:2015 年 5 月 28 日（木） 23:00 - 5 月 29 日（金）8:00
会費: 無料（飲食代は個別清算）※別途ワンドリンク注文必要。
参加資格: Google I/O 2015 に関心がある方
※未成年の方は保護者同伴でお願い致します。深夜帯ですので、何か問題が発生した場合でも、GDG 神戸では責任を負いかねます。
定員: 20 名


＜徳島会場の概要＞

名称: Google I/O Extended in Tokushima
主催: GDG 四国
協力: Google
会場: 徳島市近郊を予定
日時: 2015 年 5 月 28 日（木） 20:30 - 5 月 29 日（金）3:00
会費: 無料（飲食代のみ個別精算）
参加資格: Google I/O 2015 に興味のある 20 歳以上の方
定員: 10 名

＜信州会場の概要＞

名称: Google I/O Extended in 信州
主催: GDG 信州
協力: Google
会場: 安曇野某所（参加者のみ直接連絡）
日時: 2015 年 5 月 28 日（木） 20:30 - 5 月 29 日（金）3:00
会費: 無料
参加資格: Google I/O 2015 に興味のある 20 歳以上の方
定員: 7 名

＜福岡会場の概要＞

名称: Google I/O Extended 福岡
主催: GDG 九州
協力: Google
会場: AIP Cafe （福岡県福岡市中央区大名 1 丁目 14 - 28 第一松村ビル 3 階 302 ）
会場がわかりにくい場所にあります。AIP Cafe に来たことがない方はお問い合わせください。
日時: 2015 年 5 月 28 日（木）23:50 - 5 月 29 日（金）8:00
会費: 無料
参加資格: Google I/O 2015 に興味のある方
定員: 15 名

＜大分会場の概要＞

名称: Google I/O Extended Oita♨
主催: GDG 九州
協力: Google
会場: azito （大分県大分市府内町 1 - 6 - 43 B スクエア 3 F）
日時: 2015 年 5 月 28 日（木）23:00 - 5 月 29 日（金）5:00
会費: 無料
参加資格: Google I/O 2015 に興味のある方
定員: 10 名


＜お申し込方法＞

会場毎にお申し込み方法が異なります。詳しくは以下をご覧ください。

東京会場（六本木）：http://goo.gl/WPOisw※定員に達したため参加登録は終了いたしました。
京都会場 ：http://goo.gl/d3DyGw
神戸会場 ：http://goo.gl/forms/aRggWhmDh1
徳島会場 ：http://goo.gl/Seh11s
信州会場 ：http://goo.gl/DjdfGO
福岡会場 ：http://goo.gl/EjSKvc
大分会場 ：http://goo.gl/1h5XX1

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

Posted by Takuo Suzuki - Developer Relations Team

[この記事は プロダクト マネージャー、William Denniss による Google Developers Blog の記事 "A final farewell to ClientLogin, OAuth 1.0 (3LO), AuthSub, and OpenID 2.0" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

いよいよ ClientLogin、OAuth 1.0 （3LO）、AuthSub、OpenID 2.0 のサポートを終了し、シャットダウンのプロセスを開始したことをお知らせします。まだこれらのサービスを使用している場合、今後正常に動作しなくなりますので、 OAuth 2.0 ...
[この記事は プロダクト マネージャー、William Denniss による Google Developers Blog の記事 "A final farewell to ClientLogin, OAuth 1.0 (3LO), AuthSub, and OpenID 2.0" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

いよいよ ClientLogin、OAuth 1.0 （3LO）、AuthSub、OpenID 2.0 のサポートを終了し、シャットダウンのプロセスを開始したことをお知らせします。まだこれらのサービスを使用している場合、今後正常に動作しなくなりますので、OAuth 2.0 か OpenID Connect にすみやかに移行していただく必要があります。

サインイン システムを移行するもっとも簡単な方法は、Google Sign-in SDK を使うことです（移行についてはこちらのドキュメントをご覧ください）。Google Sign-in は Google が標準として使用している OAuth 2.0 と OpenID Connect のインフラストラクチャをベースに構築され、ウェブ、Android、iOS での認証・認可フローを、1 つのインターフェースで提供します。サーバー API を移行する場合は、OAuth 2.0 クライアント ライブラリの使用をおすすめします。

Google は今後、従来の認証プロトコルをサポート外とすることで、OpenID Connect と OAuth 2.0 のサポートに注力していきます。これら最新のオープン スタンダードは、Google アカウントのセキュリティをさらに強固なものとし、開発者のみなさまにとっても、従来より簡単に実装できるものとなっています。

※ 3LO とは、承認を行うエンドユーザーを伴った 3-legged OAuth を意味します。対照的に、2-legged OAuth（2LO）は、組織規模でのポリシーによるアクセスコントロールのような、企業ごとの認可シナリオを意味します。OAuth1 3LO と 2LO フローはどちらもサポートが終了しますが、今回のアナウンスは OAuth1 の 3LO についてのみです。

Posted by Eiji Kitamura - Developer Relations Team

2015 年 4 月 9 日に開催された Google Developers Summit より「Service Worker で作る最新モバイル ウェブ エクスペリエンス」をダイジェストでブログ記事としてお届けします ...
2015 年 4 月 9 日に開催された Google Developers Summit より「Service Worker で作る最新モバイル ウェブ エクスペリエンス」をダイジェストでブログ記事としてお届けします。


ウェブ vs ネイティブ

同じ機能を提供するアプリケーションでも、スマートフォン上のブラウザで動作するのか、それとも単体のソフトウェアとして動作するのかは、大きなテーマとしてここ数年議論されてきました。

デスクトップでは、ブラウザだけで様々なことがこなせるのはもう当たり前です。Chrome OS のように、ブラウザそのものを OS にしてしまうくらいの発展を、ウェブ技術は遂げてきた結果と言えます。

それではモバイルではどうでしょうか？



これは Flurry が行った調査結果です。

アメリカのスマートフォン ユーザーが使用時間の実に 80% 以上をネイティブ アプリケーションに費やし、それに比べるとウェブの利用時間はごく僅かであることがわかります。利用時間だけを基準にすれば、議論の余地もなくネイティブ アプリケーションの圧勝に見えます。

一体なぜなのでしょう？

私が個人的に立てた仮説はこうです。

デスクトップは広大な海、スマートフォンは小さな宇宙

デスクトップでアプリケーションを使う際、ユーザーは通常、キーボードとマウスを使います。デスクトップの世界では、キーボードやマウスさえ使いこなせれば、広大なインターネットという海の中から、自分が欲しい情報やサービスを自在に探し当てることができます。

それに対しスマートフォンでは、指先 1 つで様々なことをこなさなければなりません。ソフトウェア キーボードで文字を打つだけでもちょっとした作業なため、検索するのも楽な作業ではありません。使いたい機能がワンタップですぐに立ち上がるとしたら、どれほど楽でしょう？

つまり、キーボードとマウスでの操作が想定されたデスクトップから、タッチでの操作が想定されたスマートフォンへの最適化がネイティブ プラットフォームの方が早く進んだためではないか、という仮説です。

それでは、ウェブをよりモバイル フレンドリーにしていくために、我々ができることはなんでしょうか？Chrome がブラウザとして提供できる新しい機能、みなさんが開発者として実装できる新しい機能を
  • エクスペリエンス
  • スピードとオフライン
  • エンゲージメント
という 3 つのパートに分けてご紹介していきます。

エクスペリエンス

ウェブとネイティブを比較した際、最も大きく異なるのはそのアクセス方法です。

ウェブでは最初のアクセスの際、検索やリンクを辿ることでサービスに到達します。ネイティブではマーケットプレイスでインストールすることにより、サービスに到達します。

それでは二回目以降はどうでしょうか？ウェブでは、ブックマークしていない限り、検索やリンクをもう一度辿る必要があります。ブックマークしていたところで、フォルダ構造を辿るなどするため、最低でも数タップが必要です。逆にネイティブの場合、インストール済みのアプリケーションはホーム画面にあるため、アイコンを一度タップするだけで済みます。

インストールのハードルが高いとはいえ、リピートしてもらうことを考えれば、スマートフォンにおいて、ネイティブアプリのようなアクセス方法が理想的なのは明らかですね。ウェブでこれを実現することはできないものでしょうか？

ホーム画面に追加

既に Chrome で利用できる機能に「ホーム画面に追加」というものがあります。これを選択することで、ウェブサイトのブックマークがホーム画面に追加され、ユーザーはワンタップでブラウザを開き、アクセスできるようになります。
さらに、もう一工夫加えることで、これをよりネイティブに近いエクスペリエンスにすることができます。そこで登場するのが Web Manifest です。

manifest.json
{
  "name": "Kinlan's Amazing Application ++",
  "short_name": "Kinlan's Amaze App",
  "icons": [
    {
      "src": "launcher-icon-3x.png",
      "sizes": "144x144",
      "type": "image/png"
    }
  ],
  "start_url": "index.html",
  "display": "standalone"
}

index.html
<link rel="manifest" href="/manifest.json">

Web Manifest は JSON で記述されたウェブサイトのメタ データで、サーバー上に配置したものを HTML から link[rel="manifest"] で参照することにより効力を発揮します。上記の例ではアプリの正式名称（name）、ホーム画面に追加された際のショートネーム （short_name）、アイコンの指定（icons）（画面サイズに応じて複数指定可能）、アイコンをタップした際に開く URL（start_url）、表示モード（display）、を指定しています。この Web Manifest により、ウェブサイトをホーム画面に追加した際の挙動を、よりモバイル フレンドリーなものへと変えることができるのです。

参考 URL はこちら：

フルスクリーン

Web Manifest の display を standalone とすることで、ホーム画面のアイコンから起動した際に URL バーを隠し、よりネイティブ アプリに近い見た目にすることもできます。

インストール バナー

実はここまでのエクスペリエンスは、iOS の Safari でも同様のことが随分昔からできていました。とはいえ、ホーム画面にアイコンを追加してもらうには、ユーザーの能動的なアクションが必要で、最低でも 2 回のタップを伴うため、決してよく使われる機能ではありません。ホーム画面に追加することを促すバナーをページ上に表示しているサイトも珍しくはありません。

そこで Chrome では、M42 からこの「ホーム画面に追加」をブラウザが自動的に促してくれる機能を追加しました。


Chrome にこのバナーを表示させるためには、いくつかの条件があります。
  • ユーザーがウェブサイトを 1 週間以内に 2 回訪問
  • Web Manifest が存在する
  • Service Worker を使っている
  • HTTPS でサーブされている
※ これらの条件はあくまで現時点のものであり、今後変更される可能性があることにご注意ください。

参考 URL:

テーマカラー

Chrome では meta[name="theme-color"] を使うことで URL バーの色を変更することができます。色は hex のカラー コードを content 属性で指定します。

<meta name="theme-color" content="#db5945">

さらに Android 5.0 以降であれば、最近利用したアプリ一覧を表示した際の表示もここで指定した色で表示されるようになります。

参考 URL はこちら：

スピード・オフライン

ウェブ アプリも、ネイティブ アプリのようにリソースをローカルに持たせることで、起動速度を向上することができます。作り方によってはオフラインでも動作させることができるはずです。

ご存知のとおり、これはウェブにとって初めての試みではありません。Application Cache はこれを実現しようとした最初の標準仕様でしたが、様々な問題点が指摘されるなど、現在も広く使われている機能とは言えません。

そこで代替技術として現在注目を浴びているのが、Service Worker です。

Service Worker とは

Service Worker はオフライン技術を可能にするためだけのものではありません。Service Worker とは、ひとことで言うならこうです：

ユーザーに見えるウェブページの裏側で動かせるイベント駆動の JavaScript 環境

ウェブページで Service Worker を登録することで、様々なイベントを受け取れるようになり、それに伴い任意の動作をバックグラウンドで行えるようになります。例えば
  • ウェブページのリクエストを横取りして、ローカル プロキシのように動作。
  • ウェブページが開いていなくても、イベントを受け取り、スクリプトを実行。

Service Worker バックグラウンドで動作すると言っても、常時動いているわけではありません。イベント駆動になっていますので、各種イベントが発生するのに伴い、様々な短い処理を行うことができます。想定されているユースケースは様々です：
  • ローカル プロキシ
  • オフライン キャッシュ
  • プッシュ通知
  • バックグラウンド同期
  • ジオ フェンシング
fetch イベントを使うと、ドキュメントから発生したあらゆるリクエストをイベントとして受け取り、ローカル プロキシとして動作させることができます。これを使えば、例えば次のようなこともできます：
  • 画面サイズを元に動的に URL を書き換えることで、レスポンシブにサイズの異なる画像を取得する
  • クエリに応じてテスト用のスタブ データを返す
  • JavaScript の依存関係を動的に解決し、必要なリソースを CDN などから取ってくる（ハッカソンで出たアイディア）
なお、Service Worker は非常に強力な機能のため、HTTPS でのみ動作可能（デバッグのため localhost は例外）である点に注意してください。

サンプル コード

コードを見るのが何よりもイメージが湧きやすいと思いますので、簡単な例を示します。

navigator.serviceWorker.register('/sw.js')
  .then(function(registration) {
      // Success!
  }).catch(function(error) {
      // Error...
  });

このコードでは、index.html に存在する JavaScript から Service Worker を登録しています。
登録が成功すると、以後ブラウザのバックグラウンドで Service Worker の JavaScript（この場合 sw.js）が動き続けることになります。

Cache API

この Service Worker 上で fetch イベントを取り、ブラウザからサーバーにリクエストが発行される度に、あらかじめキャッシュしてあるリソースを返すことで、ウェブサイトを高速にしたり、オフラインで利用できるようすることができます。

self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request).then(function(response) {
      return response || fetch(event.request);
    })
  );
});

このコード例では、リクエストに対し、あらかじめキャッシュしてあるリソースをそのまま返しています。ページの本体である index.html ですらオフラインで動作できるのが Service Worker の強力な点です。


なお、Service Worker によるキャッシュ機能はウェブページそのものとは切り離されているため、非対応ブラウザで実行しても、単純に Service Worker 部が動作しないだけで、ページ自体には問題が発生しにくいという特徴があります。ブラウザ互換性をあまり気にしなくても、対応ブラウザにだけ付加的にメリットを提供できるのも ServiceWorker の魅力の一つです。

参考 URL:

エンゲージメント

モバイルプラットフォームでサービスを提供する方たちがウェブではなくネイティブを選ぶ理由のひとつに、プッシュ通知が挙げられます。メールでは見逃される可能性のあるメッセージを、肌身離さず持っている携帯電話の一等地とも言える場所に届けられるのですから、モバイルのプッシュ通知は大変強力です。
では、これがウェブで実現できたらどうでしょう？それを可能にするのが Service Worker を使ったプッシュ通知機能です。

こちらのデモでは "Enable Push Notifications" のスイッチを入れると同時に、パーミッションを求めるダイアログが表示され、許可をするとそれ以降プッシュ通知を受信することが可能になります。自分で "SEND A PUSH TO GCM VIA XHR" をクリックして動作を確認してみてください。

仕組みはこうです：
  1. ユーザーがサービスにアクセスし、サイトの最新情報を購読するボタンをクリック
  2. 許可を得るダイアログが表示され、ユーザーが許可します。
  3. 仕様上は HTTP Push と呼ばれるプロトコルを使って、サーバーからプッシュが行われます。
  4. しかし、接続するサーバーが多くなればなるほど、張らなければならないコネクション数が多くなってしまうため、Chrome では Android で既に使われている Google Cloud Messaging というサービスを利用することで、コネクションを束ねます。
  5. これにより、端末に必要なコネクションは GCM とのみとなり、サーバーは GCM サーバーに HTTP POST を使ってメッセージを送信するだけで、プッシュが可能になります。
Chrome では現状このような実装になっていますが、Service Worker はオープンスタンダードですので、将来的に Chrome もそれに合わせた挙動になるよう変更されていく予定です。

購読時のサンプル コード：

navigator.serviceWorker.ready().then(function(sw) {
  sw.pushManager.subscribe().then(function(sub) {
    // After permission is granted
    sub.subscriptionId; // registration Id
    sub.endpoint;       // GCM URL
  });
});

ウェブサイトがプッシュ通知の購読を行います。その際、ユーザーに同意を求め、許可された場合のみ、GCM と通信を行い、subscription id を取得します。そしてその subscription id をサーバーに送ります。

プッシュ受信時のサンプル コード：

self.addEventListener('push', function(event) {
  event.waitUntil(
    self.registration.showNotification(title, {
      body: body,
      icon: icon,
      tag:  tag
    }
  });
});

サーバーはその subscription id を使って GCM に Post メッセージを送ることで、プッシュ通知を行います。
Service Worker はプッシュ通知をイベントで受け取り、Notifications API を使って通知を表示します。

参考 URL:

Chrome におけるプッシュ通知の現時点での制約

Chrome のバージョン 42 からプッシュ通知が使えると書きましたが、この段階では未実装機能の制約がとても多いのが現状です。ネイティブアプリ並みのプッシュ通知を行いたい場合は、もうしばらく待つ必要があります。
  • Push メッセージにデータを乗せられない
  • Push されたら通知を出さなければならない
  • Notification にデータを乗せられない
とはいえ、プッシュ通知は大変強力な機能ですので、実際に試し、来るべき未来に備えることをオススメします。

SSL について

既にお気付きの方も多いと思いますが、Service Worker の強力な機能の多くは、ウェブサイトが HTTPS であることを前提としています。
HTTPS は、暗号化や証明書といった用途だけでなく、「ホーム画面に追加」のおおすすめや、Service Worker を使うこと、プッシュ通知を使うなどする際に、必須条件になっています。
  • 「ホーム画面に追加」のおすすめ
  • Service Worker
  • プッシュ通知
  • 暗号化
  • 証明書
この機会にサイト全体を HTTPS にすることをぜひご検討ください。

まとめ

Web Manifest と theme-color を使うことで、あなたのモバイル ウェブサイトは今すぐエクスペリエンスを向上することができます。また、Service Worker の Cache API を使えば、既存の機能を損なうことなく、スピードの改善・オフライン対応することができます。将来に備え、HTTPS やプッシュ通知の導入もご検討ください。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Lawrence Chang, Product Manager による Android Developers Blog の記事 "Drive app installs through App Indexing" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

開発者のみなさんがアプリを素晴らしいものにするため時間と努力を惜しまないのと同様に、我々もみなさんの素晴らしいコンテンツをより多くの人たちに届けるお手伝いをしたいと願っています。既に 300 億のアプリ内リンクがインデックスされていることからもわかるように、App Indexing は Android 向けアプリのインストール後のエンゲージに役立てられています。今週より、Android 向けアプリをインストールしていない方々にも、Google で検索することで、あなたのアプリを発見することができるようになります。App Indexing が実装済みで、あなたのアプリからインデックスされたコンテンツが Android 上の Google 検索の結果と一致した場合、検索結果にあなたのアプリのインストール ボタンが表示される可能性があります。そのボタンを押下することで、ユーザーは Google Play ストアに移動し、アプリをインストール、そしてアプリ内の検索結果に該当する箇所に直接アクセスすることができます ...
[この記事は Lawrence Chang, Product Manager による Android Developers Blog の記事 "Drive app installs through App Indexing" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

開発者のみなさんがアプリを素晴らしいものにするため時間と努力を惜しまないのと同様に、我々もみなさんの素晴らしいコンテンツをより多くの人たちに届けるお手伝いをしたいと願っています。既に 300 億のアプリ内リンクがインデックスされていることからもわかるように、App Indexing は Android 向けアプリのインストール後のエンゲージに役立てられています。今週より、Android 向けアプリをインストールしていない方々にも、Google で検索することで、あなたのアプリを発見することができるようになります。App Indexing が実装済みで、あなたのアプリからインデックスされたコンテンツが Android 上の Google 検索の結果と一致した場合、検索結果にあなたのアプリのインストール ボタンが表示される可能性があります。そのボタンを押下することで、ユーザーは Google Play ストアに移動し、アプリをインストール、そしてアプリ内の検索結果に該当する箇所に直接アクセスすることができます。



これらのインストール リンクの追加を皮切りに、アプリをインストールしているか否かに関わらず、App Indexing はすべての Android ユーザーのランキングシグナルとして利用されることになります。これにより、Google の検索機能が新しいユーザーの獲得だけでなく、既存ユーザーとのエンゲージメントにも役立つことを願っています。App Indexing について詳しくは g.co/AppIndexing を、Google 検索の他の活用方法については g.co/DeveloperSearch を御覧ください。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Jen Kovnats Harrington、Google Maps API プロダクト マネージャーによる Google Geo Developers Blog の記事 "Hello Places API for Android and iOS!" を元に、荒木が翻訳・加筆したものです。詳しくは元記事をご覧ください。]
[この記事は Jen Kovnats Harrington、Google Maps API プロダクト マネージャーによる Google Geo Developers Blog の記事 "Hello Places API for Android and iOS!" を元に、荒木が翻訳・加筆したものです。詳しくは元記事をご覧ください。]


人は通常、現在いる場所を地図の緯度と経度で考えたりはしません。どの店やレストランの前にいるか、周りに何があるかなどの周辺情報で現在地を把握します。そうした情報をアプリで提供できるようにするため、Google は Places API for Android をリリースし、また Places API for iOS のベータ版を公開することになりました。

Places API ウェブ サービスと JavaScript ライブラリは、しばらく前からご利用いただいています。Android と iOS 端末をネイティブにサポートすることで、端末それぞれの位置情報信号を活用し、モバイルでの新しい API の使い心地を最適なものにできます。

Android 版、iOS 版、それぞれの Places API を使えば、緯度経度で表される地理的な位置情報と、ユーザーが既に知っている場所と、関連付けて場所を認識する方法とのギャップを埋めることができます。たとえば、生まれた場所を伝えるときに、「私は緯度 25.7918359、経度 80.2127959 の地点で生まれました」とは言わず、単に「フロリダ州マイアミのジャクソン記念病院で生まれました」と言うでしょう。Places API によって、レストラン、ローカルのビジネス、ホテル、美術館や博物館、その他の見どころなど、全世界 1 億を超える数の Google グローバル プレイス データベースの情報をアプリで使うことができるようになります。


主な機能には次のようなものがあります。

  • ユーザーが場所の特定に使える、ドロップダウンの UI ウィジェット、Place picker の追加
  • ユーザーの現在地を取得する機能
  • 場所の名前、住所、電話番号、ウェブサイトなど、場所の詳細情報の表示
  • 場所の名前をすべて入力するストレスを解消し、入力時間を短縮するオートコンプリート（入力した文字から場所の名前を推測して自動的に完了する）機能
  • ユーザーに関連する新しい場所を追加して Google のプレイス データベースで表示させることによって、アプリをさらに役立つものにする機能
  • 特定の場所で端末を用いてレポートし、自分の周りの地図を改善する機能
Places API for Android の使用を開始するには、こちらの DevByte （動画）をご覧ください。またこちらのドキュメントを確認し、デモをお試しください。Places API for iOS ベータ版に申し込むには、こちらをご覧ください。

Posted by Yuichi Araki - Developer Relations Team

[この記事は Marja Hölttä、Daniel Vogelheim による Chromium Blog の記事 "New JavaScript techniques for rapid page loads" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Chrome の主な使命の 1 つは、2008 年に 基本原則の 1 つとして明言されて以来、ずっとスピードです。しかし現在、スピードは単に Javascript ベンチマークの結果というだけではなくなりました。ブラウザを使ったすべてのユーザー操作において、ウェブページの表示や読み込みがすみやかに行われることが理想的です。Chrome では、スクリプト ストリーミングとコード キャッシングという 2 つの技術を採用し、特にモバイル端末において白い画面が表示される、イライラする待ち時間を低減しています ...
[この記事は Marja Hölttä、Daniel Vogelheim による Chromium Blog の記事 "New JavaScript techniques for rapid page loads" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Chrome の主な使命の 1 つは、2008 年に基本原則の 1 つとして明言されて以来、ずっとスピードです。しかし現在、スピードは単に Javascript ベンチマークの結果というだけではなくなりました。ブラウザを使ったすべてのユーザー操作において、ウェブページの表示や読み込みがすみやかに行われることが理想的です。Chrome では、スクリプト ストリーミングとコード キャッシングという 2 つの技術を採用し、特にモバイル端末において白い画面が表示される、イライラする待ち時間を低減しています。

スクリプト ストリーミングは JavaScript ファイルのパースを最適化します。以前のバージョンの Chrome では、パースを開始する前にスクリプトをすべてダウンロードする単純な手法を使っていましたが、このアプローチではダウンロードが終了するまで CPU を活用できていませんでした。Chrome バージョン 41 からは、async と deferred のスクリプトについて、ダウンロードが開始されると同時に別のスレッドでパースが実行されるようになります。つまり、ダウンロードの完了とほぼ同時にパースも完了することになり、ページの読み込みが 10 % ほど迅速に行われることになります。これは特に大がかりなスクリプトやネットワークが遅い状況において効果的です。



コード キャッシングはもうひとつの新たな技術で、特に同じページを何度も表示するときにページが迅速に読み込まれるようになります。通常、ページの JavaScript はページを表示するたびに V8 エンジンによってコンパイルされ、プロセッサが認識できるインストラクションに変換されますが、このコンパイル済みのコードは、コンパイル実行時のマシンの状況やコンテキストによって大きく左右されるため、ユーザーがそのページから移動すると保持されません。Chrome 42 では、このコンパイル済みコードのローカルコピーを保持する拡張技術を採用することで、ユーザーがそのページに戻ってきたときにダウンロード、パース、コンパイルの手順をすべて省略できるようになります。これによってすべてのページでコンパイル時間の 40% を削減し、モバイル端末において貴重なバッテリーの消費量を減らすことができます。

以上が Chrome によってページの読み込み時間を抑える 2 つの技術についての説明になりますが、ページの読み込み時間はブラウザのパフォーマンスを向上する 1 つの手段にすぎません。Chromium プロジェクトで進められるウェブ パフォーマンスのすべての側面における改善を、今後もご期待ください。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Software Engineer の Ankur Kotwal が Google Developers Blog に投稿した "Ho Ho Ho! Google's Santa Tracker is now open source" という記事を元に荒木が翻訳・加筆したものです]
[この記事は Software Engineer の Ankur Kotwal が Google Developers Blog に投稿した "Ho Ho Ho! Google's Santa Tracker is now open source" という記事を元に荒木が翻訳・加筆したものです]

季節はすっかり春ですね。クリスマスはずいぶん前のことのように感じられますが、お知らせがあります。Google サンタ トラッカーがオープンソースとして GitHub (google/santa-tracker-web と google/santa-tracker-androidに公開されました。Web と Android 両方のアプリが Google の開発者向けプロダクトを使ってどのように実現されているのかご覧いただけます。
サンタ トラッカーといっても、ただ単にクリスマス イブのサンタさんのプレゼント配達状況を追跡するだけではありません。クリスマス シーズンを通して、冬をテーマにした数々のゲームで遊んだり、北極にあるサンタ村でサンタさんか配達の準備をする様子を見ることができるんですよ。

オープンソースとしてリリースしたのは以下のようなものです。

Android アプリ

  • Android の サンタ トラッカー アプリはひとつの APK ファイルで Ice Cream Sandwich (4.0) 以降のすべての端末をサポートしています。アプリのソースコードはこちらでご覧いただけます。
  • サンタ村はビデオやゲームやトラッカー (地図) のランチャーになっています。横幅 1 万ピクセルにも及ぶサンタ村を実現するため、Android のリソース階層をちょっと変わったふうに利用しています。これによって画面解像度ごとに別々の画像を用意する必要をなくし、APK のサイズを削減しています。
  • サンタ トラッカーのゲームは様々な技術を組み合わせて作られています。Gumball は JBox2D、Memory Match は Android の View、Jetpack は OpenGL と特製のレンダリング エンジンを使っています。
  • ユーザー エンゲージメント向上のため、App Indexing API を使って Google 検索からサンタ トラッカーのゲームを開くことができるようにしています。Deep Linking を利用して実現されています。

Android Wear


Web 版


  • Web 版のサンタ トラッカーは Polymer を使って実装されています。Polymer は Chrome チームが Web Component に基づいて作り出した新しいライブラリです。サンタ トラッカーでの利用方法をご覧になれば、コードを再利用可能なコンポーネントとしてまとめるのも Polymer を使えば簡単だということがお分かりいただけるでしょう。サンタ村での各シーン (ゲーム、ビデオ、インタラクティブなページ) はすべてカスタム要素になっていて、必要なときだけ読み込むようにすることで起動のコストを最小化しています。
  • サンタ トラッカーのインタラクティブで楽しい体験は Web アニメーション API を使って作られています。JavaScript でコンテンツのアニメーションをを統一的に扱うための標準化された API です。CSS アニメーションから大きな進歩です。Web アニメーションはインタラクティブに記述することができ、ポリフィルを使えば全てのモダンなブラウザーをサポートすることができます。Polymer 自体もマテリアル デザインの効果を実現するために内部で Web アニメーションを利用しています。アニメーションの例は GitHub を検索すればたくさん見つかります。

  • サンタさんはモバイル ファーストを推進しています。今年はモバイル Web での最適化を主眼に据えて設計しました。完全なレスポンシブ デザイン、Polymer によるタッチ ジェスチャーのサポートなどです。また、theme-color やホーム画面に追加するための Web Application Manifest といった新機能もあります。
  • 徹底的なローカリゼーションのため、Web Component として新しく i18n-msg コンポーネントを開発しました。Chrome Extension の i18n の仕組みが元になっており、開発用にライブ更新も利用できますが、最適化用にビルド ステップも備えています。
サンタ トラッカーを支える技術がどのようなものか、ぜひソース コードをご覧になって確認して下さい。開発者の皆様のお役に立つことを願っております。

Posted by Yuichi Araki - Developer Relations Team

[この記事は Chris DiBona、オープン ソース ディレクターによる Google Open Source Blog の記事 "Bidding farewell to Google Code" を元に、鈴木が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Code のプロジェクト ホスティング サービスを 2006 年に開始したときは、プロジェクト ホスティングはまだあまり一般的ではありませんでした。信頼性や成長性に疑問が抱かれていたため、ユーザーにとって別の選択肢となるようなサービスを提示できるよう Google はオープンソース コミュニティに働きかけました。それ以来、GitHub や Bitbucket bloom などさまざまなプロジェクト ホスティング サービスが登場してきました。多くのプロジェクトが Google Code からそうした他のシステムに移行していきました。こうした開発者の方々の現状を考え、Google は Google Code に持っている 1000 近いオープンソース プロジェクト ...
[この記事は Chris DiBona、オープン ソース ディレクターによる Google Open Source Blog の記事 "Bidding farewell to Google Code" を元に、鈴木が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Code のプロジェクト ホスティング サービスを 2006 年に開始したときは、プロジェクト ホスティングはまだあまり一般的ではありませんでした。信頼性や成長性に疑問が抱かれていたため、ユーザーにとって別の選択肢となるようなサービスを提示できるよう Google はオープンソース コミュニティに働きかけました。それ以来、GitHub や Bitbucket bloom などさまざまなプロジェクト ホスティング サービスが登場してきました。多くのプロジェクトが Google Code からそうした他のシステムに移行していきました。こうした開発者の方々の現状を考え、Google は Google Code に持っている 1000 近いオープンソース プロジェクトを GitHub に移行しました。

開発者が Google Code から離れているため、残りのプロジェクトでスパムや悪用の割合が増えている実情もあります。最近では Google Code の管理業務がほとんど悪用への対策に費やされるという状況で、Google Code の悪用ではないアクティビティを調べた結果、このサービスはもはや必要でないことが明白になりました。

3 月 12 日をもって、Google Code で新規プロジェクト作成はできなくなりました。そして 2016 年 1 月 25 日にサービスを完全に終了します。Google Code にお持ちのプロジェクトの移行をサポートする各種ツールのリンクを下記に示します。また、Google Code から他のホストへの移行にサポートが必要なプロジェクトについては、今後 3 か月間 Google がサポートいたします。
  • 2015 年 3 月 12 日、新規プロジェクトの作成ができなくなりました。
  • 2015 年 8 月 24 日、Google Code サイトが読み取り専用になります。プロジェクトの Source、Issue、Wiki のチェックアウトや閲覧は引き続き行っていただけます。
  • 2016 年 1 月 25 日、プロジェクト ホスティング サービスが終了します。プロジェクトの Source、Issue、Wiki の圧縮ファイルは引き続きダウンロードできます。圧縮ファイルは 2016 年の終わりまで保持する予定です。
Android や Chrome など特定のプロジェクトについては Git や Gerrit でのホスティングを継続していきます。また、Eclipse や kernel.org、その他のプロジェクトはミラーを維持します。

Google Code からデータを移行する方法

Google Code からデータを移行するもっとも簡単な方法は、Google Code から GitHub へのエクスポート ツールを使うことです。このツールを使えば、プロジェクトの Source、Issue、Wiki を新しい GitHub のリポジトリに自動的に移行できます。GitHub のインポーターでは、Subversion や Mercurial で管理している Google Code プロジェクトが Git 向けに変換されますのでご注意ください。

加えて、スタンドアロン ツールを使って GitHub や Bitbucket にも移行できます。また、SourceForge では、Google Code プロジェクト インポート サービスが提供されています。

これらのツールを使う際に問題が発生した場合は、Google Code の Issue としてご連絡いただくか、google-code-shutdown@google.com までメールでお知らせください。あるいは Chris DiBona に直接メール（cdibona@google.com）をお送りください。Hacker News や Reddit などの一般的なフォーラムサイトも頻繁に確認し、公の場でご質問に回答していきます。Google Code を使い続けていただいている皆さんにはご不便をおかけすることになり、申し訳ございません。移行プロセスが簡単なものになるよう全力でサポートしていきます。

GitHub や Bitbucket では Google Code から移行する開発者の皆さんを受け入れることを楽しみにしています。今回 Google Code 終了を公表するにあたり、どちらのサイトにも多くのご協力をいただきましたので、この場を借りて、彼らのコミュニティへの継続的なサポートに感謝したいと思います。2006 年当時には存在しなかった機能が提供されていますので、皆さんのプロジェクトで役に立つものを探すお手伝いもさせていただきます。

Posted by Takuo Suzuki - Developer Relations Team

新しい年度が始まりました。新生活を始めた方も多いのではないでしょうか？

さて、Android 版 Google 日本語入力をアップデートしたことをお知らせします。




「あめ」「うれしい」など一部の候補を確定した直後に、確定した文字に対応する絵文字や顔文字を変換候補に表示するようにしました。


ハードウェアキーボード利用時に、現在の入力モードがひらがなかアルファベットかを表示するようにしました。対応していないアプリケーションでは表示されません。


数式を入力した際、計算結果を変換候補に表示するようにしました。


Android-TV での動作をサポートしました。販売中の NexusPlayer には既に導入されていますが、本バージョンはより新しいものとなっています ...
新しい年度が始まりました。新生活を始めた方も多いのではないでしょうか？

さて、Android 版 Google 日本語入力をアップデートしたことをお知らせします。

主な変更点

予測変換の機能向上
「あめ」「うれしい」など一部の候補を確定した直後に、確定した文字に対応する絵文字や顔文字を変換候補に表示するようにしました。

(Lollipop) ハードウェアキーボード利用時の入力モード表示
ハードウェアキーボード利用時に、現在の入力モードがひらがなかアルファベットかを表示するようにしました。対応していないアプリケーションでは表示されません。

計算機能
数式を入力した際、計算結果を変換候補に表示するようにしました。

Android-TV のサポート
Android-TV での動作をサポートしました。販売中の NexusPlayer には既に導入されていますが、本バージョンはより新しいものとなっています。

その他の変更点
  • 辞書を更新しました。
  • メモリ消費量を低減しました。
  • 履歴に基づいた変換候補の精度を改善しました。
  • タブレットにおいてポップアップの表示を抑制しました。
  • (Lollipop) 入力方法切り替えキーが有効になるタイミングを調整し、素早くタイピングした時に誤って入力方法が切り替わってしまうことがないようにしました。

問題の修正
  • マッシュルームプラグインの動作互換性を改善しました。
  • 一部アプリケーションにおける確定キーの動作を改善しました。
  • 外国語向けのハードウェアキーボードを利用した時にクラッシュすることがある問題を修正しました。


これからも、Google 日本語入力をよりよくしようと、チーム一同で開発を進めていきます。お気づきの点がありましたら、ぜひプロダクト フォーラムからお知らせください。みなさんのフィードバックがなによりの励みになります。

Posted by 矢藤 康祐 Software Engineer