Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

今後、Google 広告スクリプトで search リクエストと、Google Ads Query Language を使う report リクエストを対象に、デフォルトのレポート バージョンの更新方法を変更します。これまでは、最大数か月にわたって新しいバージョンが利用できない期間がありましたが、今後は新しいレポート機能がリリースされたまもなくアクセスできるようになります。この変更は、v201809 の AdWords API ベースのレポートを使い続けている方には影響しません。

今後は最新バージョンの Google Ads API のリリースから 2 週間以内に、デフォルトのレポート バージョンを更新し、最新バージョンが使えるようになります。たとえば、v8 がリリースされるとその 2 週間以内に、GAQL を使う report 呼び出しと、すべての search 呼び出しについて、デフォルトのレポート バージョンを更新し、v8 を使うようにします。

スクリプトに悪影響が生じる可能性があり特定のバージョンに固定したい場合、手動でバージョンを指定することもできます。これはデフォルトよりも優先されるので、次のバージョンの準備が整うまでアップデートを延期できます。延期する場合、Google Ads API のバージョンが提供終了になるタイミングに注意してください。新しいバージョンにアップデートしないと、スクリプトが失敗します。API のバージョンを設定する例を次に示します。

report の場合 :
var report = AdsApp.report(query, {apiVersion: 'v7'});
search の場合 :
var results = AdsApp.search(query, {apiVersion: 'v7'});
このリリースの一環として、デフォルト(現在は v5)を v7 にアップデートします。v6 と v7 で行われたレポートのアップグレードの全一覧は、Google Ads API リリースノート ページで確認できます。

質問がある方は、サポートを得られるようにフォーラムに投稿してください。

- Google 広告スクリプト チーム、Mike Cloonan
Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

2021 年 7 月 20 日までに、上記の変更によってコードやアプリケーションに問題が起こらないようにしてください。

その後、フィールド Recommendation.keyword_match_type_recommendation やタイプ KeywordMatchTypeRecommendation を参照しているコードがある場合は、できるだけ早いうちに削除してください。これらは非推奨となり、今後のバージョンで削除されます。

ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは [email protected] にご連絡ください。


Google Ads API チーム)

主な機能は以下のとおりです。

  • クロスアカウント入札戦略を追加しました。これにより、管理者が所有する入札戦略をクライアント アカウントにアタッチできるようになります。さらに、新しいリソース AccessibleBiddingStrategy も追加されます。これは、現在の顧客がアクセスできるすべての入札戦略の読み取り専用のビューを提供します(顧客が所有するポートフォリオ戦略と、顧客に共有されているクロスアカウント入札戦略を含みます)。
  • CustomerClient.applied_labels を使って管理者アカウントが管理するラベルを取得できるようになります。
  • CallOnlyAdInfoCallAdInfo に置き換えられ、この広告タイプの機能が強化されます。たとえば、CallAdInfo.path1 フィールドや CallAdInfo.path2 フィールドを使って、広告に表示される URL の後ろにテキストを追加する機能が含まれます。
  • 販売したアイテムの追加情報と合わせてコンバージョンをアップロードできるように、ClickConversioncart_data がサポートされます。
  • TransactionAttributeUserAttribute にいくつかの項目が追加され、UserDataServiceOfflineUserDataJobService を使ってユーザーデータをアップロードする際に、販売したアイテムやユーザーの購入履歴の詳細情報を関連付けられるようになります。
  • スマート キャンペーンのサポートを追加しました。これにより、スマート キャンペーン タイプの作成、監視、管理が可能になります。スマート キャンペーンは高度に自動化された効率的なキャンペーンで、最低限の継続的な管理で最大限の成果を出せるように設計されています。詳しくは、開発ガイドをご覧ください。

さらに詳しく知りたい方へ

以下のリソースが役立ちます。 ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。



Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

Share on Twitter Share on Facebook

この記事は Google Maps Platform チームによる Google Cloud Blog の記事 "Improved accessibility in the Maps JavaScript API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Google Maps Platform JavaScript チームが行っている、Maps JavaScript API のユーザー補助機能の改善に重点を置いた最近の機能変更をいくつかご紹介します。当チームは 2020 年に、すぐに使えるユーザー補助機能と、デベロッパーがユーザー補助エクスペリエンスを作成するために利用できるフックを増やす新たな取り組みを開始しました。

Google は、Maps JavaScript の UI と API のユーザー補助機能の改善に継続的に取り組んでおり、まだまだできることがあると認識しております。お客様にはこうした新機能を毎週の最新バージョンでお試しいただき、変更点に関するフィードバックの提供新しいバグの報告にご協力いただけますと幸いです。それらを参考に、最も影響の大きい領域に優先順位を付けさせていただきます。みなさんのウェブサイトに影響を与える既存のバグに +1 し、新しいバグレポートをご提出ください。ユーザー補助機能は、さまざまなユーザーやコミュニティに多様な影響を与える複雑なトピックです。お客様のフィードバックは、Google Maps Platform の機能を誰でも利用できるようにする取り組みの指針として活用されます。


2020 年最初の機能変更は、特に根本的な問題に焦点を絞っていました。タブの順序の最適化、キーボードの有効化とスクリーン リーダーの対話的な機能、スクリーン リーダーに関する説明の追加、各マップコントロールのカラー コントラストの強調を図りました。機能変更の前後での違いをご覧ください。


タブの順序は標準的ではなく、スペースバーでボタンがアクティブになりませんでした。

タブの順序は左から右、上から下に並べられ、スペースバーでボタンがアクティブになり選択でき、色のコントラストが上がって視認性が増しています。

また、デベロッパーがマップに追加するマーカーについても詳しく調べました。マーカーは、img ロールか、インタラクティブな場合(クリック イベント リスナーが登録されている場合など)は button ロールにデフォルト設定されました。インタラクティブなマーカーもキーボードで矢印キーを繰り返し押して操作できます。デベロッパーがマーカーにタイトルを指定すると、このテキストはユーザー補助ラベルにも使用されます。こうした改善は最適化されていないマーカーにのみ適用されm。詳細については、新しい「マーカーを利用可能にする(Make a marker accessible)」ガイドと「マーカーのユーザー補助機能(Marker Accessibility)」コードサンプルをご覧ください。


ユーザー補助のラベルとロールが適用された、キーボードの矢印キーで操作できるマーカー。

マップで特に使用される UI コンポーネントは InfoWindow です。改善点の中で特筆すべきなのは、InfoWindow が開いたり閉じたりした際に、InfoWindow から出入りするタブ選択を自動的に管理する機能です。デフォルトではこれまで多くのユーザーから寄せられたフィードバックを元に、open() が自動的にフォーカスを移動するかどうかを決定します。デベロッパーの皆様は、InfoWindow を開く際に shouldFocus オプションを使用して明示的に選択することをおすすめします。

const infoWindow = new google.maps.InfoWindow({

    content: "Hello Accessibility!",

});

infoWindow.open({

    anchor: marker,

    shouldFocus: true,

});

 

InfoWindow を開くと、最初のフォーカス可能な要素(デベロッパー指定のコンテンツか、組み込みの閉じるボタン)が開きます。閉じると、フォーカスが復元されます。

Maps JavaScript API は 2005 年以降、パンやズームなどのマップ操作のキーボード コントロールをサポートしていますが、ユーザーがキーボード ショートカットを見つけるのは困難でした。今月、UI に新しいキーボード ショートカットのダイアログを追加し、使用できるショートカットをユーザーが見つけやすくしました。こうしたキーボード ショートカットは、マップ自体にフォーカスがあるときに有効になります。

マップ上の「キーボード ショートカット」ボタンをアクティブにすると、使用可能なショートカットのダイアログが表示されます。

今後導入予定の機能


ウェブでは毎日、世界中の何百万人ものユーザーが Maps JavaScript API によって提供される Google basemap を利用しています。Google の目標は、万人向けのマップを作成できるようにするために必要なツールをデベロッパーに提供することです。


Google は、Maps JavaScript の UI と API のユーザー補助機能の改善に継続的に取り組んでおり、まだまだできることがあると認識しております。今回の変更は、その手始めにすぎません。これらの新機能をぜひお試しになり、フィードバックをご提供ください。また、リリースノート ページでは、Maps JavaScript API の新しい機能の追加状況をご確認いただけます。さらに、既存のバグを検索してウェブサイトに影響するバグに +1 する、これまでに修正されたバグを確認する、フィードバックや発生した問題を記載した新しいバグレポートを送信するなどの方法で、Google Maps Platform の改善にご協力いただけますと幸いです。


Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。


Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer 
Share on Twitter Share on Facebook

このブログシリーズでは、新しく改善されたインタラクティブ Google 広告クエリビルダー ツールの構築過程についてお伝えしています。シリーズのパート 6 では、クエリのフィールドの選択と選択解除の方法について説明しました。パート 7 では、ユーザーの選択に基づいてクエリを検証する方法について説明します。

背景


パート 5 ではフィールドの同時選択可否について説明し、パート 6 でも選択可否について少し触れました。それでも、クエリビルダーを使って無効な Google Ads Query Language(GAQL)文字列を作ることは可能です。それを対処するため、パート 6SelectionService に Observable をサブスクライブする ValidationService を作成します。Observable がトリガーされるたびに、一連の検証テストを実行してエラー メッセージの一覧を生成します。ValidationService には、別の Observable を作成し、検証が行われるたびに通知を受けるようにします。こうすることで、クエリにエラーが含まれている場合、ユーザーに通知できるようになります。ユーザーが何も選択していない場合は、アプリケーションが初期状態であることを示しているため、エラーは表示されません。





以下を確認する検証テストをします。
  • SELECT 句にフィールドが含まれている
  • コア日付の選択が有効である
  • click_view の日付フィルタが有効である
  • change_eventchange_status の日付フィルタが有効である
  • change_eventchange_status の LIMIT が有効である

SELECT 句にフィールドが含まれている

有効な GAQL クエリには、SELECT 句に少なくとも 1 つの有効なフィールドが含まれている必要があります。選択されたのが SELECT 以外の句で、SELECT 句が空だった場合、エラーを生成します。

コア日付の選択が有効である

クエリのいずれかの句にコア日付セグメント(segments.datesegments.weeksegments.monthsegments.quartersegments.year)がある場合、WHERE 句のフィルタ条件を組み合わせたときに、少なくとも 1 日の日付範囲を表すようなコア日付セグメントの有限な日付範囲ができなければなりません。クエリにコア日付セグメントが存在しない場合、エラーは生成されません。


それ以外の場合は、WHERE 句のコア日付セグメントによるフィルタを組み合わせたときに、有限の範囲になることを確認します。言い換えるなら、WHERE segments.date > ‘2021-01-01’ などのフィルタが 1 つしかない場合は、日付の範囲が閉じられていないので、失敗します。この場合はエラーが生成されます。ただし、WHERE segments.date > ‘2021-01-01’ AND segments.date < ‘2021-02-01’WHERE segments.date = ‘2021-01-01’WHERE segments.date DURING LAST_7_DAYS といったフィルタは有効です。この 3 つの例には開始日と終了日があるので、エラーは生成されません。


最後に、コア日付セグメントによるフィルタが有限の範囲になる場合、それを組み合わせたときに少なくとも 1 日の範囲になることをチェックします。たとえば、フィルタ条件 WHERE segments.date = ‘2021-01-01’ AND segments.date BETWEEN ‘2021-02-01’ AND ‘2021-03-01’ を含むクエリは、両方のフィルタ条件を満たす日付が存在しないので、失敗します。この場合はエラーが生成されます。ただし、フィルタ条件 WHERE segments.date BETWEEN ‘2021-01-01’ AND ‘2021-01-31’ AND segments.date >= ‘2021-01-15’ AND segments.date < ‘2021-03-01’ は有効です。すべてのフィルタ条件を満たす日付範囲は ‘2021-01-15’ - ‘2021-01-31’ なので、エラーは生成されません。

click_view の日付フィルタが有効である

click_view が FROM 句のメインリソースである場合、他の選択内容にかかわらず、WHERE 句に直近 90 日間の 1 日を指定する日付フィルタが存在しなければなりません。

change_eventchange_status の日付フィルタが有効である

FROM 句のリソースが change_event または change_status である場合、「コア日付の選択が有効である」ルールと同じように、WHERE 句のフィルタ条件で有効な日付範囲が指定されている必要があります。ただし、この条件はクエリに日付フィールドがあるかどうか関係なく適用されます。さらに、コア日付セグメントではこのフィルタ条件は生成されません。FROM 句のメインリソースが change_event または change_status である場合、利用できるコア日付セグメントはないからです(パート 4 参照)。FROM 句のリソースが change_event である場合、Google Ads API サーバーで change_event.change_date_time フィールドのフィルタに対して日付の評価が行われます。FROM 句のリソースが change_status である場合、Google Ads API サーバーで change_status.last_change_date_time フィールドに対して日付の評価が行われます。

change_eventchange_status の LIMIT が有効である

FROM 句のリソースが change_event または change_status である場合、クエリに有効な LIMIT、すなわち正の整数が含まれている必要があります。

まとめ

これで、GAQL クエリのエラーをチェックする ValidationService ができました。ValidationService では、GAQL 文字列が変更されるたびにこのチェックをし、エラーリストを生成して、Observable からイベントを発行します。エラーリストが空でない場合、この Observable をサブスクライブするコンポーネントでエラーアイコンを表示します。この投稿では、GAQL クエリ検証のさまざまな側面について説明しました。


Google Ads API での GAQL クエリの構築について理解が深まれば幸いです。ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは [email protected] にご連絡ください。




Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team
Share on Twitter Share on Facebook

どこから始めればよいですか
新しいデベロッパー トークンを申請したデベロッパーは、Google Ads API のみにアクセスできます。新しい API ユーザーに役立つリソースは、次のとおりです。 既存の AdWords API デベロッパーは、アップグレードを開始する必要があります。以下に、着手点となるリソースを紹介します。

どこでサポートを受けることができますか

アップグレードの際に質問などございましたら、フォーラムまたは [email protected] までご連絡ください。




Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

Share on Twitter Share on Facebook

現在、change_status レポートにいくつかの新しいリソースタイプを追加する作業を懸命に進めています。今後、shared_setasset などを改善する予定です。これらのタイプは今後のバージョンの Google Ads API で完全にサポートされますが、そのために現在行っているインフラストラクチャの変更作業によって、既存のバージョンにも多少の影響が発生します。

新しいリソースタイプのサポートが追加されると、すべてのバージョンの API で新しい行を取得できるようになります。その際に、すでにリリースされているバージョンでは、resource_typeUNKNOWN として返却されます。具体的には、これまで CAMPAIGN などの既知の resource_type が返されていた行で、UNKNOWN リソースタイプが返される場合があります。これが発生するのは、これまで CAMPAIGN の変更と報告されていた変更が、実際には CAMPAIGN_ASSET の変更だった場合などです。今後のバージョンの API は CAMPAIGN_ASSET リソースタイプを認識しますが、既存のバージョンは認識しないので、UNKNOWN を使うしかありません。この行には、新しい resource_name も関連付けられ、アセットの ID が含まれるようになります。

その行の新しいリソース名には、変更の種類を表す識別子が含まれます。最新の識別子のリストは、ステータス変更ガイドをご覧ください。これを調べる必要があるのは、UNKNOWN リソースタイプが含まれる行だけです。これにより、今後の API バージョンでそのリソースタイプが完全にサポートされたときに返されるリソースタイプがわかります。

change_status レポートには、新しいリソースタイプを複数追加する予定なので、さまざまな新しいリソースタイプに対して UNKNOWN タイプが出現する可能性があります。これが表示されるのは、今後のリリースによって change_status レポートで新しいリソースタイプがサポートされるためなので、ご安心ください。

質問がある方は、サポートを受けることができるようにフォーラムに投稿してください。



Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team
Share on Twitter Share on Facebook




この Chrome の試験運用機能では、サイトの RSS を最新に保つことで、ユーザーに最新のコンテンツを提供できます。この機能の試験運用を終えて Chrome で幅広く展開するかを評価する際には、ウェブ パブリッシャー向けに詳しいガイドをお伝えしたいと思います。

Chrome を通してユーザーとウェブ パブリッシャーの深い交流をサポートしたいので、パブリッシャー、ブロガー、クリエイター、そしてオープンウェブの住民(皆さんのことです!)からの試験運用に関するフィードバックをお待ちしています。Twitter の @WebCreators や、[email protected] へのメールを通じて、最新情報を入手したり質問したりすることもできます。


Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook



これにより、PWA ユースケースのユーザー エクスペリエンスが改善され、これまでよりも OS のアプリに近くなります。次に例を示します。

ファイル ハンドリングのオリジン トライアルは 92 で始まり、2021 年 8 月末ごろまで続く予定です。この機能の詳細については、ウェブ アプリケーションをファイル ハンドラにするをご覧ください。このリリースのその他のオリジン トライアルについては、以下のオリジン トライアルをご覧ください。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルをしています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。

新しいオリジン トライアル

Shared Element Transitions

Shared Element Transitions を使うと、シングルページ アプリケーション(SPA)とマルチページ アプリケーション(MPA)の両方でシンプルな画面遷移を実現できます。デベロッパーはユーザー エージェントが提供する遷移効果の中から選ぶだけでよいので、最低限の作業でページの視覚的な洗練度が向上します。シングルページ アプリでは、この機能がない場合、アニメーションと DOM 操作を慎重に連動させなければ望む効果を実現できないので、画面遷移効果を実現するのは困難です。マルチページ アプリでは、ページが制御できるのは自身のビューだけなので、画面遷移効果を実現できない場合がほとんどです。今回のオリジン トライアルは、SPA のユースケースのみに対応します。

今回のリリースに追加されたその他の機能

アプリのショートカット機能の変更

ほとんどの Android ランチャーで、以前は 4 つまでアプリのショートカット機能を登録できましたが、今後は 3 つだけになります。サイト設定へのショートカットが Android ランチャーのアプリアイコンに追加され、アプリのショートカット機能のスロットが 1 つ減ることになります。詳しくは、アプリのショートカット機能でものごとをすばやく行うをご覧ください。

CSS

@font-face の size-adjust ディスクリプタ

@font-face に size-adjust ディスクリプタが追加され、特定のフォント フェイスで CSS の font-size や em などの派生指標に影響を与えることなく、グリフのサイズのスケーリングができるようになりました。CSS の font-size は、フォントを描画するボックスのスケール ファクタと見なされます。ボックス内のグリフのサイズはフォントによって異なりますが、size-adjust を使うと、さまざまな種類のフォントでサイズを合わせることができます。そのため、このディスクリプタを使ってフォールバック フォントとプライマリ ウェブフォントのマッチアップをすることで、Cumulative Layout Shift(ページのレイアウトのずれ)を減らすことができます。

命令的な slot 割り当て動作

命令的な slot 割り当てを使うと、マークアップで slot 属性を必要とせず、ノードからスロットへの割り当てをすることができます。これにより、入力条件や種類に応じた動的なスロット割り当て動作が可能になります。この機能は、もともとは Chrome 86 に導入されました。今回のリリースで API が調整され、他のブラウザとの相互運用性が向上しています。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.2 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。

Intl.DateTimeFormat に dayPeriod を追加

Intl.DateTimeFormat() メソッドに dayPeriod オプション(ECMA402 2021 の一部)が追加され、呼び出し元が時間を「7 in the morning」、「11 in the morning」、「12 noon」、「1 in the afternoon」、「6 in the evening」、「10 at night」などの形式(または中国語で「清晨 7 時」、「上午 11 時」、「中午 12 時」、「下午 1 時」、「下午 6 時」、「晚上 10 時」)を指定できるようになりました。

これによって Intl.DateTimeFormat() が拡張され、C++ や Java で ICU や ICU4J を呼び出して実行できる既存の操作と同じことを実現できるようになります。この機能がなければ、デベロッパーはサーバーで四半期をフォーマットするか、時間帯のパターンと時間の対応表をサーバーからクライアントに送信することによって、このタスクをする必要があります。

Array、String、TypedArray の相対インデックス メソッド

Array.prototypeString.prototypeTypedArray のプロトタイプに at() という新しいメソッドを追加し、負のインデックスによる相対インデックスを利用できるようにします。次に例を示します。

let arr = [1,2,3,4];
arr.at(-1); // Returns 4

ICU LocaleMatcher を使用する Intl BestFitMatcher

ICU LocaleMatcher に BestFitMatcher 抽象オペレーションが実装され、ロケールデータとの照合が向上します。

デスクトップ プラットフォームの SharedArrayBuffer がクロスオリジン分離環境のみに制限

デスクトップ プラットフォームの SharedArrayBuffer がクロスオリジン分離環境のみに制限されます。これにより、動作が最新の Android や Firefox と一致します。クロスオリジン分離されたページでは、オプトインされていないクロスオリジン リソースの読み込みとクロスオリジンのウィンドウとの通信がブロックされます。そのため、ページは安全な環境と見なされます。SharedArrayBuffer を使えるのは、クロスオリジン分離をオプトインしたページのみになります。導入されるオプションの詳細については、Android 版の Chrome 88 とデスクトップ版の Chrome 92 における SharedArrayBuffer のアップデートをご覧ください。

Media Session API: ビデオ会議のアクション

Media Session API に "togglemicrophone""togglecamera""hangup" アクションが追加されました。これにより、ビデオ会議サイトのデベロッパーが、ブラウザのインターフェースでこれらのアクションを扱えるようになります。たとえば、ユーザーがビデオ通話をピクチャー イン ピクチャー ウィンドウにした場合、ミュート / ミュート解除、カメラのオン / オフ、通話終了のボタンをブラウザに表示できます。ユーザーがこれらをクリックすると、ウェブサイトは Media Session API を通して処理できます。詳細については、最新記事の該当セクションを参照するか、デモをお試しください。

Resource Timing に Tainted Origin フラグを適用

Chrome は、フェッチしたリソースが Timing Allow Origin チェックを通過するかどうかを計算する際に、Tainted Origin フラグを考慮するようになります。Timing Allow Origin チェックは、ページで使われるリソースに関する詳細タイミング情報を受け取れるかどうかを判断するために Resource Timing で使用されます。オリジンをまたぐ複数のリダイレクトがある場合、Tainted Origin フラグがこのチェックに影響します。その場合、ヘッダーを '*' にする必要があります。つまり、具体的なオリジンであってはいけません。

リソースが(リダイレクトによって)2 つのオリジンにまたがる場合、このチェックを通過するために Timing-Allow-Origin: * を使用する必要があります。たとえば、オリジン A のページがオリジン B のリソースをフェッチし、オリジン B のリソースからオリジン C のリソースにリダイレクトされる場合、Tainted Origin フラグが設定され、最終的なリソースが詳細なタイミング情報を受け取るには、Timing-Allow-Origin: * が必要になります。

Web Bluetooth のメーカーデータ フィルタ

Web Bluetooth API で、ベンダー ID やプロダクト ID などのメーカーデータによるフィルタが可能になります。これまでも、近くにある Bluetooth デバイスで、アドバタイズされる名前やサービスに一致するものをブラウザのピッカーで選択することはできました。しかし、近くにある Bluetooth デバイスを、アドバタイズされるメーカー固有のデータで絞り込むことはできませんでした。メーカーのデータは、options.filters の新しいプロパティで指定し、Bluetooth.requestDevice() に渡します。詳細については、JavaScript で Bluetooth デバイスと通信するを参照するか、デモをお試しください。

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

Standardized Payment Method Identifier の支払いハンドラ

この機能は、ウェブベースの支払いハンドラが URL のない paymentrequest イベントを受け取れるようにするものですが、 "basic-card""tokenized-card" などの Standardized Payment Method Identifier が削除されました


Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

このブログシリーズでは、新しく改善されたインタラクティブ Google 広告クエリビルダー ツールの構築過程についてお伝えしています。シリーズのパート 5 では、フィールドが選択可能かどうかを判断する方法について説明しました。パート 6 では、SelectionService を使って Google Ads Query Language(GAQL)文字列にフィールドを追加する方法について説明します。

GAQL 文字列の状態

どのフィールドが選択されているかを追跡するには、GAQL 文字列の状態を追跡する必要があります。これは、以下のインターフェース定義で表される selectedFields というインスタンス変数で行います。


interface SelectedFields {
select: string[];
where: Array<{field: string, context: string}>;
orderBy: Array<{field: string, context?: string}>;
limit?: string;
params?: string;
}



select フィールドは、フィールド名の配列を保持します。where フィールドは、オブジェクトの配列を保持します。それぞれのオブジェクトには、field 名と context 文字列が含まれています。context は、フィールドに適用するフィルタ条件(つまり、演算子とオペランド)です。たとえば、WHERE 句にフィルタ条件 ad_group.id = 1234567890 を追加した場合、field は ad_group.id、context は = 1234567890 になります。同様に、orderBy フィールドも field 名と省略可能な context 文字列を含む配列を保持します。context は、ASC または DESC でソート順を示しますが、省略も可能です(デフォルトは ASC)。limit フィールドは LIMIT の整数を文字列で表現したもので、省略可能です。最後の params フィールドは PARAMETERS 句の文字列値を表します。これも省略可能です。現在のところ、この句で利用できる選択肢は 1 つだけなので、配列にする必要はありません、

フィールドの選択

ユーザーのクエリの状態を追跡するデータ構造が完成したので、任意の句のフィールドを選択するメソッドを実装できるようになります。


selectField(field: string, clause: string, context?: string): void {
...
}

clause が SELECT の場合、指定されたフィールドを selectedFieldsselect 配列に追加します。ユーザーが SELECT 句にフィールドを追加する場合、context は指定しません。


clause が WHERE である場合は、context 文字列として演算子とオペランドを含むフィルタ条件を提供する必要があるので、3 つのパラメータのすべてが必要です。ユーザーがチェックボックスをクリックして WHERE 句にフィールドを追加すると、ダイアログが開き、まずは演算子を、続いてオペランドを指定します。ユーザーが選択できる演算子のリストは、選択するフィールドの data_type に応じてあらかじめ指定されています。また、オペランドを入力するためにユーザーに表示するコンポーネントは、選択した演算子に応じて変わります。ユーザーがフィルタ条件を追加すると、演算子とオペランドを結合して 1 つの文字列にすることで context 文字列を作成します。





clause が ORDER BY である場合、context は省略可能です。ユーザーが ORDER BY 句のフィールドを選択すると、context なしで selectField を呼び出し、context がない状態で selectedFieldsorderBy 配列にフィールドを追加します。また、フィールド名の下にラジオボタンを表示し、ASC か DESC でソート順を指定できるようにしています。ユーザーがいずれかの項目をクリックすると、orderBy 配列のそれぞれのフィールドのエントリを更新し、context にソート順を追加します。




clause が LIMIT か PARAMETERS である場合は、field パラメータで指定された文字列を使って selectedFieldslimit エントリまたは params エントリを更新します。limit は正の整数である必要があるので、関連する UI コンポーネントで検証をします。現在利用できるパラメータは include_drafts だけで、このデフォルト値は false です。そのため、PARAMETERS の UI コンポーネントでは、'include_drafts=true' という選択肢が 1 つだけあるチェックボックスをユーザーに表示します。ユーザーがチェックボックスをクリックすると、field パラメータとして文字列 include_drafts=trueselectField に渡します。

SELECT での存在

フィールドを選択するロジックは単純ですが、パート 5 ではあえて触れなかった選択可否に関するルールが 2 つあります。WHERE 句または ORDER BY 句にフィールドを挿入する場合、そのフィールドは SELECT 句に存在しなければなりません。

ルール 1: 「コア日付セグメント」(segments.datesegments.weeksegments.monthsegments.quartersegments.year)を除き、すべてのセグメントセグメント化リソースは、SELECT 句に存在しなければ WHERE 句に挿入することはできません。

ルール 2: すべてのセグメントセグメント化リソース指標属性付きリソースのフィールドは、SELECT 句に存在しなければ ORDER BY 句に挿入することはできません。言い換えるなら、最初に SELECT 句に挿入することなく ORDER BY 句に配置できるのは、FROM 句のリソースのフィールドだけです。

このような場合は、ユーザーが 1 回の手順で、指定された句だけでなく SELECT 句にもフィールドを追加できるダイアログを表示します。





フィールドの選択解除

フィールドを選択解除できるように、SelectionServicedeselectField というメソッドを実装します。


deselectField(field: string, clause: string): void {

}




フィールドの選択解除は、フィールドの選択と同様です。念のため、最初にそのフィールドが選択されているかどうかをチェックします。続いて、clause が SELECT、WHERE、ORDER BY のいずれかである場合は、selectedFields の対応する配列のエントリから選択解除されたフィールドを削除します。前述のルールにより、WHERE や ORDER BY に追加される前に SELECT に存在していなければならないフィールドが SELECT から削除されると、そのフィールドが SELECT から 1 回の操作で自動的に削除されます。句が LIMIT や PARAMETERS である場合は、selectedFields のそれぞれのエントリを undefined に更新します。

出力の更新

selectedFields 変数、selectField メソッド、deselectField メソッドがそろったので、クエリ文字列の状態を追跡できます。アプリケーション全体で変化を追跡できるように、SelectionServiceObservable を作成し、selectFielddeselectField が呼び出されるたびに next を呼び出します。これにより、GAQL クエリの状態を認識したいコンポーネントで Observable をサブスクライブできるようになります。

まとめ

SelectionService を更新し、フィールドの選択と選択解除ができるようになりました。今回の投稿では、以下について説明しました。
  • GAQL クエリと句の構造
  • フィールドの選択可否に関する追加の詳細情報
  • Angular での Observable の利用
Google Ads API での GAOL クエリの構築について理解が深まれば幸いです。ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは [email protected] にご連絡ください。




Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team
Share on Twitter Share on Facebook

このプラットフォームでは、ブログ投稿や、簡単な操作で使えるオープンソース ツールを紹介しています。コンテンツは、プロダクトの種類によって、Machine Learning、Flutter、Firebase、Angular、Cloud、Android に分類されています。分類は今後さらに追加される予定です。

Developer Library ならではの特徴は、取り上げられているすべてのサイトが正確さと妥当性の観点で Google のエキスパート チームによって細かく検証されている点です。つまり、このサイトにコンテンツが掲載されているということは、Google が承認したということです。

このサイトのコンテンツの幅広さをお見せするため、公開されているコンテンツや作成したデベロッパーの動画インタビューの一部を以下に紹介します。

Developer Library の更なる成長のために、皆さんにご協力いただける方法が 2 つあります。

1 つ目として、Developer Library で公開したい優れたコンテンツをお持ちの方は、こちらからレビューの申請をしてください。

2 つ目として、フィードバックも歓迎しています。Developer Library サイトに追加や変更の希望がある方は、こちらの簡単なフィードバック フォームに入力するか、GitHub で Issue を送信してください。

皆さんの作品を楽しみにしています。


Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook


Google は 多くの女性のエンジニアが勉強会やイベントでスピーカーとして活躍できるためのプログラム「Women Developer Academy」 を 7 月 17 日(土)より開催します。

Women Developer Academy は、技術勉強会やイベントで活躍する女性スピーカーを育成するためのプログラムで、オンライン ワークショップを通じて、登壇・講演を向上させるスキルやリソースを提供します。

本プログラムでは、ワークショップを通じて、プレゼンテーションスキルを向上させ、自信とネットワークを構築しようとしている IT 専門家(ソフトウェア エンジニア、データ サイエンティスト、開発者など)に向けてこの 3 週間プログラムはデザインされています。またいくつかのトピックに焦点を当てた週次ワークショップ(詳細は以下)が開催されます。新しいスキルを習得するだけでなく、似たような悩みを抱える他の女性デベロッパーに出会い、つながり、コミュニティ ネットワークを通じて、登壇機会を見つけることができます。(多くの女性が登壇枠に出ていない理由は、技術的なスキルが不足しているからではありません!)

Google は Women Developer Academy を通じて、技術勉強会やイベントの登壇者の多様性を支援していきたいと考えています。

みなさまからの応募をお待ちしております。


プログラム内容

Week 1 - July 17 (1 週目のセッションは韓国地域の参加者と一緒に英語で行われます)
  • Session 1 : WDA プログラムの紹介、WTM&GDE プログラムの概要
  • Session 2 : Workshop: 適切なテーマの選び方
  • Session 3 : 登壇する自信がない ... 自信をつけるには
Week 2 - July 24(日本語セッション)
  • Session 1 : 優れた技術プレゼンテーションの構築法
  • Session 2 : Machine Learning Workshop
Week 3 - July 31(日本語セッション)
  • Session 1 : Google Developer Expert (GDE) について
  • Session 2 : 女性 GDE 活躍事例

※ 参加者数が限られているため、なるべくすべてのセッションに参加できる方のみご登録をお願いいたします。



タイムライン

  • 6 月 21 日 : 応募登録開始
  • 7 月 10 日 : 登録締切
  • 7 月 8 日 ~ : 参加確認メールを送信
  • 7 月 17 日 ~ 31 日 : Women Developer Academy 開催

参加対象

  • 次の技術のいずれかの知識、情熱と経験がある方 : Android, Google Cloud, Tensorflow, Machine Learning, Flutter, Firebase, Kotlin, Go, Web Technologies, Google Workspace
  • 公の場で演説した経験がほとんどない方
  • イベントやセミナーで登壇したい方
  • デベロッパー コミュニティで積極的に発言し、開発者会議やミートアップにスピーカーとして参加したいという意志がある方
  • 7 月に行われるすべてのセッションに(オンライン)参加し、プログラムの要件に専念することができる方
  • 日本に在住している女性の開発者
  • 登録してくださったすべての方がプログラムに参加できるわけではありません。上記要件を満たしている方に、プログラム詳細をメールにて個別ご連絡いたします。

以下のプログラム要件にご留意ください

  • コンテンツへのアクセスのために使用できる個人 Gmail や Gsuite アカウント
  • デスクトップ コンピュータまたはラップトップ
  • ウェブカメラとマイク(内蔵または外付け)


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


Google for Startups は、成長段階にある日本の有望なスタートアップを対象に 8 週間のオンライン プログラム「Growth Academy 2021」を開催します。Google の社員や外部のアドバイザーが、メンタリング セッション、ワークショップなどを通じてスタートアップの成長を支援します。

2021 年 6 月 25 日に参加スタートアップの応募を締め切り、2021 年 9 月 よりプログラムを開始いたします。詳細なスケジュールについては プログラムのウェブサイトをご確認ください。

スタートアップの創業者が直面する課題は、顧客の拡大から、収益力の向上、組織の拡大、資金調達の準備まで多岐にわたります。本プログラムは、Google のノウハウを結集して問題の解決と成長の加速を支援し、スタートアップを次のステージへと導くサポートをします。また、同じ課題を持つスタートアップ同士が学び合えるようにネットワーキングの場を提供します。

昨年は 6 社の素晴らしいスタートアップにご参加いただきました。
2021 年も、革新的で Google のノウハウを活用して急成長を目指すスタートアップの皆さまの応募をお待ちしております。


プログラムのハイライト



Growth Academy 2021 が求めるチーム


募集概要


詳細や応募条件はウェブサイトをご参照ください。


Posted by Yuri Uehara - Marketing Manager, Google for Startups


Share on Twitter Share on Facebook

この度、Google Ads API の v7 リリースをお知らせします。V7 の機能を使うには、クライアント ライブラリとクライアントのコードをアップグレードする必要があります。更新版のクライアント ライブラリとコードサンプルは、来週公開されます。互換性を伴わない変更の詳細については、移行ガイドをご覧ください。

主な機能は以下のとおりです。
  • 以下の新しいアセットテスト アカウントで利用できます。
    • コールアウト アセット
    • 構造化スニペット アセット
    • サイトリンク アセット
  • すでに追加されているプロモーション アセットが本番環境とテスト アカウントで利用できます。
  • Google Ads API で、Apple の SKAdNetwork のレポートがサポートされます。この機能を使うと、iOS アプリで発生する SKAdNetwork コンバージョンの数や、それらのコンバージョンの SKAdNetwork コンバージョン値を広告主が照会できます。
  • キーワード プラニングが以下をサポートします。
    • アノテーション データを使った不必要なキーワードの除外
    • 検索ボリュームでのカスタム日付範囲の選択
    • 生成されたキーワード アイデアとキーワード プランのキーワードに対する指標の集計のリクエスト
  • フィルタ処理と選択を簡単にするため、ad_group_ad_label と ad_group_criterion_label ラベルを追加しました。
  • 入札戦略とキャンペーン シミュレーションの管理ができるようになります。
  • リソース超過エラーを更新し、超過した制限の種類や、その制限で許可されているリソースの数などの詳細情報を含めるようにしました。
  • 限界投資収益率キャンペーン推奨予算を利用できるようになります。キャンペーンの投資収益率が上昇することが予想される場合に、キャンペーンの予算を調整することが提案されます。
詳細やその他の機能については、リリースノートをご覧ください。


さらに詳しく知りたい方へ

以下のリソースが役立ちます。 ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。


Share on Twitter Share on Facebook

 

Sparkplug

V8 エンジンには複数のコンパイラがあり、JavaScript 実行のさまざまなフェーズでトレードオフを使い分けることができます。3 年前に、Ignition と Turbofan で構成される新しい 2 層コンパイラ システムを導入しました。Ignition はバイトコード インタプリタで、できる限り遅延なく JavaScript の実行を開始する役割を担います。Turbofan は最適化をするコンパイラで、JavaScript の実行中に収集される情報に基づいて高パフォーマンスなマシンコードを生成します。そのため、起動は Ignition のバイトコード コンパイラよりも遅くなります。Sparkplug は Ignition と Turbofan のバランスをとったもので、ネイティブのマシンコードを生成しますが、JavaScript コードの実行中に集める情報には依存しません。そのため、すぐに実行を開始できるうえに、比較的高速なコードを生成できます。この新しいエンジンに使われている技術の詳細については、V8 ブログ投稿をご覧ください。



ショート ビルトイン

ショート ビルトインは、V8 エンジンが生成したコードをメモリに格納する場所を最適化する仕組みです。V8 が JavaScript から CPU 固有のコードを生成すると、そのコードはメモリに配置されます。多くの場合、この生成されたコードはビルトイン関数を呼び出します。ビルトイン関数は、2 つの変数の加算などの基本的な演算から JavaScript 標準ライブラリの本格的な関数まで、あらゆる一般的なルーチンを処理する小さなコード スニペットです。CPU によっては、生成されたコードから離れた場所にある関数を呼び出すと、CPU 内部の最適化(分岐予測ロジックなど)が失敗する場合があります。これを防ぐには、生成されたコードと同じメモリ領域にビルトイン関数をコピーします。この変更は、新しい Apple M1 チップで特に大きな効果を発揮します。この機能によるさまざまなプラットフォームへの影響の詳細については、V8 ブログ投稿をご覧ください。
今後もさまざまなパフォーマンスの改善についてお知らせしますので、ご期待ください。

すべての統計情報の出典 : Speedometer 2.0

Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

このブログシリーズでは、新しく改善されたインタラクティブ Google 広告クエリビルダー ツールの構築過程についてお伝えしています。シリーズのパート 4 では、ResourceService を作成し、アプリ内のユーザーのロケーションによって決まる FROM 句のリソースをもとにして関連フィールドを表示する方法について説明しました。パート 5 では、Google Ads Query Language(GAQL)クエリ文字列でフィールドが選択できるかどうかを決定する方法について説明します。


背景と目的

フィールドが選択できるかどうか、すなわち、GAQL 文字列の句を追加できるかどうかは、1)FROM 句におけるメインリソースの固有のプロパティとそのフィールドのプロパティ、2)GAQL クエリ文字列の現在の状態、という 2 つによって決まります。ユーザーに選択可能なフィールドとして表示されるのは固有のプロパティだけなので、項目(1)にはパート 4 で作成した ResourceService で対処できます。

項目(2)に対処するために、SelectionService という新しいサービスを作成します。このサービスの役割は、選択可否の判断、フィールドの選択、フィールドの選択解除などです。この投稿では、フィールドの選択可否の判断について説明します。SelectionService によるフィールドの選択と選択解除の方法については、シリーズのパート 6 で説明します。

フィールドの同時利用性

すべてのフィールドを同時に利用できるとは限りません。2 つのフィールドを同時に利用できる場合、両方のフィールドが 1 つの GAQL 文字列内に共存できます。2 つのフィールドを同時に利用できない場合は、2 つのフィールドのどちらかのみを GAQL 文字列のいずれかの句に含めることができます。そのため、評価対象のフィールドとは同時に利用できないフィールドが GAQL 文字列内にある場合、評価対象のフィールドは選択不可となります。UI はそれを反映し、対応するエラー メッセージをユーザーに表示します。





実装


incompatibleSelected というインスタンス変数で、メインリソースの各フィールドについて、同時に選択できないフィールドのうち現在選択されているものを追跡します。この変数は、それぞれのフィールドを、同時に選択できないフィールドのうち現在選択されているものの一覧を表す Set にマッピングします。

interface IncompatibleSelected: {[key: string]: Set<string>}


この incompatibleSelected を初期化して、ResourceService で求めたリソースのすべてのフィールドがマップのキーになるように、また各エントリの値が空の Set になるようにします。

フィールドが選択されると、incompatibleSelected の Set(選択されたフィールドと同時に選択できないフィールドの集合)に、選択されたフィールドを追加します。たとえば、FROM 句のリソースが ad_group であるとします。segments.ad_destination_type は、metrics.absolute_top_impression_percentagemetrics.active_view_cpm などとは同時に選択できません。次の表は、これらのフィールド間の同時選択性の関係を示しています。

フィールド 同時に選択できないフィールド
segments.ad_destination_type [metrics.absolute_top_impression_percentage, metrics.active_view_cpm, …]
metrics.absolute_top_impression_percentage [segments.ad_destination_type, …]
metrics.active_view_cpm [segments.ad_destination_type, …]
segments.ad_destination_type が選択されると、incompatibleSelected マップの metrics.absolute_top_impression_percentagemetrics.active_view_cpm のエントリに segments.ad_destination_type を追加します。

クエリのいずれかの句に segments.ad_destination_type を追加したときの incompatibleSelected フィールドの一部を抜粋すると、次のようになります。

incompatibleSelected = {

'segments.ad_destination_type': {},
'metrics.absolute_top_impression_percentage': {'segments.ad_destination_type'}
'metrics.active_view_cpm': {'segments.ad_destination_type'}
...
}


フィールドの選択を解除するたびに、最初にそのフィールドがクエリのいずれかの句に含まれているかをチェックする必要があります(詳しくはパート 6 で説明します)。含まれている場合は、incompatibleSelected を更新すべきではないからです。たとえば、segments.ad_destination_type が SELECT 句と ORDER BY 句で選択されており、ORDER BY でのみ選択解除された場合、まだ segments.ad_destination_type がクエリに含まれているので、incompatibleSelected マップを変更してはいけません。ただし、選択解除されたフィールドがどの句にも含まれていない場合は、Set(選択解除されたフィールドとは同時に選択できないフィールドの集合)からそのフィールドを削除できます。

先ほどの例で、SELECT 句から segments.ad_destination_type を削除すると、このフィールドはクエリに存在しなくなります。そのため、incompatibleSelected マップの metrics.absolute_top_impression_percentagemetrics.active_view_cpm のエントリからこのフィールドを削除します。この時点で、incompatibleSelected マップのすべてのエントリは空の Set となります。


このデータ構造があれば、フィールド名をパラメータとして受け取る isSelectable というメソッドを作ることができます。isSelectable は、incompatibleSelected でそのフィールドに対応する Set が空であれば true を、そうでなければ false を返します。


  isSelectable(field: string): boolean {
return this.incompatibleSelected[field]?.size === 0;
}

まとめ

以上で、フィールドが選択可能かどうかを判断する SelectionService のロジックを実装できました。ユーザーにフィールドを表示する際には、isSelectable(field) を呼び出すだけで、UI に表示するものを決めることができます。今回の投稿では、フィールドの同時選択性と、フィールドが選択できるかどうかに関する内容を説明しました。パート 6 では、このセクションの内容をもとに、フィールドの選択や選択解除が行われたときに、SelectionService で GAQL クエリ文字列の状態を追跡する方法について説明します。

Google Ads API での GAOL クエリの構築についての理解が深まれば幸いです。ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは [email protected] にご連絡ください。



Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team
Share on Twitter Share on Facebook

Share on Twitter Share on Facebook


2021 年 7 月 6 日(火)と 7 月 13 日(火)、ゲーム、アプリ業界で活躍するインフラエンジニア、サーバーアプリケーションエンジニア、テクニカルリーダーを対象に「CLOUD ONAIR 業種別 チャンネル - Google Cloud INSIDE Games & Apps」を開催します。

Google Cloud をご活用いただいているお客様が、実際に開発・運用しているからこそのリアル体験をご紹介します。


開催概要

名 称 : Google Cloud INSIDE Games & Apps: Online

会 期 : 2021 年 7 月 6 日(火)、7 月 13 日(火) 18 : 00 – 19 : 00

主 催 : グーグル・クラウド・ジャパン合同会社




プログラム

2021 年 7 月 6 日(火)

バーチャル体験とリアル体験の融合を叶える「プロジェクトセカイ」の裏側
  伊藤 寛起 氏、株式会社 Colorful Palette エンジニアリングマネージャー
  高橋 信頼 氏、株式会社 Diarkis 代表取締役CEO
  吉村 光平、Google Cloud シニア アカウント エグゼクティブ



2021 年 7 月 13 日(火)

これを見れば、まるっとわかる。Google Cloud Day: Digital '21 Recap for ゲーム業界で働くエンジニア
  川原 雄太、Google Cloud カスタマー エンジニア

2021 年 | Google Cloud 最新情報アップデートをまとめてご紹介。
  田丸 司、Google Cloud カスタマー エンジニア




詳細・参加申し込み

こちらからお申し込みください。




※ 競合他社様、パートナー企業様からのお申し込みはお断りさせていただくことがございます。
※ 報道関係者のご参加はお断りさせていただきます。
※ ビジネス向けのイベントとなっております。学生の方のお申し込みはご遠慮ください。





Share on Twitter Share on Facebook


Google I/O 2021 において、Google は傾きと回転、および WebGL Overlay View のベータ版リリースを発表しました。これにより、まったく新しい方法でマッピング エクスペリエンスの構築が可能になります。Overlay ViewMaps JavaScript API に以前から存在する機能で、マップの上に透明なレイヤをレンダリングできます。開発者は何年にもわたり、マップの上に 2 次元の描画をするため Overlay View を使用してきましたが、Overlay View ではマップの上に実質的に浮かんでいる透明なレイヤにしかレンダリングできない状態でした。


WebGL Overlay View では、ベクターの基本地図のレンダリングに使用されるのと同じ WebGL レンダリングのライフサイクルにに直接働きかけて、利用できます。これにより、初めて 2 次元と 3 次元のオブジェクトを直接マップ上に高速にレンダリングできるようになったため、従来の Maps JavaScript API では不可能であったユーザー体験が構築可能になりました。


この記事では、Maps JavaScript API の新しい WebGL による機能の簡単な概要をご紹介します。これにより、次世代のマッピング エクスペリエンスを作成するために十分な知識が得られます。


WebGL とは


WebGL は低レベルのブラウザ API で、元は Mozilla Foundation により作られたものです。この API を使用すれば、スマートフォンやコンピュータなどのクライアント デバイスの GPU のレンダリング能力や処理能力を、ウェブアプリから利用できます。ブラウザ単独では、3D 空間のオブジェクトのレンダリングといった重い処理を実行することはできませんが、WebGL を使用すれば、そのような処理に特化して設計されたクライアント側の GPU で実行できます。


WebGL について詳しくは、WebGL の設計と保守をしている Khronos Group のドキュメントをご覧ください。


要件

WebGL Overlay View を使用するには、ベクターマップが有効な Map ID が必要です。また、マップ ID を作成するときは、傾きと回転を有効にすることを強くおすすめします。これを有効にしないと、マップはデフォルトの真上からのビューに限定されます。言い換えると、マップを 3 次元的に動かすことはできません。

マップ IDベクターマップの詳しい使い方は、関連ドキュメントをご覧ください。


傾きと回転の設定

設定された傾きと回転でマップを読み込むには、マップを作成するときに「tilt」と「heading」プロパティの値を指定します。

const mapOptions = {

  mapId: "15431d2b469f209e",

  tilt: 0,

  heading: 0,

  zoom: 17,

  center: {

    lat: -33.86957547870852, 

    lng: 151.20832318199652

  }

}

const mapDiv = document.getElementById("map");

const map = new google.maps.Map(mapDiv, mapOptions);

tilt は度単位の整数または浮動小数点数で、値は 0 から 67.5 までです。0 度はデフォルトの真下に向いたビューを、67.5 は最大の傾斜角度を意味します。設定可能な tilt の最大値はズームレベルによっても異なります。

回転は heading プロパティで、0 から 360 度までの整数または浮動小数点数として設定します。0 と 360 は北の方向を意味します。

また、傾きと回転は実行時のいつでも、プログラムからマップ オブジェクトに対して「setTilt」と「setHeading」を直接呼び出して変更できます。この機能は、ユーザーの操作などのイベントに対応してマップの向きを変える場合に役立ちます。

map.setTilt(45);

map.setHeading(180);


さらに、ユーザーは Shift キーを押したまま、マウスでドラッグするか矢印キーを使用して、マップの傾きと回転を手動でコントロールできます。

傾きと回転の詳しい説明は、ドキュメントをご覧ください。


WebGL Overlay View をマップへ追加する

「google.maps.WebglOverlayView」のインスタンスを作成すると、WebGL Overlay View を Maps JavaScript API で使用できます。オーバーレイのインスタンスを作成したら、インスタンスの「setMap」を呼び出して、マップに適用します。

const webglOverlayView = new google.maps.WebglOverlayView;

webglOverlayView.setMap(map);


マップの WebGL レンダリング コンテキストにアクセスし、そこでレンダリングするオブジェクトを扱えるようにするため、WebGL Overlay View ではベクター基本地図の WebGL レンダリング コンテキストのライフサイクルにおいて 5 つの機能を提供します。

概要について簡単にご説明します。
  • 「onAdd」では、たとえばフェッチや最終的にオーバーレイに渡すための中間データ構造の作成など、前処理をします。これらの処理をすべてここで行うのは、マップのレンダリング速度が低下しないことを保証するためです。
  • 「onRemove」では、すべての中間オブジェクトを破棄します。できればより早い段階で破棄します。
  • 「onContextRestored」はマップがレンダリングされる前に呼び出され、WebGL の状態、たとえばシェーダー、GL バッファ オブジェクトなどの初期化、バインド、再初期化をします。
  • 「onDraw」では、マップの実際のレンダリングと、その関連する操作に指定された動作をします。シーンをレンダリングするための描画呼び出しは、できるだけ最小限にしてください。ここで多くの動作をすると、基本地図のレンダリングと、WebGL で行うすべての動作の速度が低下します。
  • 「onContextLost」では、既存の GL ステートに関連付けられているすべてのステートをクリーンアップします。この時点では WebGL コンテキストは破棄されているため、これらのステートは無意味になっています。
これらの操作を実装するには、ひとつの関数にこれらを設定し、WebGL のレンダリング コンテキストのライフサイクルにおいて、適切な時点で Maps JavaScript API により実行されるようにします。例 :

webglOverlayView.onDraw = (gl,

coordinateTransformer) => { //レンダリングを実行 }


WebGL Overlay View と、そのライフサイクル操作の使い方について詳しくは、ドキュメントをご覧ください。

カメラ アニメーションの作成

WebGL Overlay View のベータ版リリースには「moveCamera」を紹介しています。これは新しくい統合されたカメラ コントロール手法で、カメラの位置、傾き斜、回転、ズームを同時に設定できます。「setTilt」や「setHeading」と同様に、「moveCamera」は「Map」オブジェクトに対して直接呼び出されます。

アニメーションのループで「moveCamera」を連続的に呼び出すと、カメラの位置の間で滑らかなアニメーションを作成できます。たとえば、この例ではブラウザの「requestAnimationFrame」API を使用して、各フレームの傾き斜と回転を変化できます。

const cameraOptions = {

  tilt: 0,

  heading: 0

}

function animateCamera () {

  cameraOptions.tilt += 1;

  cameraOptions.heading += 1;

  map.moveCamera(cameraOptions);

}

requestAnimationFrame(animateCamera);


ズームや浮動小数点数のサポートも含め、これらの調整によって従来では不可能であったようなカメラのコントロールが可能になるだけでなく、高い精度でカメラ位置をコントロールできるようになります。

「moveCamera」について詳しくは、ドキュメントをご覧ください。

試してみる

WebGL による Maps JavaScript API の新しい機能は、Beta チャンネルから API を読み込んで、今すぐ試すことができます。すぐに開発を始められるよう、新しい Codelab、すべての詳細が記されたドキュメント、サンプルコード、より詳細なサンプルアプリを用意しています。また、機能ツアートラベルのデモで詳細をご確認いただけます。さらに、これらの機能の実装をお試しいただけます。


フィードバックやご質問は、Issue Tracker にお寄せください。頂いたバグレポート、新機能のリクエスト、フィードバックなどは、新しい WebGL ベースのマップ機能のテストと改善に役立てさせていただきます。

3D でのマップ構築の可能性を探求し、優れたマップの作成にお役立てください。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。


Share on Twitter Share on Facebook