Todd Kerpelman
Firebase デベロッパー アドボケート

単に優れたアプリをリリースして待っているだけでは、ビジネスを成功させることはできません。ビジネスを成功させるには、ユーザーのフィードバックにすばやく対応し、新機能のテストを行い、ユーザーが最も注目するコンテンツを提供する必要があります。

Firebase Remote Config は、まさにそのために作られたものです。Firebase Remote Config を使うと、クラウドからアプリのルック アンド フィールを変更できるので、常にユーザーのニーズにすばやく対応することができます。さらに、ユーザーごとに提供するコンテンツを変える、機能を徐々に展開する、ユーザーのアプリの使用方法に合わせてカスタマイズしたコンテンツを提供するといったことも可能です。

それでは、アプリに Remote Config を導入すると何ができるようになるかを見てみましょう。



アップデート不要でアプリを更新

アプリをリリースしたものの、直後にそれが完璧でなかったことに気づくという経験は、誰にでもあることでしょう。ユーザーが好まない、不適切だったり混乱を招いてしまうようなテキストを使ってしまったかもしれません。ゲームのレベルを難しくしすぎてプレイヤーがそれ以上進めなくなってしまったかもしれません。または、追加したアニメーションが終了するまで時間がかかりすぎるというような単純なことかもしれません。

従来は、こういった問題を修正するために、アプリのコードの値を変更してビルドし、新しいバージョンを公開した上で、すべてのユーザーが新バージョンをダウンロードするのを待つ必要がありました。

しかし、アプリに Firebase プラットフォームの Remote Config を導入していれば、クラウドから短時間で簡単に値を変更できるようになります。ユーザーが次にアプリを起動すると、Remote Config が新しい値をダウンロードしてユーザーのニーズに対応します。アプリの新しいバージョンを公開する必要はありません。

適切なユーザーに適切なコンテンツを提供する

Firebase Remote Config では、条件を設定することによって、ユーザーの対象グループごとに異なる設定を配信することができます。条件とは、ユーザーごとに特定の値を配信するために対象を設定する規則です。たとえば、国ごとに異なる Remote Config データを配信したり、iOS 端末と Android 端末に別のデータセットを配信することができます。

さらに高度な対象指定を行うために、Firebase Analytics で定義した Audience に基づいて異なる値を配信することもできます。たとえば、かつてアプリ内のストアを訪れたことがあり、まだ何も購入していないプレイヤーに対してストアの外観を変更したい場合は、その Audience 向けの Remote Config の値を作成します。

A/B テストと段階的ロールアウト

Remote Config の条件を利用すると、ランダムなグループのユーザーごとに異なる値を提供することができます。この機能によって、A/B テストや新機能の段階的ロールアウトを行うことができます。

リリースを考えているアプリの新機能が対象ユーザーに好まれるかどうかわからない場合、コードにフラグをつけてその機能を隠しておき、Remote Config でそのフラグの値を変更すると、機能のオン、オフを切り替えることができます。たとえば、「新機能の実験」という条件を設定して 10% のユーザーに対して有効にすると、この新機能を一部のユーザーのみにオンにし、その機能がユーザーに好まれることを確認してから、ユーザー全体にオンにするといった使い方ができます。

同じように、ユーザーのグループに対して異なる値を指定すれば、A/B テストを行うこともできます。たとえば、アプリ内購入ボタンに「今すぐ購入」と表示した場合と、「購入手続き」と表示した場合では、どちらが購入率が高くなるでしょうか。こういった実験は、A/B テストを使うと簡単に行えます。

A/B テストの結果は、Firebase Analytics で実験に基づいたユーザー プロパティを設定すると、すぐに確認できるようになります。すべての Firebase Analytics レポート(たとえば、購入手続きを始めたかどうかのレポート)は、このプロパティを使ってフィルタリングできます。A/B テストはこれからも改善されますので、今後のニュースにもご注目ください。

定着率が大幅に向上した Fabulous


この機能を他に先駆けて導入したパートナーの多くは、既に Firebase Remote Config を使用してアプリの変更をテストしています。

デューク大学で開発された Fabulous は、生活習慣の改善をサポートするアプリです。Fabulous では、どの手法をとれば最も効果的にユーザーにアプリを使ってもらえるかを探るために、アプリを使い始める際のフローに関する実験が行われました。画像やテキスト、ボタンのラベルを変更する A/B テストだけではなく、Remote Config を利用した初回起動プロセス全体の A/B テストを行い、どのダイアログをどの順番で表示すれば良いかを判断しました。

Remote Config による実験のおかげで、Fabulous の初回起動のフローを完了させるユーザーの数は 42% から 64% に上昇し、1 日のユーザーリテンション率が 27% 増加しました。

平均的なアプリは、大半のユーザーを最初の 3 日間で離脱することがわかっています。そのため、アプリの初回起動プロセスにこういった改善を加え、その効果を A/B テストで確認することは、アプリが長期的に成功を収めるために非常に重要です。

クラウドと連携

Remote Config では、すべてのデフォルト値をデバイス上でローカルに提供でき、デフォルトと異なる値のみがクラウドから送信されます。アプリのすべての値をクラウドと連携させ、Remote Config で設定を行えるようにすることで、アプリの柔軟性が向上します。変更のみが送信されるので、ネットワークの呼び出しは軽量です。そのため、ハードコードしていた文字列や定数、アプリの定数用ファイル(開発者なら誰でもこのようなファイルを作った経験があるでしょう)をすべて Remote Config でクラウド対応にすることも可能です。

Firebase Remote Config は、Firebase プラットフォームの一部であり、iOS と Android の両方で無償で利用できます。詳細については、ドキュメントをご覧ください。また、Firebase SDK のその他の機能についてもぜひご確認ください。


Posted by Khanh LeViet - Developer Relations Team


Web Music ハッカソンは「web」と「音楽」が大好きな開発者が集結し、皆でハックをして、成果を発表するイベントです。波形を加工したり、楽器を作ることのできる Web Audio API、ブラウザと外部 MIDI 機器をダイレクトに接続する Web MIDI API を 1 日中ハックして想い描く web と音楽の未来をプロトタイプして語りましょう。

テーマは DJ / VJ

今回のハッカソンは当日だけでは終わりません。後日ライブハウスを貸し切り、生まれた作品を DJ に演奏してもらう場を設けます。演奏される作品はハッカソンでの優秀作品、DJ の方々が「ぜひ使いたい」と感じた作品に限らせていただきますので、アイデアと発表時の作品の完成度合いがとても重要になります。

また今回は、開発アイディアのインスピレーションを得たり、チームビルディングを目的として、HackCamp 様の協力の下、事前に Meetup 行います。

イベント内容

名称 : Web Music ハッカソン#5
日時 : 2016 年 7 月 30 日(土)9:30 - 18:00(受付 9:00 - 10:00)
会場 : Google 東京オフィス 六本木ヒルズ森タワー
会費 : 無料
定員 : 50名
主催 : Web Music Developers JP、Google
協賛 : HackCamp、LIG、AMEI (一般社団法人 音楽電子事業協会)
お問い合わせ:[email protected]
ハッシュタグ : #webmusic
参加対象: 「web」と「音楽」が大好きな方、Web Audio/MIDI API を使ってみたい方、VJ / DJ に興味があり映像等を作成できる方(初心者用の教材もあります)。

申し込み方法

事前 Meetup:https://a4137318eceda1f12129a1472a.doorkeeper.jp/events/47799
ハッカソン:https://goo.gl/tXSS5O

事前 Meetup、ハッカソンは、それぞれ別途お申し込み下さい。募集は定員になり次第締め切らせていただきます。ご参加いただける方には、 7 月 20 日より順次ご登録いただいたメールアドレス宛に参加証をお送りする予定です。

過去の Web Music ハッカソンからは、ブラウザ上で楽器を作る、ツール・センサを使ったシーケンサ、外部 MIDI 機器と連携したVJ、ワンボード・マイコンと連携したハック等、様々なアプリケーションがハックされてきました。今回も幅広い分野で Web Audio / MIDI API がハックされるのを楽しみにしています。テーマは DJ / VJ ですが、その他の分野での参加も歓迎しています。

注意事項:

  • 事前 Meetup、ハッカソンいずれかのみの参加でも問題ありませんが、なるべく両方にご参加ください。
  • 申込みフォームにご記入いただいたアイデアは、事前 Meetupにて紹介させていただく可能性がありますので予めご了承ください。
  • 音が出る API を使いますので、ヘッドフォンまたはイヤホンをご持参ください。
  • チームで参加される場合も、チーム全員個別でお申込みください。
  • 当日利用する PC、その他提供が告知されていない機器はご持参ください。
  • AMEI 様より、KORG、Roland、ヤマハのデジタル機器をご提供いただく予定です。

その他

ハッカソンとは制限時間を設けて技術やアイデアをプロトタイピングして、それを試す方法の 1 つです。チームで、または個人で 1 つのモノを作り上げ、成果物を発表し合い、同じ方向を向いている皆でコメントをし合うことで更にアイデアを膨らませる、また新たなアイデアを得る大きなチャンスです。web と音楽が好きな方は是非ご参加ください。


Posted by Eiji Kitamura - Developer Relations Team

Google Maps JavaScript API を活用してウェブ アプリケーションを構築する開発者の方のために、JavaScript コンソールのエラーメッセージ表示をこの数か月にわたり改善してきました。この変更のねらいは次のとおりです。

  • 開発者の方にもっと詳しいエラーメッセージを提供する
  • エラーの解消方法を開発者の方に提供する
  • エラーメッセージを表示するポップアップをやめる
  • エラーが発生した時でも利用者に対してポジティブな印象を作り出す


開発者は JavaScript コンソールを普段どのように利用するのか? いつ? なぜ?

ウェブ開発者はアプリケーションの開発やデバッグの際にブラウザツールを利用します。開発者は、アプリやライブラリ、API に関するいろいろなメッセージを JavaScript コンソールで確認することができます。Google Maps JavaScript API はユーザーに対して数種類のエラーメッセージをコンソールに表示してきました。しかし、ウェブ開発者が問題の原因を突き止め、解決策を探るために必要な情報がそのメッセージでは十分に説明されていないことがありました。

ユーザーが古いエラーメッセージを見た時何が起きていたか?

以前のポップアップ型のエラーメッセージは、ウェブページの上に表示されていました。ユーザーは、そのページで地図を操作することがなかったとしても、この JavaScript の警告画面の OK ボタンをクリックしないとウェブページを操作することができませんでした。また、概要的なエラーメッセージが 4 種類用意されているだけでした。


改良版では開発者とユーザーは何を見ることができるのか?

現在、コンソールには 22 種類のエラーメッセージを表示します。このメッセージの一覧はドキュメントでご覧いただけます。さらにエラーメッセージとあわせて、開発者サイトに記載されたそのエラーの解決方法へのリンクも表示します。反対に、エンドユーザーに対するエラーメッセージは簡素化されました。

また、たとえばマップの読み込みが失敗したとしても、改良されたエラーメッセージはマップ要素内に表示され、ユーザーはそのページの残りの部分を引き続き操作することができます。



今回の変更によって、開発者のみなさんの実装やエンドユーザーとのインタラクションの改善に繋がることを望んでいます。

Posted by Kosuke Mizubayashi, Technical Solutions Engineer

Todd Kerpelman
Firebase デベロッパー アドボケート

ウェブサイト上の特定の場所に遷移することができる URL。この概念については、皆さんよくご存じかと思います。モバイル コンピューティング化が進むなか、特定のモバイルアプリ内の特定の場所に遷移することができる URL の使用が増えています。ディープ リンキングと呼ばれるコンセプトです。

アプリへのディープ リンキングの利用は非常に重要であり、その理由は明らかです。たった 1 つの URL で、ユーザーを自分のアプリに誘導するだけでなく、アプリ内の特定の場所に連れていくことができるからです。つまり、アプリの新機能をお知らせするメールの中のリンクをタップするだけで、ユーザーが直接その新機能に遷移できるということです。また、ウェブサイトの「アプリを試す」ボタンをタップすることで、ユーザーをそのアプリに連れていくだけでなく、アプリをインストールするきっかけとなったアプリ内の特定のコンテンツに直接遷移できるようになります。

ただ残念なことに、アプリへのディープリンキングは完ぺきではなく、同じリンクで、お使いの iOS と Android アプリの両方にリダイレクトすることは容易ではありません。もしユーザーがアプリをインストールしていなければ、正常に機能しないか、障害が発生することもあります。何より、ターゲット ユーザーが、まずアプリストアからアプリをインストールしなければならないとしたら、元々のリンクのコンテクストは失われ、そのユーザー用にカスタマイズされた導入ページではなく、通常のホーム画面が表示されてしまうことになります。



この問題を解決するために作られたディープリンクが、Firebase Dynamic Links です。単一のリンクで、ユーザーをインストール済みの iOS または Android アプリに遷移させることができます。もしユーザーがアプリをインストールしていない場合、ユーザーをアプリストアや Google Play 上の適切な掲載情報に連れていくことができます。一番のポイントは、このリンクがインストール中も保持されることです。これにより、初めてアプリを立ち上げた時に、ユーザーをこのアプリに連れてきたディープリンク URL を再取得することができます。

「Share a Coke And a Song」キャンペーンでの Dynamic Links の活用



夏向けのプロモーションとして、Shazam はコカ・コーラと協業し、リップシンクの動画を使って、友達同士で好きな曲を共有できるという企画を実施しています。

ユーザーは、友達から送られた動画をウェブページ内で閲覧できます。Firebase Dynamic Links の導入前は、ウェブページに「アプリをインストール」と「動画を作成する」の 2 つのリンクが含まれており、どちらをクリックするかはユーザー次第でした。しかし、Firebase Dynamic Links を導入することで、その 2 つのリンクを、「Shazam で動画を作成する」というリンクに置き換え、リップシンクの動画を作成したいユーザーを直接アプリにジャンプさせるか、アプリストアに連れていくことができるようになりました。

Dynamic Links を利用すると、アプリをインストールしたユーザーは、アプリ内の希望のコンテンツに直接アクセスできます。Shazam の調査によれば、この手法でアプリをインストールしたユーザーの 2 週間後の継続率は、通常の方法でアプリを始めたユーザーに比べ、15% 高いとのことです。

Dynamic Links の作成

Firebase Dynamic Links は即座に作成できるため、必要な時にいつでもアプリやウェブサイト上に新しいリンクを生成できます。Firebase コンソールから、オンラインフォームを使って Dynamic Links を作成することもできます。これは、技術的な知識を持たないチームメンバーが、URL を手動入力せずにリンクを作成したい場合に利用できます。

Firebase Dynamic Links は、Firebase プラットフォームの一部なので、Firebase Analytics などの機能とも連動しています。リンクをクリックした人数などの基本的な情報に加え、utm_ パラメータ(通常、マーケティングチームが外部キャンペーンに追加するパラメータ)を自動的に追跡するため、ユーザーがアプリにアクセスするきっかけとなったキャンペーンや媒体別に、重要なアプリ内イベントを分析することができます。

さっそく使ってみましょう

Firebase Dynamic Links は、Firebase プラットフォームの利用度合いに関わらず、無料で利用でき、すぐに利用開始できます。利用方法の例として以下が挙げられます。

  • モバイルゲームをお持ちの場合、Dynamic Links を生成し、特定のレベルやリプレイをゲーム内で共有しましょう。ユーザー同士がまったく同じレベルでスコアを争えるようにしたり、別ユーザーのキャラクター プロフィールへリンクさせることができます。Firebase Dynamic Links は、アプリ内でのユーザー間の情報共有に最適です。
  • デスクトップ ユーザーをモバイル ユーザーへウェブサイトのユーザーをモバイルアプリに誘導したい場合、Dynamic Links を使い、「スマホから閲覧」という機能を活用できます。これは、SMS やメールを使って位置を共有するために、Google マップで使われている「スマホに送信」機能とまったく同じです。
  • また、モバイル端末でウェブサイトを閲覧しているユーザーを、アプリ上の同じコンテンツにアクセスさせたい場合、Dynamic Link を使うことで、ユーザーがアプリに遷移し、必要なコンテンツに直接アクセスできるようになります。


Dynamic Links は、メール、SMS、ソーシャル メディアを媒体としたキャンペーンにも最適です。

Firebase Dynamic Links の詳しい情報はこちらから確認できます。Firebase コンソールにアクセスし、すぐにご利用を開始してみてください。


Posted by Khanh LeViet - Developer Relations Team



ヘッダーが 1 行になったことで、そこに表示される情報の重要性が増します。Android N では、デフォルトで時間が表示されなくなります。メッセージング アプリのように時間が重要になる通知の場合では、setShowWhen(true) で時間の表示を有効化できます。さらに、コンテンツ情報や番号よりもサブテキストが優先されるようになります。Android N デバイスでは番号は表示されなくなり、以前のバージョンの Android でサブテキストがない場合に限り、コンテンツ情報が表示されます。いずれの場合でも、サブテキストには意味のある便利な情報を使用してください。たとえば、ユーザーが 1 つしかアカウントを持っていない場合は、サブテキストにアカウントのメールアドレスを表示しないようにします。

また、通知アクションのデザインも見直されており、通知の下に別のバーが表示されるようになっています。



新しい通知には、アイコンが表示されていないことにお気づきかもしれません。通知シェードの限られたスペースにアイコンを入れるのではなく、ラベルが大きくなっています。ただし、通知アクション アイコンは必須のままであり、古いバージョンの Android や Android Wear などのデバイスでは引き続き使用されます。

NotificationCompat.Builder やそこで提供されている標準スタイルを使って通知を構築している場合、コードを変更することなく、デフォルトで新しいルック アンド フィールが反映されます。


カスタムビューのサポート強化

上記の方法ではなく、カスタムの RemoteViews を使って通知を作成している場合、新しいスタイルに適応させるのは困難な場合があります。新しいヘッダー、展開動作、アクション、大きなアイコンは、通知のメインのテキストとタイトルとは別々の要素として配置されるため、すべての要素を提供できる新しい DecoratedCustomViewStyleDecoratedMediaCustomViewStyle が導入されています。これによって、新しく追加された setCustomContentView() メソッドを利用してコンテンツ部分のみを作成すればいいようになっています。



また、今後ルック アンド フィールが変更されても、スタイルのアップデートはプラットフォーム側で行われ、アプリ側ではコードの変更が必要なくなるため、対応するのが簡単になります。


ダイレクト リプライ

通知アクションからは、既に Activity の起動に加え、ServiceBroadcastReceiver によるバックグラウンドでの作業を行うことができるようになっています。今回はさらに、ダイレクト リプライを使って通知アクション内でインライン テキスト入力が可能なアクションを作成できるようになりました。



ダイレクト リプライでは、もともと Android Wear 向けに導入されたものと同じ RemoteInput API を使用して、Action がユーザーから直接入力を受け取れるようになっています。

RemoteInput 自体には、キーなどの情報が含まれています。後ほど、このキーを使用して入力やユーザーが入力を開始する前に表示されるヒントのテキストを取得できます。

// Where should direct replies be put in the intent bundle (can be any string)
private static final String KEY_TEXT_REPLY = "key_text_reply";

// Create the RemoteInput specifying this key
String replyLabel = getString(R.string.reply_label);
RemoteInput remoteInput = new RemoteInput.Builder(KEY_TEXT_REPLY)
        .setLabel(replyLabel)
        .build();


構築した RemoteInput は、addRemoteInput() メソッドでアクションにアタッチすることができます。Android Wear 2.0 用にスマート リプライの選択肢を生成する setAllowGeneratedReplies(true) を呼び出し、ユーザーがすばやく簡単に応答できるようにすることも検討するとよいでしょう。

// Add to your action, enabling Direct Reply for it
NotificationCompat.Action action =
    new NotificationCompat.Action.Builder(R.drawable.reply, replyLabel, pendingIntent)
        .addRemoteInput(remoteInput)
        .setAllowGeneratedReplies(true)
        .build();


なお、ダイレクト リプライをサポートしていない Marshmallow 以前のデバイスでは、Action に渡す pendingIntentActivity である必要があります(ユーザーに応答を入力してもらうために、ロック画面を解除して Activity を開始し、入力フィールドにフォーカスを当てるためです)。Android N デバイスの場合は、ロック画面からでもバックグラウンドでテキスト入力を処理できるように、Service(別のスレッドで処理する必要がある場合)または BroadcastReceiver(UI スレッドで動作する場合)である必要があります(システム設定からは、ロックされたデバイスでのダイレクト リプライの有効、無効を制御することができます)。

その後、ServiceBroadcastReceiverRemoteInput.getResultsFromIntent() メソッドを使い、入力されたテキストを抽出できます。
private CharSequence getMessageText(Intent intent) {
    Bundle remoteInput = RemoteInput.getResultsFromIntent(intent);
    if (remoteInput != null) {
        return remoteInput.getCharSequence(KEY_TEXT_REPLY);
    }
    return null;
 }


テキストを処理した後は、通知を更新する必要があります。これがトリガーとなって、ダイレクト リプライの UI が非表示になります。この際に、リプライが正常に受信され、処理されたことをユーザーが確認できるようにする必要があります。

ほとんどのテンプレートでは、この処理に新しく追加された setRemoteInputHistory() メソッドを使用しています。このメソッドは、通知の下部にリプライを追加します。他のユーザーのリプライなどによってメイン コンテンツが更新されるまでは、履歴にリプライを追加するようにします。



ただし、会話をやり取りするようなメッセージング アプリを開発している場合は、MessagingStyle を使用してメッセージを追加するとよいでしょう。


MessagingStyle

ダイレクト リプライと新しく追加された MessagingStyle は、継続的にやり取りされる会話の表示に最適です。



このスタイルは、addMessage() メソッドで追加できる複数のメッセージ用の組み込みフォーマットです。各メッセージには、テキスト本文、タイムスタンプ、メッセージの送信者を渡すことができます(これによってグループでの会話がしやすくなります)。

builder.setStyle(new NotificationCompat.MessagingStyle("Me")
    .setConversationTitle("Team lunch")
    .addMessage("Hi", timestampMillis1, null) // Pass in null for user.
    .addMessage("What's up?", timestampMillis2, "Coworker")
    .addMessage("Not much", timestampMillis3, null)
    .addMessage("How about lunch?", timestampMillis4, "Coworker"));


このスタイルは、現在のユーザーのメッセージを区別して示し、その名前も表示(このケースでは「Me」を表示)することに特化しています。オプションで会話のタイトルも設定できます。BigTextStyle を使ってこれを手動で実現することもできますが、このスタイルを Android Wear 2.0 で使用すると、ユーザーは即座にインラインで応答を受信できます。展開した通知ビューを処理する手間が省けるため、Wear に完全対応したアプリを構築しなくてもシームレスな操作を提供できます。


バンドル通知

新しい外観、ダイレクト リプライ、MessagingStyle と、今までのあらゆるベスト プラクティスを活用して通知を作成した後は、全般的な通知の操作性について検討します。とりわけ、複数の通知を送信する(たとえば、継続する会話の 1 件ごとや、新しいメールのスレッドごとに通知する)場合はこれが重要になります。

バンドル通知は、ユーザーが別の通知を参照している際に 1 件だけサマリーを表示したい場合にも、あるいはすべての通知を同時に処理したり、まとめられた通知を展開して個々の通知を処理したい場合にも最適です(これには、アクションやダイレクト リプライも含まれます)。

Android Wear で通知のスタックを開発したことがある場合、それとまったく同じ API を使うことができ、各通知に setGroup() を追加するだけで、通知を 1 つにまとめることができます。グループは 1 つに限る必要はないので、通知は好きなようにまとめることができます。たとえば、メールアプリではアカウントごとに通知をまとめるとよいかもしれません。

また、サマリー通知を作成することも重要です。サマリー通知は、setGroupSummary(true) で指定できます。Marshmallow 以前のデバイスで表示される通知はサマリー通知のみなので、(おわかりと思いますが)個々の通知をすべてまとめる必要があります。その際には、InboxStyle を使うとよいでしょう。ただしこれは必須ではありません。Android N 以上のデバイスでは、サマリー通知から一部の情報(サブテキスト、コンテンツ インテント、削除インテント)が抽出され、バンドル通知用の折りたたまれた通知になります。そのため、すべての API レベルでサマリー通知を作成する必要があります。

Android N デバイスでは、全般的なユーザー エクスペリエンスを改善するために、グループのない通知を 4 つ以上送信すると、自動的に通知がまとめられます


N は Notification(通知)の N

Android の通知は常に進化し続けています。Gingerbread のころのシングルタップ ターゲットから、展開可能な通知、アクション、MediaStyle、最新のダイレクト リプライやバンドル通知などの機能に至るまで、通知は Android の総合的なユーザー エクスペリエンスにおいて重要な役割を果たしています。

ぜひ、多くの新しいツール(と下方互換性を維持するための NotificationCompat)をご活用ください。#BuildBetterApps での皆様からの報告を楽しみにしています。

さらに情報を得るには、Android Development Patterns Collection をフォローしてください。



Posted by Yuichi Araki - Developer Relations Team



2. Search Console の新しいレポート機能

私たちは、ウェブマスターやデベロッパーが、検索結果におけるパフォーマンスの記録や測定を簡単に行えるようにしたいと考えています。今回、Search Console に、デベロッパーが自らのリッチカード マークアップが有効であることを確認できる、新しいレポート機能が追加されました。このレポートには、マークアップするフィールドを増やすと効果のあるカードを表す「enhanceable cards」という項目を設けています。また Search Appearance フィルタが追加されていて、ウェブマスターが AMP やリッチカードという条件でトラフィックをフィルタリングするのに便利です。

3. リアルタイム インデクシング

ユーザーが検索しているのは、レシピや映画情報だけではありません。たった今起きている出来事についての最新情報を探すために、Google 検索にやってくることもあります。こうした考えから始まったのが、リアルタイム インデクシングを利用することで、リアルタイムの出来事を検索するユーザーと新鮮なコンテンツを結びつけようという Google の取り組みです。Google Indexing API を使えば、パブリッシャーは自らのコンテンツがクロール対象になってインデクシングされるのを待つのではなく、リアルタイムでのインデクシングを促せるようになります。この取り組みはまだ始まったばかりですが、今年夏にもベータ版を公開したいと考えています。

4. Accelerated Mobile Pages(AMP)で Google 検索を高速化

Google が Accelerated Mobile Pages(AMP)をどのように使っているかについて、最新情報を公開しました。AMP はモバイル ウェブの表示を高速化するオープンソース プロジェクトです。Google 検索では AMP を使うことで、コンテンツを一瞬で読み込めるようにしました。スピードは重要です。読み込みに 3 秒以上かかると、40% 超のユーザーがサイトを離れてしまいます。Google は、iOS と Android 向けの Google アプリに、AMP を適用したカルーセル形式のニュースコンテンツを採用し、同時に AMP とリッチカードを組み合わせる実験を行っていることを発表しました。詳しい情報は、Google のブログgithub のページをご覧ください。

参加者はセッションだけでなく、Search & AMP のブースでも Google の担当者と直接話すことができました。



5. 構造化データ テストツールのアップデート

広く使われている構造化データ テストツールがアップデートされました。これにより、このツールは DevSite Search Gallery、新しい Search Preview サービスと密接に連携し、リッチカードが検索結果ページでどのように見えるのかをプレビューできるようになりました。

6. App Indexing の新サービスへの移行(と新機能追加)

App Indexing の Firebase への移行が発表されました。Firebase は、Google のデベロッパー向け統合プラットフォームです。Firebase App Indexing を使って、アプリをもっと優れたものにする方法を知るには、セッションの動画をご覧ください。

7. アプリ ストリーミング

アプリ ストリーミングという新しい方法を使えば、Android ユーザーはアプリのダウンロードとインストールをせずに、ゲームを試してみることができます。この機能は Google 検索で利用可能です。詳しくは、セッションの動画をご覧ください。

8. ドキュメントのリニューアル

デベロッパー向けドキュメントのリニューアルも行いました。ドキュメントをトピック別のガイドに整理し、読みやすくしました。

Google I/O に参加くださり、ありがとうございます。デベロッパーのみなさんと直接話して、その経験をじかに聞くのは、毎回とてもためになります。現地で参加された方も、遠隔地からご覧いただいた方も、引き続きウェブマスター フォーラムや、ハングアウト オンエアを使って毎週開かれている Google のウェブマスター オフィスアワーにご参加ください。


Posted by Takuo Suzuki - Developer Relations Team
Share on Twitter Share on Facebook

Laurence Moroney
デベロッパー アドボケート





Firebase Cloud Messaging は、メッセージや通知を確実に Android、iOS、ウェブに配信できる無償のクロスプラットフォームのメッセージング ソリューションです。たとえば、新しいデータが同期できることを通知したり、リピート率を向上させるためにスペシャル オファーを提示したりするような使い方があります。メッセージは、個々のデバイス、デバイスのグループ、トピックをサブスクライブしているデバイスに宛てて送信できます。

メッセージのペイロードは最大 4kB で、デバイスからサーバーや他のデバイス宛てにアップストリーム メッセージを送信することもできます。

Firebase Cloud Messaging は Google Cloud Messaging に取って代わるものです。既に Google Cloud Messaging をお使いの方向けのオプションなどの詳細はこちらからご確認いただけます。

Firebase Cloud Messaging を使ってアプリを構築してみたい方向けに、いくつかのすばらしいサンプルも提供しています。AndroidiOSウェブ向けのガイドも参考にしてください。


Posted by Khanh LeViet - Developer Relations Team
Share on Twitter Share on Facebook

Android アプリで SHA1PRNG アルゴリズムを利用して Crypto プロバイダからキーを導出している場合は、本物のキー導出関数を使うように変更する必要があります。既存のデータも暗号化し直す必要があるかもしれません。

Java 暗号化アーキテクチャを使用すると、次のような呼び出しによって暗号や疑似乱数ジェネレータのようなクラスのインスタンスを作成できます。
SomeClass.getInstance("SomeAlgorithm", "SomeProvider");
もっと単純に、次のように書くこともできます。
SomeClass.getInstance("SomeAlgorithm");
たとえば、次のような使い方が可能です。
Cipher.getInstance(“AES/CBC/PKCS5PADDING”);
SecureRandom.getInstance(“SHA1PRNG”);

Android でプロバイダを指定することは推奨されていません。通常、プロバイダを指定した Java Cryptography Extension(JCE)API の呼び出しを行うのは、プロバイダがアプリケーションに含まれている場合や、ProviderNotFoundException が発生した場合にアプリケーションで対応できる場合に限る必要があります。

残念なことに、多くのアプリは削除される「Crypto」プロバイダに依存しています。これはキー導出のアンチパターンです。

このプロバイダは、SecureRandom のインスタンス用の「SHA1PRNG」アルゴリズムの実装のみを提供するものでした。ここで問題になるのは、SHA1PRNG アルゴリズムは暗号学的に安全ではないことです。詳細に興味がある読者の方は、Yongge Want 氏と Tony Nicol 氏の『On statistical distance based testing of pseudo random sequences and experiments with PHP and Debian OpenSSL』のセクション 8.1 をご覧ください。バイナリ形式で考えた場合、「ランダム」シーケンスは 0 を返す可能性が高く、シードによってはさらにその傾向が強くなることが説明されています。

そのため、Android N では SHA1PRNG アルゴリズムと Crypto プロバイダの実装が廃止されます。数年前に公開された資格情報を安全に保存する暗号の使用という記事では、キー導出に SecureRandom を使用する際の問題が取り上げられています。しかし、この方法が継続的に使用されていることを考慮し、この問題を再検討することになりました。

このプロバイダは、パスワードをシードとして暗号化キーを導出するという誤った使われ方が一般的になっています。SHA1PRNG の実装には、出力を得る前に setSeed() を呼び出すとそれが固定されてしまうというバグがあります。パスワードをシードとし、「ランダム」な出力バイトを使用してキーを導出すると、このバグが発生します(この文で、カッコつきの「ランダム」は「予測可能で暗号学的に脆弱」という意味です)。そのようなキーがデータの暗号化や復号化に使われることになります。

次に、正しくキーを導出する方法と、安全ではないキーで暗号化されたデータを復号化する方法について説明します。廃止される SHA1PRNG 機能を使用するためのヘルパークラスを含む完全な例も掲載しています。これは、この方法を用いて復号化しなければ使うことができないデータを復号化することのみを目的としたものです。

キーは、次のように導出することができます。
   /* User types in their password: */  
   String password = "password";  

   /* Store these things on disk used to derive key later: */  
   int iterationCount = 1000;  
   int saltLength = 32; // bytes; should be the same size
              as the output (256 / 8 = 32)  
   int keyLength = 256; // 256-bits for AES-256, 128-bits for AES-128, etc  
   byte[] salt; // Should be of saltLength  

   /* When first creating the key, obtain a salt with this: */  
   SecureRandom random = new SecureRandom();  
   byte[] salt = new byte[saltLength];  
   random.nextBytes(salt);  

   /* Use this to derive the key from the password: */  
   KeySpec keySpec = new PBEKeySpec(password.toCharArray(), salt,  
              iterationCount, keyLength);  
   SecretKeyFactory keyFactory = SecretKeyFactory  
              .getInstance("PBKDF2WithHmacSHA1");  
   byte[] keyBytes = keyFactory.generateSecret(keySpec).getEncoded();  
   SecretKey key = new SecretKeySpec(keyBytes, "AES");  

これだけです。他には何もする必要はありません。

データ移行を簡単にするために、毎回パスワードから導出される安全でないキーで暗号化されているデータへの対応方法も紹介します。キーは、サンプルアプリのヘルパークラス InsecureSHA1PRNGKeyDerivator を使って導出できます。
 private static SecretKey deriveKeyInsecurely(String password, int
 keySizeInBytes) {  
    byte[] passwordBytes = password.getBytes(StandardCharsets.US_ASCII);  
    return new SecretKeySpec(  
            InsecureSHA1PRNGKeyDerivator.deriveInsecureKey(  
                     passwordBytes, keySizeInBytes),  
            "AES");  
 }  

その後、先ほどの説明にあった安全に導出したキーを使ってデータを再暗号化すれば、あとはもう安心です。

注 1: アプリを動作させるための一時措置として、SDK バージョン 23(Marshmallow 用の SDK バージョン)以下を対象としたアプリでは、インスタンスを作成できるようになっています。Android SDK では、Crypto プロバイダの存在に依存しないようにしてください。これは今後完全に削除される予定となっています。

注 2: 多くのシステムで SHA1PRNG アルゴリズムの存在が前提とされているため、プロバイダを指定せずに SHA1PRNG インスタンスをリクエストした場合、OpenSSLRandom のインスタンスが返されるようになっています。これは OpenSSL に由来する安全な乱数ソースです。


Posted by Yuichi Araki - Developer Relations Team
Share on Twitter Share on Facebook

今週はマルチ プラットフォーム型ゲームのパブリッシャーである Poki の共同創業者 Sebastiaan Moeys さんを紹介します。Poki は子供向けのウェブゲームやゲームアプリを開発、公開している会社で、月間 3,000 万人のアクティブ ユーザー数を誇ります。元々はウェブ専門でしたが、モバイルの普及を受け、最近になって Zoi という同社初のアプリをリリースしました。Zoi の総ダウンロード数は 50 万件を超え、アプリストアでの評価も 4.4 と高水準を維持しています。それでは、こうした成功の秘訣をご覧ください。


1. 初めてのアプリ内分析はシンプルなものにする

Poki のチームはアプリ内分析を熟知しており、そのデータを利用して意思決定を効果的に行っています。

Poki では 3 つの指標に注目して状況把握に努めています。1 つ目の「純粋なプレイ時間」というカスタム指標では、広告を見ている時間やゲームの読み込み時間を除いた、アプリの純粋な利用時間を測定します。2 つ目の指標はユーザーの定着率で、1 日目、3 日目、7 日目の値を確認し、市場の有力ゲームと比較してパフォーマンスを評価します。3 つ目の指標は離脱率です。

Moeys さんは強力な分析基盤を時間をかけて構築する重要性を説いていますが、最初はシンプルな分析から始める方がよいと考えています。

「最初は簡単な分析から始めましょう。アプリ内分析は広範囲に及ぶため、最初からすべてを理解するのは不可能です。理解できる範囲で、少しずつ指標を増やしていくことを目標としましょう。」

まずは重要な指標を 1 つ(離脱率など)を選んでください。続いて、その指標を活用し、アプリの質を高める作業を日常的に行うようにします。 


2. 簡単、スピーディーに仮説をテストしてから本格的な開発に乗り出す

ゲームのユーザーはどの国でもマルチ スクリーンを既に受け入れており、複数のプラットフォームでゲームを楽しんでいます。最初はウェブ専門だった Poki も、この流れに合わせてモバイルにも進出するようになりました。しかし、この新しいチャレンジにより、新たな問題が発生したのも事実です。

今では同社が新しいゲームの開発に乗り出すたびに、チームの規模が大きくなり、必要な資金も増額するようになりました。プロジェクトの遂行に伴うリスクが、次第に大きくなっていったのです。

しかし、Poki はこの問題を巧みに回避し、大きな成果を上げています。最初からすべてのプラットフォームに対応せず、まずはウェブだけで試験的にリリースし、テストと改善を重ねることに専念しました。ウェブの実績を立ててから、モバイル向けの開発に着手します。ウェブでの経験は、その後のさまざまな場面での意思決定に役立っています。

「ゲームの開発に反復型の手法を取り入れたことで、ユーザーに愛されるゲームを時間をかけて作り上げることが可能となり、その流れで獲得した推進力や洞察を生かして、ユーザー拡大を図ることもできるようになりました。最初にウェブでテストする効果には、ゲームの完成度を高めることができる、アプリ内の最適な広告掲載位置を迅速な A/B テストで特定できる、アプリをローカライズすべき国や地域を特定できる、将来的なアプリのリリースに向けて既存のユーザーに評判を広めてもらうことができる、などがあります。」

Zoi で成功したこの手法は、他のプロジェクトへの適用も始まっています。Poki は現在 3 つのゲームを開発中で、モバイルでの成功を盤石なものにすべくデータの収集を行っているところです。Moeys さんは、本格リリースの前に迅速かつ低コストなテストを実施する同社の開発手法は汎用性があり、他のゲーム デベロッパーにも導入できると考えています。「新しいデベロッパーの場合は特に、自分たちの仮説が正しいかどうかをできるだけ早いタイミングでテストをしてほしい。プロトタイプを迅速にテストし、ゲームの設計と収益化戦略を見直してからアプリをリリースする必要があります。」

Google の投資会社である Google Ventures も、開発を始める前にアイデアをテストする手法を支持しています。同社はこの手法を広めるため、「Design Sprint」という方法論を構築しました。アイデアをまとめ、プロトタイプを作り、顧客と協力してテストを実施する 5 日間のプロセスにより、ビジネス上の重要な課題を解消します。コストをかけずにプロトタイプをテストする Google Venture の手法の詳細については、こちらをご覧ください。


3. 海外の市場にも目を向ける

Moeys さんが今の Poki につながる活動を始めたのは、オランダで高校生活を送っていたときのこと。当時はウェブのゲームが人気で、友人たちもみんなプレイしており、Moeys さん自身、ウェブゲームは全国的な流行だと認識していました。ところが、家族旅行でフランスを訪れたときに、フランスまではその流行が浸透していないことに驚いたそうです。自宅へ戻った Moeys さんはウェブサイトを立ち上げ、親の辞書を使ってすべてのコンテンツをフランス語に翻訳しました。その後のことは周知のとおり。今の Poki には 29 人の翻訳担当者がいて、海外市場への参入をサポートしています。

Moeys さんは今でも同じ原則に従って、ゲームを売り込む最適な市場を見つけています。国際的な収益化戦略を手間なく迅速に導入できるため、AdMob を活用しています。Moeys さんは海外進出を狙っている開発者向けに、次のようなアドバイスを残しています。

「Google のサービスを利用し、手間なく広告を掲載することをおすすめします。特定の市場でゲームの人気が出始めたら、まずはその市場に詳しいパートナーを見つけてください。Google のツールを利用し、Google ネットワークの需要に合わせて現地向けの広告を掲載することも重要です。私たちも多くの市場でこの戦略を実践し、多くの収益を上げてきました。」

今回紹介したヒントを有効だと思った方は、「AdMob実践ガイド:アプリの収益化」もご覧ください。AdMob の Twitter アカウントや Google+ ページのフォロー、そして Poki の Twitter のチェックもお願いします。


Posted by Joe Salisbury - AdMob プロダクト スペシャリスト
Share on Twitter Share on Facebook


アプリ収益化のヒントについて、もっと多くの情報を入手したい場合は、AdMob の Twitter や Google+ アカウント ページをフォローしてください。

* Canalys 2015, "Worldwide smart phones forecast overview 2015-2019"


Posted by Joe Salisbury, Product Specialist, AdMob
Share on Twitter Share on Facebook

Google I/O '16: Android 開発ツールの新機能


新機能の詳細

デザイン
Android Studio 2.2 プレビューの新しい Layout Editor
新しい Layout Editor によるメニューの編集

一見したところ、Constraint Layout は RelativeLayout に似ていますが、これは Studio 内で使用するためのものです。Constraint Layout を使用すると、アプリのデザインを効率的に記述して LinearLayout、FrameLayout、TableLayout、GridLayout のようなレイアウトを減らすことができます。また、ビルトインの自動制約インターフェース エンジンも組み込まれているので、自由に UI をデザインし、面倒な作業はすべて Android Studio に任せることができます。

この機能を簡単に使えるように、Android Studio 2.2 プレビューの新規プロジェクト ウィザードのビルトイン テンプレートで Constraint Layout が生成されるようになっています。または、新しい Layout Editor で任意の部分を右クリックし、[Convert to ConstraintLayout] オプションを選択しても、この機能を利用できます。

今回のリリースは、UI デザイナーと Constraint Layout の初期プレビューです。今後のリリースでは、さらなる機能拡張が予定されています。詳しくは、Android Studio のツールサイトをご覧ください。


Constraint Layout


Layout Inspector の起動
  • Layout Inspector: 新しいレイアウトでも既存のレイアウトでも、アプリの UI をデバッグしてレイアウトが期待どおりに表示されるかどうかを確認したいケースは多いでしょう。新しい Layout Inspector を利用すると、アプリのビュー階層に入り込んで画面上の各 UI コンポーネントの属性を分析できます。 
このツールは、Android Monitor ウィンドウの Layout Inspector アイコンをクリックするだけで起動できます。ツールが起動すると、Android Studio は分析用にアプリの現在のビュー階層のスナップショットを作成します。
Layout Inspector


開発


Android Studio の Firebase プラグイン
コードサンプル ブラウザ
ビルド

CMake ユーザーの方は、Gradle ファイルの externalNativeBuild セクションに CMList.txt ファイルへのパスを追加するだけです。
Android Studio での CMake ビルド

NDK-Build ユーザーの方は、Gradle ファイルの上記のセクションに *.mk ファイルへのパスを追加するだけです。
Android Studio での NDK-Build

Jack で増分ビルドを使用するには、build.gradle ファイルに次の設定を追加します。


Jack の増分コンパイル オプションの有効化
Jack は自動的にクラスパスにあるアノテーション プロセッサを適用します。apk にバンドルせずにコンパイル時のアノテーション プロセッサを使用するには、新しくサポートされた次の annotationProcessor 依存性スコープを使用します。


Jack アノテーション プロセッサ処理の有効化
  • 結合マニフェスト ビューア: ビルドタイプ、フレーバー、バリアントに基づいてどのようにプロジェクトの依存性と AndroidManifest が結合されるかを Android Studio から簡単に確認できます。AndroidManifest.xml で、画面下にある新しい Merged Manifest タブをクリックします。AndroidManifest の各ノードがさまざまなプロジェクトの依存性によってどのように解決されるかをご確認ください。 
結合マニフェスト ビューア
テスト

  • Espresso テスト レコーダー: UI テストの記述は時に非効率な作業になります。Espresso UI テストの記録機能を利用すると、アプリを操作するだけでテストを作成できるようになります。Android Studio は UI の操作をキャプチャし、完全に再利用が可能な Espresso テストに変換します。これは、ローカルや Firebase Test lab で実行することができます。このレコーダーを使うには、[Run] メニューから [Record Espresso Test] を選択します。

Espresso テスト レコーダー

  • APK Analyzer: 新しい APK Analyzer を使うと、APK 内のさまざまなコンポーネントの中身やサイズを把握することができます。さらに、Dex ファイルの 64K リファレンス メソッド制限問題の回避、ProGuard 設定問題の診断、結合 AndroidManifest.xml ファイルの表示、コンパイル済みのリソース ファイル(resources.arsc)の検査なども可能です。これによって、 APK サイズを削減したり、APK に意図したものが確実に含まれるようにすることができます。
APK Analyzer は、APK ファイルそのもののサイズと、APK 内のさまざまなコンポーネントのダウンロード サイズの両方を表示します。ダウンロード サイズは、Google Play が提供する APK をインストールする際にユーザーがダウンロードする必要があるサイズの目安です。この情報によって、どの部分でサイズを削減すればよいか、優先順位付けをしやすくなります。
この新機能を利用するには、[Build] メニューをクリックして [Analyze APK…] を選択し、分析したい APK を指定します。


APK Analyzer

  • Java 対応 C++ デバッガー:  N 以上で動作する C++ コードをデバッグする場合、Java 言語に対応した 1 つの lldb インスタンスでデバッグを行うことができます。このデバッガーは、ファスト ステップやメモリ ウォッチポイントなどのすばらしい lldb 機能のサポートを継続しつつ、Java 言語のブレイクポイントでの中断や、Java 言語のメモリ内容の表示ができるようになっています。


  • 自動デバッガー選択: Android Studio アプリは、デバッガー タイプに「Auto」を利用できます。これによって、Java 言語対応 C++ デバッガーと C++ プロジェクト用のハイブリッド デバッガーから自動的で適切なデバッガーが選択されるようになります。 Java 言語のみを使用するプロジェクトでは、Java 言語デバッガーがそのまま利用されます。

C++ での自動デバッガーの有効化

次のステップ

ダウンロード
旧バージョンの Android Studio をご使用中の方は、ナビゲーション メニューから Canary チャンネルのアップデートを確認できます(Windows / Linux の場合は [Help] → [Check for Update]、OS X の場合は [Android Studio] → [Check for Updates])。このアップデートは既存の Android Studio にパッチを適用するものではなく、新しいバージョンをダウンロードするものです。Android Studio 2.2 プレビューは、Canary リリースサイトからもダウンロードできます。

Android Studio 2.2 プレビューをご利用いただく場合、新しい Canary とともに安定版もご利用いただくことを推奨します。2 つのバージョンを共存させる方法については、ツールサイトをご覧ください。

気に入った機能や問題点、新機能の提案などのフィードバックは大歓迎です。Google+ のページや Twitter で Android Studio 開発チームからの情報を常にチェックしてください。

Posted by Yuichi Araki - Developer Relations Team
Share on Twitter Share on Facebook