[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

この記事は Erik Pasternak とキッズ コーディング チームによる Google Developers Blog の記事 "Introducing Blockly 1.0 for Android and iOS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Blockly はブロックベースのコーディング体験を提供するオープンソース ライブラリです。この 5 年間で、デベロッパーは Blockly を使って、Code.org のような教育プラットフォームから、littleBits のような電子工作キット、MIT App Inventor のような Android アプリ作成ツールまで、何百ものプロジェクトを生み出してきました。昨年には、Scratch チームと協力して Scratch Blocks を開発したこともお知らせしました。これは Blockly をソースをフォークして作られたもので、子供向けアプリのコーディングに最適化されています。

本日(*原文公開当時)は、Android と iOS で Blockly のリリース 1.0 が完成したことをお知らせします。Blockly 1.0 には、モバイルアプリでネイティブに Blockly を使うために必要な次のものがすべてがそろっています。
  • Blockly の標準 UI
  • カスタム ブロック、ツールボックス カテゴリ、レイアウト
  • 関数、変数、ミューテーター、エクステンション
  • JavaScript、Python、Dart、PHP、Lua コード生成
  • 国際化サポート(RTL 言語も含む)

本日の 1.0 へのアップデートは、ネイティブのモバイル環境を主眼に置いたものですが、ウェブ版のプロジェクトもここ半年でいくつかのアップデートが行われています。パフォーマンスとテストは大きく改善されており、構造的な API が追加され、モバイルウェブでのタッチ機能のサポートも改善されています。さらに、Internet Explorer と Edge のサポートも強化され、IE10 以上で Blockly が完全にサポートされています。

また、クロス プラットフォーム開発を容易にするために、さまざまな作業も行われています。ブロックはすべて JSON で定義できるようになったので、1 つのブロック定義をウェブ、iOS、Android で使い回すことができます。これら 3 つのプラットフォームの詳細については、ドキュメントをご覧ください。


iOS コードラボは、すぐにご利用いただけます(Android 版も近日中に提供予定)。Blockly の詳細については、上の紹介ビデオデベロッパー サイトをご覧ください。また、メーリング リストにもご参加ください。ウェブAndroidiOS のコードを直接参照することもできます。



Reviewed by Takuo Suzuki - Developer Relations Team

この記事は Google Maps API のソリューション アーキテクト、Ken Nevarez による Google Geo Developers Blog の記事 "Google Maps and Particle partner to bring location-aware capabilities to IoT devices" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年、「IoT を容易にする Particle と GCP」でも紹介した IoT プラットフォームの Particle と Google Maps APIs を組み合わせることによって、GPS を使わずに IoT 端末で位置情報を容易に検出できるようになりました。たった 1 行のコードを書き加えるだけで、ネットワーク上に分散する端末やセンサー(IoT エッジデバイス)からGoogle Maps Geolocation API を使用して Wi-Fi や携帯電話の基地局に関する Google の地理空間データベースにアクセスできるようになります。

IoT 端末やセンサーの位置情報を把握するために、高価で消費電力の大きな GPS モジュールはもはや必要ありません。既存の GPS システムと Google Maps APIs を一緒に活用することで、精度の高い位置情報を得ることが可能となり、屋内など GPS が働かない場合でも位置情報を把握することができます。

現在 Particle と Google では、収集したデータを Google Cloud Platform に送信する一連の流れをサポートしています。IoT センサーは自身の位置情報を検知すると、関連データを収集して返します。Google Cloud Platform にこうしたデータを蓄え、堅牢なクラウド上で利用することができます。

従来のアセット トラッキングは GPS などをベースに構築されていますが、GPS は過密な都市エリアや室内では利用できないことがしばしばあります。これは、GPS 信号が高層ビルや屋根によって遮断されてしまうためです。一方 Geolocation API は、携帯電話の基地局や Wi-Fi の信号をベースにするので、GPS が無効な場合でも位置の検出が可能です。そのため、屋内外を問わず、あらゆる場所のアセットのトラッキングが可能です。

IoT が主導する世界では、位置以外の情報も捉えることができます。こうした追加情報は、利用目的によって大変重要なものもあります。たとえば、冷凍品のサプライチェーンでは、「温度」に関する情報は工場、発送センター、輸送トラックにとって重要なデータの一つです。こうした情報によって、サプライチェーンの全体像を把握して、高品質の商品を配送することが可能になります。
Particle プラットフォーム上に構築されたWi-Fi 対応製品は、位置情報に基づいてその設定を自動化する機能も提供します。Geolocation API を使用することで位置情報に応じて、タイムゾーンの設定や、利用可能な周波数帯域の調整、地域ごとのサービス プロバイダへの接続などを自動的に行います。これにより、製品の設定作業はシームレスになり、操作性も向上し、有用な分析も可能になります。

たとえば、窓のブラインドの場合、位置情報をもとに日照時間のデータを参照して、その開閉を制御することで室内の温度を調整することができます。また、位置情報を送信する機能がついたコーヒー メーカーの場合、その位置情報から市場浸透率やターゲット層の詳細などマーケット分析に必要な情報を得ることもできます。

Particle 端末で位置情報を有効にする方法は、こちらのドキュメントを参照ください。必要な基本ステップは次の 4 つです。

  1. 位置情報に対して有効な Google Maps API キーを取得する
  2. Particle 端末に Google マップのファームウェアを書き込む
  3. Particle Console で Google Maps Integration を有効にする
  4. テストする

Google と Particle の詳細は、デベロッパー ドキュメントをご覧ください。


Reviewed by 丸山 智康 (Tomoyasu Maruyama) - Google Customer Engineer Lead, Japan and APAC

この記事は Paint Timing Promoter、Shubhie Panicker による Chromium Blog の記事 "Chrome 60 Beta: Paint Timing API, CSS font-display, and Credential Management API improvements" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

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

Paint Timing API
汎用的な指標では、ページを読み込む瞬間をあらゆるケースにおいて的確に記録することはできません。一方、First Paint と First Contentful Paint は、ユーザーにとって重要な読み込み中の瞬間を測定できるため、非常に有益な値です。新しい Paint Timing API では、この First Paint と First Contentful Paint を取得するための指標が公開されています。これにより、デベロッパーは自身のサイトの読み込みパフォーマンスをより詳しく把握できます。

Screen Shot 2017-06-08 at 8.57.03 AM.png
Google.com における First Paint と First Contentful Paint の瞬間の画像。Google I/O 2017 の「Web Performance:Leveraging the Metrics that Most Affect User Experience」より引用


CSS font-display
ダウンロード可能なウェブフォントは、より視覚的にリッチなウェブ エクスペリエンスを実現するためによく利用されます。従来の Chrome では、きれいに整った画面を確実に表示するために、指定のフォントが利用可能になるまでテキストのレンダリングを遅らせていました。しかし、通信速度が遅いとフォントをダウンロードするのに何秒もかかることがあるため、ユーザーにコンテンツが表示されるまでの時間に大幅な遅延が生じてしまいます。Chrome では現在、CSS の @font-face ディスクリプタと、対応する font-display プロパティをサポートしています。これにより、デベロッパーはフォントのダウンロード中に、Chrome でテキスト コンテンツを表示する方法とタイミングを指定することができます。

Credential Management API の改善
デベロッパーのみなさまからのフィードバックを受け、Credential Management API をすべてのサイトで利用しやすいものに改善し、保存済みパスワードにアクセスするためのカスタム fetch() を廃止しました。Chrome 60 以降、ユーザーのパスワードは PasswordCredential の一部として直接返されるようになります。

さらに、Web Authentication Working Group の取り組みに合わせ、一連の変更を加えました。たとえば、requireUserMediation を廃止し、preventSilentAccess に名称変更しています。


今回のリリースに追加されたその他の機能
  • Payment Request API がデスクトップ版の Chrome でサポートされるようになりました。 
  • Payment Request API を使用することにより、支払い機能を備えたネイティブ Android アプリで サイト上での支払い処理が行えるようになりました。 
  • オブジェクトの rest および spread プロパティが新たにサポートされ、オブジェクトの統合やシャロー クローン、さまざまな変更不能なオブジェクト パターンの作成がより簡単にできるようになりました。 
  • 新しい Web Budget API によって、プッシュ通知のパーミッションを持つサイトで有限のプッシュ メッセージを送信できるようになりました。これにより、ユーザーに通知を表示しなくても、データの同期やユーザーが他のデバイスで操作した通知の削除などのバックグラウンド処理をトリガーできます。 
  • 新しい Web Push 暗号化フォーマットがサポート対象になりました。使用可能な箇所は、PushManager.supportedContentEncodings で検出できます。 
  • PushSubscription.expirationTime が利用可能になり、定期購入の期限が切れる場合はその時期についてサイトに通知されるようになりました。 
  • パフォーマンスと予測可能性を向上させるため、scrollTouchEvents の既存機能に合わせて、pointermove イベントと mousemove イベントが AnimationFrame ごとに 1 回発行されるようになりました。 
  • CSS 疑似クラスの :focus-within が利用可能になりました。これは :focus 疑似クラスが影響を与えるあらゆる要素、および :focus の影響を受ける子孫を持つあらゆる要素に影響を与えます。 
  • CSS フレーム タイミング関数が利用可能になりました。最初から最後まですべてのフレームをまったく同じ時間表示するアニメーションにおいて、アニメーションをループさせる際に役立ちます。 
  • 編集アクションの検出方法が改良されました。InputEvent によってユーザー入力をスクリプトで管理できるようになり、さらに充実した詳細情報が編集可能な要素に提供されます。 
  • セキュリティ向上のため、ユーザーがサイトを離れる際にトリガーされる BeforeUnload ダイアログは、その表示を試みるフレームがユーザーの操作やインタラクションを取得したことがある場合にのみ表示されるようになりした。ただし、これとは別に BeforeUnloadEvent は引き続きディスパッチされます。 
  • ロイヤリティ フリーのオープンな動画コーディング フォーマットである VP9 が、MP4(ISO BMFF)コンテナと一緒に使用できるようになり、以下の新しい VP9 文字列フォーマットが必要になりました。 
  • 新しい VP9 文字列フォーマットが利用可能になり、さまざまなメディア関連 API で受け付けられるようになりました。そのため、デベロッパーは動画コーデックとしては一般的であるものの未公開のエンコード プロパティを記述することができます。

サポートの終了と相互運用性の改善
  • getElementsByTagName() は、DOM 仕様のアップデートに伴い、修飾名を受け付けるようになりました。 
  • /deep/ は、事実上は操作不能な子孫コンビネータとして動作するようになりました。 
  • ユーザー エクスペリエンスの向上のためNavigator.vibrate() を呼び出すと、ユーザーがフレームまたは組み込まれたフレームを明示的にタップしていない場合は、即座に false が返されるようになりました。これは既存のクロスオリジン iframe の動作と一致しています。 
  • WEBKIT_KEYFRAME_RULEWEBKIT_KEYFRAMES_RULE は削除され、接頭辞のない標準 API、KEYFRAME_RULEKEYFRAMES_RULE に置き換えられました。 
  • 非標準の WebKitAnimationEventWebKitTransitionEvent は、document.createEvent() のサポート対象外になりました。 
  • 仕様に準拠するため、NodeIterator.filterTreeWalker.filter は JavaScript オブジェクトをラップしなくなりました。また、.prototypewindow.NodeFilter から削除されました。 
  • RTCPeerConnection.getStreamById() が削除されました。代わりに polyfill を使用することをお勧めします。 
  • SVGPathElement.getPathSegAtLength()SVGPathElement 仕様から削除されたため、サポートを終了しました。 
  • Headers.prototype.getAll() は仕様から削除されたため、Fetch API から削除されました。 


この記事は プロダクト マネージャー、Wei Liu による Android Developers Blog の記事 "Making the Internet safer and faster: Introducing reCAPTCHA Android API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

10 年前に reCAPTCHA がリリースされたとき、その目的はシンプルなものでした。その目的とは、スパムや不正使用の心配をせずに、ユーザーが好きなサイトにアクセスできるようにすることです。長い年月を経て reCAPTCHA は大きな変化を遂げ、ゆがんだテキストから住所の番地や名前へ、そして 2014 年の No CAPTCHA reCAPTCHA、今年 3 月の Invisible reCAPTCHA へと進化しています。

現在までに、10 億以上のユーザーが reCAPTCHA のメリットを受けています。私たちはこの保護の改善に引き続き取り組んでゆきます。

reCAPTCHA は、あらゆる場所にいるオンラインのユーザーを保護します。モバイル端末の利用が急速に拡大する中で重要になるのは、モバイルアプリとそのデータを安全に保つことです。reCAPTCHA が 10 歳の誕生日を迎える本日、最初の reCAPTCHA Android API が Google Play Services の一部としてリリースされたことをお知らせします。

この API を使うと、reCAPTCHA による人間とボットの区別の精度が上がり、モバイル ユーザーの操作性を向上させることができます。これは最新の Invisible reCAPTCHA テクノロジーを利用したもので、裏でリスク分析を行うことによって、ほとんどの人間のユーザーはクリックなしで通過できるようになっています。そのため、モバイル ユーザーは中断されることなくアプリを楽しむことができます。スパムや不正使用に悩まされることがない点は変わりません。

reCAPTCHA Android API は、モバイルアプリを保護する端末認証、セーフ ブラウジングなどのサービスを提供する Google SafetyNet の一部です。モバイル デベロッパーは、同じ API で端末とユーザーの両方を認証できるので、さらに効率的にアプリのセキュリティ リスクを低減できます。また、Android のセキュリティ保護の多様性も向上し、有害な可能性があるアプリを監視する Google Play Protect、端末の暗号化、通常のセキュリティ アップデートにこの機能が加わることになります。reCAPTCHA Android API を組み込む方法については、こちらのサイトをご覧ください。また、iOS 版のライブラリにもご期待ください。

reCAPTCHA の旅はまだ続きます。私たちは、(ボットを除く)誰もがインターネットを安全かつ簡単に使えるようにすることに取り組んでゆきます。



Reviewed by Takeshi Hagikura - Developer Relations Team

この記事は Google Assistant プロダクト マネージャー、Brad Abrams による Google Developers Blog の記事 "From Actions on Google to the SDK, the Google Assistant is getting better for developers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

2016 年 12 月に、Google Home 向け Actions on Google デベロッパー プラットフォームのアーリーアクセス版を発表しました。それ以来、ユーザーを増やし、このプラットフォームの機能やデベロッパー エクスペリエンスを向上させることに重点的に取り組んできました。本日(*原文公開当時)、本プラットフォームがスマートフォンに対応し、新機能が追加されて SDK が強化されたことをお知らせします。あらゆる場所にいる Google Assistant ユーザー向けにすばらしいアプリを作成するため、私たちは今後も皆さんと協力してゆきます。

スマートフォン向け Actions on Google の導入


2016 年 12 月に Actions on Google プラットフォームがリリースされてから、Google Home では創造性あふれる楽しいアプリが生まれています。たとえば、FitStar でフィットネスを行ったり、CNBC で最新ニュースを取得したりするものがあります。そしてこのたび、Android スマートフォンと iPhone の両方の Assistant で Actions on Google が利用できるようになりました。


スマートフォンでも Assistant アプリが利用できるようになるので、ユーザーベースの拡大や、まったく新しいユースケースのアプリの構築も可能です。膨大なメニューの中から衣料品を購入する、食料品を注文するといった操作は、音声のみのインターフェースに適したものではないからです。さらに、画面が使えるようになることで、アプリでイメージ カルーセル、リスト、サジェスチョン表示などの新しい UI 要素を簡単に使えるようにもなります。


Assistant 向けスマートフォン アプリは、構築やデプロイが可能になっています。ドキュメントはこちらです。


イギリスでは、近日中に英語の Actions on Google がリリースされる予定です。フランス語、ドイツ語などの言語も今年中にリリースされる予定です。


取引と支払いへの対応

Assistant の目的は、皆さんのやりたいことをサポートすることです。それは、単に質問をしたり、情報を聞いたりすることにとどまりません。購入手続きも簡単に行えるようにしたいと考えています。

Google Assistant アプリで支払いを行うには、2 つのオプションがあります。1つ目のオプションは、無償で簡単に組み込むことができる Google ペイメントを使う事で、すでに Google に登録されている何億ものカードを活用できます。または、2つ目のオプションとしてユーザーがすでにアプリに登録している支払い方法も使うことができます。この 2 つ目のオプションを使う場合は、ユーザーがシームレスに決済ができるソリューションを構築する事を推奨します。


もちろん、取引はユーザーの支払いで終わるわけではありません。注文のトラッキングや変更、再注文などが必要になる場合もあります。そのため、Assistant では、単一の履歴ビューですべての取引を参照できるようになっています。さらに、リピート率向上のために、注文のアップデート機能も開発しています。この機能を使うと、迎えにきた車が到着したとき、食料品が配送されたとき、処方箋が準備できたときなどにステータスのアップデートを送信できます。


取引を行うアプリは、本日より作成やテストができるようになっています。スマートフォンの Google Assistant ユーザーも、近日中にこの機能を利用できるようになります。

ツールとアプリの見つけやすさの向上

以上のような新機能では、今まで以上に基本を理解することが重要になります。また、言うまでもなく、優れたツールや人目に触れやすくすることはもっとも重要です。


そこで、デベロッパー エクスペリエンスの向上のため、本日、新しいデベロッパー コンソールをリリースしました。このコンソールにより、デベロッパーがチームで作業し、アプリの使用状況、パフォーマンス、ユーザー検出パターンに基づくデータの収集ができるようになります。これは、Firebase コンソールと Google Cloud コンソールを統合して、アプリ内のデータを共有できるようにしたものです。


さらに、新たなアプリのディレクトリもリリースします。ユーザーは Google Assistant を 1 回タップするだけでこの機能にアクセスでき、カテゴリやユーザーの評価を確認できます。各アプリのディレクトリ ページはウェブでも共有できるので、新しいユーザーや既存のユーザーにアプリを宣伝したり、ユーザーが友だちと共有したりできます。


今回のアップデートによって、ユーザーはアプリのショートカットを作成できるようになります。そのため、ユーザーは「OK Google、Forecaster Joe にアウターバンクスの波の様子を聞いてくれ」と言わなくても、たとえば「OK Google、波は来てるかい?」とパーソナル ショートカットを声に出すだけで簡単にアプリに戻ることができます。


こういった機能によって確かにユーザーはアプリを見つけやすくなるはずですが、私たちの仕事はこれで終わりではありません。今後も、さらに新機能を追加し、アプリを見つけやすくしてゆく予定です。

Assistant SDK のアップデート

先月、Google Assistant SDK のプレビュー版を紹介しました。これは現在も改善が続けられており、たくさんの新機能が追加されています。


ホットワードがサポートされたので、デベロッパーはボタンなどの物理的な操作ではなく、「OK Google」をトリガーとする端末を構築できるようになります。また、タイマーとアラームの機能も追加されているので、ビルトインで Google Assistant が組み込まれている端末に「OK Google、60 秒のタイマーを設定してくれ」と言うことができるようになります。


この SDK とプラットフォームは生まれて間もないものですが、今まで以上に包括的なデベロッパー エクスペリエンスを提供できるように作業を続けています。また、Google Assistant SDK を搭載したものも含め、新しい端末にこのプラットフォームを提供することも検討中です。



新しいデベロッパー コンテストのお知らせ

最後に重要なお知らせです。初めての Actions on Google デベロッパー コンテストが開催されることになりました。このコンテストでは、優秀な Google Assistant アプリに 20 以上の賞が贈られる予定です。早速開発を始めましょう。皆さんのアプリを見るのが待ちきれません。


今後も、皆さんとともに新しい Google Assistant アプリを開発できることを楽しみにしています。


Reviewed by Takuo Suzuki - Developer Relations Team

この記事は Google Maps API プロダクト マネージャー、Joel Kalmanowicz による Google Geo Developers Blog の記事 "Get your users where they need to go on any platform with Google Maps URLs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google I/O 2017 でご紹介した「Google Maps URL」は、任意のアプリから Google マップに直接リンクすることができる新たな方法です。毎月 10 億人以上のユーザーが Google マップのアプリやサイトを利用して世界中の情報にアクセスしています。今回発表した仕組みによって、任意のアプリやサイトから Google マップを簡単に活用することができます。


URL を利用する理由

ユーザーが何か目的を達成したいときに、地図が重要なことがあります。しかし、地図がアプリやサイトの中で重要なサービスではないこともあります。特定の場所を示すなど、ユーザーが移動する際の手助けになれば十分というときもあるでしょう。買い物をするために皆さんのもとに訪れようとしているお客様が付近の店舗を探したい場合や、他のユーザーとどこで待ち合わせするかを決めようとしている場合ということもあるでしょう。こうした状況に、Google マップは簡単に対応することができます。

Google Maps URL を使うことによって、 Google マップにリンクし、必要とする機能を自動的に呼び出すことができます。この Google Maps URL は新しい機能というわけではありません。あるプラットフォームでは、ブラウザの URL をコピーすることで動作することに気づいている方もいることでしょう。Android のアクティビティの起動を司るインテントや iOS の URL スキームも利用できます。しかし、これはネイティブ プラットフォームでしか動作しません。デベロッパーの作業も増えますし、マルチユーザー機能は同じプラットフォームのユーザーに制限されます。

クロスプラットフォーム

そこで必要になるのが、Android、iOS、ウェブのすべてをサポートするクロスプラットフォームのユニバーサル URL スキームです。たとえば、メッセージング アプリのユーザーは、メッセージの受信者が Android か iOS かを気にすること無く、友人と会う場所を共有したいはずです。同様に、デベロッパーも同じ機能を 2 つの異なるライブラリで再実装したいとは思わないはずです。

Google Maps URL を開くと、ユーザーの端末の種類に関わらず、インストールされている Google マップのアプリがそれを処理することになります。Android や iOS の Google マップが利用できる場合、それが開きます。そうでない場合は、ブラウザで Google マップが開きます。

利用は簡単

この機能は簡単に利用できます。実施したいことに沿って、URL のいくつかの値を置き換えるだけなので、プログラムで URL を作成するのも簡単です。いくつか例を示します。

予約した宿泊先へ行く方法を知りたい場合や、近隣の飲食店を探したい場合は、次のようにURLを定義します。
https://www.google.com/maps/search/?api=1&query=sushi+near+94043
query パラメータにクエリを指定します。ここでは特定の場所を指定していますが、場所を指定しない場合は、リンクをクリックしたユーザーの近くの場所で探します。ここをクリックすると近くの寿司店を探すことができますので、お試しください。

次のリンクは先ほどのクエリに似ていますが、 1 つの結果だけを返し、ページに追加情報が表示されます。
google.com/maps/search/?api=1&query=shoreline+amphitheatre
api パラメータ(必須)には、使用する Google Maps URL のバージョンを指定します。現在リリースされているバージョンは 1 です。


フィットネス アプリを設定したユーザーが自転車で新しいルートを走ってみたい場合は、次のようにします。
www.google.com/maps/dir/?api=1&destination=stevens+creek+trail&travelmode=bicycling&dir_action=navigate
ここでは、travelmode(移動モード)に bicycling(自転車)を、destination(行き先)に自転車専用道路を指定します。

また、実際にどんな場所かを確かめるために、直接ストリート ビューを開くこともできます。
www.google.com/maps/@?api=1&map_action=pano&viewpoint=36.0665,-112.0906&heading=85&pitch=10&fov=75
viewpoint(視点)パラメータには、表示したい場所の緯度経度を指定します。また、heading(方角)、pitch(上下の角度)、fov(視野角)パラメータで見る方向を指定します。

機能の詳細

Google Maps URL を活用すると、Google マップで何らかのタスクを実行するユーザーをサポートできます。しかし、もっと柔軟な対応が必要な場合や、カスタマイズや制御が必要な場合には、さらに強力な Google Maps API を活用して、Google マップをアプリやサイトに組み込む方法をおすすめします。API が提供する豊富な機能を使うことによって、カメラの制御マップへの図形の描画マップのスタイル設定などのさまざまな機能にアクセスできます。さらに、マップだけでなく、場所のメタデータやイメージなどを活用することもできます。

詳しい情報は

皆さんのニーズを満たすため、Google マップを使ったアプリで大変な作業を簡単に済ませたいという方は、ぜひ Google Maps URL をお使いください。詳細は、新しいドキュメントをご覧ください。

Google Maps URL と Google Maps APIs を利用していただき、ありがとうございます!フィードバックや問題点は、Issue Tracker で共有してください。


Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Customer Engineer Lead, Japan and APAC

この記事は プロダクト マネージャー 、Jumana Al Hashal  による The Firebase Blog の記事 "Making Dynamic Links Easier" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Firebase Dynamic Links は便利なリンクシステムです。1 つだけのリンクで、インストール済みの iOS や Android アプリを開き、ディープリンクを使用し、ユーザーが探しているコンテンツを直接にアプリ内で表示することができます。アプリがインストールされていない場合にも、同じリンクで App Store や Google Play のアプリのページからアプリ内のコンテンツまで案内することができます。

私たちは 1 年前からこの機能を改善し、よりスムーズでよりパワフルな体験をデベロッパー、ユーザーの両方に届けられるよう努力してきました。今回、最新の機能を iOS SDK と Android SDK に届けることができたことを嬉しく思います。

Dynamic Links をダイナミックに生成する


今まで、Dynamic Links を生成するには Firebase コンソールからアクセスする必要がありました。広告、宣伝などのキャンペーンの目的では十分でしたが、デベロッパーの皆さまからは、ユーザー同士で共有できるキャンペーンなどに対応するために、アプリからリンクを作成できるようにしたいというフィードバックを多数いただいていました。

そのため、iOS と Android の Firebase SDK に、ロングとショートの Dynamic Link を生成する機能を追加しました。

iOS:

guard let deepLink = URL(string: "https://mydomain.com/page?param=value") else { return }

let components = DynamicLinkComponents(link: deepLink, domain: domain)

let iOSParams = DynamicLinkIOSParameters(bundleID: bundleID)
iOSParams.minimumAppVersion = minVersion
components.iOSParameters = iOSParams

// ダイナミック リンクを生成する
let link = components.url

// またはショート リンクを生成する
components.shorten { (shortURL, warnings, error) in
      if let error = error {
        print(error.localizedDescription)
        return
      }
      
    // TODO: shortURL を使用する
    }

Android:

String deepLink = "https://mydomain.com/page?param=value";

DynamicLink.Builder builder = FirebaseDynamicLinks.getInstance()
        .createDynamicLink()
        .setDynamicLinkDomain(domain)
        .setAndroidParameters(new DynamicLink.AndroidParameters.Builder()
                .setMinimumVersion(minVersion)
                .build())
        .setLink(deepLink);

// ダイナミック リンクを生成する
DynamicLink link = builder.buildDynamicLink();

// またはショート リンクを生成する
builder.buildShortDynamicLink()
        .addOnSuccessListener(new OnSuccessListener() {
            @Override
            public void onSuccess(ShortDynamicLink shortDynamicLink) {
                // shortDynamicLink を使用する
            }
        });

新しい Android API

アプリから Dynamic Links を実装しやすくするために Android API を考え直して、新たに FirebaseDynamicLinks というクラスを追加しました。新しいライブラリを追加するには、build.gradle に次の行を追加します。


compile "com.google.firebase:firebase-dynamic-links:11.0.0"

これによって、Dynamic Link から起動したアクティビティを開く際の処理が簡単になります。

FirebaseDynamicLinks.getInstance().getDynamicLink(getIntent())
  .addOnSuccessListener(
    new OnSuccessListener() {
      @Override
      public void onSuccess(PendingDynamicLinkData data) {
      if (data == null || data.getLink() == null) {
        // FDL は特にない。何もする必要がない
        return;
      }

      Intent launchIntent = data.getUpdateAppIntent(MainActivity.this);
      if (launchIntent != null) {
        startActivity(launchIntent); // アップグレード フローを起動する
      }

     Uri deepLink = dynamicLink.getLink();
     String myAppItemId = deepLink.getQueryParameter("myAppItemId");
     // TODO: myAppItemId のコンテンツを表示する
    }
});

新しい API に関するご質問やフィードバックがあった場合は、サポートページをご確認ください


Reviewed by Oscar Rodríguez - Developer Relations Team

この記事は Google Drive プロダクト マネージャー、Hodie Meyers、G Suite デベロッパー アドボケート、Wesley Chun(@wescpy)による Google Apps Developer Blog の記事 "VIDEO: Part 1—Introducing Team Drives for developers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

エンタープライズ企業は常に効率化の方法を模索していますが、デベロッパーに正しいツールを用意することで違いを生みだすことができます。Google は今年、Team Drives をリリースしました。これは、Google Drive でユーザーに好評だった機能を企業のチームにも提供するものです。さらに、デベロッパーが Team Drives を活用したアプリを開発できるよう、Google Drive API もアップデートしました。

この最新の G Suite Dev Show 動画では、アプリで Team Drives の機能を活用する方法について説明しています。うれしいことに、まったく新しい API を学習する必要はありません。Team Drives の機能は Drive API に組み込まれているため、これまでに身につけた知識を使って開発できます。どうぞご覧ください。

この動画を最後まで見ていただければ、Team Drives の機能をアプリに組み込む際の次のような基本操作について理解できるでしょう。
  1. Team Drives の作成方法 
  2. Team Drives にメンバーやユーザーを追加する方法 
  3. Team Drives でフォルダを作成する方法(通常の Drive フォルダと同様) 
  4. Team Drives フォルダにファイルをアップロードまたはインポートする方法(通常のフォルダへのファイルのアップロードと同様) 
Drive API は、さまざまなデベロッパーが Google Drive と Team Drives の両方と連携するソリューションを作成するために役立ちます。独立ソフトウェア ベンダー(ISV)の方でも、システム インテグレーター(SI)や IT 従事者の方でも、生産性向上、企業の G Suite への移行サポート、ワークフローを自動化するツールの開発など、さまざまな用途に Drive API を利用できます。

Team Drives 機能では、Drive API v2 と v3 の両方を利用できます。さらに詳しい説明は、Drive API ドキュメントをご覧ください。皆さんが Team Drives を使って作るアプリを楽しみにしています。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Firebase Hosting エンジニア、Michael Bleigh による The Firebase Blog の記事 "Serving dynamic content with Cloud Functions on Firebase Hosting" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


3 年前、Firebase Hosting がリリースされ、デベロッパーが高速で魅力的なウェブ コンテンツをより簡単に提供できるようになりました。2 か月前には、Cloud Functions for Firebase のベータ版がリリースされ、デベロッパーがサーバーやインフラについて心配せずに、カスタム バックエンド ロジックを記述できるようになりました。先日の Google I/O では、Firebase Hosting と Cloud Functions を組み合わせて、世界規模の拡張性とパフォーマンスを備えた Progressive Web Apps を作成できる柔軟なツールセットとして使う方法を紹介しました。

プロジェクトの firebase.json 設定ファイルに rewrite を追加すると、HTTPS Cloud Function を Firebase Hosting アプリに接続できます。
{
  "hosting": {
    "rewrites": [
      {"source": "/function/**", "function":"myFunction"}
    ]
  }
}

接続後は、一致するリクエストがスムーズに Cloud Function に渡されます(上記の例では、myFunction という名前の機能が呼ばれます)。このわずか 1 行の変更だけで、Firebase Hosting ユーザーは以下のようなすばらしい新機能を使えるようになります。
  1. サーバーサイド レンダリング: 今までは、Firebase Hosting は静的なコンテンツしか提供できませんでしたが、Express などの業界標準ライブラリを使ってダイナミック コンテンツを提供できるようになります。超高速なグローバル CDN キャッシュが活用できる点は変わりません。
  2. カスタム API: Cloud Functions と Firebase Hosting を組み合わせると、独自のドメインにカスタム API エンドポイントを作成して、クロスオリジン リクエストの負荷を避けることができます。さらに、数行のコードを追加すると、Firebase Auth でエンドポイントを認証することもできます。
  3. ユーザー生成ウェブ コンテンツ: Firebase Hosting で初めてデプロイ不要で AMPTwitter Cards などに対応したコンテンツを生成できるようになりました。これで、Firebase Hosting アプリはこれまで以上にコンテンツ共有や検索が容易になります。

Cloud Functions ユーザーは、SSL で保護されたカスタム ドメインで機能を実行できるようになり、不必要な実行を防ぐ強力なキャッシュも利用できます。

ご自分の Firebase プロジェクトの Firebase Hosting で Cloud Functions を使う方法については、ドキュメントをご覧ください。I/O セッション「Firebase Hosting で高速なウェブ体験を開発する」もご覧ください。

Reviewed by Khanh LeViet - Developer Relations Team

この記事は ソフトウェア エンジニア、Zachary Nado による Google Developers Blog の記事 "AMP Compression Update" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

先日、Google AMP Cache に Brotli 圧縮が追加されたことをお知らせしました。Google AMP Cache から提供されるすべての AMP ドキュメントを Brotli 圧縮できるようになりました。これによって、ユーザーは帯域幅をかなり節約でき、モバイル体験の向上という目的にまた一歩近づきます。

Brotli は、Jyrki Alakuijala 氏と Zoltán Szabadka 氏が Google Research Europe の圧縮チームとともに作成した新しい効率的な圧縮アルゴリズムです。2015 年にリリースされて以来、Google の他の領域でもかなりの効率化に貢献しています。Brotli は汎用的な圧縮アルゴリズムですが、ウェブ ドキュメントでは特に効果が見込まれます。gzip の代わりに Brotli を利用すると、ドキュメントのサイズが平均で約 10% 小さくなります。Google AMP Cache では、1 日あたり数百ギガバイトの帯域幅が節約できます。

ドキュメントのサイズが小さくなると、ページの読み込みが早くなるだけでなく、データ量が限られたプランのユーザーは帯域幅を大幅に節約できます。しかし、Google AMP Cache はまだ始まりにすぎません。エンジニアリング チームは他のさまざまな製品で Brotli をサポートする作業を続けています。それによって、Google 全体にわたる帯域幅の節約が実現します。


Reviewed by Yoshifumi Yamaguchi - Developer Relations Team

この記事は スパム対策ニンジャ、Kazushi Nagayama、ポリシー スペシャリスト、Bryan Woodward による Android Developers Blog の記事 "Google Play’s policy on incentivized ratings, reviews, and installs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。  
  
Google Play の信頼性と安全性の確保は、Google の最優先事項の 1 つです。先日は、スパム インストール偽の評価やレビューへの対抗策の強化についてお知らせしました。こういった発表をさらに強調し、明確化するために、報酬に基づく評価、レビュー、インストールに関するデベロッパー プログラム ポリシーをアップデートしました。  
 
デベロッパーは、いかなるアプリについても、ストア内の配置を操作しようとしてはいけません。これには、詐欺や報酬によるインストールやレビュー、評価などの不正な手段を用いた製品の評価やレビュー、インストール数のつり上げが含まれますが、それに限定されません。

 

報酬に基づく操作の定義


ユーザーが評価、レビュー、インストールの操作を、金銭、物品、あるいはそれと同等のものと引き替えに行った場合、それは報酬に基づくものと見なされます。報酬に基づく評価やレビューは例外なくポリシー違反です。Google は、ストアの統一性を維持するため、対策をとり続けます。Google Play のアプリの配置を変えることを意図したインストールは、検知されて除外されます。  

ユーザー獲得手段としての報酬に基づくインストール


報酬に基づくインストールは、Google Play アプリの配置を操作するためだけに行われている場合もあります。この場合、ポリシー違反になります。ただし、一部のデベロッパーは、報酬に基づくインストールを正式なユーザー獲得チャンネルとして利用しています。この 2 つの異なるユースケースを判別するため、次のようなアプローチを採用しています。  
  • 報酬に基づくインストールをユーザー獲得チャンネルの 1 つとして利用しただけでは、ストアからアプリが自動的に削除されることはありません。ただし、ストアの統一性を損なうような行動は監視されており、そのような行動には対策がとられます。
  • Google がアプリの配置を操作しようとした行動であると判断した場合、それに対処するため、報酬に基づくインストールをシステムで監視して除外します。トップチャートから削除されることもあります。削除すべき根拠がある場合、アプリがストアから削除されることもあります。

このアプローチを通して、Google Play でアプリを探すトップチャートなどの仕組みが、実際のアプリの人気を反映したものになることを期待しています。  
 
原則として、報酬に基づくアクションを利用しないことをおすすめします。報酬によるユーザーは、他の獲得チャンネルによるユーザーとはまったく異なります。Google リサーチチームによる内部分析では、報酬によるユーザーは有償または有機的な獲得チャンネルによるユーザーよりも維持率が低く、アプリ内購入額も少なくなっています。  
 
Google Play ポリシーについての詳細は、デベロッパー ポリシー センターをご覧ください。Google Play で成功するためのおすすめやベスト プラクティスは、Android デベロッパー ウェブサイトをご覧ください。  
このブログ投稿はどのくらい役に立ちましたか?

Reviewed by Yoshifumi Yamaguchi - Developer Relations Team

この記事は AMP Project プロダクト マネージャー、Rudy Galfi による Accelerated Mobile Pages Project の記事 "AMP Roadmap Update for Q2 – Accelerated Mobile Pages Project" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
  
AMP ロードマップがアップデートされました。新しいプロジェクトが追加され、既存の優先事項の進捗が反映されています。とりわけ、フォーマット、アナリティクス、広告の改善に重点が置かれています。以下に、これらの分野について主な点を記載します。  
 

フォーマット


この四半期には、e コマース、エンゲージメント、デベロッパー ツールに特に注力します。この 3 つの分野すべてで、6 月末までに大きな機能を完成させる予定です。  
 
現在、amp-bindオリジン トライアルとして利用できます。これは、AMP のインタラクティブ性を向上させる柔軟なイベント バインディング システムで、この四半期の後半に正式リリースされる予定です。amp-bind に追加された最新機能は、amp-list の src パラメータにバインドする機能です。これによって、並べ替え、フィルター、ページ切り替え、任意のサーバーからの検索結果の取得といった操作を再読み込みやページのナビゲーションなしにインプレースで行うなど、さまざまな機能が実現できるようになります。さらに、クライアントサイドでの並べ替えとフィルター操作をサポートするメソッドを実装しています。この機能と、現在進行中である 2 つの機能(非同期フォーム検証フォーム入力のオートコンプリート)を合わせれば、AMP で強力な e コマースページをはるかに簡単に作成できるようになります。  
 
また、AMP で豊かで魅力的なユーザー エクスペリエンスを提供するための作業も続けています。まず、AMP で美しいイメージのサポートを強化するために、amp-image-lightbox の改善に再び取り組んでいます。これによって、amp-carousel と連携した迫力あるライトボックスを簡単に実装して体験してもらえるようになります。次に、スクロール時のバウンド動作の改善も続けています。ここでは少しアプローチを変えており、スクロール時のバウンド アニメーション用の柔軟なフレームワークを公開する方向としています。これが完成すると、この汎用ソリューションを視差スクロール状況依存で表示されるヘッダーにも利用できるようになります。  
 
最後に、さまざまな業種のデベロッパーが見栄えのよい AMP を短時間で作成できるように、AMP Start の新しいテンプレートをいくつか作成しています。また、サイトのテンプレートをカスタマイズしやすくするために AMP Start 設定ツールを開発し、コードを直接編集しなくても AMP Start ページを簡単に設定できるようにしました。  
 

アナリティクス


いくつかの最近の改修によって、AMP 広告のサポート要件を中心に amp-analytics 機能が拡張されています。他の可視性トリガー パラメータとともに指定できる waitFor プロパティの導入によって、要素の可視性トラッキングにおける柔軟性が向上しています。また、可視性データの報告タイミングを指定できる機能(仮に「reportWhen」と呼ばれています)のサポートを追加する予定です。これは、情報(ページ ライフサイクル全体で蓄積され、1 度だけ報告されるデータ)をまとめる際に便利です。  
 
ページを参照する状況に応じてクライアント ID を変えるメカニズムは、すでに導入されています。これは、まもなくリリースされる Google アナリティクスの変更点に関するお知らせにも含まれていましたが、サイトオーナーのドメインから提供される AMP ページと非 AMP ページをまたいでユーザー数を正しくカウントできるようにするものです。これは、別のアナリティクス ベンダーでも同様に有効になります。  
 
この四半期の残りの期間は、amp-analytics を利用したデータ収集を行う AMP 拡張機能の準備に重点的に取り組む予定です。さらに、アナリティクスのヒット リクエストの一部として送信する前に AMP 変数を変換するフィルターのサポートも追加する予定です。  
 

広告


この四半期では、収益を向上させるためのオプションの追加など、既存の広告の UX 動作の改善を重点的に実施します。また、引き続き DoubleClick for Publishers による AMP 広告提供機能のサポートにも注力します。  
 
現在のデフォルト広告プレースホルダは、私たちが意図していたよりも目立つというフィードバックを受け、いくつかの別のオプションを試した上で、以前のバージョンよりも目立たないものを決定しました。これは近日中にリリースされる予定です。また、広告プレースホルダが表示される時間を最小限にとどめるために、AMP ページで表示される非 AMP 広告の読み込みを最適化する方法も模索しています。  
 
サイトオーナーの収益を向上させるための作業も恒常的に行っています。来月には、IMA SDK を使ってブラウザのビルトイン動画プレーヤーでプリロール広告を表示する amp-ima-video コンポーネントをリリースする予定です。ユーザーがしばらくページに滞在している場合、広告を別の広告に差し替えると効果的でしょう。現在、最低限のインターバル後に自動リフレッシュされる広告の準備を進めています。これによって、サイトオーナーは同じページ数で多くの広告から収益を得られるようになります。  
 
DoubleClick チームは、1 つのページ内での広告リクエストの対応付け作業を行っています。この機能を使うと、競合他社の広告の除外やブロックをリクエストする広告を配信できるようになります。さらに、DoubleClick フォーマット チームは、カスタム クリエイティブ タイプを使った AMP クリエイティブの配信機能の準備も進めています。これは、7 月までにリリースされる予定です。  
 
* * *

作業を行ったり、フィードバックを寄せてくださっている AMP 開発コミュニティの方々に感謝いたします。いつものように、問題や機能リクエストがありましたら遠慮なくお知らせください。  
 
Reviewed by Yoshifumi Yamaguchi - Developer Relations Team

この記事は Google Play プロダクト マネージャー、Rahim Nathwani による Android Developers Blog の記事 "Request a professional app translation from the Google Play Console and reach new users" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

アプリやゲームのローカライズは、世界中の潜在的なユーザーを獲得するための重要なステップで、ダウンロード数の増加やユーザー エクスペリエンスの向上に役立ちます。
Google Play では、これをサポートするアプリの翻訳サービスが提供されています。これはプロの翻訳者によるサービスで、アプリのユーザー インターフェース文字列、Play ストアのテキスト、アプリ内製品、ユニバーサル アプリ キャンペーン広告などを翻訳できます。アプリの翻訳サービスは Google Play Console から直接利用でき、簡単に始めることができます。
  • 翻訳ベンダーを選択します。
  • Play Console の中だけで、注文、受領、翻訳の適用を行えます。
  • 支払いは、Google ウォレットを使ってオンラインで行います。
  • 以前に注文したことがある場合、その翻訳は再利用されるので同じ翻訳に対して 2 重に支払いを行う必要はありません。新版を頻繁にリリースする方にはうれしい機能です。
アプリ翻訳サービスを使って 1 つのアプリとストアの説明を 1 つの言語に翻訳する場合、一般的な価格は約 5500円(50 米ドル)になります(費用は、テキストの量と言語によって異なります)。
ぜひ、アプリ翻訳サービスの詳細をご覧いただき、実際にお試しください。

このブログ投稿はどのくらい役に立ちましたか?
Posted by Hak Matsuda - Developer Relations Team

この記事は エンジニアリング部門副社長、Dave Burke による Android Developers Blog の記事 "Android O APIs are final, get your apps ready!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

先月の Google I/O では、Android O の 2 回目のデベロッパー プレビューについて発表し、合わせて、主なテーマ、Fluid ExperiencesVitals や、モジュール ベースの仕組みを目指す Project Treble の取り組みについてもお知らせしました。これは、最初のベータ版品質のリリース候補として重要なマイルストーンともなるものです。基調講演や分科会では、Android の新機能を詳しく取り上げました。ライブストリーミングを見逃した方は、こちらからセッションのアーカイブをすべてご覧いただけます。

すでに Android O API の最終版が搭載された Developer Preview 3 と最新のシステム イメージ、そして Android Studio のアップデートがリリースされています。これらによって、今夏の終わり頃に予定されている正式リリースの準備を行うことができます。7 月には再度プレビューのアップデートが行われ、ほぼ最終となるシステム イメージが提供される予定です。

すでに Android ベータ版プログラムに端末を登録している方には、間もなく Developer Preview 3 へのアップデートが配信されるはずです。

アプリを Android O に対応させる


正式リリースが来月以降に迫る中で、最初の重要なステップとなるのが、現在のアプリを Android O に対応させることです。これによって、新しいプラットフォームがユーザーの端末に配信される際に、シームレスな移行が可能になります。

まだアプリの互換性をテストしていない方でも、始めるのは簡単です。サポートされている端末を Android ベータ版に登録すると、最新のアップデートが OTA で配信され、Google Play から現在のアプリをインストールしてテストできるようになります。アプリは適切な見栄えで動作し、Android O の動作の変更点に問題なく対応できるはずです。特に、バックグラウンドでの制限と、ネットワークセキュリティ識別子に関する変更点に注意してください。

必要なアップデートを終えた後は、アプリのプラットフォームのターゲットを変更せず、すぐに対応したバージョンのアプリを Google Play で公開することをおすすめします。

Android O の機能と API を使用してアプリを強化する


Android O の機能でアプリを強化すると、エンゲージメントを高め、新しいインタラクションを提供することができます。ユーザーはより多くのことを制御できるようになり、セキュリティも強固になります。さらに、アプリのパフォーマンスも向上させることができます。

通知チャンネル通知ドットは、新しいコンテンツを通知してユーザーをアプリに呼び戻す新たな方法です。ピクチャ イン ピクチャは、別のタスクの実行中でもアプリを画面に表示したままにできる機能です。自動入力は、フォームデータの入力を簡単にしつつ、安全にデータを保管します。さらに、アダプティブ アイコンXML フォント リソースダウンロード可能フォント絵文字TextView の自動サイズ変更AAudio APIや、その他の機能もご確認ください。また、バックグラウンド実行の制限など、O アプリでの重要なシステム動作の変更点のサポートも計画するとよいでしょう。

新機能や API、それをアプリに組み込む方法については、O Developer Preview サイトにアクセスしてご確認ください。
ユーザーが別のタスクを実行しながらアプリを使えるようにするピクチャ イン ピクチャモード(上)。ユーザーのアプリ利用率を向上させ、直接アプリの中心機能にジャンプできるようにする通知ドット(下)。

Developer Preview 3 を使ってみる


本日のプレビュー アップデートには、最新版の Android O プラットフォームが含まれています。これは API レベル 26 の最終版で、たくさんのバグの修正や最適化が行われています。最終となる API 26 SDK は、Android Studio の SDK Manager からダウンロードできます。また、Android Support Library 26.0.0 ベータ 2 は Google の Maven レポジトリからダウンロードできます。

これらには、公式な Android O API に対応したアプリを開発およびテストするために必要な機能がすべて備わっています。最終版の SDK をインストールすると、プロジェクトの compileSdkVersion を API 26 にアップデートして公式 Android O API でコンパイルできるようになります。また、アプリの targetSdkVersion を API 26 に更新して、オプトインし、Android O に固有の動作の変更についてアプリをテストすることをおすすめします。Android O でビルドするための環境設定の詳しい手順については、移行ガイドをご覧ください。

API は 2 回目のデベロッパー プレビューから変更されています。既存のコードで Android O プレビュー API を利用している方は、差分レポートでコードに影響が出る可能性がある場所を確認してください。

Android O 向けに開発を行っている方は、Canary チャンネルから利用できる最新版の Android Studio 3.0 にアップデートすることをおすすめします。Android Studio 3.0 では、アプリのパフォーマンス プロファイリング ツールの改善、Kotlin プログラミング言語のサポート、Gradle ビルドの最適化などの新機能だけでなく、Instant Apps ビルドのサポート、アダプティブ アイコン ウィザードXML フォントダウンロード可能フォントのサポートも利用できます。
Android Studio 3.0 には、アプリの XML フォント リソースをプレビューできる Android O の機能を使って開発するためのツールが含まれています。

こういった機能を使う予定がない方は、Android O 安定版チャンネルの Android Studio 2.3.3 を使って開発することもできます。ただし、アダプティブ アイコン、ダウンロード可能フォント、XML フォント関連の作業を行うツールは、Android Studio 2.3.3 では利用できない点に注意してください。

Google Play のアルファ版、ベータ版、または製品版チャンネルにアプリを公開する


API は最終版なので、API 26 を使用しコンパイル(オプションで、API 26 をターゲットに指定することもできます)した APK のアップデートを、Google Play のアルファ版、ベータ版、または製品版チャンネルに公開できます。プレビュー期間中に O をターゲットにしたアプリを公開すると、Android ベータ版プログラムに登録しているユーザーなどを対象に、既存の端末での互換性のテストや API 26 を実行している端末へのアップデートの送信を行うことができます。

アップデートしたアプリが Android O だけでなく旧バージョンでも動作することを確かめるには、通常、Google Play のベータ版テスト機能を使って、デベロッパー プレビューのユーザーを含む少人数のユーザーから初期段階でのフィードバックを入手し、その後、アップデートしたアプリを段階的にユーザー全員にリリースします。

プレビュー アップデートの入手方法


Developer Preview 3 は、近日中に Android ベータ版プログラムを通して世界中のデベロッパーやアーリー アダプターに配信されます。まだ登録していない方は、android.com/beta にアクセスして、対象の Android スマートフォンまたはタブレットをオプトインしてください。通常どおり、このアップデートを手動でダウンロードして端末に書き込むこともできます。O Developer Preview は、Pixel、Pixel XL、Pixel C、Nexus 5X、Nexus 6P、Nexus Player で利用いただけます。

いつもフィードバックにご協力いただき、ありがとうございます。今夏の終わり頃に予定している正式リリースに向けて努力してまいりますので、今後もフィードバックやリクエストをお寄せください。Android O に対応した皆さんのアプリを楽しみにしています。



Posted by Yuichi Araki - Developer Relations Team

この記事は デベロッパー プログラム エンジニア、Nicolas Garnier による The Firebase Blog の記事 "Content Moderation with Cloud Functions for Firebase" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。  
 
掲示板、ソーシャル ネットワーク、ブログ プラットフォームなど、ユーザーがコンテンツを投稿できるアプリでは、常に不適切なコンテンツが公開されるリスクが存在します。本投稿では、Firebase アプリで Cloud Functions を使って自動的に不適切なコンテンツを無害化する方法について紹介します。  
 
コンテンツを無害化するもっとも一般的な戦略は、「受動的な無害化」です。通常は、ユーザーに不適切なコンテンツを報告してもらうためのリンクを追加し、ルールに従っていないコンテンツを手動で確認して削除します。しかし、受動的な無害化を補完するために自動的な無害化の仕組みを追加すると、不適切なコンテンツが公開されることを防ぐ仕組みをさらに強化できます。Cloud Functions を使うと、Firebase アプリでユーザーが公開した不適切なテキストや写真などのコンテンツに対する自動チェックを簡単に行うことができます。どのくらい簡単にできるのか、早速見てみましょう。  
 
ここでは、2 種類の自動コンテンツ無害化を実行します。  
 
テキストの無害化では、汚い言葉やシャウト(「SHOUTING!!!」など、すべて大文字の言葉)をすべて削除します。  

画像の無害化では、アダルト コンテンツや暴力的なコンテンツにぼかしをかけます。  

本質的に、自動的な無害化は信頼できる環境(つまり、クライアント以外)で行う必要があります。そのため、Cloud Functions for Firebase はまさに適任です。2 種類の無害化を行うには、2 つの機能が必要です。  
 

テキストの無害化


テキストの無害化では、Firebase Realtime Database をトリガーとして moderator という名前の機能を実行します。ユーザーが Realtime Database に新しくコメントや投稿を追加すると、bad-words npm パッケージを使って汚い言葉を削除する機能が実行されます。続いて、capitalize-sentence npm パッケージを使って、大文字が多用されているメッセージ(通常は、ユーザーによるシャウト)を小文字に修正します。最後のステップでは、無害化したメッセージを Realtime Database に書き戻します。  
 
実例として、ユーザーがチャットルームに書き込んだメッセージのリストを表す単純なデータ構造を考えてみましょう。メッセージは 1 つの text 属性を含むオブジェクトで、/messages リストに格納されています。  
 
/functions-project-12345
   /messages
       /key-123456
           text: "This is my first message!"
       /key-123457
           text: "IN THIS MESSAGE I AM SHOUTING!!!"

新しく追加されたメッセージに対して機能が実行されると、2 つの属性が追加されます。無害化機能によってメッセージが検証された際に true になる sanitized 属性と、メッセージで不適切なコンテンツが検知され、修正された場合に true になる moderated 属性です。たとえば、上の 2 つのメッセージに対して無害化機能が実行されると、次のようになります。  
/functions-project-12345
   /messages
       /key-123456
           text: "This is my first message!",
           sanitized: true,
           moderated: false
       /key-123457
           text: "In this message I am shouting."
           sanitized: true,
           moderated: true

 
moderator 機能は、メッセージが書き込まれるたびに実行されます。これは、functions.database().path('/messages/{messageId}').onWrite(...) トリガールールを使用して設定します。ここでは、メッセージを無害化し、そのメッセージを Realtime Database に書き戻しています。
exports.moderator = functions.database.ref('/messages/{messageId}')
  .onWrite(event => {
      const message = event.data.val();

      if (message && !message.sanitized) {
        // Retrieved the message values.
        console.log('Retrieved message content: ', message);

        // Run moderation checks on on the message and moderate if needed.
        const moderatedMessage = moderateMessage(message.text);

        // Update the Firebase DB with checked message.
        console.log('Message has been moderated. Saving to DB: ', moderatedMessage);
        return event.data.adminRef.update({
          text: moderatedMessage,
          sanitized: true,
          moderated: message.text !== moderatedMessage
        });
      }
    });

 
moderateMessage 関数では、まずユーザーがシャウトしているかどうかをチェックし、シャウトしている場合は文を小文字に変換します。次に、bad-words パッケージ フィルタを使って汚い言葉をすべて削除します。  
 
function moderateMessage(message) {
  // Re-capitalize if the user is Shouting.
  if (isShouting(message)) {
    console.log('User is shouting. Fixing sentence case...');
    message = stopShouting(message);
  }

  // Moderate if the user uses SwearWords.
  if (containsSwearwords(message)) {
    console.log('User is swearing. moderating...');
    message = moderateSwearwords(message);
  }

  return message;
}

// Returns true if the string contains swearwords.
function containsSwearwords(message) {
  return message !== badWordsFilter.clean(message);
}

// Hide all swearwords. e.g: Crap => ****.
function moderateSwearwords(message) {
  return badWordsFilter.clean(message);
}

// Detect if the current message is shouting. i.e. there are too many Uppercase
// characters or exclamation points.
function isShouting(message) {
  return message.replace(/[^A-Z]/g, '').length > message.length / 2 || message.replace(/[^!]/g, '').length >= 3;
}

// Correctly capitalize the string as a sentence (e.g. uppercase after dots)
// and remove exclamation points.
function stopShouting(message) {
  return capitalizeSentence(message.toLowerCase()).replace(/!+/g, '.');
}

注: bad-words パッケージは badwords-list パッケージの汚い言葉のリストを使いますが、これには 400 個の言葉しか含まれていません。ご存じのように、ユーザーの想像力は無制限なので、これはすべてを網羅したリストではありません。そのため、汚い言葉の辞書を拡張する必要があるかもしれません。  
 

画像の無害化


画像の無害化を行うために、Cloud Storage にファイルがアップロードされるたびに実行される blurOffensiveImages 機能を設定します。これは、functions.cloud.storage().onChange(...) トリガールールを使用して設定します。ここでは、Google Cloud Vision API を使って画像に暴力的なコンテンツやアダルト コンテンツが含まれているかをチェックしています。Cloud Vision API には、画像内の不適切なコンテンツを検知することに特化した機能があります。画像が不適切だった場合は、画像にぼかしをかけます。  
exports.blurOffensiveImages = functions.storage.object().onChange(event => {
  const object = event.data;
  const file = gcs.bucket(object.bucket).file(object.name);

  // Exit if this is a move or deletion event.
  if (object.resourceState === 'not_exists') {
    return console.log('This is a deletion event.');
  }

  // Check the image content using the Cloud Vision API.
  return vision.detectSafeSearch(file).then(data => {
    const safeSearch = data[0];
    console.log('SafeSearch results on image', safeSearch);

    if (safeSearch.adult || safeSearch.violence) {
      return blurImage(object.name, object.bucket, object.metadata);
    }
  });
});

Cloud Storage に格納されている画像をぼかすには、まず Cloud Functions インスタンスのローカルに画像をダウンロードします。そして、ImageMagick で画像をぼかし、Cloud Storage に再アップロードします。ImageMagick はすべてのインスタンスにデフォルトでインストールされています。  
 
function blurImage(filePath, bucketName, metadata) {
 const filePathSplit = filePath.split('/');
 filePathSplit.pop();
 const fileDir = filePathSplit.join('/');
 const tempLocalDir = `${LOCAL_TMP_FOLDER}${fileDir}`;
 const tempLocalFile = `${LOCAL_TMP_FOLDER}${filePath}`;
 const bucket = gcs.bucket(bucketName);

 // Create the temp directory where the storage file will be downloaded.
 return mkdirp(tempLocalDir).then(() => {
   console.log('Temporary directory has been created', tempLocalDir);
   // Download file from bucket.
   return bucket.file(filePath).download({
     destination: tempLocalFile
   });
 }).then(() => {
   console.log('The file has been downloaded to', tempLocalFile);
   // Blur the image using ImageMagick.
   return exec(`convert ${tempLocalFile} -channel RGBA -blur 0x8 ${tempLocalFile}`);
 }).then(() => {
   console.log('Blurred image created at', tempLocalFile);
   // Uploading the Blurred image.
   return bucket.upload(tempLocalFile, {
     destination: filePath,
     metadata: {metadata: metadata} // Keeping custom metadata.
   });
 }).then(() => {
   console.log('Blurred image uploaded to Storage at', filePath);
 });
}

 
Cloud Functions for Firebase は、ユーザーの操作に応答して自動的に無害化ルールを適用できる優れたツールです。テキストの無害化画像の無害化のサンプルはオープンソースです。自由にご覧ください。  
 
Posted by Khanh LeViet - Developer Relations Team

この記事は App Maker プロダクト マネージャー、Geva Rechav による Google Apps Developer Blog の記事 "Google I/O session recap: how to build custom apps with App Maker" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

業務や顧客、社員に特有のワークフローやプロセスはあらゆる企業に存在します。多くの場合、そのようなワークフローやプロセスは、マクロやスクリプトとともに大きなスプレッドシートやその場しのぎのデータベースに保存されています。しかし、そういったスプレッドシートやデータベースがカスタムの業務アプリになったらどうでしょう。便利な UI やユーザー個別の役割が提供され、データの入力エラーを最小限にとどめつつ生産性を向上させるアプリがあったらどうなるでしょうか。

今年の Google I/O では、企業が App Maker を使うべき理由を説明しました。App Maker は、コードをほとんど書く必要がないアプリ開発ツールです。これを使うと、企業は G Suite でカスタムアプリをすばやく構築できます。以下をご確認ください。


さらに詳しく知りたい方のために、以下にプレゼンテーションの概要をまとめました。

App Maker で企業の「アプリのギャップ」を埋める 

多くの企業が、実際に「アプリのギャップ」に悩まされています。この点は、主要な SaaS 製品を導入している企業も変わりありません。テリトリープランニングやアセットのパフォーマンス トラッキングなど、標準 CRM では対応できない極端な例を考えてみるとよいでしょう。

Google も、同じギャップを経験しました。数年前、人材募集担当者は月に何千名も面接して、複数の面接官が長いフィードバックを作成していました。あまりに膨大な量だったため、採用委員会が候補者を精査してタイムリーな判断を行うのは難しく、対応が遅れていました。この問題を解決するため、IT チームが自社インフラのさまざまな要素を活用してアプリを作成することにしました。

やがて、他の部門からもアプリを作ってほしいという要望が寄せられたため、App Maker を作成しました。そして、Google 社内の数個のアプリから始まったこの仕組みは、数千名が利用する 400 近い内部アプリに進化したのです。さらに、こういったアプリの大半は、IT 部門以外のエンジニアでない人々が構築したものです。

現在では、App Maker を使って、ソフトウェア エンジニアや専門家以外のデベロッパー(ビジネス アナリスト、コーディング愛好家など)がアプリをすばやく構築して導入し、ワークフローの課題を解消できるようになりました。

機能の仕組み 

App Maker を使うと、簡単にデータ バインディングを行い、ドラッグ アンド ドロップで UI を設計できるため、数か月どころか数日でアプリを構築できます。アプリには、さまざまなデータソース、Google のサービスや API を組み込むことができるので、以前の資産も活用できます。作成したすべてのアプリは G Suite のドライブの一部になるので、データがドメインの外に出ることはありません。

App Maker アプリは、次の 3 段階で作成できます。
  1. データモデルを定義します。これは、既存の Google スプレッドシートを App Maker にインポートする、Google Cloud SQL インスタンスに接続する、フィールドごとにカスタム オブジェクトを手動で定義する、のいずれかの方法で行います。
  2. UI を構築します。それには、データ入力フォームなどのビルド済みのコンポーネントやレポート テンプレートを追加します。イベント トリガーやアプリのフローも簡単に作成できます。 
  3. オプションで、クライアント UI やアプリサーバーで実行されるオープンソースの HTML、CSS、JavaScript を追加し、そのままでは提供されないカスタム機能を実装します。
現在、App Maker はアーリー アダプター プログラム(EAP)となっており、G Suite Business のユーザー全員が利用できます。使ってみたい方は、こちらから申請してください

考えられる活用事例 

どのようなものを作ることができるのか、よくわからないという方もいらっしゃるでしょう。以下に、ユーザーの事例に基づいたいくつかの着手点を紹介します。
  • 比較的多くのユーザーが定期的にアップデートする大きなスプレッドシートがある場合: 通常、スプレッドシートにはその元となるワークフローがあります。App Maker アプリを使うと、よりよい UI を提供できるので、ワークフローの視覚化、アクションの確認、データ入力エラーの削減などが可能です。 
  • カレンダーや Gmail で一括操作を何度も行っている場合: たとえば、社員が部署を異動する場合、App Maker アプリを作成して数クリックで必要な一括操作を行うことができます。 
  • すでに Apps Script や BigQuery を利用している場合: この場合、すでにワークフローのカスタマイズに投資を行っていることになります。App Maker は、カスタムアプリ開発を加速させます。
G Suite の App Maker で独自のアプリを作成しましょう。早速 EAP にお申し込みください



Posted by Eiji Kitamura - Developer Relations Team

「LIFULL HOME’S(ライフルホームズ)」は、パソコン、モバイル、アプリに対応した、日本の不動産販売・賃貸情報を扱う検索プラットフォームです。ユーザー エクスペリエンスの改善に向けて、LIFULL チームがどのようにユーザー重視のアプローチを行ったか、また、レビューやアプリ内 A/B テストなどの機能をどのように活用して Google Play でのエンゲージメントを向上させたか、ご覧ください。





Posted by Takuo Suzuki - Developer Relations Team

この記事は NaCl、PNaCl、WebAssembly ソフトウェア エンジニア、Brad Nelson による Chromium Blog の記事 "Goodbye PNaCl, Hello WebAssembly!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

かつて、ウェブでネイティブ コードを実行するにはブラウザのプラグインが必要でした。しかし、2013 年に PNaCl サンドボックスが導入され、安全、ポータブル、かつ高性能なアプリをプラグインなしで構築する手段が提供されました。これは Chrome ではうまく動作しましたが、すべてのブラウザでシームレスに動作するソリューションではありませんでした。

その後ウェブ コミュニティでは、コードを高速に実行するクロスブラウザのソリューションとして、WebAssembly への注目が高まってきました。WebAssembly は、既存の標準ベースのウェブ プラットフォーム API を活用して、ブラウザ内動画編集ツールを作成したり、Unity ゲームを高フレームレートで実行するために必要なスピードを提供します。WebAssembly を使ったアプリケーションは、すでにさまざまなブラウザで実行されています。Chrome と Firefox はネイティブで WebAssembly をサポートしており、Edge と Safari でもプレビュー版の WebAssembly がサポートされています。

クロスブラウザ サポートにおけるこの勢いを考え、私たちはネイティブ コード関連の作業については、今後 WebAssembly に集中する予定です。Chrome アプリと拡張機能の内部を除き、PNaCl のサポートはすべて 2018 年の第 1 四半期に終了します。WebAssembly 関連のエコシステムは、新しいものも既存のものも含め、高性能ウェブアプリに適したものになります。また、PNaCl の利用率が低いことも、サポート終了の十分な理由となっています。

このテクノロジーの移行は、難易度の高い作業になる可能性があることは認識しています。これを簡単にするために、既存の PNaCl 実装をウェブ プラットフォームに移行する際の推奨事項の一覧と、WebAssembly の機能ロードマップを作成しました。移行プロセスを始めるにあたって、難しい問題が発生した場合は、ぜひお知らせください。できる限りスムーズな移行ができるよう、サポートいたします。

WebAssembly の導入によって、ウェブ プラットフォームにはどんなブラウザでも実行できる高速かつ迫力のある新世代ウェブアプリの基盤ができました。皆さんが次に作成するアプリを楽しみにしています。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は デベロッパー アドボケート、Laurence Moroney による The Firebase Blog の記事 "Firebase Phone Auth" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。  

初めてリリースされたときから、Firebase はさまざまな認証スキームを提供しています。  
ユーザーが基本情報を提供するメールとパスワード認証(iOSAndroidウェブ)を使ったアプリを構築することができます。この場合、Firebase はこれらを ID として利用し、ログインを管理します。また、フェデレーション ID を使うこともできます。この場合、ユーザーがアプリにユーザー登録するのではなく、GoogleFacebookTwitterGitHub などのサードパーティが提供する認証情報を使ってログインします。加えて、登録していないユーザーにセキュリティ ルールを提供する匿名認証を使うこともできます。  
多くのデベロッパーからリクエストされていた認証タイプに、電話番号を使ったログイン機能があります。それを受けて、本日は Firebase Auth で電話番号認証がサポートされたことをお知らせします。現在 Digits SDK を使って電話番号認証を行っている方は、Firebase Auth への移行の詳細が記載されているこちらのお知らせをご覧ください。  
Firebase 電話番号認証は、次のように動作します。  
 
 

ログイン画面


ここに示すのは、Google と Facebook によるフェデレーション ID、メールとパスワードによる基本認証に加えて、電話番号認証をサポートするアプリの例です。  
このアプリは、FirebaseUI を使って構築されています。そのため、本記事で説明するフローの多くは、FirebaseUI を組み込むことによって自動的に実装されます。  
画面の下部を見ればわかるように、電話番号でログインする [Sign in with Phone] オプションが表示されています。  
では、ユーザーがこのボタンをタップするとどうなるかを詳しく見てみましょう。  
 

ログインフロー

ユーザーは、[Sign in with Phone] ボタンを初めてタップした後、端末の電話番号を入力します。[Verify] を押すと番号が Firebase に送信され、6 桁のコードが生成されて SMS 経由で端末に送られます。  

ユーザーが正しいコードを入力すると、Firebase がそれを確認し、ユーザーとして認識します。以降のセッションでは、ログイン状態が維持されます。  
ログイン済みのユーザーは、Firebase コンソールで次のように表示されます。  

Firebase Authentication の詳細は、Firebase デベロッパー サイトをご覧ください。  
Firebase UI は、ログインやユーザー登録のフローのベスト プラクティスをすばやく簡単に実装できるオープンソース ライブラリです。現在、Firebase UI の電話番号認証は iOSウェブで利用できます。近日中に Android にも対応する予定です。  
Firebase と Firebase Authentication の拡大と開発は今後も続いていきます。皆さんのフィードバックをお待ちしていますので、ぜひ firebase.google.com/support までご連絡ください。  

Reviewed by Khanh LeViet - Developer Relations Team

この記事は プロダクト マネージャー、Ali Abdelhadi による The Firebase Blog の記事 "Introducing Firebase Performance Monitoring" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

優れたモバイルアプリを作成する上で、エンドユーザーの視点によるパフォーマンスの監視は大きな難題です。これは、アプリのコードのパフォーマンスにも、ネットワークの応答性や信頼性についても言えることです。ユーザーの離脱や否定的なレビューを避けるためには、どこに改善の必要があるかを把握できなければなりません。逆に、Google Play の星 5 つのレビューの 60% では、スピード、デザイン、ユーザビリティについて言及されています。

ネイティブ アプリのパフォーマンスの監視における最大の難題は、状況を把握することです。ユーザーの体感速度が遅くなったり、アニメーションがスムーズに動作しないことがわかるだけでは不十分です。そのような現象がアプリのどこで発生しているかを把握する必要があります。また、さまざまな国や端末、OS レベルなどによって現象がどのように異なるかを把握することも重要です。

これこそが、iOS と Android 向けの Firebase Performance Monitoring が開発された理由です。このツールは、本番環境でのパフォーマンス指標を取得して計測する SDK と、SDK が取得したデータを分析できるコンソールを提供します。



Firebase Performance Monitoring には、トレースとネットワーク アクティビティ監視という 2 つの主な機能があります。まずは、トレースについて説明しましょう。トレース機能を使うと、アプリの特定の操作にかかる時間を把握したり、「カウンター」API を使って操作にカスタムの指標を追加できます。たとえば、イメージの読み込みが始まってから画面でイメージのレンダリングが終わるまでの時間をトレースしたり、カウンターを使ってイメージ読み込み時のキャッシュのヒット回数やミス回数をトラッキングすることができます。

アプリの起動は SDK をインストールするだけで自動でトレースできるので、アプリのコールド スタートにかかる時間を監視できます。


Firebase Performance が提供するもう 1 つの機能は、ネットワーク アクティビティの監視です。アプリが実行する HTTP/S リクエストは、送信されてから応答を受信するまで、自動的に監視されます。URL のパターンごとに、応答時間、ペイロード サイズ、成功率を確認できます。


リクエストに失敗した場合は、原因となったレスポンス コードについて 400 番台と 500 番台の内訳を確認できます。



収集されるトレースおよびネットワーク関連の全指標では、国、端末、アプリのバージョン、OS のバージョンの内訳を確認できます。これによって問題の原因を絞り込めるので、修正が簡単になります。



現在、Firebase Performance Monitoring はベータ版として公開されています。詳しくはこちらのドキュメントまたは I/O セッションをご覧ください。



Reviewed by Khanh LeViet - Developer Relations Team