[go: nahoru, domu]

[この記事は Florian Bertele, Product Manager, Google Places API による Geo Developers Blog の記事 "New Autocomplete widget helps users with places and address entry in mobile apps" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

米国時間 12 月 17 日、Google は、アプリ内でユーザーが場所や住所をより素早く入力できるようにする機能の提供を開始しました。ユーザーが場所の名前や住所を入力している途中で、自動的に補完するオートコンプリート機能であり、次の 2 つの方法で提供します。一つは、オートコンプリート ウィジェットです。iOS(英語)と Android に対応しており、わずかなコーディング作業でオートコンプリート機能をアプリケーションに追加できます。もう一つは、オートコンプリート機能を追加した Place Picker です。

オートコンプリート ウィジェットとは


今回リリースしたオートコンプリート ウィジェットの UI には、オーバーレイとフルスクリーンの 2 つのタイプがあります。

オーバーレイ タイプのオートコンプリート ウィジェット


フルスクリーン タイプのオートコンプリート ウィジェット

Android では、オートコンプリート ウィジェットはフラグメント(英語)として追加することができます。イベント リスナーを追加し、オートコンプリートされたプレイスのリファレンスをアプリケーションにて受け取ります。あるいは、オートコンプリート ウィジェットをインテント(英語)で起動することもできます。
アクティビティのXML レイアウト ファイルにフラグメントを追加する方法:
<fragment
  android:id="@+id/place_autocomplete_fragment"
  android:layout_width="match_parent"
  android:layout_height="wrap_content"
android:name="com.google.android.gms.location.places.ui.PlaceAutocompleteFragment"
  />

アクティビティの onCreate() メソッドにイベント リスナーを追加する方法:
// 
PlaceAutocompleteFragment fragment = (PlaceAutocompleteFragment)
    getFragmentManager().findFragmentById(R.id.place_autocomplete_fragment);

fragment.setOnPlaceSelectedListener(new PlaceSelectionListener() {
   @Override
   public void onPlaceSelected(Place place) { // 選択したプレイスを処理
   }
   @Override
   public void onError(Status status) { // エラーを処理
   }


オートコンプリート ウィジェットを起動するインテントを作成する方法:
try {
   Intent intent =
            new PlaceAutocomplete.IntentBuilder(PlaceAutocomplete.MODE_FULLSCREEN)
           .build(this);
   startActivityForResult(intent, PLACE_AUTOCOMPLETE_REQUEST_CODE);
} catch (GooglePlayServicesRepairableException e) {
   GooglePlayServicesUtil
           .getErrorDialog(e.getConnectionStatusCode(), getActivity(), 0);
} catch (GooglePlayServicesNotAvailableException e) {
   // 例外を処理
}


iOS(Objective-C)では、オートコンプリートのデリゲートを実装してプレイス選択に対応します。
@interface MyViewController () 
@end

@implementation ViewController
.
.
.
- (IBAction)onLaunchClicked:(id)sender {
  // ボタン押下時にオートコンプリート ビュー コントローラーを表示
  GMSAutocompleteViewController *acController = [[GMSAutocompleteViewController alloc] init];
  acController.delegate = self;
  [self presentViewController:acController animated:YES completion:nil];
}

- (void)viewController:(GMSAutocompleteViewController *)viewController
    didAutocompleteWithPlace:(GMSPlace *)place {
  // ユーザーがプレイスを選択
  [self dismissViewControllerAnimated:YES completion:nil];
}

- (void)viewController:(GMSAutocompleteViewController *)viewController
    didAutocompleteWithError:(NSError *)error {
  [self dismissViewControllerAnimated:YES completion:nil];
}

// ユーザーがキャンセル ボタンを押下
- (void)wasCancelled:(GMSAutocompleteViewController *)viewController {
  [self dismissViewControllerAnimated:YES completion:nil];
}

@end

Swift の場合:
import UIKit
import GoogleMaps

class MyViewController: UIViewController {
    
    @IBAction func onLaunchClicked(sender: AnyObject) {
        let acController = GMSAutocompleteViewController()
        acController.delegate = self
        self.presentViewController(acController, animated: true, completion: nil)
    }
}

extension MyViewController: GMSAutocompleteViewControllerDelegate {
    
    func viewController(viewController: GMSAutocompleteViewController!, didAutocompleteWithPlace place: GMSPlace!) {
        // ユーザーがプレイスを選択
        self.dismissViewControllerAnimated(true, completion: nil)
    }
    
    func viewController(viewController: GMSAutocompleteViewController!, didAutocompleteWithError error: NSError!) {
        self.dismissViewControllerAnimated(true, completion: nil)
    }
    
    func wasCancelled(viewController: GMSAutocompleteViewController!) {
        self.dismissViewControllerAnimated(true, completion: nil)
    }
}

Place Picker にもオートコンプリートを


今回、場所名や住所、地図上の位置など、自分の現在地を知らせるのに便利な UI ウィジェット Place Picker にもオートコンプリート機能を追加しました。ユーザーは場所名や住所の一部を入力するだけで、目的の場所をさらに素早く選択できるようになります。

なお、すでにアプリで Place Picker を利用している場合は、自動的にオートコンプリート機能が実行されますので、開発者側では何もする必要はありません。
まずはドキュメントとコード サンプルをご覧ください。ご質問やご意見、ご提案などがありましたら、Stack Overflow(英語)または Google Maps API のバグ報告用掲示板(英語)にてお知らせください。

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

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

Google Play サービス 8.3 では、Google アカウントでのサインインのエクスペリエンスを大きく改善しました。変更について理解を深めていただけるよう、このブログにデベロッパー向けの解説を連載することとし、今回はその第一弾です。本稿では、ユーザー エクスペリエンスに対する変更、その変更をアプリに実装する方法、Google へのサインイン部分のコーディングをよりシンプルにする API のアップデートを紹介します。Android Marshmallow では、この新しい Sign-In API はデバイスのパーミッションを一切要求しません。旧バージョンの API では、デバイス上のアカウントへのランタイム アクセスを要求していましたが、これは不要になりました。

ユーザー エクスペリエンスの改善

Google のソーシャル サインイン ボタンを操作するユーザー エクスペリエンスについて、デベロッパーの皆様からのフィードバックが多数寄せられてきました。ユーザーにとってはステップが多く、混乱を招くとのご指摘を多数の方からいただきました。従来のユーザー エクスペリエンスは、まずユーザーがボタンをタッチすると、アカウントを選択するためのダイアログが表示されるというものでした。アカウントに Google+ プロファイルがない場合、ここで作成しなければなりません。さらに、アプリで必要とされる情報のタイプに基づいてパーミッションを付与する必要があります。従来はこのような手順を踏まないと、アプリにサインインできませんでした。

新しい API では、アプリが要求するパーミッションの初期セットが削減され、こちらに示したとおり、基本的なプロファイル情報に、オプションとしてメールアドレスを追加するようになっています。これでユーザー エクスペリエンスがかなりシンプルになります。まずはボタンそのもの:これまで、サインイン ボタンのブランディングが、実際には Google+ のデータを使用することはない場合でも、サインインに Google+ のデータが必要と誤解するユーザーもいる、というフィードバックを多数いただいてきました。そこで SignInButton のスコープを削減し、ブランディングを再構成、ボタンの表示を「Sign In with Google」(Google へのサインイン)として、Google 標準のブランディング に従い、基本的なプロファイル情報のみを使用するようにしました。
それ以降のユーザー操作もシンプルになりました。以前はこの場面で、デバイスに登録されたメールアドレスから、Google アカウントを選択する画面が表示され、続いて [Create Google+ Profile] ダイアログとパーミッションに同意するダイアログが表示されていました。
それが、ユーザーにアカウントを選択して同意してもらうだけという単一のステップに変更されました。ユーザーが Google+ プロファイルを所有していない場合、作成するステップは省略されています。その後の同意ダイアログは別途表示することになります。アプリがなぜユーザーのカレンダーや連絡先にアクセスするかについて、ユーザーが理解しやすいよう、データが実際に必要になったときのみ、コンテキスト内で認可を求めるのがベストプラクティスです。
これらに変更によって、Google アカウントを使ったサインイン率が向上すると期待しています。

InstacartNPR OneBring! など、この新しい API を使用したアプリは既に公開されています。
次回の投稿では、API を変更して Google Sign-In を使用するアプリのコーディングをもっと簡単にする方法について説明します。


Posted by Eiji Kitamura - Developer Relations Team

[この記事は Lily Sheringham、Google Play デベロッパー マーケティングによる Android Developers Blog の記事 "Developer tips for success with Player Analytics and Google Play games services" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

編集者のメモ: デベロッパーからのヒントを紹介するシリーズです。Google Play で成功を収めるには、Player Analytics と Google Play ゲーム サービスをどのように活用すればいいのか、人気が高いゲームのデベロッパー数名に話を聞きました。- Ed.

デベロッパー コンソールから利用可能な Google Play ゲーム サービスは、ゲームに実績や順位表といった機能を追加するためのものです。Google Play ゲーム サービスで提供している Player Analytics は、ゲームに特化した無料のアナリティクス ツールで、デベロッパー コンソールの「ゲーム サービス」タブから利用できます。このレポートを使えば、ゲームにおけるプレーヤーの進行、有料サービス購入の状況、ゲームをやめるタイミングなどをデータ駆動型のアプローチで把握することができます。

Player Analytics によってユーザー1人あたりの収益 140% 増を達成した「Bombsquad」


Eric Froemling は独立系のデベロッパーで、ゲーム「Bombsquad」は当初趣味として製作していました。しかし今、Eric はこのゲームで生計を立てています。昨年 Eric は、このゲームのビジネスモデルを有償から無償に切り替えました。Player Analytics を活用して、プレイヤーの定着率とマネタイズ(収益化)の方法を改善した結果、アクティブ ユーザー 1 人 1 日あたりの平均収益(ARPDAU)が 140 % 増となりました。

プレイヤーのゲーマー体験を改善して、定着率と現金収入を増やすために、Eric が Player Analytics とデベロッパー コンソールをどのように使用したかについては、こちらの動画をご覧ください。

Auxbrain が明かす、Google Play ゲーム サービスで成功するためのヒント


ゲーム開発会社 Auxbrain の創設者であり CEO である Kevin Pazirandeh は、「Zombie Highway」 のクリエイターでもあります。Kevin は Google Play ゲーム サービスの活用方法の知見を次のようにコメントしています。

「多少の例外はありますが、エンゲージメント(ユーザーのゲーム利用時間)の測定については、これほど良いツールは他に見当たりません。さらに、ユーザーの定着率が表形式で示されているだけでなく、エンゲージメントの変化もわかることも大事です。このツールを使ったことのない人たちのために説明すると、ユーザーの定着率のテーブルは毎日更新されるもので、最初にプレイした日から数日後に再度プレイしたプレーヤーのパーセンテージがわかります。自分のゲームの定着率をよく似た他のゲームのものと比較すれば、開発した機能が正しかったかそうでないか、デベロッパーにはすぐにわかります」

Google Play ゲーム サービスのアナリティクス ツールを最大限に活用するための方法について、Kevin がとっておきのコツを教えてくれました。
  1. Player Analytics は無償で使える - あなたのゲームに Google Play ゲーム サービスを既に組み込んでいる場合は、デベロッパー コンソール上で [Game services] > [Player Analytics] を選択すると、そのゲームに関するアナリティクス データを取得することができます。
  2. 変更は必ずしも改善とはならない - デベロッパーがよかれと思ってゲームに手を加えても、プレーヤーはその変更を改善とは捉えない場合があります。ゲームに変更を加えるときには、その効果を測る方法も、戦略として用意しておきましょう。Player Analytics で変更の影響が確認できない領域については変更を実施せず、効果が予測できる変更を優先させましょう。
  3. 成績やイベントを設定するとプレーヤーの進捗が追跡できる - プレーヤーの成績やイベントを記録する機能を実装すると、プレイヤーの進捗レポートや Event viewer を使用して、各プレイヤーのゲームの到達度を追跡することができます。こうすると、プレーヤーが苦戦したり行き詰ったりする場面がすぐにわかるので、プレーヤーが先に進めるように救済する方法を探すこともできます。
  4. サインイン情報を使用してより多くのデータを入手 - 収集したプレーヤーの進捗データが増えるのに比例して、Player Analytics のレポートの精度も上がります。データを収集するには、ゲームに加わるプレーヤーを増やすのが一番です。プレイヤーのログインは自動的に実行し、ゲームに再訪したプレイヤーに対しては、最初の画面で(チュートリアルを示してから)、前回の続きからゲームを開始できるようにします。
  5. 定着率テーブルでプレーヤーのエンゲージメントを追跡 - 定着率テーブル レポートで、どのタイミングでプレーヤーが離脱するかを長期間にわたって観察することができます。ゲームに変更を加える前後で定着率が変化したかどうかを見ることもできますし、ゲームの設計を変更するとプレーヤーの離脱するタイミングが早くなったり遅くなったりするかどうかを、他の類似ゲームと比較して判断することもできます。
Google Play Games Services の詳細はこちらをご覧ください。また、当社の製品とベストプラクティスの情報は、あなたのビジネスを世界規模に拡大することにつながる可能性があります。


Posted by Eiji Kitamura - Developer Relations Team

[この記事は Aditya Tendulkar, Product Manager, Google My Business による Geo Developers Blog の記事 "Introducing the Google My Business API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

米国時間 12 月 15 日、Google は Google My Business API(英語)をリリースしました。Google My Business は、Google の検索ユーザーと世界中の企業とをつなぐ上で有効な手段です。この API により、大企業やサードパーティが Google My Business プラットフォームに統合することが容易になり、より簡単な方法で最新情報を Google 検索および Google マップに公開できるようになります。例えば、クリスマスや年末年始といった特別な期間の営業時間を設定し、その設定内容をすべての営業拠点・店舗に反映させることが容易にできます。

Google My Business API では次のことが可能になります。

  • 店舗名、住所、電話番号、カテゴリー、営業時間などさまざまな情報を設定しながらロケーションを作成 
  • 特別営業時間(祝祭日や特別なイベントなど営業時間が普段と異なる場合の設定)を管理 
  • ビジネス ロケーションに閉業・閉店のマークを設定 
  • 営業用の写真を管理 
  • ロケーションおよびビジネスのアカウントにてマネージャーを一覧表示、招待、削除 
  • ロケーションの更新・重複・一時停止状況を確認 
  • ロケーションを名前、カテゴリー、ラベルで検索/フィルタリング 
  • 地点と半径、または Place ID を指定してそのビジネスのサービス提供エリアを設定 
  • 新しいロケーションを作成して特別営業時間を設定する 

Java コードのサンプルを紹介します。

public static Location createLocation(String accountName) throws Exception {
  Location location = new Location();

  // Street address
  Address address = new Address();
  List addressLines = Arrays.asList("740 Valencia Street");
  address.setAddressLines(addressLines);
  address.setLocality("San Francisco");
  address.setAdministrativeArea("CA");
  address.setCountry("US");
  address.setPostalCode("94110");
  location.setAddress(address);

  // Business hours
  BusinessHours businessHours = new BusinessHours();
  List periods = new ArrayList<>();
  List days = Arrays.asList("Monday", "Tuesday", "Wednesday", "Thursday", "Friday");
  for (String day : days) {
    TimePeriod period = new TimePeriod();
    period.setOpenDay(day);
    period.setOpenTime("11:00");
    period.setCloseTime("20:00");
    period.setCloseDay(day);
    periods.add(period);
  }
  businessHours.setPeriods(periods);
  location.setBusinessHours(businessHours);

  // Special hours
    Date christmasEve = new Date().setYear(2015).setMonth(12).setDay(24);
    Date christmasDay = new Date().setYear(2015).setMonth(12).setDay(25);
    List periods = new ArrayList<>();
    periods.add(new SpecialHourPeriod()
        .setStartDate(christmasEve)
        .setOpenTime("11:00")
        .setCloseTime("20:00")
        .setEndDate(christmasEve));
    periods.add(new SpecialHourPeriod()
        .setStartDate(christmasDay)
        .setIsClosed(true));
   SpecialHours specialHours = new SpecialHours()
        .setSpecialHourPeriods(periods);

  location.setSpecialHours(specialHours);

  location.setLocationName("Dandelion Chocolate");
  location.setStoreCode("DC1");
  location.setPrimaryPhone("415 349-0942");
  location.setPrimaryCategory(new Category().setCategoryId("gcid:chocolate_shop"));
  location.setWebsiteUrl("https://www.dandelionchocolate.com/");

  // Create Location
  CreateLocationRequest createLocationRequest = new CreateLocationRequest();
  // RequestId is a unique id for each location created
  createLocationRequest.setRequestId(“1a84939c-ab7d-4581-8930-ee35af6fefac”);
  createLocationRequest.setLocation(location);
  createLocationRequest.setLanguageCode("en-US");
  Mybusiness.Accounts.Locations.Create createLocation =
      mybusiness.accounts().locations().create(accountName, createLocationRequest);

  Location createdLocation = createLocation.execute();

  System.out.printf("Created Location:\n%s", createdLocation.toPrettyString());
 
  return createdLocation;
}
以上の特別営業時間が Google My Business に(英語)設定されると、次の図のように、ホリデーシーズンの営業時間に表示が切り替わります。(英語)。



Google My Business API の詳細およびアクセスの申請方法については、こちらのデベロッパー向けのページ(英語)をご覧ください。

ご質問やご意見などがありましたら、Google My Business API フォーラムにて API チームにご連絡ください。

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

[この記事は Laurence Moroney、Android Wear デベロッパー アドボケートによる Android Developers Blog の記事 "What’s new in Google Play services 8.3" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Play サービス 8.3 では新たな機能が多数追加されたので、それについてご紹介します。

今回のリリースの大きな特徴は、ユーザー認証の強化です。まず、Google Sign-In 関連の API を更新し、ユーザー エクスペリエンスが簡潔になるように実装を簡略化しました。新しい Google Sign-In では、デバイス アカウントのパーミッションが不要です。Marshmallow 向けにアプリの開発を進めているデベロッパーには大変便利になりました。API には、最新の Google ブランディングも反映しています。Google Play サービス 8.3 を使用する際、デフォルトのスコープでは SignInButton はこのような外観でした。
以前なら、ユーザーは「サインイン」ボタンにタッチしてから、複数のステップ(アカウントの選択、プロファイル情報へアクセスするためのパーミッション付与、場合によっては Google+ アカウントの作成など)を実行しなければなりませんでした。ところが Google Play サービス 8.3 では、ワンタップするだけで基本プロファイルにアクセスできます。

新しい API に関するドキュメントはこちらでご確認いただけます。

また、複数のデバイスで同時にサインインしやすくするため、Google Sign-In を使っている場合でも、従来のパスワードベースの認証を使っている場合でも、Smart Lock API は重要な更新を受信します。また、新しい API メソッドを追加しました。このメソッドは、ユーザーがサインイン用に使用しているメールアドレスをサインイン用のフォームにあらかじめ入力しておく、またはフォームが表示された際にユーザーの入力を支援するような設定を行うためのダイアログを表示するためのものです。getHintPickerサンプル コード)をご確認ください。このメソッドでは、どのデバイスからもパーミッションを受け取る必要はなく、メソッドがデバイス上のアカウント情報をサインイン情報として受信していた、ピッカーに代わる役割を果たします。したがって Marshmallow では、デバイスからのアクセスにはランタイム パーミッションが必要となります。

ヒント情報を使用すれば、サインイン用のフォームに必要な情報、すなわち名前、メールアドレス、プロフィール画像などを、サインイン時にワンタップで一気に入力することができます。あるいはメールアドレスを使って、ユーザーをサインインやサインアップの操作にスマートに誘導することもできます。ユーザーが選択したエントリがデバイス上のアカウントと一致する場合、検証済みのメールアドレスを Google からヒント情報として送信して、メールアドレスの検証とユーザー認証を省略できる仕組みをシステムに実装するのが一番望ましい方法です。ID Token は、Google Sign-In でも採用しています。

Google Play サービスには、ユーザーの所在地を特定するために、GPS、WiFi、携帯電話の無線通信用信号など、内蔵している位置情報のセンサーから情報を抽出し、使いやすい API に統合して格納する、位置情報統合(FLP)機能があります。バッチ化については、FLP を改善しました。バージョン 8.3 より古いバージョンでは、位置情報のバッチ API を使用して FLP でネットワーク トラフィックを統合し、使用電力を節約していました。ただし、アプリが位置情報リクエストのバッチを削除した場合、バッチはクリアされていました。これを防ぐために、バッチ化した位置情報を直ちに返す API を追加しました。詳細は、FusedLocationProviderApiflushLocationsremoveLocationUpdates メソッドの呼び出しをご確認ください。

App Invites は、ユーザーが知人とアプリを共有できるようにするテクノロジーです。Google Play サービス 8.3 には、App Invites を組み込んでアプリをビルドすると、コーディングをかなりシンプルにできるよう更新されました。AppInvite.AppInviteApi.getInvitation() メソッドが使えるようになりました。このメソッドは、ディープリンク アクティビティの起動に使用する ResultCallback をセットアップするので、コードがシンプルになります。

Play Game サービスの Player Stats API もアップデートされています。最新版には、ゲームを辞めてしまいそうなプレーヤーを表す、新しいシグナルが追加されました。このシグナルを利用して、辞めそうなプレーヤーに通常価格よりお得なパワーアップ アイテムを販売するなど、ユーザーの定着率を上げる特別プロモーションを提供できます。

最後に、ウェアラブル端末対応のアプリを開発している場合、優れたユーザー エクスペリエンスを提供するには、バッテリーの寿命と電力利用の最適化が極めて重要になることはご存じでしょう。Google Play サービス 8.3 では、緊急時にもデータ アイテムを同期できる DataApi を更新しました。データ アイテムに優先度が追加されたので、同期を実行するタイミングを指定できるようになりました。遠隔操作アプリのように、すぐに同期しなければならないアプリを制作されている場合、setUrgent() を呼び出すと、同期を直ちに実行することができます。連絡先を更新するアプリであれば、多少の同期遅れを許可することができます。緊急ではない DataItems は 30 分まで遅延できますが、2~3分以内に届くことがほとんどです。デフォルトでは優先度は「低」に設定されています。したがって、以前と同様に即時の同期を実行したい場合は、setUrgent() を呼び出す必要があります。

Android Wear API のリスナーに、フィルターが追加されたため、リスナーは変更のサブセットのみを携帯端末とウォッチの両方で受け取れるようになりました。Android の Manifest ファイルに登録済みのリスナーはフィルターで抽出され、プロセスの開始が必要なイベントのみを受信します。それ以外のイベントは、addListener() などのメソッドで追加された、接続中のリスナーに送信されます。リスナーが関心を持っていないイベントを除去する手間が省けるので、アプリやシステムの効率が上がります。

今回の Google Play サービスのリリースについての説明は、以上です。詳細は、Google デベロッパーサイトをご覧ください。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Gayathri Rajan、Ryan Cairns による Google Developers Blog の記事 "Building Brillo-iant devices with Weave for a Connected world" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

今年初めの Google I/O において、端末接続に最適なソリューション、 BrilloWeave のプレビュー版をリリースしました。

Brillo は、Android、コアサービス、開発者キット、デベロッパー コンソールで構成されており、軽量の組み込み OS を採用することで、ハードウェアでもソフトウェアと同様に簡単かつスピーディに開発が行えます。豊富なハードウェア機能とカスタマイズ オプションがあり、試作品から本番までの速やかな移行や、無線(OTA)更新、メトリック、クラッシュ レポートなど各種管理が可能です。

Brillo の詳細については、次のビデオをご覧ください。
接続端末の開発では、他の端末との通信方法を選択し、ユーザーと接続端末の通信を許可する必要があります。そこで Weave が必要となります。Weave では、双方向から操作できる通信機能を端末に直接組み込むことができます。また携帯電話や端末がクラウドから、ローカルやリモートで相互に通信できるメッセージング サービスも提供しており、Weave クラウド サーバーを使用することで、リモート通信でウェブ接続端末にどこからでも安全にアクセスできます。Weave で端末の設定やアクセス制限を安全に行うこともできます。さらに Brillo 内に直接組み込まれているため Brillo に対してシームレスに動作しますが、Weave ライブラリを既存の Linux ベース OS で使用することも可能です。

Weave の優れた機能については、次のビデオをご覧ください。
Weave には iOS 用と Android 用のモバイル SDK が搭載されており、モバイル ユーザーの接続状態を管理し、さらに機能を強化できるアプリを構築できます。アプリを実際の端末まで適用したいと考えるアプリ開発者は、Weave のモバイル およびウェブ API を使用して、機種や台数に関係なく Weave 端末を 1 つのアプリで制御できます。

Brillo と Weave は、デフォルト設定でもオープン、拡張可能、しかも安全なため、さまざまな端末や使用事例をサポートでき、提供されるプラットフォーム、ツール、サービスで端末やアプリがさらに使いやすくなります。

プラットフォーム以外にも、認定 Weave ブランドの端末を提供する Weave 互換性プログラムのほか、シリコン ベンダーが Brillo 準拠のハードウェア開発と販売を行うための、ハードウェア プログラムを順次公開していきます。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Joshu Gordon、デベロッパー アドボケートによる Android Developers Blog の記事 "New Course on Developing Android Apps for Google Cast and Android TV" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google は、Android アプリのユーザーが日常を過ごしている場所、つまりリビングルームでもお役に立ちます。Google Cast を使うと、ユーザーは Android、iOS、ウェブから、お気に入りのアプリをテレビに送信することができます。Android TV を使用すれば手持ちのテレビを Android 端末として使えるので、アプリを大きな画面で見ることができます。
先日お知らせした Android Wear のコースに続き、新しいオンライン コース「Google Cast and Android TV Development」(Google Cast と Android TV の開発)を Udacity に開設したことをお知らせします。このコースでは、既存の Android アプリを拡張して、テレビと連携させる方法を説明しています。実用的なアドバイス、コード スニペット、サンプルコードの詳細な説明など、盛りだくさんの内容です。

Google Cast と Android TV の両方に対応するためにアプリを書き直す必要はありません。Android TV は、Android に新しいフォームファクタが加わっただけのものです。Leanback library により、大きなスクリーンにアプリを表示するのが簡単になります。また、アプリに映画のような UI を追加することもできます。Google Cast には、誰もがすぐにこのデバイスを使えるように、サンプルやガイドが用意されています。また Google は Cast Companion Library を提供していますが、これは Android アプリの Google Cast への追加を迅速かつ簡単に実行するためのものです。

オンライン コースでは、Android WearAndroid Auto など、他の Google プラットフォームも含めた、ユビキタス コンピューティング シリーズの一環として実施します。それぞれが独立した短期コースのため、単独でも一括でも受講可能です。

学習は今すぐ、無料で開始できます。ユーザーのみなさんが、あなたのアプリをテレビで見られる日を待っていますよ。


Posted by Takuo Suzuki - Developer Relations Team

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

3 つの新しい Android Marshmallow サンプル アプリケーションの提供が開始されました。通常どおり、GitHub の Google Samples リポジトリ、または Android Studio のサンプル ブラウザから直接入手できます。

Android ダイレクト シェアのサンプル







ダイレクト シェアは Android Marshmallow の新機能であり、提供される API によって、ユーザーはより直感的に素早く情報を共有できるようになります。ダイレクト シェアによって、ユーザーは他のアプリ内のターゲット (例: 連絡先) とコンテンツを共有できます。たとえば、ダイレクト シェアのターゲットが他のソーシャル ネットワーク アプリのアクティビティを起動し、そのアプリ内の特定の友人と直接コンテンツを共有できるようになります。

このサンプルはダミーのメッセージング アプリで、その他のメッセージング アプリと同様に、プレーン テキストを共有するインテント (意図・目的) を受け取ります。このサンプルは、共有するインテントの候補リストに、複数のオプションを直接表示させる方法をデモします。別のアプリからのテキストメッセージをユーザーが共有する際、このサンプル アプリがオプションとしてリストされます。ダイレクト シェアの機能を使用すると、このアプリの選択ダイアログにいくつかの連絡先が直接表示されます。

ダイレクト シェアを有効にするには、アプリに ChooserTargetService を拡張するサービスを実装する必要があります。メソッド onGetChooserTargets() をオーバーライドし、ダイレクト シェアのオプションのリストを返します。

AndroidManifest.xml の、インテントを受け取るアクティビティにメタデータのタグを加えます。android.service.chooser.chooser_target_service として android:name を指定し、サービスに android:value を指定します。

Android MidiSynth のサンプル

Android 6.0 では新たに MIDI がサポートされました。このサンプルでは MIDI キーボードなど、取り付けられた入力デバイスから送られた MIDI メッセージを受信・再生するために MIDI API を使用する方法をデモします。

Android MIDI API (android.media.midi) により、デベロッパーはAndroid 端末に MIDI 端末を接続し、送られてくる MIDI メッセージを処理することができるようになります。

このサンプルでは、以下のような MIDI API の基本機能のいくつかをデモします。
  • 現在、使用可能なデバイスの一覧表 (含: 名前、ベンダー、性能)
  • MIDI 端末の接続時または接続解除時の通知
  • MIDI メッセージの受信と処理

シンプルなオシレーターと音符再生機能も実装されています。

Android MidiScope のサンプル

取り付けられたデバイスから MIDI 信号を受け取り、処理するために MIDI API を使用する方法をデモするサンプルです。

Android MIDI API (android.media.midi) により、デベロッパーはAndroid に MIDI 端末を接続し、送られてくる MIDI 信号を処理することができるようになります。このサンプルでは、現在使用可能なデバイスの一覧表 (含: 名前、ベンダー、性能)、MIDI 端末の接続時または接続解除時の通知、MIDI 信号の受け取りといった MIDI API の基本機能をデモします。このサンプルは受け取った MIDI 信号すべてをスクリーン ログに表示するのみで、サウンドは再生しません。

サンプルを今すぐ確認して、Android Marshmallow 開発に取り組んでみてください。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Mugur Marculescu、プロダクト マネージャーによる Google Developers Blog の記事 "gRPC releases Beta, opening door for use in production environments" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

gRPC ベータ版がリリースされました。今回のリリースは API の安定性を高める重要なリリースであり、今後の変更は追加のみになる予定です。本番環境での gRPC 利用も視野に入れることができます。

また、インストール プロセスも大幅に向上される予定です。過去数週間にわたり、gRPC パッケージを Debian Stable/Backports にて公開しました。多くの場合、インストールには Debian パッケージまたは言語別のパッケージ マネージャー(たとえば、 mavenpipgemcomposerpeclnpmnugetpod)を使用する 2 つの方法があります。また、 gRPC docker イメージを Docker Hub で利用できるようになりました。

grpc.io のドキュメントには最新の変更を反映し、言語固有の リファレンス ドキュメントを追加リリースするなどの更新を行いました。ベータ版リリースにともなう JavaGo他のすべての言語の変更点については、GitHub のリリース ノートを確認してください。

今後数ヶ月は、本稼働でのパフォーマンスや安定性の向上に集中的に取り組み、機能を厳選して追加していく予定です。 これは、 HTTP/2 上での高性能で拡張性の高い API とマイクロサービスを可能にするという、Google の方針および目標の一環です。またドキュメントも明確に記述され、新たな使用例やガイドが引き続き追加される予定です。

gRPC に対するコミュニティの対応や、gRPC を使用予定の各種プロジェクト(etcd v3 の試験 API、RESTful API 用の grpc-gateway など)に対し感謝申し上げます。またコードのコントリビューション、プレゼンテーションの実施、gRPCの採用、コミュニティへの参加をいただいた皆様には心よりお礼申し上げます。正式版(1.0)へのご支援もどうぞよろしくお願いいたします。

Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Damien Mabin、デベロッパーアドボケートによる Android Developers Blog の記事 "Virtual currency: Sources and Sinks" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

仮想通貨を提供し、無料提供をうたったモバイル ゲームが近年増えていますが、ゲーム開発時に陥りがちな危険が多数あることも認識しておかなくてはなりません。1 つめの危険は経済バランスが狂うことです。Play Games Services のツールに含まれる Sources and Sinks は、ゲームの仮想経済バランスを測る便利な機能です。

ゲーム経済における現在の状況を、簡単な図式を使って視覚化できます。下の図 1 では、x 軸 (時間) と y 軸 (仮想通貨の量) 上に、2 つの曲線があります。
  • 1 つはプレイヤーが稼いだ仮想通貨の量 (オレンジ色の線)です
  • もう 1 つはプレイヤーが使った仮想通貨の量です (緑色の線)

図 1: 収益性の低い経済状態 図 1: 収益性の低い経済状態
図のこれらの曲線は何を意味しているのでしょうか?この場合、ゲームの収益化が期待できないことを示しています。稼いだ通貨量より使った通貨量が少なければ、ユーザーは黒字になります。ユーザーはお金が足りないと感じていません。これはプレイヤーが通貨の使い方または通貨を使うことの価値を理解していないということです。仮想通貨を利用可能なコンテンツがどのくらいあるか、またそのようなコンテンツをすぐに見つけやすくなっているかを再検証する必要があります。またインフレは好ましくないため、ゲームで稼ぐことができる通貨の量を減らすことを検討しても良いでしょう。最終的に、図 2 のような曲線を描くことが望ましいといえます。
図 2 バランスのとれた経済 図 2 バランスのとれた経済
図 1 よりかなり改善されました。ユーザーは、稼ぐ量よりも多くの通貨を使っています。でも少し待ってください。なぜこのようになったのでしょうか?これには 2 つの理由があります。1 つめは、プレイヤーが変更の前に貯めていた通貨のストックを使っているからです。そして 2 つ目は、ユーザーがアプリで購入した通貨は、上の図に含めるべきではないということです。これは覚えておくべき重要なポイントです。もう数日待てば、2 つの曲線が少し近づくでしょう。その差分が、ユーザーが IAP を通じて購入した仮想通貨ということになります。

図 3 安定した経済 図 3 安定した経済
Play Games Services では、コード 2 行でこのように経済を視覚化できます。iOS や Android でも利用でき、ユーザーがサインインする必要もありません。Android や iOS のアプリでは以下のようになります。
実装方法についての詳細はこちらをご覧ください。

実装が完了すれば、Play Store デベロッパー コンソール にてグラフを表示することができます。[Game Service] セクションで、[Player analytics] から [overview] をクリックしてください。


Posted by Eiji Kitamura - Developer Relations Team

[この記事は Wayne Piekarski、デベロッパー アドボケートによる Android Developers Blog の記事 "New Courses -- Developing Watch Apps for Android Wear" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

先日、Android Wear を使用したユビキタス コンピューティング に関する Udacity の新コースを発表しました。これは、Udacity と Google が共同開発したものです。Android Wear のオールウェイズ オン ディスプレイを使えば、一目ですばやく情報を得ることができます。このコースでは、各種通知、カスタム ウォッチ フェイス、フルバージョン アプリの提供に必要な情報について学ぶことができます。

Google のデベロッパー アドボケートにより考案されたこのコースは、Android Wear の利用開始に向けた実践的なアプローチであり、コード スニペットやサンプル コードに関する詳しい説明のほか、既存の Android アプリを Android Wear で使用するための簡単な方法を紹介します。毎日使用するウォッチのインターフェイスは、見やすく目立ちすぎないことが重要です。そこで、ユーザー インターフェースの製作やユニークなウェアラブル プラットフォームで実現可能な機能についても取り上げます。
このコースは、Android Wear、Android Auto、Android TV、Google Cast といった、Google プラットフォーム上のユビキタス コンピューティング シリーズの一部として提供されます。それぞれが独立した短期コースのため、単独でも一括でも受講可能です。Android Wear プラットフォームは、お持ちのアプリに機能性をプラスし、他アプリとの差別化を実現する絶好の機会です。この Udacity コースでは、時間をかけず簡単に Android Wear プラットフォームについて学ぶことができます。

今すぐ無料のコースを始めましょう!


Posted by Eiji Kitamura - Developer Relations Team

[この記事は Megan Boundey, Product Manager, Google Maps Mobile APIs による Geo Developer Blog の記事 The new Google Maps SDK for iOS includes bitcode support, new events and more"" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

米国時間 11 月 30 日、Google は Google Maps SDK for iOS 1.11(英語)をリリースいたしました。このバージョンでは、ビットコード(Bitcode)(英語)への対応や新たなイベントの追加とともに、これまで Android SDK でしか提供されていなかったいくつかの機能が加わりました。

ビットコードは、AppStore にアップロードされるアプリの中間表現です。ビットコードにより、Apple は、プロビジョニング時に特定の対象デバイスのための最適化を行うことができます。

また、今回のバージョンアップでは、didLongPressInfoWindowOfMarker(英語)および didCloseInfoWindowOfMarker(英語)という2つのイベントを新たに追加しました。前者は、Maps SDK for iOS 対応アプリのユーザー操作に、iOS の長押しを活用できるようにするイベントです。後者は、ある特定のマーカーに関連付けられている詳細情報をユーザーが見たあとに、地図を縮小表示するようなプログラムを作成する際に特に便利です。

このほかにも、GMSMapViewDelegate(英語)および GMSPanoramaViewDelegate(英語)プロトコルにレンダリング開始および終了イベントを追加しました。レンダリング開始イベントは、タイルが要求された直後、またはラベルのレンダリング開始直後のトリガーとなります。また、終了イベントは、タイルおよび StreetView のパノラマのレンダリング完了時それぞれのトリガーとなります。

終了イベントは、アクティビティ インディケーターと併用することで、地図のレンダリングが完了したことを正確に表すことができます。この機能の使用方法を示したサンプル コードを紹介します(このサンプルでは、ユーザー エクスペリエンスを向上させるため SVProgressHUD(英語)も加えていますが、これは必須ではありません。)

import UIKit
import GoogleMaps

class MapRenderingViewController: UIViewController {
  @IBOutlet var mapView: GMSMapView!

  override func viewDidLoad() {
    super.viewDidLoad()
    mapView.delegate = self
  }

  // MARK: - GMSMapViewDelegate

  func mapViewDidStartTileRendering(mapView: GMSMapView!) {
    SVProgressHUD.showWithStatus("Loading tiles")
  }

  func mapViewDidFinishTileRendering(mapView: GMSMapView!) {
    SVProgressHUD.dismiss()
  }
}


Google Maps SDK for iOS 1.11 には、さらに以下の便利な新機能とバグ修正が含まれています。

  • グラウンド オーバーレイの透過度をアルファ値で設定 
  • ポリゴン ホールへの対応 
  • ハイズーム時のカメラのチルト レンジを拡大 
  • Places のオート コンプリート機能を追加

詳しくはリリース ノート(英語)をご確認下さい。Google Maps SDK for iOS 1.11(英語)に早速アップデートしてみましょう。

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

Google では 12 月 16 日(水)、Google のテクノロジーの最新情報を紹介する開発者向けイベント Google Developers Meetup #2 を開催します。本イベントでは、Google の Developer Relations チームや Google Developer Experts が、Google の開発プラットフォーム、API, SDK、ツールなどの活用方法をご紹介します。


■イベント概要

【イベント名】 Google Developers Meetup #2
【日程】 2015 年 12 月 16 日(水) 19:00 - 21:00 (開場: 18:30)※ 終了後、懇親会(軽食付き)を行う予定です。
【場所】 イベント&コミュニティスペース dots. in 渋谷
【定員】 200 名
【会費】 無料
【主催】 グーグル株式会社


■セッション
  • スマートフォン体験を一歩先へ - プログレッシブウェブアプリの作り方
  •  : Eiji Kitamura (Developer Advocate)
  • みんなの知らない Chrome Apps の世界 : Yoichiro Tanaka (Google Developer Experts)
  • TechFeedというテクノロジーキュレーションサービスを作った話 : Toru Yoshikawa (Google Developer Experts)
※アジェンダは予告なく変更させていただく可能性があります。予めご了承ください。


■申し込み方法
こちらのフォームよりお申し込みください

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



Posted by Takuo Suzuki - Developer Relations Team

[この記事は Lily Sheringham、Google Play チームによる Android Developers Blog の記事 "Android Developer Story: RogerVoice takes advantage of beta testing to launch its app on Android first" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

RogerVoice は、聴覚障がい者が音声認識システムおよび文字キャプションを使用して通話できるアプリです。重度の聴覚障がいを持つ Olivier Jeannel によって設立されたこの会社は、Kickstarter を通じて 35,000 ドルもの資金調達に成功し事業をスタートさせました。今日、Android プラットフォームで RogerVoice のアプリが初めてリリースされました。

アクセスしやすく直感的なユーザー インターフェースを制作するにあたり、マテリアル デザインとベータ テストがどのように貢献したかについて、RogerVoice の開発チームは次のように語っています。

Google Play の機能を利用した RogerVoice アプリ開発の詳細について:


Posted by Eiji Kitamura - Developer Relations Team

[この記事は Elena Kelarevan、Google Maps API プロダクト マネージャーによる Geo Developers Blog の記事 "New Controls Style for the Google Maps JavaScript API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

コントロールはユーザーと地図間の情報のやり取りを可能にする UI です。ストリート ビューを見るためにペグマンを動かす、または地図と衛星画像を切り替えるなど、コントロールを使用して地図上を探索し、地図から必要な情報を取得します。

Google Maps JavaScript API が提供する多様なオプションにより、デベロッパーは、可視性、位置付け、スタイリング、挙動を変更することでコントロールをカスタマイズすることができます。コントロールのオプションは地図上でコントロールが作用する方法を変更する上で、高い柔軟性をデベロッパーにもたらします。

9 月に Google Maps JavaScript API のデフォルト コントロールのアップデートをリリースしました。アップデートされたコントロールは、さらにモダンな外観と感覚を備え、Google Maps Embed APIGoogle Maps website など、他の Google マップ製品との調和が強化されています。

この API のアップデートにより、コントロールの大部分においてポジション、色、サイズが変更され、一部では機能性も多少変化します。たとえば、ズーム コントロール機能は左上部ではなく右下に配置され、スライダーの代わりに [+] と [-] のボタンのみになりました。さらに、API の バージョン 3.22 (現在の試験運用バージョン) では、コントロールおよびコントロール オプションのいくつかは使用できなくなりました。Google のロゴも新しいバージョンにアップデートされています。


API バージョン 3.23 (2015 年 11 月以降の試験運用バージョン) では、一時的に旧コントロール スタイルに切り替えることができます。バージョン 3.22 と 3.23 で旧コントロール スタイルを使用するには、地図を初期化する前に単独のパラメータ google.maps.controlStyle = 'azteca' を設定します。このパラメータは 2016 年 8 月まで使用可能であり、アプリケーションに必要なアップデートを実施するには十分な時間がとれると思います。バージョン 3.24 (2016 年 2 月以降の試験運用バージョン) では、このパラメータは削除されます。地図に重複するカスタム コントロールまたは UI を使用している場合、2016 年 8 月までに時間的余裕をもって新コントロール スタイルでアプリケーションをテストし、アップデートすることを推奨します。新しいロゴは API のバージョンすべてに影響を及ぼす唯一の変更であり、削除することはできません。

各コントロールによる影響についての詳しい説明と、旧コントロールに戻すための切り替え方法についてはデベロッパー ドキュメントをご参照ください。また、Maps API の バージョンごとの動作方法、使用している API のバージョンを確認する方法、およびデベロッパー向けのベストプラクティスについての詳細は、Maps API の バージョン ガイド をご覧ください。


Posted by Eiji Kitamura - Developer Relations Team

[この記事は Shanee Nishry による Android Developers Blog の記事 "Game Performance: Vertex Array Objects" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

以前、頂点レイアウト修飾子を使用して、OpenGL アプリケーションのパフォーマンスと決定性を向上させる方法をご案内しました。この投稿では、オブジェクト描画に際し、パフォーマンスを向上し、よりクリーンなコードを生成できる便利なテクニックをもう 1 つご紹介します。

頂点バッファのバインド

画面上に描画する前に、該当する頂点シェーダー属性に頂点データ(例、ポジション、法線、テクスチャ座標)をバインドする必要があります。それには、頂点バッファをバインドし、全体の頂点属性を有効にして、glVertexAttribPointer でバッファのレイアウトを記述します。

描画処理は以下のようになります。
const GLuint ATTRIBUTE_LOCATION_POSITIONS   = 0;
const GLuint ATTRIBUTE_LOCATION_TEXTUREUV = 1;
const GLuint ATTRIBUTE_LOCATION_NORMALS     = 2;
// Bind shader program, uniforms and textures
// ...
// Bind the vertex buffer
glBindBuffer( GL_ARRAY_BUFFER, vertex_buffer_object );
// Set the vertex attributes
glEnableVertexAttribArray( ATTRIBUTE_LOCATION_POSITIONS );
glVertexAttribPointer( ATTRIBUTE_LOCATION_POSITIONS, 3, GL_FLOAT, GL_FALSE, 32, 0 );

glEnableVertexAttribArray( ATTRIBUTE_LOCATION_TEXTUREUV );
glVertexAttribPointer( ATTRIBUTE_LOCATION_TEXTUREUV, 2, GL_FLOAT, GL_FALSE, 32, 12 );

glEnableVertexAttribArray( ATTRIBUTE_LOCATION_NORMALS );
glVertexAttribPointer( ATTRIBUTE_LOCATION_NORMALS, 3, GL_FLOAT, GL_FALSE, 32, 20 );
// Draw elements
glDrawElements( GL_TRIANGLES, count, GL_UNSIGNED_SHORT, 0 );
このコードは、あまり好ましいものではありません。それにはいくつかの理由があります。1 つめの理由は、描画の前に正しい属性を有効または無効にして、頂点バッファのレイアウトをキャッシュに格納する必要があることです。つまり、ほとんど意味のないタスクのために、ハードコーディングかデータ保管のいずれかを実行しなければなりません。

2 つめの理由はパフォーマンスです。有効化する属性を個別にドライバーに伝えなければならず、これは最適とはいえません。この情報をプリコンパイルしておいて、一括して引き渡すのが最善策です。

最後に、これは純粋に見た目の問題ですが、長いボイラプレートコードによって描画処理が雑然としてしまうということが挙げられます。これは、できるならば避けたいところです。

このコードが好ましくないと思われる理由は他にもありますレイアウト修飾子を活用している点は素晴らしいのですが、このコードではすでに OpenGL ES 3 以上を使用しているため、 ジオメトリのインスタンス化 も使用すればさらに良くなるでしょう。単一の描画処理に多くのインスタンスをメッシュのようにバッチさせることで、パフォーマンスを確実に強化できます。

では、上記のコードをどのように改善できるのでしょうか。

頂点配列オブジェクト(Vertex Array Objects: VAO)

OpenGL ES 3 またはそれ以上を使用している場合、頂点属性の状態を保管するために頂点配列オブジェクト(VAO)を使用します。

VAO を使用することにより、繰り返して使用される頂点の説明フォーマットがドライバーにコンパイルされます。加えて、glVertexAttribPointer で必要とされる頂点フォーマットのキャッシュ格納が不要となり、また、描画ごとのボイラプレートコードを減らすことができます。

頂点配列オブジェクトの作成

最初に VAO を作成する必要があります。頂点バッファ オブジェクトに沿ってメッシュごとに作成すると、以下のようになります。
const GLuint ATTRIBUTE_LOCATION_POSITIONS   = 0;
const GLuint ATTRIBUTE_LOCATION_TEXTUREUV = 1;
const GLuint ATTRIBUTE_LOCATION_NORMALS     = 2;
// Bind the vertex buffer object
glBindBuffer( GL_ARRAY_BUFFER, vertex_buffer_object );
// Create a VAO
GLuint vao;
glGenVertexArrays( 1, &vao );
glBindVertexArray( vao );
// Set the vertex attributes as usual
glEnableVertexAttribArray( ATTRIBUTE_LOCATION_POSITIONS );
glVertexAttribPointer( ATTRIBUTE_LOCATION_POSITIONS, 3, GL_FLOAT, GL_FALSE, 32, 0 );

glEnableVertexAttribArray( ATTRIBUTE_LOCATION_TEXTUREUV );
glVertexAttribPointer( ATTRIBUTE_LOCATION_TEXTUREUV, 2, GL_FLOAT, GL_FALSE, 32, 12 );

glEnableVertexAttribArray( ATTRIBUTE_LOCATION_NORMALS );
glVertexAttribPointer( ATTRIBUTE_LOCATION_NORMALS, 3, GL_FLOAT, GL_FALSE, 32, 20 );
// Unbind the VAO to avoid accidentally overwriting the state
// Skip this if you are confident your code will not do so
glBindVertexArray( 0 );
以下の追加部分を除いて、前のコード セクションに類似していることに気づかれるでしょう。
// Create a vertex array object
GLuint vao;
glGenVertexArrays( 1, &vao );
glBindVertexArray( vao );
これらの行で VAO を作成し、バインドしています。この後の glEnableVertexAttribArrayglVertexAttribPointer コールはすべて今バインドされている VAO に記録されます。手順としては新たに生成された VAO を使用すればいいだけなので、描画ごとの手続きは大いに簡素化されます。

頂点配列オブジェクトの使用

このメッシュを使用して次に描画をする際は、glBindVertexArray を使用して VAO をバインドするのみで、
// Bind shader program, uniforms and textures
// ...
// Bind Vertex Array Object
glBindVertexArray( vao );
// Draw elements
glDrawElements( GL_TRIANGLES, count, GL_UNSIGNED_SHORT, 0 );
頂点属性の経由は不要になります。これにより、コードはよりシンプルに、フレームごとのコールは短く、効果的になり、ドライバーによるバインドが最適化されることでパフォーマンスも向上します。

glBindBuffer は呼び出されていないことにお気づきでしょうか。これは、VAO により glBindBuffer コール自体が記録されることはないものの、VAO が記録されている間の glVertexAttribPointer の呼び出しが、現在バインドされているバッファを参照しているからです。

ゲーム パフォーマンスを改善する方法をさらにお知りになりたい場合は、ゲーム パフォーマンスに関する記事のシリーズをご覧ください。Android でビルドしている場合、Android のパフォーマンス パターンもご参考にしてください。


Posted by Ryuichi Hoshi - Developer Relations Team

Fablic は、堀井 翔太氏と 竹渓 潤氏が設立した日本のスタートアップです。主に女性をターゲットにしたフリマアプリFRIL を開発し、アプリを通じて個人間で簡単に洋服を売買できるようにしました。

Fablic の創業者達と同社エンジニアの浅野 慧氏、デザイナーの山口 有由希氏へのインタビューから、マテリアル デザインの実装と Android Studio を使用することで、いかにユーザー エンゲージメントが向上し、利用者数が 30% 増える結果となったのかについて、参考になるヒントをご紹介します。



またGoogle Play デベロッパー コンソールの機能を最大限に活用してアプリを公開し、ユーザー数の拡大やユーザー エンゲージメントの向上を実現する方法についてもご紹介しています。

Posted by Takuo Suzuki - Developer Relations Team

[この記事は Lucas Garron、Chris Palmer、Chrome セキュリティ チームによる Online Security Blog の記事 "Simplifying the Page Security Icon in Chrome" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

ウェブサイトではセキュリティのために HTTPS がよく使用されますが、小さなエラーが発生することもあります。これまで Chrome ではこのようなセキュリティ状態をあらわすため、アドレス バーのページセキュリティ アイコンに黄色い「三角形の警告」バッジを表示してきました。

Chrome 46 以降は、「HTTPS における小さなエラー」状態をあらわす際、HTTP ページと同様のアイコンが使用されます。
変更の理由:
  1. HTTP ページのアイコンを使用することで、セキュリティの状態がさらに分かりやすくなります。
  2. 知っておくべきセキュリティ状態の種類が少なくなります。

混在コンテンツ(Mixed Content)に関する警告の非表示

HTTP 画像など特定の混在コンテンツを含む HTTPS ページが主に変更の対象となります。

サイト運営者が直面する課題: HTTP サイトから HTTPS に移行することで混在コンテンツが発生します。これは長期的に見ると望ましくないものの、移行のデバッグには不可欠です。移行中のサイトの安全性は完全とは言えませんが、以前に比べて低下することはまずありません。

黄色い「三角形の警告」バッジを非表示にすると、このような移行期間中は混在コンテンツのあるページに関する警告が表示されなくなります。サイト運営者には、一刻も早い HTTPS への切り替えをおすすめします。

セキュリティ状態の種類を減少

Chrome におけるセキュリティ状態の種類が、4 つから 3 つになります。

ウェブページのセキュリティ状態を正確に表示することと、多数のセキュリティの状態や詳細情報をユーザーを混乱させないこと。この 2 つを適切に両立させる必要があります。HTTP ページアイコンと、この黄色の「三角形の警告」バッジが判別しにくいということが分かったため、この 2 つの状態のセキュリティ上の違いについて、強調しないほうがよいと判断しました。デベロッパーや関心をお持ちのユーザーは、URL が「https://」で始まっているかどうかで違いを区別できます。

将来的にはほとんどのウェブサイトが安全となることを願っており、アイコンの種類を安全かそうでないかの 2 つに集約できるよう計画を進めています。今回の発表はその計画の成功に向けての小さな 1 歩です。


Posted by Eiji Kitamura - Developer Relations Team

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

2014 年 12 月に発表した HtmlService 向けの iframe の sandbox モードにより、アプリケーションのユーザー インターフェース(User Interface: UI)のスピードは向上しました。また、クライアント上で多様な JS ライブラリを使用できるようになりました。それ以降、iframe の sandbox モードの改善を継続的に進め、その結果として、Firefox のサポート、ファイルのアップロード、トップ ナビゲーションのサポート、Google Picker API のサポート改善を含む多くの新機能を追加してきました。iframe の sandobox はより高速な UI を提供し、NATIVE と EMULATED モードよりも性能が高いため、今後は iframe の sandbox モードをご利用ください。

今後、HtmlService の EMULATED モードと NATIVE モードは推奨されません。スクリプトの移行に十分な時間を確保するため、数か月かけて段階的に EMULATED モードと NATIVE モードを廃止していく予定です。

この移行を支援するため migration guide(移行ガイド)が提供されています。変更が必要になるのは、移行ガイドに記載されている機能を使用している場合のみであり、多くのスクリプトでは変更は不要です。移行ガイドでは、互換性が保証されない変更についてもいくつか紹介しています。iframe の sandbox モードへの切り替えによる動作不良を確実に防止するため、HtmlService を使用するスクリプトはすべて見直しを実施してください。

今後の予定は以下のとおりです。

2015 年 11 月NATIVE モードが明確に指定されていない限り 新しい スクリプトすべてに対して、iframe の sandbox モードがデフォルトとして使用されます。たとえば既存スクリプトを複製する場合、sandbox モードに NATIVE を明確に設定しない限り、新しいスクリプトでは iframe の sandbox モードが使用されます。

2015 年 12 月、 (正確な日付は Sunset Schedule をご覧ください)、EMULATED モードの廃止。EMULATED モードを明確に指定しているスクリプトでは iframe の sandbox モードがデフォルトになります。

2016 年 4 月 28 日、 スクリプト内で NATIVE モードを明確に指定していない限り、 すべての スクリプトのデフォルトは iframe の sandbox になります。たとえばスクリプトにモードが指定されていない場合、NATIVE モードが使用されていたとしても iframe の sandbox モードへ切り替えられます。UI が iframe の sandbox モードで正常に動作することを確認してください。

2016 年 6 月 30 日、 NATIVE モードの廃止。NATIVE モードを明確に指定しているスクリプトでは iframe の sandbox モードがデフォルトになります。

ご不便に思われることもあるかもしれませんが、段階的に廃止を実施することで移行プロセスの負担を減少できると考えています。デベロッパーのみなさまが Google Apps Script を使用して優れたアプリを制作できるよう、斬新で安全な環境を提供することが私たちの目標です。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Takeshi Hagikura、Yuichi Araki、デベロッパー プログラム エンジニアによる Android Developers Blog の記事 "New in Android Samples: Authenticating to remote servers using the Fingerprint API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

以前のブログ投稿で発表されたように、Android 6.0 Marshmallow がユーザー向けに一般公開されました。これまでも、デベロッパーが使用できる新機能を主な対象として、サンプル の更新を行ってきましたが、先日 AsymmetricFingerprintDialog というクライアント / サーバー環境で、指紋リーダー(Nexus Imprint など)を認証に使用する方法について紹介する新たなサンプルをリリースしました。

このサンプルの詳しい仕組みや、Android M プレビュー発表時にリリースした FingerprintDialog サンプルとの違いについて説明します。

対称鍵と非対称鍵

Android Fingerprint API は、指紋情報を端末上のハードウェアで保護された領域に保存し、ユーザーのプライバシーを保護します。これによって外部からの悪質な攻撃を防ぎ、信頼性の低いアプリケーションからでも読み取られることがないのでユーザーが安全に指紋認証を行うことを保証できます。
またアプリケーション デベロッパー向けにAndroid の保護機能が提供され、機密性の高いデータやリソースにアクセスする前に、ユーザーが登録された指紋の持ち主であることを保証できます。これによってオフライン データとオンライン通信の両方のセキュリティ を暗号化レベルで高めることができ、アプリケーションが改ざんされたとしてもデータやリソースを保護できます。

指紋リーダ搭載の端末では暗号に使用される鍵はハードウェアで保護された領域に保存されます。暗号に使用される鍵のタイプは、アプリケーションの用途に応じてデベロッパーが選択できます。
  • 対称鍵: パスワードのように、ローカル データを暗号化できます。この鍵は、データベースやオフライン ファイルに安全にアクセスしたい場合に適しています。
  • 非対称鍵: 公開鍵と秘密鍵からなる鍵のペアです。公開鍵はインターネットで安全に送信され、リモート サーバーに保存できます。公開鍵を使って署名認証ができるように、秘密鍵は後からデータ署名に使用できます。署名済みのデータを改ざんすることはできず、データ作成者を明確に特定できます。このように、非対称鍵はネットワークのログインやオンライン処理の認証に使用できます。同様に、秘密鍵によってのみデータを復号化できるように、公開鍵をデータの暗号化に使用することもできます。

このサンプルでは、オンライン購入の認証時に非対称鍵を使用する方法について説明します。対称鍵の使用については、以前に公開された FingerprintDialog のサンプルを参照してください。

以下は、非対称鍵を使用した場合に Android アプリ、ユーザー、バックエンドがどのように連携するかを図で示したものです。

1. 設定: 非対称鍵のペアの作成

まず、次のように非対称鍵のペアを作成します。
KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
keyPairGenerator.initialize(
        new KeyGenParameterSpec.Builder(KEY_NAME,
                KeyProperties.PURPOSE_SIGN)
                .setDigests(KeyProperties.DIGEST_SHA256)
                .setAlgorithmParameterSpec(new ECGenParameterSpec("secp256r1"))
                .setUserAuthenticationRequired(true)
                .build());
keyPairGenerator.generateKeyPair();
.setUserAuthenticationRequired(true) に注目してください。このメソッドを呼ぶことにより、秘密鍵を使用する前に、登録した指紋の認証を強制できるようになります。

次に作成した秘密鍵と公開鍵を以下のように取得します。
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
PublicKey publicKey =
        keyStore.getCertificate(MainActivity.KEY_NAME).getPublicKey();
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
PrivateKey key = (PrivateKey) keyStore.getKey(KEY_NAME, null);

2. 登録: サーバーへの公開鍵の登録

次に、公開鍵をバックエンドに送信し、その後のユーザの購入がユーザーによって承認されていること(この公開鍵に対応する秘密鍵によって署名されていること)をバックエンドが確認する必要があります。このサンプルでは、公開鍵の送信を模擬的に再現するためにバックエンド実装を端末上で動作する模擬コードを使用していますが、実際には公開鍵をネットワーク経由で送信する必要があります。
boolean enroll(String userId, String password, PublicKey publicKey);

3. 認証: 指紋による署名処理

商品購入などでユーザーが処理を認証できるように、指紋センサーへのタッチを促すプロンプトを表示します。
続いて、次のように指紋の読み込みを開始します。

Signature.getInstance("SHA256withECDSA");
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
PrivateKey key = (PrivateKey) keyStore.getKey(KEY_NAME, null);
signature.initSign(key);
CryptoObject cryptObject = new FingerprintManager.CryptoObject(signature);
CancellationSignal cancellationSignal = new CancellationSignal();
FingerprintManager fingerprintManager =
        context.getSystemService(FingerprintManager.class);
fingerprintManager.authenticate(cryptoObject, cancellationSignal, 0, this, null);

4. 最終処理: バックエンドへのデータ送信と照合

認証が成功したら、次のように署名済みのデータ(このサンプルでは、購入処理の内容)をバックエンドに送信します。
Signature signature = cryptoObject.getSignature();
// Include a client nonce in the transaction so that the nonce is also signed 
// by the private key and the backend can verify that the same nonce can't be used 
// to prevent replay attacks.
Transaction transaction = new Transaction("user", 1, new SecureRandom().nextLong());
try {
    signature.update(transaction.toByteArray());
    byte[] sigBytes = signature.sign();
    // Send the transaction and signedTransaction to the dummy backend
    if (mStoreBackend.verify(transaction, sigBytes)) {
        mActivity.onPurchased(sigBytes);
        dismiss();
    } else {
        mActivity.onPurchaseFailed();
        dismiss();
    }
} catch (SignatureException e) {
    throw new RuntimeException(e);
}

最後に、ステップ 2 で登録した公開鍵を使用し、バックエンドにある署名済みデータと照合します。
@Override
public boolean verify(Transaction transaction, byte[] transactionSignature) {
    try {
        if (mReceivedTransactions.contains(transaction)) {
            // It verifies the equality of the transaction including the client nonce
            // So attackers can't do replay attacks.
            return false;
        }
        mReceivedTransactions.add(transaction);
        PublicKey publicKey = mPublicKeys.get(transaction.getUserId());
        Signature verificationFunction = Signature.getInstance("SHA256withECDSA");
        verificationFunction.initVerify(publicKey);
        verificationFunction.update(transaction.toByteArray());
        if (verificationFunction.verify(transactionSignature)) {
            // Transaction is verified with the public key associated with the user
            // Do some post purchase processing in the server
            return true;
        }
    } catch (NoSuchAlgorithmException | InvalidKeyException | SignatureException e) {
        // In a real world, better to send some error message to the user
    }
    return false;
}

ステップ 1 で述べたとおり、秘密鍵を使用する前にユーザー認証が毎回必要であるため、この時点でユーザー自身の指紋が正しく認証されているとみなすことができます。バックエンドで購入後の処理を実行し、ユーザーに処理が成功したことを通知しましょう。

その他の更新されたサンプル

その他に、 Android for Work API に関連する Marshmallow で更新された機能についてサンプルを更新しました。




  • AppRestrictionEnforcerAppRestrictionSchema のサンプルは、Android 5.0 Lollipop の Android for Work API の一部として アプリ制限機能導入時にリリースされました。AppRestrictionEnforcer は、プロファイル オーナーとして他のアプリに制限を設定する方法について説明しています。AppRestrictionSchema は、AppRestrictionEnforcer で制御できるいくつかの制限を定義しています。この更新は、Android 6.0 で追加導入された 2 つの制限タイプの使用方法について説明しています。

  • 更新されたサンプルがデベロッパーの皆様のお役に立てればと思います。サンプルについてのご質問は、GitHub ページ で Issue を登録するか、Pull Request を送っていただくようお願い致します。


    Posted by Takeshi Hagikura - Developer Relations Team