Quantcast
Channel: Google Developers Japan
Viewing all 2204 articles
Browse latest View live

Inevitable ja Night イベントレポート「 IoT、AI、VRの未来を語るディスカッション03」

$
0
0
6 月 12 日に開催した「Inevitable ja Night - インターネットの次にくるもの」ではさまざまなゲストを交え、Google Cloud といったテクノロジーの進化によってこの先の世界はどう変わっていくのか、VRやARなどの領域で活躍している人材をゲストに議論しました。本記事は、「IoT、AI、VRの未来を語るディスカッション」でのソラコム玉川憲氏、ABEJA岡田陽介氏、InstaVR芳賀洋行氏とモデレーターの及川卓也氏のセッション記事の第三弾になります。

【スピーカー】
株式会社ソラコム代表取締役社長 玉川憲 氏
株式会社ABEJA代表取締役社長 CEO兼CTO 岡田陽介 氏
InstaVR株式会社代表取締役社長 芳賀洋行 氏

【モデレーター】
フリーランス Technical Advisor 及川卓也 氏

「クラウドは不安」という人の“不安”の正体は?

及川卓也氏(以下、及川):すばらしい。流れを作っていただきました。ということで、一応IoT、VR、AI、ちょっと長くかかっちゃったんですけれども、それぞれの技術をほかのお2人から聞くっていうところで考えてみました。
このIoT、AI、VRの未来で、クラウドの技術の進化とか今後の不可避な流れ、Inevitableというところを話したいんですが、これ、ちょっと2ついっぺんにしちゃおうかなと思っていて。



クラウドは、おそらく3者ともなかったら今、起業できなかった、事業を進められないところもあると思うんですけれども。あ、ちょっとこれ会場に聞いてみよう。今、自分でまだパブリッククラウドを使っていないっていう。でも手を挙げにくいか。

玉川憲氏(以下、玉川):いない。手を挙げにくいですよね。

及川:使ってる方、手を挙げてもらっていいですか?

(会場挙手)

及川:これどうですか? 野鳥の会の玉川さん。

岡田陽介氏(以下、岡田):(笑)。

玉川:そうですね、76.8パーセントぐらいが手をあげてますね(笑)。

及川:なるほど。ありがとうございます。なにかの理由があってできないとか推測できるところもあるので、そういった不安なところに対してどうアドバイスするか。クラウドを含め、今後の技術予測みたいなところでなにかお話しすることがあれば聞きたいんですけれども。
ちょっとふわっとした質問かもしれないですけど。まあ、クラウドで不安だという人にはどう言われますか? だいたい不安な要素ってあれですよね……なんなの?

玉川:いや、私が某クラウドをやっていた2010年には、本当にそういう意見が多かったんですよね。大企業の中のIT予算とかでも、パックマンモデルって言われたんですけど、「8割が保守のためで、新規に使えるのなんて2割だから、もちろんクラウドは使うんだけど、ほとんど使わないよ」という話だったんです。でも、最近だいぶ変わりましたよね。
保守に使うのをできるだけ下げて新しいことをやっていかないと、どれだけ大企業であっても生き残っていけない。それが、ここ7年ぐらいの世界の変化なのかなと思っています。
そうなったときに、現時点で日本でも、……なんていうんでしょう。SORACOMはある意味、クラウドのモバイルなんですけど、「クラウドだから使いません」はほとんど聞かなくなったと思うので。もう本当に、不可避な流れのメインストリームに乗ったのかなと思っています。

ですので今、単純にめんどくさくて手を挙げていない人もいたと思うんですけど、もし使っていない人がいたら、その……とくにGoogle Cloudを使ってみたほうがいいと思います(笑)。

どのクラウドでもいいと思うんですけど、パブリッククラウドでメガクラウドといわれるものはどれも使いやすいですし、ものすごくいいので、ぜひ使ってみていただければなと思いますね。

「ないもの」を心配しがちな日本人

及川:そうですね。ちょっとじゃあ岡田さんと芳賀さんに聞きたいんですけれども。そうは言っても、マルチクラウドをしてなくて、どこかの1社のパブリッククラウドにいってたら、可用性とか、ダウンの時間はすごい短いかもしれない。でも、ダウンしたときが心配だったりとかってあるじゃないですか。

そこらへん、自分たちがパブリッククラウドを使うときにどう考えられたか、なにか今、対処ってされているのかを聞きたいんですけれども。

芳賀洋行氏(以下、芳賀):対処ですよね? まあ「そんなもんだ」ぐらいですよね。私が始めた時ってSaaSのサービスを使ってバックエンドを組んだんですけど。始めてだいたい3ヶ月後になくなるって発表がありまして。それはそんなもんだと思って「じゃあ乗せ替えるか」みたいな。



結局、止めないで乗せ替えなきゃいけないんですけど。別にめんどくさいだけで「まあそんなもんだ」「結局スケーラビリティも上がったし、コストも安くなったから、まあいいか。いいチャンスだった」みたいな、そんなもんですね。

及川:それはサービスのシャットダウンですよね。サービス自身のダウンタイムみたいなところって心配したりはしました?

芳賀:ああ……。でも、そんなにないですよ。

及川:ないです。ないのを心配する人が、日本人では多いんですよ。

芳賀:自社で持っていたほうが危ない気しますけれどもね。ダウンタイム……ありましたっけ? でも、この間の……どこだっけあれは? どこかでS3が火災になったときはドッキリしましたけど、あれだって分散されていれば問題ないわけなんで。

及川:要するに、分散は普通にしておきましょうって話ですよね。

芳賀:そうですね。「めんどくさいからやらない」となると、それはリスクあるかもしれないですけど。きっちりやっていればいいと思います。

及川:ベストプラクティスはいっぱいあるから、それはきっちりやりましょう、という。

芳賀:そうですね。

及川:岡田さんは、なにか付け足しとかあります?

岡田:そういった意味では、1つのデータセンターに依存するのはまずいので、単純にエリア分散しましょうねというところですね。
あと、我々はよくIoT的にやってるんですけど、エッジ側のデバイスから送らせたりするんですね。なにがいいかというと、最悪ダウンしてても、そこで保留されていたりするので、落ちてもとくに問題にならない。
とくにつながらなくなっても「つながらないよ」って言うんですけど、つながるようになったらまた再度通信を開始してくれる。そういった「どういうハンドリングプロセスを取るか」という、そのエンジニアリングのプロセスでけっこう解決できるところは多いなと思ったりしますね。

コードを書く→世界に価値を提供する、のサイクルを楽しめる

及川:なるほど。わかりました。ありがとうございます。このセッション自身は、前が押したのであと14分あると私の時計では言ってるんですが。とても個人的なことで、私は10時55分の飛行機に乗らなきゃいけないというのがあるので。ちょっと早めに終わらせていただきたいんですけれども(笑)。

もう1つ、技術者の方が興味を持つと思われる質問を。基本的にはやっぱり、皆さんがエンジニアで創業者の方なので、技術というところを入れておきながら、もう少し技術から離れたところを聞きたいなと思っているんですね。

1つは、3人とも起業するのが目的じゃなかったのかなって勝手に推測してるんです。なにかやりたいってことがあり、それで起業という選択肢を取ったのかなと思うんですけれども。違うなら違うと言っていいですよ、芳賀さん(笑)。

まあ、わかんないです。そこらへんちょっと教えてほしいんです。起業の経緯というところです。どうしよう。じゃあ芳賀さんからお願いしていいですか。

芳賀:僕からですか。僕、ちょっと起業の経緯はけっこう違うというか……。

及川:知ってます。だから振りました(笑)。

芳賀:僕はどちらかというと、個人でVRアプリを作ってまして。これがけっこうウケちゃいまして。それで最初にドバイとかのお客さんから「困っちゃってる。VR作れない」って、僕のほうに依頼が来て、一時期ドバイのアプリを全部僕が作ってたんですよね。
そのあといくつかVRアプリ作ってたら、気がついたらVRの動画再生プレイヤーがGoogleさんが出している動画プレイヤーよりも一時期、ランキングが上になっちゃってですね。気がついたら、先頭集団にいまして。
「これは起業したほうがいいかな」ということで、投資家さんを回ったら「じゃあ投資します」って話が決まりまして。そこから「会社ないんだっけ?」っていう話になりました。なので、会社を作るのはプロダクトより後でしたね。

及川:それっておもしろい話で。プロダクトをそのまま成長させたいとか続けたいときに資金をもらう必要があり、資金をもらうためには法人が必要だったから、法人化するために起業しました。

芳賀:おっしゃるとおりです。

及川:なので、さっき私が話したみたいに、もともと起業がゴールなわけではなくて、プロダクトのグロースがゴールであり、そのためのステップとして起業があった、と。

芳賀:そうですね。本当にシンプルなモチベーションでした。エンジニアとして、机に座って何時間コードを書いて、世界に価値を提供してよろこんでもらえる。このサイクルを楽しめる。しかも、自分たちが好きなようにというか、それがまず楽しいですし。それに僕としてはあまりほかにやることもなかったというか、起業を止めるものはとくになかったので、大丈夫でした。

及川:いや、芳賀さんの話を聞くと、人生ね、肩の力が抜けるというか(笑)。普通にやりたいことへ突き進んで、きちっと評価されていったならばこういう結果になるみたいなところがあって。違いますか?

芳賀:そんな感じだと思います。

及川:勝手に印象づけちゃいました。

芳賀:ありがとうございます。

「売るために起業したけど、やっぱり売れないぞ」

及川:岡田さんいかがですか。どういう経緯で起業されたか。先ほど自己紹介でもちょっと言われてましたけどね。

岡田:そうですね。そういった意味だと、私はシリコンバレーへ行ったときにそういうものに出会って。日本に戻って、共同創業メンバーと何人かでディープラーニングをカタカタやってみたんですね。当時はCPUしかなかったので、「1回学習スタートしたら1週間はPCに触れません」みたいな時もあったんですけど。



そういうかたちでやったらけっこううまくいって、「ああ、すごいこれ、いいかたちでできたね」「じゃあここまでうまくできたんだから、これ売ろう」「売るためには会社あったほうがいいよね」という感じで会社作ったみたいのが経緯ですね。
ただ、これには裏話があって。当時2012年の9月に創業してるんですけど。本当にディープラーニングが売れなくて。

2012年9月にディープラーニングと言って反応する方はゼロなんですよね、基本的に。Google Japanの方でもほぼいなかったのぐらいのレベル感で、けっこう苦しかったんです。2013年、14、15、16ぐらいにだいぶ流れがきて、伸びたんですけど。

なので、我々は最初にディープラーニングがあって、「売るために起業したけど、やっぱり売れないぞ」となって。売るためにバーティカルで、小売業やって、ソリューションを出した。そして今、ようやくプラットフォーム事業も進めている。だから、かなり違和感があるんですけど。

やっぱり、そういう意味では「やりたかったことがあるので起業した」というのは、まったく同じかなと思います。

やりたい技術ありきの起業

及川:技術に惚れ込んだという感じなんですよね。なるほど。わかりました。玉川さん、いかがですか?

玉川:そうですね、私もどちらかというと、起業をしたくて起業したというよりも、もともとクラウドのビジネスをやっていて、「こういうプラットフォームビジネスってすばらしいな」と思っていたんですね。なぜかというと、それがあることでいろんな人をモチベートできて、新しいチャレンジを促すというようなプラットフォームビジネスがいいなと思っていたからです。

某クラウドの立ち上げを日本でやってたときに、2014年だったと思うんですけど、アメリカに出張してた時でした。今一緒にやってるCTOの安川(健太)と一緒に飲んでいて、そういう通信プラットフォームをクラウドの上で作れるんじゃないかと盛り上がって。
出張してたので、当時寝れなくて。時差ボケがいつも激しいので。それで仮想のリリースノートを、その夜、寝れなかったので書いたんですね。こういう通信プラットフォームを書きました。そのまま寝て、朝起きてそのプレスリリースを見ると、「これいけるんじゃないか」と思ったのがきっかけですね。なので、飲みが始まりということですね。

及川:今、プレスリリースという話が出たんですけど、Amazonさんって、プロダクトの企画ってプレスリリースから書くんですよね。

玉川:A社はそうですね。

及川:ですよね。気を遣ってますね(笑)。

(会場笑)

私、プロダクトマネージャーをやっていて、それでいろいろな会社からアドバイスしてほしいと言われると「プレスリリースから書くといいらしいぜ」と言ってるんですけども。それはそのA社さんから教えてもらいました。

目指すゴールへのより良い道としてIPOもしくは事業売却を選ぶ

ちょっと時間も限られているので、なんの話を聞こうかなと思ってるんですが。1つだけ、ここに書いてないけど、私が3人にどうしても聞きたいことがあるんですよ。もう手を挙げるだけでいいですよ。

今後の展開を、いわゆるスタートアップのイグジットを聞きたいなと思っています。ただ、みなさんがみなさん起業家を目指してるわけじゃなかったり、なまめかしい話も多いと思うので、手を挙げるだけでいいんです。

イグジットで、IPOで上場を目指してるのは当然あると思います。もう1つは事業売却があると思うんですね。

みなさんがそうかどうかは別にして、例えば1つ、Googleに買われたいというのはもしかしたらスタートアップのゴールとしてあるかもしれないですけれども、日本で買われたいなと思うような会社ってありますか? 会社名は言わなくていいですから。……手を挙げろってこれ難しいですね。みんな力ましちゃいますよね。どうでしょう?

玉川:手を挙げると語弊があるので、ちょっとひと言。



ソラコムに関して言うと、もともとそういう経緯で通信プラットフォームを提供したいと思って。しかも、「日本発でグローバル」が僕らのミッションでありパッションであるので、そういう意味でいったときに、IPOであれイグジットであれ、そのグローバルプラットフォームの実現するよりよい道を選ぶと考えています。

起業家精神を持ったテクノロジストの重要性

及川:わかりました。その次の質問にちょっと関わるんですけれども、正直、私は日本ではITがすごい強くて、エンジニアが入りたい会社がゼロとは言わないですが、あまりまだ多くなくって、だんだん増えてきているところが喜ばしいなと思ってるんですね。

なので、みなさんになってほしいなと思うので。みなさんは今後日本で、元気なスタートアップだったり、優秀なスタートアップだったら買収したいと思うことはあると思うし、あってほしいなと思います。

もしそうだとしたら、どんなスタートアップにそういった魅力を感じるかを教えてほしいなと思うんですけれども。意見がある方。

岡田:そういった意味ですと、我々の会社はけっこうめずらしくて、テクノプレナーシップというのをすごい言っています。これがなにかというと、テクノロジストとアントレプレナーの造語なんですよね。

起業家精神を持ったテクノロジスト、技術者みたいなことを我々は言ってるんですけど。この両方が重要かなと思っているんです。テクノロジストだけだと、日本で儲からない。でも、すごく技術力あるベンチャー企業ってけっこうあったりすると思いますし、逆パターンもけっこう大きいと思うんですよね。

なので、これが2つともマッチしてる会社がたぶんGoogleだったり某A社だったりすると思ってまして。そういった会社が日本から生まれるといいなと思ってたりします。そうやってテクノプレナーシップを社内で育てて、逆にそういった人たちが卒業していって、次なるスタートアップを作っていってくれることもすごいウェルカムだなと思ってます。

逆にそういったことを、今日はこの場に学生さんたちもいらしてると思うんですけど、少しでも聞いて、「なるほどな」と思って。そういった気持ちになっていただければ、すごいうれしいなとは思ってます。

やりたい技術に起業家精神が加わっただけ

及川:はい。芳賀さん、どうぞ。

芳賀:一応僕もMBAを取っているので、実際に事業を始めるとなると、本当に勝たなきゃいけないんですよね。グローバルでやっちゃうと世界中の人がいわゆる競合になるわけで。しかも、1社か2社ぐらいしか残らないという厳しい状況になります。

勝つための資源として、どうしても手に入れなきゃいけないコンポーネントがあります。それが買収でしか手に入らないといったら、それはもう選択肢がないんですよね。それがどこの会社かどこの国かはあまり大きな問題ではないとは思います。いいものを、僕たちが前に進んでちゃんとやっていくのに必要なものを、それを手に入れるというかたちにはなると思います。

及川:じゃあ、希少価値を生むぐらい、技術なり製品の魅力を高めていく。

芳賀:そうですね。もちろんそれは逆も言えることで。我々がそういうピースになったときには、そういった選択肢も出てくるんじゃないかなとは思っています。

及川:なるほど。わかりました。

玉川:私も芳賀さんと近くて。実はもうソラコム、買収はまだしてないんですけど、出資というのは行っていて。例えば、通信の中でも最近LPWAということで、Low Power Wide Area Network、省電力の広域通信のエリアが非常に注目されているんですけど。

その中の1つのテクノロジーでLoRaWANと呼ばれるテクノロジーがあります。そこに関してはM2Bという会社に出資をして、非常に高いテクノロジーを持っているので、そこと一緒になってLoRaWANの事業に展開する。

今年2月からLoRaWANの事業を始めているので、実は日本発のLoRaWANの商用化をやったんですけど。こういったようなかたちで、テクノロジーを持っている会社と一緒にやるのは非常にいいやり方だなと思っています。

及川:なるほど。やはりテクノロジーありき。あと岡田さんの話でいうと、起業家精神というところがそこに加わると、企業としても個人としても魅力があるでしょっていう話ですね。わかりました。

パッションを追いかけ続けた結果、今がある

あと4分ぐらいになってきましたので、最後、ちょっと締めのかたちで。最後に書いてあるエンジニア創業者として起業してよかったこと・苦労したことっていう質問があります。



先ほどのGoogleのAndroid、Boot CampだとかMachine Learningでみんな覚えさせてるみたいなところで。先ほど玉川さんの会社の紹介にもあったと思いますけど、やっぱりエンジニアリング的なみたいなものがあると思いますね。

なので、エンジニアの人たち、もしくはエンジニアではなかったとしても、会場の人たちに、今後のメッセージみたいなところを少し言ってほしいなと思うんですね。要は、エンジニア創業者から今日の参加者への言葉というところでまとめてもらえればと思います。どなたからいいでしょうか。じゃあ玉川さんからでいいですか?

玉川:そうですねえ、けっこう難しいテーマだと思うんですけど(笑)。
私自身、エンジニアとしてやってきて、リサーチャー、エンジニア、それからコンサルティング、エバンジェリストみたいな感じです。振り返ってみると、結局はパッションがあるところに一生懸命に力を注いでいって、VRやって、ウェアラブルやって、それでアジャイルやって、クラウドやって、1周してIoTに戻ってきたみたいな感じになり、結果的に会社を作っていることになっているので。狙ってたわけじゃないんですけど、結局はエンジニアあがりの創業者というかたちになりました。

非常に自分の人生としてはよかったかなと思っていて。connecting the dotsじゃないですけど、振り返ってみて初めてわかるんです。

僕の場合はパッションを追っかけてたらそうなったので、みなさんにぜひ自分のパッションを追っかけてほしいなと思います。

このイベントってInevitable、……そこの本の最初でも書いてあるんですけれども、テクノロジーってもう止まらないです。これはもう絶対にInevitableなので、そのテクノロジーの進化から逃げようと思ったって、エンジニアは絶対逃げられないと思うんですよね。なので、逃げるよりかは目を見開いてじっくり見て、自分のパッションがあるところを選んで使っていけばいいんじゃないかと思います。

私自身はそうしてきて、今非常にハッピーで、優れたチームメンバーに恵まれて、毎日楽しくやっております。ぜひ少しでも多くの日本のエンジニアにそういう道を選んでほしいなと思っています。

興味あるものの中から「のめり込めるもの」が見つかる

及川:ありがとうございます。岡田さん、お願いします。

岡田:私はどちらかというと、エンジニアもやりつつ、もともとデザイナーでご飯を食べてた時もあったり、いろんなことをやってきたんですね。なので、玉川さんと一緒かなと思うんですけど。その時その時にやってきたことが今、すべて糧になっているなと思ってまして。

会社をやっていると、どの部署が重要だとかあまりないと思ってるんですよね。全部重要なんですよね。なので、その重要性をちゃんと理解した上で、そこのバランスをとって経営ができているところに関しては、私はすごいよかったなと思っています。

逆に私自身が苦労してるところでいうと、首を突っ込んじゃう人なので、なるべく首を突っ込まないように、現場に任せていきたいなと思ってはいるんですけれども。

そういった面も含めて、逆に知ってるからこそメンバーを尊重できるじゃないですけど。「ここ大変だよね」と一緒に走っていけるところはすごいあるかなと思っていますね。

結論なんですけど、エンジニアの方だからこそ、エンジニアリングにもちろん興味持つのはぜんぜんいいと思うんですけど、いろんなことに興味を持っていろんなことに全力投球していく。なにか1つ「これだ!」みたいなものが見つかって。それにどんどんのめり込んでいけばすごい成功していけるのかなと、私は信じて進んでいます。

及川:ありがとうございます。じゃあ最後、芳賀さん。

芳賀:ありがとうございます。エンジニア経営者でよかったこととしては、そもそもInstaVRを作ったのは、ドバイにアプリを作るのがめんどくさくて、楽したくて会社を作ったんですよね。

実際に経営してると死ぬほどめんどくさいことがいっぱいある。めちゃくちゃ探すんですよ、エンジニアなので。人を雇うよりも「これSaaSになにかないの?」って。探すところは圧倒的な効率化につながってます。

あと、特許とか論文とかけっこうちゃんと読んじゃってるので。そうすると「そもそもここ特許取れてるから、やったって大丈夫だよね」と、事業選定とかで無駄な道をいかないとかは、エンジニアならではあるかなと思っています。

エンジニアじゃないところ、例えば経営論だったり、財務資料を読めたり、あとリーダーシップだったり。僕はY Combinatorのスタートアップスクールに1回行ったことがあるんですけど、Instagramの経営者もぜんぜんできてなくて。「いや、でもそれは訓練だよ」と、あそこのパートの人は言い切ってる。訓練しないからできないだけ。

なので、そこは恐れずに、訓練が足りてないだけだから。訓練……いわゆるコードを書いてない人と一緒で、訓練してないだけなので。そこはそんなものだと思って気にせず、起業していただければなと思っています。

及川:どうもありがとうございます。要は、やはりそれに対してパッションを持てるかというところだったり、いろんなものを経験したり。connecting dotsは、我々の会話の中でもよく出てくると思うんですけれども。どこかで長いキャリアのなかで、活かされてくることもある。

あとは、本当にひたすら必要だったら勉強していけばいい。どの年齢になっても同じだなというところなので。

テクノロジーに対しての可能性を信じている方が今日、会場に集まってると思いますので、こういった熱意ですとか、継続した勉強を続けていく。人口減少云々はありますけれども、技術でそこらへんを解決していくというような未来を考えていけたらいいかなということでまとめさせていただきます。
どうもありがとうございました。

いかがでしたでしょうか? 今後このようなテーマでの議論を定期的に開催していく予定です。


次回イベント開催のお知らせ
「Inevitable ja Night - インターネットの次にくるもの Presented by Google Cloud」
第2回 AI とビジネスに起こる不可避な流れ
日時 : 11 月 14 日 (火) 19 : 00 - 21 : 00
定員 : 200名
主催 : グーグル合同会社

Posted by Takuo Suzuki - Developer Relations Team

TensorFlow Serving 1.0

$
0
0
この記事は ソフトウェア エンジニア、Kiril Gorovoy による Google Developers Blog の記事 "TensorFlow Serving 1.0" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

TensorFlow Servingは、本番環境向けに高パフォーマンスな機械学習済みモデルを提供するシステムです。2016 年 2 月に初めてオープンソースとしてリリースされてから、TensorFlow Serving は大きく発展しています。本日(*原文公開当時)は、TensorFlow Serving 1.0 のリリースについてお知らせします。バージョン 1.0 は TensorFlow のヘッドを使ってビルドされており、今後のバージョンは TensorFlow のリリースとマイナーバージョンを合わせたものになる予定です。

このシステムの概要については、Noah Fiedel による Google I/O 2017 のセッションをご覧ください。

初めて発表された時、このプロジェクトはモデルのライフサイクルを管理し、推論リクエストに応答するコア機能を提供する一連のライブラリでした。その後、Predict APIを備えた gRPC モデルサーバーのバイナリと、Kubernetes へのデプロイ方法を説明したサンプルが導入されました。それ以降も、さまざまなユースケースへの対応や API の安定化を行い、ユーザーのニーズを満たすように機能を拡張する作業が進められています。現在、Google には、本番環境で TensorFlow Serving を使っているプロジェクトが 800 以上あります。サーバーや API は厳しいテストを経ており、堅牢で安定した高パフォーマンスな実装へと集約されています。

オープンソース コミュニティの意見を聞き、apt-get installで導入できるビルド済みのバイナリも提供しています。現在では、時間をかけてコンパイルをする必要はなく、単にインストールして実行するだけで TensorFlow Serving を使うことができます。Linux 以外のシステムにサーバー バイナリをインストールする場合は、おなじみの Docker コンテナを利用することができます。

TensorFlow Serving の今回のリリースでは、以前の SessionBundle モデル フォーマットの公式サポートが終了しています。現在、公式にサポートされているフォーマットは、TensorFlow 1.0 の一部として導入された TensorFlow のモデル フォーマットであるSavedModelとなっています。

まずは、プロジェクトのドキュメントやチュートリアルをご確認ください。TensorFlow Serving 1.0 をお楽しみください!



Reviewed by Takuo Suzuki - Developer Relations Team

最新のデベロッパー向けハンドブック アプリで、Google Play での成功に役立つ最新の情報を入手

$
0
0
この記事は Google Play Developer Marketing、Dom Elliott による Android Developers Blog の記事 "Get the updated Playbook app for news and tips to help you grow your business on Google Play" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 

このたび、デベロッパー向けハンドブック アプリを更新いたしました。この機会にハンドブック アプリを入手し、アプリ開発に役立つ機能、おすすめの方法、Google Play での成功戦略について理解を深めてください。Google Play でのアプリの開発と公開、ユーザーの獲得とエンゲージメントの向上、収益の増加に役立つ情報が満載です。ハンドブック アプリは 14 言語でご利用いただけます(English, Bahasa Indonesia, Deutsch, español (Latinoamérica), le français, português do Brasil, ภาษาไทย, tiếng Việt, Türk, русский язы́к, 한국어, 中文 (简体), 中文 (繁體)日本語)。  
ベータ版テストにご参加いただいた皆さま、貴重なフィードバックをありがとうございました(今後もご協力いただけましたら幸いです)。最新の更新では、ユーザー エクスペリエンスをシンプルにし、コンテンツを簡単に見つけられるようにしました。また、コンテンツ タイプごとに通知を自動化し(カスタマイズも可能)、常に最新の情報を手に入れられるようにしました。さらに、関心のあるトピックを設定画面で選択することで、関連性の高い投稿や動画をホーム画面に表示できるようになりました。  
 

ぜひ最新のデベロッパー向けハンドブックアプリをインストールしてください。基本的な使い方は次のとおりです。  
  • 画面の説明に沿ってセットアップを行い、お使いの Google アカウントでログインしてください。
  • ホーム画面では、最新の投稿を読むことができます。[設定] 画面で関心のあるトピックを選択すると、関連性の高いコンテンツがホーム画面に表示されます。
  • ガイドでは、Google がおすすめする方法について、[開発]、[公開]、[エンゲージメント]、[成長]、[収益] に分けて詳しく解説しています。
  • 投稿動画では、Google や業界の専門家からの最新の投稿や動画をご覧いただけます。トピックを選択して記事を絞り込むこともできます。
  • ハートのアイコンをタップしてコンテンツを保存すると、保存済みの記事としてホーム画面に表示され簡単にアクセスできます。


Posted by Hak Matsuda - Developer Relations Team

第 2 回 INEVITABLE ja night 開催のお知らせ

$
0
0

Google Cloud に代表されるクラウド技術の進化の先にある世界を、機械学習、VR / AR、IoT などの領域で活躍されているスタートアップの方々と一緒に議論するイベント「INEVITABLE ja night」。第 1 回目(2017 年 6 月開催)では、「不可避な未来 と NEXT 5 BILLION 対談」、「IoT、AI、VR の未来を語るディスカッション」をテーマに今後のテクノロジーの進化によってこの先の世界がどのように変わっていくのかを、VR や AR などの領域で活躍されている方々をゲストに議論しました。当日の様子はこちらで詳しく紹介しています。ぜひご覧ください。

さて、第 2 回目は「AI とビジネスに起こる不可避な流れ」がテーマです。機械学習 / 人工知能技術にフォーカスをあて、実際にこれらの技術を活用して新たなビジネスを展開している方々をお招きし、ご講演いただきます。

【開催概要】
イベント名 : INEVITABLE ja night - “インターネットの次にくるもの”
第 2 回 AI とビジネスに起こる不可避な流れ
日程 : 2017 年 11 月 14 日 (火) 19 : 00 - 21 : 00(開場 18:30 より)
会場 : グーグル合同会社
定員 : 200 名
参加登録 : 事前登録制(※後日、参加いただける方には参加証を送ります。)


スピーカー(予定):

國光 宏尚 氏 
株式会社 gumi 代表取締役社長

2004 年にカリフォルニアのサンタモニカカレッジを卒業後、株式会社アットムービーへ入社し、同年取締役に就任。映画やドラマのプロデュースを手掛ける一方で、さまざまなインターネット関係の新規事業を立ち上げる。2007 年 6 月、モバイルを中心としたインターネットコンテンツを提供する株式会社 gumi を創業し、代表取締役に就任(現任)。2015 年 12 月、VR 系のスタートアップを支援する 100%子会社「Tokyo VR Startups 株式会社」を設立し、代表取締役に就任(現任)。2016 年 2 月、海外 VR/AR 市場への投資を目的としたベンチャーキャピタルファンド「VR FUND,L.P.」に出資し、ジェネラルパートナーとして運営に参画。


樽石 将人 氏
Retty 株式会社 CTO

レッドハットおよびヴィーエー・リナックス・システムズ・ジャパンで、OS、コンパイラー、サーバーの開発を経験後、グーグル日本法人に入社。日米のオフィスを行き来し、システム基盤、Google マップのナビ機能、モバイル検索の開発・運用に従事。東日本大震災時には、安否情報を共有する Google パーソンファインダーなどを開発。その後、楽天で次世代プラットフォーム開発を担当し、2014 年 6 月から Retty に CTO として参画。海外への事業展開に向け、技術チームをリードする。


平山 知宏 氏
Tunnel 株式会社 開発担当執行役員

2008 年株式会社博報堂 DYMP に入社。インターネット広告のプランニングから効果分析、可視化業務を経て、博報堂研究所研究員を兼任。2010 年に同社を退職し、2011 年に東京大学大学院情報理工学系研究科入学、MEMS センサーの研究を専攻。在学中の 2012 年から Tunnel 社に参加し、卒業後はそのまま同社の CTO となる。Tunnel 社ではスマホアプリである RoomClip のインフラ・サーバサイド開発に加えて、画像解析やビッグデータの解析、機械学習などの領域に従事。


小島 英揮 氏
Still Day One 合同会社 代表社員 
パラレルマーケター・エバンジェリスト

25 年以上、IT のマーケティング業務に従事。PFU やアドビ システムズなどでインターネット関連製品を担当後、2009 年~2016 年に AWS の日本のマーケティングを統括。国内最大のクラウドコミュニティ JAWS - UG を立上げる。現在、オンライン決済や AI など複数の IT 企業でのマーケティングを軸に、パラレルキャリアを実践中。

プログラムの詳細や参加の申し込み手続きは 10 月上旬開始を予定しています。メールアドレスをご登録いただいた方には、情報更新の際にお知らせをお送りします。ご登録方法は事前登録サイトをご覧ください。

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


Posted by Takuo Suzuki - Developer Relations Team

Firebase ですごいモバイルゲームを作ろう

$
0
0
この記事はアート ディレクター、Darin Hilton による The Firebase Blog の記事 "Making great mobile games with Firebase" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

モバイルゲームの開発や保守はたいへんです。レベル作成ツールを含むゲームをリリースして、別のプレーヤーとコンテンツを共有できるようにする場合を考えてみましょう。さらに、プレーヤーの行動に応じて、新しいコンテンツを提供したり、ロックを解除したりできるようにします。もちろん、ヒット間違いなしのこのゲームに簡単にログインできるようにする機能も必要です。


そういったことを自分たちで行う場合、ユーザー管理、データ ストレージ、サーバーサイド ロジックなどを構築する必要があります。これには長い時間がかかり、さらに重要なことに、本当にやりたいこと、すなわち、すばらしいモバイルゲームを作ることに手がつけられなくなってしまいます。

Unity および C++ 用の Firebase SDK は、ゲームにこういった機能を追加するために必要なツールを提供し、しかも簡単に使いこなすことができます。では、次の大ヒットゲームを作るために、どのように Firebase を活用できるでしょうか。わかりやすいように、Unity で簡単なサンプルゲーム、MechaHamster を作成してみました。ぜひ Google Playでチェックしてみてください。または、Githubからサンプル プロジェクトをダウンロードして、とても簡単に Firebase をゲームに組み込めることを確かめてみてください。

MechaHamster のサンプルコードを詳しく見てみる前に、皆さんのゲームの成功をお手伝いする Firebase 製品の概要をご覧ください。

Analytics


優れた成果をもたらすゲームに欠かせないものの 1 つが、アナリティクス ツールです。Google Analytics for Firebaseを使うと、プレーヤーがどこで苦労しているかを確認し、必要に応じて調整することができます。さらに、Analytics は Adwords やその他の主要な広告ネットワークとも統合されており、最小限の作業で最大限のキャンペーンの成果を得ることができます。AdMob でゲームを収益化している場合は、2 つのアカウントをリンクすることもできます。そうすると、ゲーム内購入と AdMob を合わせたプレーヤーの生涯価値(LTV)を Analytics コンソールから直接確認できるようになります。また、Streamview では、プレーヤーがゲームをどのように操作しているかをリアルタイムで把握できます。

Test Lab for Android - Game Loop Test


ゲームのアップデートをリリースする前には、それが正しく動作するかを確かめる必要があります。しかし、大量の対象端末を使って手動でテストを行うには、膨大な時間がかかります。この問題を解決するために、先日の Google I/O 開催に合わせて新機能 Firebase Test Lab for Android Game Loop Testがリリースされました。ゲームにデモモードを追加すれば、ゲームがさまざまな端末で動作することを Test Lab が自動的に確認してくれます。詳しくは、こちらのブログ投稿をご覧ください。

Authentication


リリース前に対処すべきもう 1 つの機能は、プレーヤーが簡単にログインしてすぐにゲームを開始できるようにすることです。Firebase Authenticationは、単純なメールとパスワードによるログインから、Google、Facebook、Twitter、Github のような共通 ID プロバイダを使ったログインまで、ログインや認証の処理をすべて行ってくれます。I/O で発表されたように、現在の Firebase は電話番号認証もサポートしています。また、Firebase Authentication は端末間で状態を共有するので、プレーヤーはプラットフォームを問わず、前回中断したところからゲームを再開できます。

Remote Config


ゲームを始めるプレーヤーが増えるにつれて、プレーヤーたちが悩ましいと思っている部分もわかってくることでしょう。離脱率が上がり始めることもあるかもしれません。そういった場合は、何らかの調整が必要になります。Firebase Remote Configを使うと、コンソールで値を変更し、それをプレーヤーにプッシュできます。たとえば、レベルを攻略できないプレーヤーがいる場合は、難易度を調整してリモートで更新できます。Remote Config は開発サイクルにも役立てることができます。たとえば、新しいビルドを作成しなくても、パラメータを調整してテストすることができます。

Realtime Database


確かなプレーヤーのコミュニティができると、プレーヤーが作成したさまざまなレベルが公開されることになるでしょう。Firebase Realtime Databaseを使うと、プレーヤーのデータを保管してリアルタイムに同期することができます。つまり、皆さんが開発するレベル作成ツールから、簡単にデータを保存して他のプレーヤーと共有することができます。自分でサーバーを用意する必要はなく、Realtime Database はオフライン用に最適化されています。さらに、Realtime Database は Firebase Auth と統合されているので、ユーザー固有のデータに安全にアクセスできます。

Cloud Messaging と Dynamic Links


数か月後には、皆さんのゲームは人気になって高いエンゲージメントや活発なコミュニティが実現します。次の新しいコンテンツをリリースする準備もできていると思いますが、そのことを効率良くプレーヤーに伝えるには、どうすればよいでしょうか。Firebase Cloud Messagingを使うと、プレーヤーのセグメントを対象にして、コーディングなしにメッセージを送ることができます。また、Firebase Dynamic Linksを使うと、プレーヤーが新しいコンテンツ(または、皆さんのゲームへの招待状)を別のプレーヤーと共有できます。Dynamic Links はアプリのインストール プロセスを経ても有効なので、新しいプレーヤーはアプリをインストールした後、そのまま共有されたコンテンツを開くことができます。

私たちが Firebase で目指しているのは、優れたアプリを作成してビジネスを成功に導けるよう、モバイル デベロッパーの皆さんをサポートすることです。ゲームについて言えば、Firebase は退屈な作業を肩代わりしてくれます。そのため、皆さんは重要なこと、すなわち、すばらしいゲームを作ることに集中できます。C++ および Unity 用のモバイル SDK は、firebase.google.com/gamesで公開されています。GitHub のサンプルゲーム プロジェクト MechaHamsterもぜひご覧ください。

Reviewed by Khanh LeViet - Developer Relations Team

Android Instant Apps: ダウンロード サイズを制御するためのベストプラクティス

$
0
0
この記事は Google Play デベロッパー リレーションズ パートナー、Maru Ahues Bouza による Android Developers Blog の記事 "Android Instant Apps: Best practices for managing download size" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android Instant Apps は、ウェブのリンクをタップするだけで高機能なネイティブ アプリを利用できるようにするものです。事前にインストールせずにアプリを利用でき、レベルや質の高いエンゲージメントを実現できます。
しかし、モバイル ウェブページの読み込み時間と同程度の待ち時間を実現するには、構造を整え、サイズを小さくする必要があります。そうすれば、URL をタップした際に短時間でダウンロードして実行できるようになります。この点を考慮し、エントリポイントとなる URL をタップした際に読み込まれるバイナリは、できる限り小さく、4MB 以下にすることをおすすめします。バイナリが小さいほど Instant Apps の読み込みも早くなり、ユーザー エクスペリエンスがスムーズになります。
このドキュメントでは、アプリの構造やバイナリサイズを制御し、スムーズな Instant Apps を提供するためのベスト プラクティスを紹介します。このベスト プラクティスは、インストールするアプリを開発する際にも役に立つでしょう。

コードベースのリファクタリング

バイナリサイズを削減するために一番効果的な方法は、アプリをリファクタリングして複数の機能モジュールに分割することです。現在のサイズや機能セットでは複数の機能に分割する必要がない場合でも、そのように設計しておくことをおすすめします。そうすると、将来的に既存の機能のバイナリサイズに影響を与えずに機能を追加できるようになります。さらに、インストール可能なアプリと Instant Apps の両方のバイナリを生成できるように、モジュール式の単一コードベースにすることを強くおすすめします。これによって、プロジェクトやコードを別々に管理する手間が減り、それぞれ整理されたプロジェクト構造になります。早期アクセス パートナーの経験から、ダウンロード時のバイナリサイズにもっとも大きな影響を与えるのはこの点であることがわかっています。ただし、この作業はもっとも手間がかかります。
具体的には、単一の(ベース)モジュールから着手し、関連する部分を機能モジュールに移動させるというコードのリファクタリングを行います。なお、Instant Apps の開発中は、バイナリサイズについて心配することはありません。サイズの制限は、ローカルでビルドするバイナリには適用されません。バイナリは、Play Developers Console から開発トラック(開発時に Instant Apps をすばやくデプロイするための特別なトラック)に公開することもできます。この場合、サイズの制限は 10MB です。[1, 2] 4MB の制限は、バイナリが開発トラックを卒業する際に適用されます。
各機能モジュールは、指定された URL に対応するエントリ ポイントであるアクティビティを 1 つ(または複数)持つことができます。単一のコードベースを複数のモジュールに分割する場合、機能ごとに異なるエントリ ポイントを使います。プラットフォームは、必要に応じて関連する機能を読み込みます。なお、任意のエントリ ポイントでダウンロードされるバイナリの合計が 4MB 以下である必要がある点に注意してください。そのため、任意の機能モジュールとベース モジュールを組み合わせたサイズが 4MB 以下でなければなりません。
おすすめは、最初に機能とアクティビティとエントリ ポイントのマッピングを定義し、それから各エントリ ポイントのバイナリサイズを削減するためのリファクタリング作業を構造的に行うことです。
さらに、ライブラリの含め方も検討します。特定の機能モジュールにライブラリが必要になる場合、そのライブラリをベース APK ではなく、機能モジュールのみに追加するようにします。そうすれば、ベース モジュールのサイズを削減できます。たとえば、X、Y、Z という 3 つのライブラリに依存するアプリがあるとします。まず、すべての依存関係をベースの gradle.build ファイルに記載し、すべてのライブラリをベース モジュールに格納しようとするかもしれませんが、機能モジュールのコードがライブラリ Z のみを必要とする場合、その依存関係をベース モジュールから機能モジュールに移す方が妥当です。そうしても、別の機能モジュールが同じライブラリに依存していない限り問題はありません。複数の機能モジュールが同じライブラリを使う場合は、当然ながらベース モジュール内に残しておきます。

lint チェック

多くのアプリは、たくさんのリソースが登録されています。そして、時間が経つにつれて、使われなくなるリソースも出てきます。Android Studio には、使っていないリソースをチェックできる便利な lint チェックが組み込まれています。Alt+Ctrl+Shift+I(Mac OS では Cmd+Option+Shift+I)を押し、「unused resources」と打ち込んで [Unused resources Android | Lint | Performance] インスペクションを開始します。この機能は、インストールが可能な APK のサイズ削減にも役立ちます。

文字列リソース

リソースと同じく、文字列にも注目しましょう。文字列にも、使われていないものがあるかもしれません。通常、不要な文字列リソースを削除すれば、アプリのサイズを大幅に削減できます。アプリが複数言語をサポートする場合、ローカライズされたリソースの数を減らすこともできます。通常、これによってリソース アセットを大幅に削減できます。数か国語しかサポートしていないアプリで AppCompat ライブラリを使っている場合は、特にこれが重要になります。このライブラリには、複数言語のメッセージが含まれています。resConfigを使用すると、特定のリソース構成のみを選択できます。ヒント: 通常は、「auto」を指定してサードパーティ製ライブラリからプルされる構成を制限し、プロジェクトで定義されている構成セットに一致させるようにします。

WebP への切り替え

PNG イメージの代わりに WebP を使うと、ドローアブル リソースのサイズを大幅に削減できる可能性があります。Android Instant Apps は、WebP 形式のすべての機能(透過、ロスレスなど)をサポートしているので、機能が失われることはありません。なお、アプリのランチャー アイコンは PNG 形式でなければいけませんが、普通、これらのファイルはプロジェクトの mipmap- ディレクトリに格納されるため、問題にはなりません。下位互換性のあるソリューションが必要な場合は、オリジナルの PNG イメージを APK モジュールに含める必要があります。その場合、WebP リソースは自動的に無視されます(メイン ソースセットは、すべての AAR モジュールや機能モジュールのリソースより優先されます)。[4]
もちろん、ベクター ドローアブルを利用すれば、貴重なスペースをさらに節約できるかもしれませんが、それにはコードの変更が必要です。Instant Apps では WebP イメージを使い、インストール可能な APK では PNG イメージを使うという前述の方法には、コードの変更は必要ありません。

アセットのランタイム ダウンロード

最後に、技術的にはすべてのリソースを Instant Apps の APK に格納する必要はない点も覚えておきましょう。アプリは、実行時に追加アセットをダウンロードすることもできます。このアプローチを使うと、必要なアセットのみダウンロードすることもできます。これには、コードベースに大きな変更が必要になる可能性がありますが、インストール可能な APK のサイズを減らすためにも役立ちます。
リソースの削減だけではアプリの機能モジュールのサイズを制限以下にできない場合は、コードのサイズを削減する方法を探る必要があります。

ネイティブ ライブラリのレビュー

サードパーティ製ライブラリには、Instant Apps ではまったく使わないネイティブ コードが含まれているものもあります。そのため、APK のネイティブ ライブラリをレビューする最初の段階として、実際に使われるものだけが格納されているかを確認します。ここでは、APK Analyzer([Build] -> [APK Analyzer…])を使ってコンパイル済みの APK を調べてください。[5]

外部ライブラリのレビュー

次は、アプリのコードにリンクされているすべての外部ライブラリをレビューします。推移的依存関係のおかげで驚くべきことが起こっていることがわかるかもしれません。推移的依存関係とは、プロジェクト内のライブラリが別のライブラリに依存していることを指します。また、その別のライブラリは、さらに別のライブラリに依存している可能性もあります。このような推移的依存関係によって、まったく必要としないライブラリ(コードではまったく使っていない JSON 処理ライブラリ)が含まれるなど、驚くべきことが起こっている場合があります。詳細は、Gradle ユーザーガイドの「推移的依存関係の除外」セクションをご覧ください。
Android Studio には、プロジェクトの外部依存関係を分析する便利なツールがいくつか搭載されています。まずは、[Project] ビューから見るとよいでしょう。
[Project] ビューには [External libraries] というセクションがあり、推移的依存関係を含め、プロジェクトで使用されているすべてのライブラリが表示されています。
ベース機能のサイズをさらに削減するには、コードの依存関係や外部ライブラリに注目する必要があります。[Project] ビューを確認し、使っていないライブラリを探します。そのようなライブラリは、プロジェクトに必要のない推移的依存関係かもしれません。また、同じ機能を提供するライブラリも探します(イメージの読み込みやキャッシュを行う複数のライブラリなど)。[4]
APK Analyzerツールを使うと、ビルド同士を比較できます。このツールは、Instant App の APK でも利用できます。
最後に、推移的依存関係のリストをレビューし、不要なものを除外します。gradle -q :MODULE:dependencies --configuration compileコマンドを使うと、依存関係グラフをレビューできます。詳細は、Gradle のドキュメントをご覧ください。

その他のヒント

Android Studio 3.0 には、App Links Assistant ツールが搭載されています。このツールは、必要なインテント フィルタを生成したり、プロジェクトを複数のモジュールに分割する際に役立ちます。[3]
Instant Apps バンドルがサイズ制限を下回るようになったら、ビルド処理が最新であることを確認します。アプリのパッケージと Instant Apps の APK が「APK Signature Scheme v2」で署名されているかどうかをチェックしてください。最新バージョンの SDK ツールで APK を署名していれば、すべて自動で行われるはずです。ただし、手動でビルド アーティファクトに署名している場合は、jarsigner は使わず、apksignerを使う必要があります。
また、アプリのコードを Instant Apps のランタイム環境に対応させる際のおすすめの方法をいくつか紹介しておきましょう。Instant Apps とインストール可能なアプリのコードでは、InstantApps.isInstantApp(...)を使って多少の条件分岐を入れることは優れた手法であり、一般的にソースコードが読みにくくなることはありません(もちろん、乱用しなければですが)。また、共有インテントを使用する場合は、端末にインストールされているアプリを明示的に列挙しないようにします。Instant App のセキュリティ モデルは、これを認めていません。その場合は、単に通常の Intent.createChooser() を使って実行できるすべてのアクションのリストをユーザーに提示します。
既存の Android アプリを Instant Apps 化するために必要な作業量はデベロッパーによって異なり、アプリが現在どのように構成されているかに大きく依存します。プロジェクトがすでに複数のモジュールで構成されていれば、簡単に行えるかもしれません。しかし、コードやリソース アセットのサイズを減らす作業を重点的に行わなければならない場合もあるでしょう。ここで説明したツールや Android プラットフォーム機能は、そのために導入されています。

Android Instant Apps を使っているその他のデベロッパーの紹介

最後に、すでに Instant Apps を構築しているデベロッパーによるすばらしい投稿を紹介しましょう。
Android Developers ウェブサイトにアクセスし、Android Instant Apps を使ってみてください。また、他のデベロッパーによるアプリ高速化のサクセス ストーリーもご覧ください



Reviewed by Yuichi Araki - Developer Relations Team

Cloud Functions for Firebase で Promise を活用する

$
0
0
この記事はデベロッパー アドボケート、Doug Stevenson による The Firebase Blog の記事 "Keep your promises when using Cloud Functions for Firebase!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 
 
多くの Firebase デベロッパーは、Android、iOS、ウェブのいずれか、または 3 つすべてのアプリの開発に集中しています。私のように、ほとんどの時間をクライアント側の開発にかけている場合、バックエンド側のコンポーネント開発は難しいと感じるかもしれません。しかし Cloud Functions for Firebaseを活用することで、サーバー管理を気にせずに、簡単に楽しく JavaScript でバックエンド側のコードを書いたり、デプロイしたりすることができます。私の場合は Android プログラミングが得意分野ですので、Cloud Functions をマスターするために、JavaScript の理解をブラッシュアップし、node.js を学習しました。  

Promise の紹介

JavaScript と node.js について学習する中で、Promise という非同期タスクの管理方法を学びました。ブラウザで JavaScript や Cloud Functions を使ったことがある方はすでにご存知かもしれませんが、Promise は、非同期タスクを処理するに良く使われるクラスです。Android の Firebase API にたまに出てくる Task APIに近いコンセプトです。  
 
Promise は、データベースへの書き込み、ネットワーク リクエストなどの非同期タスクを実装するときに利用します。非同期タスクの実行中に関数を終了させないようにするには、関数から Promise を返します(ただし、クライアントに応答を送信する必要がある HTTP/S トリガーは除きます)。Promise を返すときは、その関数のすべての 非同期タスクが完了した際に Resolve される Promise を返すようにします。YouTube の Firebase チャンネルにある以下の動画では、Cloud Functions での Promise の動作を紹介しています。  
 

以上の動画には、Jen が Promise の 2 つの使い方を紹介します。1 つ目は複数のタスクを連結して順番に処理するために使われる Promise の then()メソッドです。2 つ目は複数のタスクを並列に実行し、すべての タスクが完了するまで待機する Promise.all() メソットです。この 2 つのメカニズムを活用すると、関数内に行われるほとんどの処理を実装することができます。タスクが完了したときに、Promise を返して、Cloud Functions 環境にクリーンアップ処理を任せます。  
 

ECONNRESET 問題

シンプルな処理は作りやすいのですが、多数の Promise が同時に実行される複雑なタスクはなかなか実装しにくいケースがあります。Promise が正しく実装されていないときのひとつの症状として、Firebase console のログに次のようなエラーが表示される場合があります。  
Error: read ECONNRESET 
このエラーに関しては、いくつかの原因が考えられます。クライアント ライブラリのバグである可能性もありますが、ほとんどの場合は、Promise が正しく使われていないことが原因です。  
ネットワーク接続が完了する前に関数が終了すると、オープンされているコネクションは強制的にクローズされることがあります。この場合ログに ECONNRESET が記録されます。これは、次のような状況で発生します:  
例えば、3 つの非同期タスクを起動する必要があるプログラムを考えましょう。次のように、Promise を返す doSomeAsync() で、3 つのタスクを起動して、3 つ目のタスクの Promise を返します。  
doSomeAsync(x)
doSomeAsync(y)
return doSomeAsync(z)

関数から Promise を返すこと自体には問題がありません。しかし、Cloud Functions では、すべての タスクが完了するまで待機する Promise が必要です。上の書き方だと、1 つ目のタスクと 2 つ目のタスクが 3 つ目のタスクが完了する前に完了する保証がありません。3 つ目のタスクが 1 つ目のタスクや 2 つ目のタスクより前に完了すると、Cloud Functions は実行中のタスクをクリーンアップしてしまう可能性があります。  
このプログラムを修正するには、すべての Promise を組み合わせた新しい Promise を作る必要があります。この Promise は、すべての Promise が完了するまで待機して Resolve します。正しい書き方は以下のとおりです。  
const promise_x = doSomeAsync(x)
const promise_y = doSomeAsync(y)
const promise_z = doSomeAsync(z)
return Promise.all([promise_x, promise_y, promise_z])

関数内で起動した すべての非同期タスクをきちんと管理しないと、ログに恐怖の ECONNRESET エラーが出現し、プログラムは予想通りに動作しない可能性があります。すべての Promise をきちんと管理するには、人がすべての約束を守るのと同じように、ある種の努力が必要です。  
Google I/O '17 のセッションで、私が作ったオープンソースのウェブ 3 目並べゲームを紹介しました。このゲームは完全に Firebase だけで作成し、複雑な非同期タスクを実装しています。こちらの動画を御覧ください。  

Cloud Functions に関するその他のチュートリアルやコンテンツ、他の Firebase 製品にご興味がある方は、YouTube の Firebase チャンネルFirebase ブログをご覧ください。  
 
Reviewed by Oscar Rodríguez - Developer Relations Team

Android Instant Apps をサポートする端末が 5 億台を突破

$
0
0
この記事は Jonathan Karmel による Android Developers Blog の記事 "500 million devices now supported for Android Instant Apps" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Instant Apps は、ユーザーがインストールせずに即座にアプリを利用できるようにするものです。今年の Google I/Oで一般公開されてから、サポート端末の数や Instant Apps の提供状況について改善が図られてきました。そしてついに、Google Play が提供されている国で 5 億人以上の Android ユーザーが Instant Apps にアクセスできるようになりました。

業界を問わず、すでに多くの Google Play のアプリ会社やゲーム会社が Instant Apps を作り始めています。そういった会社は、Instant Apps のリリースとともにエンゲージメント、獲得、維持のそれぞれにおいて、すばらしい成果をあげています。
Vimeo:世界中に 5,000 万人のクリエイターと 2 億 4,000 万人の閲覧者を持つ Vimeo は、人々が簡単に動画を友だちと共有できるプラットフォームを構築しています。Vimeo は、Android Instant Apps を実装することによって、ネイティブ アプリのエクスペリエンスを通し、簡単な操作でユーザーがコンテンツに没入できるようにしたいと考えました。その結果、セッションの継続時間が 130% 増加しました。Vimeo が Instant Apps でエンゲージメントを増加させた方法をご覧ください。
Jet: アメリカをベースにサービスを提供しているJet は、セール等、ユーザーが安く買い物をできる機会をリアルタイムに知らせるエンジンを活用したショッピング プラットフォームを提供しています。Jet は、既存のアプリをさらに拡大したいと考え、Instant Apps に対応するアップデートを行いました。その結果、Instant Apps のリリース後には、コンバージョン率が 27% 増加しましたJet が行った Instant Apps のリリースについて、詳しくご覧ください。
NYTimes Crosswords: NYTimes Crosswords の Instant Apps では、ニューヨーク タイムズの日刊紙に掲載されているクロスワード パズルを提供しています。Instant Apps 化の目的は、ユーザーにネイティブに近いエクスペリエンスを提供し、アプリのエンゲージメントを増加させることでした。その結果、ユーザーごとのセッション数が 2 倍に増加しました。そして、初期の結果に基づき、さらに効率的な獲得、コンバージョン、長期維持を実現しています。NYTimes がアプリのセッション数を増加させた方法をご覧ください。
dotloop: dotloop は、不動産のプロが住宅の販売者や購入者と簡単にやりとりし、いつでもどこでもドキュメントにサインできるようにする不動産取引プラットフォームです。Instant Apps 化の目的は、ドキュメントにサインする際にネイティブ アプリのエクスペリエンスを提供することでした。その結果、ドキュメントにサインしたユーザーの数が 62% 増加するなど、主な指標を向上させることができました。dotloop が Android Instant Apps をサポートしてエンゲージメントを増加させた方法をご覧ください。
Onefootball:ベルリンをベースとし、230 を超えるリーグを対象にニュースやライブスコア、日程、結果、対戦表、統計情報などを 15 言語で提供するアプリです。Onefootball は、他のアップデートと合わせて APK サイズを削減し、Instant Apps 化を行いました。その結果、ニュースを読んだり、コンテンツを共有するユーザー数が 55% 増加しましたOnefootball がリリース後にエンゲージメントを増加させた方法をご覧ください。
Realtor.com:PC とモバイル プラットフォームで毎月 6,000 万近くのユニーク アクセス数を達成する、有数のオンライン不動産仲介業者です。Realtor.com は、12 MB のアプリをモジュール化して Android Instant Apps をサポートしました。その結果、Realtor.com の物件詳細一覧のページビューあたりの引き合い数が倍になり、主要なコンバージョン指標が増加しました。Realtor.com が Instant Apps の APK サイズを削減した方法をご覧ください。

Android Instant Apps のダウンロード サイズを制御するその他のベスト プラクティスもご覧ください。また、g.co/instantapps にアクセスして Instant Apps の構築に役立つ情報を入手し、早速開発を始めましょう!


このブログ投稿はどのくらい役に立ちましたか?




Reviewed by Takuo Suzuki - Developer Relations Team

deeplearn.js でブラウザから機械学習の力を活用

$
0
0
この記事は Google Big Picture チーム ソフトウェア エンジニア、Nikhil Thorat、Daniel Smilkov による Google Research Blog の記事 "Harness the Power of Machine Learning in Your Browser with Deeplearn.js" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

機械学習(ML)は、物体認識言語翻訳ヘルスケアなど、さまざまな領域に適用できるますます強力なツールになっています。 しかし多くの場合、ML によるシステム開発は、一般的な ML ライブラリを使って開発できる専門知識や計算リソースを持つ人材に依存してしまいます。

Google では、できる限り多くの人に機械学習の門戸を開くべく、人間と ML のインタラクションを研究して再デザインする取り組み「PAIR」を推進しています。今回その一環として、WebGL を利用した機械学習用オープンソース JavaScript ライブラリである deeplearn.js 0.1.0を発表しました。これはブラウザ単独で動作し、ライブラリのインストールやバックエンドは必要としません。


Web ブラウザは世界でもっとも人気のあるプログラミング プラットフォームの 1 つであり、ブラウザ上で機械学習を使えることで得られるメリットはたくさんあります。クライアント サイドの ML ライブラリは、インタラクティブな説明や、すばやいプロトタイピングと可視化、オフライン計算などのプラットフォームとして利用できます。

ウェブ用の機械学習ライブラリは数年前から存在していますが(例: Andrej Karpathy の convnetjs)、JavaScript のスピードによる制限があったり、学習は行えず推論しかできなかったりしていました(例えば TensorFire など)。deeplearn.js はそれらとは違い、 バックプロパゲーションによる完全なモデル学習を行え、WebGL による GPU 計算により大幅な学習の高速化も可能です。

deeplearn.js の API は TensorFlowNumPyの構造をまねており、TensorFlow のような学習の遅延実行モデルや、NumPy のような推論のインタラクティブな推論実行のモデルも提供します。。さらに、TensorFlow でよく利用される操作もいくつか実装されています。deeplearn.js のリリースに加えて、TensorFlow のチェックポイントから重みをエクスポートするツールも提供される予定です。これを使うと、ウェブページ内部で重みをインポートして deeplearn.js で推論できます。

ぜひこのライブラリの可能性を体験してみてください。ブラウザだけで 1 行のコードも書かずに写真や手書きの数字を認識する畳み込みニューラル ネットワークをトレーニングできます。


deeplearn.js のトップページでは、実際に動作するいくつかの deeplearn.js のデモが公開されています。例えばウェブカメラを使ってリアルタイムにイメージを分類するデモでは、ネットワークの内部状態を確認できます。また毎秒 60 フレームのスムーズな抽象画風の動画も生成できます。トップページではその他のデモも公開されています。

deeplearn.jp は、機械学習の認知と導入事例を広げるべく開発されたツールです。機械学習を簡単に活用できる強力なツールを開発者に提供することで、「普通」のユーザーが機械学習の便利さに触れられる機会を増やすことが目的です。その実現に向けて、オープンソース コミュニティの皆さんと協力し合えることを楽しみにしています。

Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud

reCAPTCHA と Firebase でウェブ コンテンツを不正使用から守る

$
0
0
この記事はデベロッパー アドボケート、Doug Stevenson による The Firebase Blog の記事 "Guard Your Web Content from Abuse with reCAPTCHA and Firebase" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ウェブを使ったことがある方なら、reCAPTCHAが表示され、本当に人間が操作しているのか確かめるサイトを見たことがあるのではないでしょうか。たとえば、goo.gl 短縮 URL 生成ツールを使う場合、次のような reCAPTCHA を通過しなければ短縮リンクを作成できません。

ウェブサイト エンジニアは、サイトをスパムやボットによる不正使用から守りつつ、人間による正規の利用を許可するために、このようなことを行っています。では、なぜこのような保護が必要なのでしょうか。時間や保存容量の面で高価なバックエンド コードがあり、実際のウェブユーザーのみにしかアクセスしてほしくないなどの可能性が考えられます。

ウェブサイトをお持ちの皆さんは、サービスを保護するために reCAPTCHA を使うことができます。また、Firebase Hostingを使ってサイトを構築している場合、Cloud Functions for Firebaseを利用すれば、簡単に reCAPTCHA を組み込んで安全で拡張可能な reCAPTCHA 検証バックエンドを提供できます。

この記事では、数ステップで完了する基本的な組み込み方法を紹介します。後でこの方法を拡張して、皆さんのサイトに reCAPTCHA を組み込んでいただくことも可能です。このチュートリアルでは、すでにウェブ開発や Firebase ConsoleFirebase CLIについて、いくらかの経験があることを前提としています。

1. コンソールで Firebase プロジェクトを作成する

Firebase コンソールを開き、新しいプロジェクトを作成します。このプロジェクトには、課金は必要ありません。実験はすべてクレジット カードを登録せずに行うことができます。プロジェクトを作成したら、コンソールで行うことはもうありません。

2. プロジェクトのコードを格納するディレクトリを設定する

Firebase CLI から、プロジェクトを作成したときに利用した Google アカウントにログインします。
$ firebase login

次に、プロジェクトのルート ディレクトリを作成し、初期化します。
$ mkdir my_project
$ cd my_project
$ firebase init

firebase initを実行するときは、hosting と functions の両方を選択します。プロジェクトを選ぶよう尋ねられたら、先ほど作成したプロジェクトを選択します。その他のプロンプトでは、すべてデフォルトを選びます。最終的に、ウェブ コンテンツ用の publicフォルダと、バックエンド コード用の functionsフォルダを含むディレクトリ構造ができあがります。

次に、Cloud Functions バックエンドで reCAPTCHA の検証に使用するいくつかのモジュールを npm を使ってインストールします。reCAPTCHA API では、バックエンドから検証するために HTTP リクエストを作成する必要があります。これには、 request モジュールと request-promise モジュールを使用します。次のようにして、これらのモジュールをインストールします。
$ cd functions
$ npm install request request-promise

package.jsonファイルには、firebase-functions と firebase-admin に加えて、上記の 2 つのモジュールが新しく追加されます。

3. ウェブ デプロイメントをテストする

次のように、deploy コマンドを実行し、ウェブ コンテンツをデプロイできることを確認します。
$ firebase deploy --only hosting

コマンドが終了すると、新しいウェブサイトのパブリック URL が表示されます。これは、次のような形式になっています。
✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/your-project/overview
Hosting URL: https://your-project.firebaseapp.com

your-projectは、コンソールからプロジェクトを作成したときに割り当てられた固有の ID です。Hosting の URL をブラウザに貼り付けると、「Firebase Hosting Setup Complete」というページが表示されるはずです。

4. reCAPTCHA API キーを取得する

reCAPTCHA を動作させるには、2 つの API キーが必要になります。1 つはウェブ クライアント用、もう 1 つはサーバー API 用です。これらは、reCAPTCHA 管理パネルから取得できるため、そのページに移動します。新しいサイトを作って名前を付け、[reCAPTCHA V2] を選択します。ドメイン欄には、Firebase Hosting の完全なサイト名(例: 「your-project.firebaseapp.com」)を入力します。

登録が完了したら、Site キーSecret キーを入手できます。Site キーはフロントエンド HTML に使用し、Secret キーは Cloud Functions にホストするバックエンドで使用します。

5. reCAPTCHA ページを追加する

次に、reCAPTCHA を表示する新しい HTML ページを追加します。プロジェクトの publicディレクトリに、recaptcha.htmlという名前で reCAPTCHA を表示する新しい HTML ファイルを追加します。新しいファイルには、次の内容を直接コピーして貼り付けてください。
<html>
<head>
<title>Firebase + reCAPTCHA</title>
<script src="https://www.google.com/recaptcha/api.js" async defer></script>
<script type="text/javascript">
function dataCallback(response) {
console.log("dataCallback", response)
window.location.href = "/checkRecaptcha?response=" + encodeURIComponent(response)
}
function dataExpiredCallback() {
console.log("dataExpiredCallback")
}
</script>
</head>
<body>
<div class="g-recaptcha"
data-sitekey="PASTE_YOUR_SITE_KEY_HERE"
data-callback="dataCallback"
data-expired-callback="dataExpiredCallback"/>
</body>
</html>

body の中に「g-recaptcha」クラスの div があります。ここで最初に行う必要があるのは、reCAPTCHA の Site キーを div の data-sitekey 属性の値にコピーすることです。上部にある最初のスクリプトが読み込まれると、この div は自動的に reCAPTCHA の UI に変換されます。詳しくは、こちらのドキュメントをご覧ください。

もう 1 度 firebase deployを実行してから、Hosting の URL の「/recaptcha.html」に移動すると、すぐに確認できます。しかし、まだ reCAPTCHA を使ってはいけません。検証できるようにするには、バックエンドのコードが必要です。

このページの JavaScript コードでは、dataCallbackdataExpiredCallbackという 2 つの関数が定義されています。この 2 つの関数は、reCAPTCHA が成功した場合と、ユーザーが一定時間内に成功させることができなかった場合のコールバックになっており、div から参照されています。

重要なのは、dataCallbackでブラウザを /checkRecaptchaというパスの別の URL にリダイレクトし、responseという名前でパラメータを渡している点です。この文字列は reCAPTCHA が生成するもので、ランダムな文字列のように見えます。

ウェブサイトには /checkRecaptchaというパスはまだ存在しません。そこで、reCAPTCHA からのレスポンス文字列を Cloud Function を使って検証するようにします。

6. reCAPTCHA のレスポンスを検証する Cloud Function を作る

プロジェクトの functions ディレクトリにある index.js ファイルを編集します。このファイルには、いくつかのサンプルコードが書かれていますが、それは削除して構いません。その場所に、次の JavaScript コードを貼り付けます。
const functions = require('firebase-functions')
const rp = require('request-promise')

exports.checkRecaptcha = functions.https.onRequest((req, res) => {
const response = req.query.response
console.log("recaptcha response", response)
rp({
uri: 'https://recaptcha.google.com/recaptcha/api/siteverify',
method: 'POST',
formData: {
secret: 'PASTE_YOUR_SECRET_CODE_HERE',
response: response
},
json: true
}).then(result => {
console.log("recaptcha result", result)
if (result.success) {
res.send("You're good to go, human.")
}
else {
res.send("Recaptcha verification failed. Are you a robot?")
}
}).catch(reason => {
console.log("Recaptcha request failure", reason)
res.send("Recaptcha request failed.")
})
})

ここで最初に行う必要があるのは、登録サイトで取得した reCAPTCHA の Secret キーを「PASTE_YOUR_SECRET_CODE_HERE」と書かれた場所に貼り付けることです。

(鋭い読者の皆さんは、ドキュメントには reCAPTCHA API エンドポイントのホストが、「www.google.com」と書かれているにもかかわらず、ここでは「recaptcha.google.com」になっていることに気づくかもしれません。これは問題ありません。Spark プランでこの呼び出しを行うためには、ここに記載したように、recaptcha.google.com を使う必要があります。このホストは、Cloud Functions からの外部トラフィックの宛先としてホワイトリストに登録されています)

このコードは、HTTPS 関数を定義しています。これがトリガーされると、クエリ文字列として受信したレスポンスを検証するために、reCAPTCHA API への別の HTTPS リクエスト(request-promise モジュールを使用しています)が作成されます。3 通りのケースがあり、それに応じてクライアントに 3 通りのレスポンスが返されることに注意してください。具体的には、以下のいずれかになります。
  1. reCAPTCHA の検証が成功する(ユーザーは人間である)
  2. reCAPTCHA が失敗する(ロボットの可能性がある)
  3. API の呼び出しが失敗する

重要になるのは、 すべてのケースでクライアントにレスポンスを送り返すことです。そうしないと、Function はタイムアウトし、Firebase Console のログにエラー メッセージが出力されます。

次のコマンドを実行して、この新しい関数をデプロイします(同時に、ウェブ コンテンツもデプロイされます)。
$ firebase deploy

出力から、関数が URL に割り当てられたことがわかります。これは、次のような URL になります。
https://us-central1-your-project.cloudfunctions.net/checkRecaptcha

ここに表示されているホストは、ウェブ コンテンツが格納されているホストとは明らかに異なります。ここで実際にやりたいのは、次のような URL で、お使いのウェブホストを指定して関数を参照することです。
https://your-project.firebaseapp.com/checkRecaptcha

これができれば、関数がウェブサイトの一部であるように見えます。Firebase Hosting と Cloud Functions を利用すると、これを実現できます。

7. Hosting の URL を Cloud Function にマッピングするためのリライトを追加する

プロジェクトのルート ディレクトリにある firebase.jsonファイルを編集し、その内容に次の JSON 設定を貼り付けます。
{
"hosting": {
"public": "public",
"rewrites": [
{
"source": "/checkRecaptcha",
"function": "checkRecaptcha"
}
]
}
}

詳しくはドキュメントをご覧いただくとして、ここでは、リライト用のセクションを新しく追加しています。具体的には、URL パス /checkRecaptchaにアクセスした際に、先ほど functions/index.jsファイルに貼り付けた checkRecaptcha関数が呼び出されるようにしています。

recaptcha.htmlの JavaScript コードで、ユーザーが reCAPTCHA を通過した際は、このパスにリダイレクトするようにしたことを思い出してください。そのため、reCAPTCHA の処理を終えたユーザーは、実質的にこの関数に送られることになります。

最後にもう 1 度デプロイを行い、すべてのファイルを Firebase に送信します。
$ firebase deploy

8. reCAPTCHA をテストする

Hosting の URL の /recaptcha.htmlに移動し、reCAPTCHA を通過してみましょう。たとえば、何枚かの写真が表示され、車や道を判別することが求められます。人間としてふさわしい操作を行って reCAPTCHA を通過すると、HTML 内の JavaScript によって関数にリダイレクトされます。その関数は、サーバーを使って本当に人間による操作であるかを検証し、その結果、「You're good to go, human.」というメッセージが表示されます。

ここで紹介した Cloud Functions for Firebase で reCAPTCHA を使うサンプルは、おそらく実際のウェブサイトで利用するものより、かなりシンプルになっています。reCAPTCHA のレスポンスを関数に送る方法はいくつかあり、当然ながら、皆さんはユーザーにメッセージを表示するよりももっと役立つことをしたいと思うでしょう。しかしこの例は、ウェブ コンテンツをボットによる不正使用から保護する最初の一歩になるはずです。



Reviewed by Eiji Kitamura - Developer Relations Team

Google Play で良質のアプリやゲームを見つけやすくなります

$
0
0
この記事は Google Play プロダクト マネージャー、Andrew Ahn による Android Developers Blog の記事 "How we’re helping people find quality apps and games on Google Play" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ユーザーは、期待通りのパフォーマンスや質を提供するアプリやゲームを活用して楽しんでいます。一方で、電池の消費が早かったり、表示が遅かったり、クラッシュするアプリやゲームは不満の種になっています。実際、Google Play のアプリのレビューを社内で分析した結果、星 1 つのレビューの半数で、アプリの安定度が指摘されていました。アプリの質を重視するデベロッパーの評価は上がり、結果として定着率や収益も上がります。

私たちは、Google Play で最大限の満足を提供するための努力を続けています。先日、その一環として、検索や検出のアルゴリズムが強化され、アプリの質が反映されるようになりました。これによって、Play ストアで高品質のアプリが低品質でクラッシュが頻発するアプリよりも上位に現れるようになります。高品質のアプリは使用頻度が高く、アンインストールされにくいことがわかっています。

パフォーマンスを重視するデベロッパーは、Play Console を使って品質に関わる多数の問題を発見し、修正できます。Android Vitalsは、パフォーマンスに関する重大な問題を特定し、対応できるようにします。そのような問題は、ユーザーが皆さんのアプリをインストールした端末でオプトインしている場合、その端末から報告されます。リリース前レポートには、人気のある物理端末でアルファ版やベータ版のアプリをテストした結果が表示されるので、 アップデートをリリースする前に問題を見つけることができます。さらに、評価とレビューでは、アプリのユーザーから直接寄せられる声をもとに、アプリの質に関する知見を得ることができます。これらがもたらす可能性については、アプリのパフォーマンス改善によって評価が 4.1☆ から 4.5☆ に上昇した Busuuの事例をご覧ください。

Google Play は、皆さんが安全、高品質、便利で実用的なアプリを見つけられるように努力しています。アプリの質やパフォーマンスを重視すれば、Google Play でさらに成功を収めることができます。アプリやゲームのビジネスをさらに拡大するための秘訣やベスト プラクティスについては、Playbook アプリをご覧ください

このブログ投稿はどのくらい役に立ちましたか?


Reviewed by Hak Matsuda - Developer Relations Team

Android 8.0 Oreo のご紹介

$
0
0
この記事は エンジニアリング担当 VP、Dave Burke による Android Developers Blog の記事 "Introducing Android 8.0 Oreo" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


デベロッパーやアーリー アダプターの皆さまによる1 年以上にわたる開発と数か月のテストを経て(ありがとうございました!)、ついに Android 8.0 Oreo を公式にリリースする準備が整いました。Android 8.0 には、ピクチャ イン ピクチャ(PIP)、Autofill、統合された Instant Apps、Google Play プロテクト、短縮された起動時間などのすばらしい機能が満載です。

すぐにアクセスできるよう、ソースは Android Open Source Project(AOSP)で公開しています。米国では、Pixel と Nexus 5X/6P ビルドは携帯通信会社によるテストに入っており、Pixel C や Nexus Player と合わせて今後数週間のうちに段階的ロールアウトが始まる予定です。Android ベータ版のユーザーは、最終版へのアップデートを本日(*原文公開当時)受け取ります。イメージも公開されており、手動でダウンロードしてフラッシュすることもできます。ここ何か月もの間、私たちはパートナーの皆さまと密に連携してきました。Essential、Huawei、HTC、Kyocera、Motorola、Nokia Phones の HMD Global Home、Samsung、Sharp、Sony などのハードウェア メーカーは、今年末までに Android 8.0 Oreo に対応した新しい端末のリリースやアップグレードを予定しています。

Android Oreo の新機能


Android 8.0 Oreo は、シームレスにリッチな体験を実現することに主眼を置いています。次のような機能によって、Android はより強力で使いやすくなります。
  • ピクチャ イン ピクチャ(PIP)を使うと、ユーザーは 2 つのタスクを自由な画面サイズで同時に制御できます。アプリでサポートするのも簡単です(右側のイメージ)
  • 通知機能を拡張する通知ドットは、アプリのアクティビティを表示する新たな方法です。何もしなくてもほとんどのアプリに組み込むことができ、ドットの色もアイコンから自動的に抽出されます
  • Autofill フレームワークによって、新しい端末を設定したり、パスワードを同期する作業がもっと簡単になります。フォームデータを利用するアプリは、Autofill 用にアプリを最適化できます。パスワード管理アプリは、新しい API を使ってお気に入りのアプリでユーザーにサービスを提供できます。Autofill は、Google Play Services のアップデートの一部として、数週間後に完全版がロールアウトされる予定です


また、Android Vitals にも投資が行っています。これは、電池寿命、起動時間、グラフィックのレンダリング時間、安定性などを最適化しつつ、デベロッパーにアプリの健全性を把握しやすくすることにフォーカスを当てたプロジェクトです。
  • システムの最適化: アプリが早くスムーズに動作するように、システム全体に手を加えています。たとえばランタイムには、新しいコンカレント コンパクション ガベージ コレクションの追加や、コードのローカル性の向上などが行われています。
  • バックグラウンドの制限事項: バックグラウンドの位置情報や Wi-Fi スキャンに新たな制限を設け、バックグラウンドでのアプリの実行方法を変更しています。こういった制限はすべてのアプリに適用され、意図せずに電池やメモリを使いすぎることがなくなります。この内容を理解し、アプリで考慮するようにしてください。
  • 補助機能として利用できる Android Vitals ダッシュボードと IDE プロファイラ: Play Console でアプリの集計データを参照し、よく発生する問題をピンポイントで検出できます。極端なクラッシュ発生率、ANR 発生率、フリーズしたフレーム、レンダリングの遅延、極端なウェイクアップ数などが表示されます。さらに、Android Studio 3.0 には新しいパフォーマンス プロファイラが、プラットフォームには新しい計測ツールが搭載されています。


Android 8.0 では、アプリから直接特定のアプリ ショートカットをランチャーに固定し、エンゲージメントを向上させることが可能(左)。ユーザーのアプリ利用率を向上させ、直接アプリの中心機能にジャンプできるようにする通知ドット(右)

さらに優れた効率的なアプリをビルドするために、Android Oreo には多くのデベロッパー向け新機能も含まれています。そのうちのいくつかを紹介しましょう。
  • TextView の自動サイズ設定: 自動でサイズが設定される TextViewでは、テキストが自動的に TextView 一杯に表示されます。テキストの量には関係しません。プリセット テキストサイズの配列を作成するか、最大、最小サイズとその間の段階を設定すれば、利用可能な TextView のスペース一杯になるようにテキストが拡大、縮小されます。
  • XML フォント: フォントがリソースタイプとして完全にサポートされました。XML レイアウトでフォントを使用したり、XML でフォント ファミリーを定義できるようになりました。
  • ダウンロード可能なフォントと絵文字: ダウンロード可能なフォントを使うと、APK にフォントを含める代わりに、共有プロバイダからフォントを読み込むことができます。プロバイダとサポート ライブラリは、フォントのダウンロードを管理し、アプリ間でフォントを共有できるようにしています。ダウンロード可能な絵文字でも同じ実装がサポートされているため、端末に組み込まれた絵文字に制限されることなく、アップデートされた絵文字を利用できます。
  • アダプティブ アイコン: 端末メーカーが選択したマスクに応じて、システムによって異なる形状で表示されるアダプティブ アイコンを作成できます。さらに、アイコンとのインタラクションがアニメーションで表示されます。アダプティブ アイコンは、ランチャー、ショートカット、設定、共有ダイアログ、オーバービュー画面で利用できます。

端末モデルごとに異なる図形を表示するアダプティブ アイコン
  • ショートカットの固定: アプリ ショートカットとホーム画面ウィジェットは、ユーザーのエンゲージメントを向上させる格好のツールで、アプリからショートカットとウィジェットをランチャーに固定することができます。また、ショートカットを作成しやすいように、専用のアクティビティを追加することもできます。このアクティビティには、カスタムのオプションと確認機能を搭載できます。
  • 広色域アプリ: イメージング アプリは、広色域ディスプレイを搭載した新しい端末の機能を完全に活用できるようになります。広色域イメージを表示するアプリは、マニフェスト ファイルに(アクティビティごとに)フラグを設定し、埋め込み広色域プロファイル(AdobeRGB、Pro Photo RGB、DCI-P3 など)を使ってビットマップを読み込みます。
  • WebView の機能強化: Android Oreo の WebView では、デフォルトでマルチプロセス モードが有効になっており、アプリでエラーとクラッシュを制御するための API も追加されています。また、アプリの WebView オブジェクトで Google セーフ ブラウジングによる URL の確認が行えるようにもなっています。
  • Java 8 言語 API とランタイム最適化: 新しい java.time API などのいくつかの新しい Java 言語 API が Android でサポートされます。さらに、Android ランタイムが高速化されており、アプリのベンチマークによっては、最大 2 倍早くなっています。


これらの機能や、その他の新機能の詳細は、developer.android.comAndroid 8.0 Oreo サイトをご覧ください。また、デベロッパー向け新機能の概要は、Android Oreo の新機能を紹介した動画をご覧ください。

アプリの準備をお忘れなく


まだ準備ができていないという方は、早速少し時間を割いてアプリをテストし、Android Oreo にアップグレードしたユーザーに期待どおりのアプリを提供できるようにしましょう。

それには、Android Oreo が動作する端末かエミュレータに、Google Play にある現在のアプリをインストールして、ユーザーフローのテストを行います。アプリが適切な見栄えで動作し、Android Oreo の動作の変更点に問題なく対応できるようにしてください。特に、バックグラウンドの位置情報の制限通知チャンネル、そしてネットワークセキュリティ識別子に関する変更点に注意してください。

問題を解決できたら、ユーザーが Android 8.0 Oreo を受信し始めたときにアプリが利用できるように、Google Play のアルファ版、ベータ版、または本番チャンネルでアプリのアップデートを公開します。

Android Studio で開発をスピードアップ


Android Oreo の新しい API を使ってビルドを行う準備ができた方は、ベータ版チャンネルからダウンロードできる最新版の Android Studio 3.0にアップデートすることをおすすめします。Android Studio 3.0 では、アプリのパフォーマンス プロファイリング ツールの改善、Kotlin プログラミング言語のサポート、Gradle ビルドの最適化が行われています。さらに、Instant AppsXML フォントダウンロード可能フォントアダプティブ アイコンなどで開発も簡単になります。
アプリの XML フォント リソースのプレビューなど、Android Oreo の機能を使って開発するためのツールを含む Android Studio 3.0

また、Android サポート ライブラリ 26.0.2へのアップデートもおすすめします。これは、Google の Maven レポジトリで公開されています。合わせて、SDK Manager から入手できる最新の SDK、ツール、エミュレータ システム イメージのアップデートもご利用ください。

これから Android Oreo の開発を始めようとしている方は、まず移行ガイドをご覧ください。手順や、行う必要がある設定変更の概要が書かれています。

正式な Android 8.0 API でコンパイルするには、プロジェクトの compileSdkVersionを API 26 にアップデートします。また、アプリの targetSdkVersionを API 26 に更新して、Android Oreo に固有の動作の変更をオプトインし、アプリのテストを行うことをおすすめします。Android Oreo でビルドするための環境設定の詳しい手順については、移行ガイドをご覧ください。

アップデートを Google Play に公開する


Google Play では、API 26 でコンパイルしたアプリや、API 26 をターゲットにしたアプリを受け付けています。準備ができ次第、APK のアップデートをアルファ版、ベータ版、または本番チャンネルで公開しましょう。

Android Oreo だけでなく、古いバージョンでもアップデートしたアプリが問題なく動作することを確認しておきましょう。まずは、Google Play のベータ版テスト機能を使って、少人数のユーザーから初期段階でのフィードバックを入手し、段階的にロールアウトすることをおすすめします。皆さんのアプリのアップデートを楽しみにしています。

Android Oreo の今後


Developer Preview の Issue Tracker は近日中にクローズされますが、フィードバックは今後も大歓迎です。AOSP Issue Tracker で Android 8.0 に対して新しく問題を送信してください。

Android O Developer Preview やパブリック ベータに参加してくださったたくさんのデベロッパーとアーリー アダプターの皆さん、本当にどうもありがとうございました。皆さまから送られたすばらしいフィードバックやたくさんの問題は、ユーザーやデベロッパーにとってすばらしい Android Oreo プラットフォームを生み出すために役立ちました。



Reviewed by Takuo Suzuki - Developer Relations Team

新機能とベスト プラクティスを活用し、Google Play でサブスクリプション ビジネスを構築する

$
0
0
この記事は プロダクト マネージャー、Tom Grinsted による Android Developers Blog の記事 "Build a subscriptions business on Google Play with these new features and best practices" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

サブスクリプションは持続可能な収入源になり得るため、自信を持って長期的なビジネスの拡大に投資できるようになります。Google Play では、サブスクリプション アプリが急速に拡大しています。定期購入のユーザー数は昨年 1 年間で倍増し、その額は過去 3 年間で 10 倍になっています。成長著しいサブスクリプション ビジネスをさらに支援するため、I/O 2017 では Google Play Console のサブスクリプション ダッシュボードを紹介しました。そして新たに獲得、維持、キャンセルに対応した新しい 3 つの定期購入レポートが追加されました。これによって、データを理解し、情報に基づくビジネスの決定ができるようになります。以下では、新機能とサブスクリプション ビジネスを拡大するための最新ベスト プラクティス、そして Google Play で成功を収めている他のデベロッパーの事例を紹介します。

Google Play Console で利用できる新しいサブスクリプション レポート

Google Play Console の 3 つの新しいサブスクリプション レポート

獲得レポートを使うと、Adwords や UTM タグ キャンペーンなどの異なる獲得チャンネルを評価できます。どのチャンネルやキャンペーンが新しいサブスクリプション 購入者をもっとも多く獲得できているかを判断する際に役立ちます。

維持レポートには、サブスクリプション 購入者の維持期間が表示され、対象をカスタマイズすることも可能です。さまざまなサブスクリプション プロダクトの比較、無料試用サービスの終了などの主要なイベントのグラフ表示、意思決定を迅速に行うための予測値の表示なども簡単に行うことができます。

最後は、キャンセル レポートです。この詳細なキャンセル データから、ユーザーがキャンセルしたタイミング、ユーザーが自分でキャンセルを選んだ場合などの自発的キャンセルか、支払いに失敗した場合など非自発的理由か、などがわかります。ユーザーがキャンセルと合わせてアンインストールを行ったのかどうかもわかります。

Google Play Console の改善は、これからも続きます。サブスクリプション機能の改善についてアイデアやフィードバックをお持ちの方は、どうぞお知らせください

新しい Google Play Billing Library の活用


これらの機能を活用するには、アプリの定期購入の支払手段として Google Play Billing を利用する必要があります。Play Billing は、新しい Google Play Billing Libraryを利用すると簡単に実装できます。Play Billing もアップデートされており、アプリの公開時ではなく、購入者が購入処理を開始しようとしたタイミングで課金パーミッションが強制されるようになっています。つまり、Play Billing がサポートされている国とサポートされていない国の両方で 1 つの APK を 公開できます(サポートされていない国向けに課金パーミッションを使わない APK を別管理する必要はありません)。アプリ内購入を提供する前に、課金がサポートされているかどうかをまず確認することを忘れないようにしましょう。

「サブスクリプション 第一」の企業になり、Google Play で成功を収める


デベロッパーが Google Play でのサブスクリプション の提供に慣れていくにつれ、成功を収めているパートナーは、効果的な対策について多くのことを学んでいます。サブスクリプション アプリについて専門的な知識を持つパートナー マネージャーの Niko Schröer は、成功を収めるサブスクリプション 企業になるために役立つ新しい投稿を Medium に掲載しています。その投稿には、2017 年 7 月に公開された Android の定期購入者についての詳細なユーザー リサーチ [PDF]へのリンクがあります。このドキュメントは、ユーザーが定期購入プロダクトに何を求めているかを理解するうえで役立ちます。サブスクリプションに関する新しいベスト プラクティスも公開されており、Google Play で成功するための秘訣と併せて Playbook アプリで読むこともできます。

他のデベロッパーはどうやって Play のサブスクリプションで成功を収めているか


シンガポールをベースとする動画アプリ Vikiは、サブスクリプション を使って持続可能、予測可能な収入ストリームを構築しており、それによって独自コンテンツへの投資やユーザーへの上質な体験の提供を実現しています。サブスクリプション による合計収益はこの 1 年で 200% 以上、中東やラテンアメリカなどの新興市場では 700% 増加しています。Viki のプロダクトおよびエンジニアリング担当上級副社長である Alex Chan 氏の話をお聞きください。

中東と北アフリカで人気の音楽サービスである Anghamiのデベロッパーは、ユーザー インターフェースの実験とお試し価格によってアプリの定期購入者数を増加させました。Anghami はある宣伝期間にお試し価格を使い、1 日あたりの平均登録者数と比較して新規登録者を 400% 増加させました。詳しくは、Anghami が定期購入を成功させた方法をご覧ください。
このブログ投稿はどのくらい役に立ちましたか?

Reviewed by Hak Matsuda - Developer Relations Team

複数バージョンの Chrome を共存させる

$
0
0
この記事は “ビット職人”、Greg Thompson による Chromium Blog の記事 "Run multiple versions of Chrome side-by-side" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ユーザーが Chrome をインストールする場合、デフォルトでは、公開されているビルドの中で、もっとも安定し、サポートが充実しているものを受け取ることになります。ただし、従来より、Chrome のファンやウェブ デベロッパーの皆さんは、Chrome のベータ版や Dev 版などのリリース前パッケージをインストールして、新しい Chrome の機能を試すことができます。今までは、安定版の Chrome がインストールされているコンピュータに、このような正式リリース前の Chrome をインストールすることはできませんでした。そのため、デベロッパーの皆さんは、次のバージョンの Chrome でサイトをテストするか、現在ユーザーが見ているサイトを表示させるか、どちらかを選択しなければなりませんでした。

本日(*原文公開当時)より、Chrome ベータ版と Chrome Dev 版は、安定版の Chrome と同じ Windows コンピュータにインストールして同時に実行できるようになりました。これによって、デベロッパーの皆さんは、複数のバージョンの Chrome を使ってサイトを簡単にテストできるようになります。現在のところ、Windows、Android、Linux で複数バージョンの Chrome の共存が可能になっており、今後のリリースで、他のプラットフォームにも対応する予定です。


同じ Windows コンピュータで Chrome、Chrome ベータ版、Chrome Dev 版が共存可能に 

Chrome ベータ版や Chrome Dev 版をインストールするには、Chromium リリース チャンネルページにアクセスします。すでに Chrome の Dev 版やベータ版をインストールしており、安定版の Chrome と共存させたい方は、一度アンインストールし、このページから再インストールする必要があります。アンインストールする前に Chrome にログインしておくと、ブックマークや設定などのデータを簡単に移行できます。また、Chrome の Dev 版やベータ版で問題を見つけた方は、フィードバックをお送りください


Reviewed by Eiji Kitamura - Developer Relations Team

DevFest 2017 が日本各地で開催されます

$
0
0



DevFest は、Google Developer Group(GDG)コミュニティによって世界各地で開かれるデベロッパー向けイベントです。参加者は AndroidFirebaseGoogle Cloud PlatformTensorFlowによる機械学習、Webなどの Google のデベロッパー テクノロジーに関する技術情報、知識やアイデアを共有できます。

それぞれの DevFest は、主催するコミュニティとその地域のニーズに沿ったユニークな内容となり、日本では下記のイベント企画がされています。情報は追加、更新されていきますので、ブログ記事やツイッターをご確認ください。



DevFest Tokyo 2017
日時:2017 年 10 月 9 日(祝)、10:00 - 17:00(仮)
場所:国際交流館 プラザ平成(東京都江東区青海2-2-1)
参加費:無料
定員:1,000 名
対 象 者:Android, Web, GCP (ML), Firebase 技術者および学生
主 催:GDG Tokyo, Shibuya.apk, DroidKaigi, 日本Androidの会, golang.tokyo, html5j, GTUG Girls, Women Who Go, XR 女子部, Droid Girls, Geek Women Japan, GCPUG, TFUG, TangoWG




■ DevFest Kyoto 2017
日時:2017 年 11 月 4 日
場所:京都市内
参加費:無料
定員:40 名
主催:GDG 京都、KyotoGAS



■ GDG温泉︎ in 湯布院 Devfest
日時:2017 年 11 月 3 日(祝)〜 11 月 5 日(日)
場所:由布市湯布院町川上茶屋の上 3366-4 日本文理大学 湯布院研修所
参加費:17,000円(2 泊 3 日 5 食付き)
定員:20 名
主催:GDG九州


Posted by Takuo Suzuki - Developer Relations Team

Google が Android 版 Google I/O 2017 のソースを公開

$
0
0
この記事は Shailen Tuli による Android Developers Blog の記事 "Google releases source for Google I/O 2017 for Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

本日(*原文公開当時)、Google I/O 2017 Android 公式アプリのソースコードを公開しました。

今年のアプリは、既存機能が大幅に変更されており、いくつかの新機能が追加されています。また、技術スタックに Firebaseを使うように拡張されています。本投稿では、主なアプリの変更点や設計上の検討事項について紹介します。

2017 年版アプリのいちばんの目玉機能は、イベント予約システムです。これは、参加者個人の時間を節約し、効率的にカンファレンスに参加できるようにするものです。登録済みの参加者は、カンファレンスの前および開催中にセッションを予約したり順番待ちリストに登録することができ、予約しておけば長い列に並ばず、スムーズにセッションに入場できました。予約データは参加者のカンファレンス バッジと同期されるので、イベント スタッフは NFC 対応スマートフォンで予約を確認できます。予約機能はとても好評だったうえに、予約データに応じて I/O の前や最中にセッション会場の大きさを変更して実際の需要に合わせて座席数を調整するなど、イベント スタッフにも役立ちました。

予約機能は、Firebase Realtime Database(RTDB)と Cloud Functions for Firebaseで実装されています。RTDB を使うと、コードにリスナーを実装してデータベースの更新を受信するだけで、簡単にユーザーの端末間で同期をとることができます。また、RTDB ではすぐに利用できるオフライン サポートも提供されています。そのため、たとえ移動中でネットワーク接続が断続的であっても、カンファレンスのデータを利用できます。Cloud Function は、ユーザーの予約リクエストをバックグラウンドで処理します。この際、トランザクションを使っているので正しい状態が保証されます(いたずら好きなユーザーがたくさんの座席を確保できないようになっています!)。また、イベントバッジ システムとも連動しています。

昨年と同様、抽象化レイヤとしてすべてのアプリのデータに対して ContentProvider を使っています。これは、RTDB データと ContentProvider を統合する方法が必要になるということを意味します。つまり、データに 2 つのローカル キャッシュがあるので、それをうまく制御しなければなりません。1 つ目は、ContentProvider 経由でアクセスする既存のローカル SQLite データベース、2 つ目は、RTDB がオフライン アクセスに利用するために作成するローカル キャッシュです。これを実現するために、すべてのアプリのデータを ContentProvider に管理させることにしました。RTDB でユーザーの予約データが変化した場合、必ず ContentProvider を更新し、これを常に信頼できるアプリの単一データソースとします。この場合、 RTDB へのコネクションをオープンしておく必要があるのは 1 つの画面(SessionDetailActivity)だけになります。これは、ユーザーが予約を管理することができる画面です。アプリのその他の部分に表示される予約データは、ContentProvider が提供しています。オフライン モードや、RTDB への接続状態が悪い場合や遅い場合は、ContentProvider が提供する最新の既知の予約状態を表示します。

また、IOSched 全体の同期ロジックに RTDB を組み込むよいパターンを見つけ出すことも必要でした。特に、RTDB では、アプリで使っている ping-and-fetch 同期モデルとはまったく異なるアプローチが使われています。ユーザーデータの端末間の同期や、ウェブおよび iOS クライアント間の同期には Cloud Endpointsの利用を継続することにしました(データ自身は Datastoreに格納されます)。RTDB は元々データを同期できるようになっていますが、ユーザーの予約データが確実にすべての端末に存在するようにしたいと考えました。 アプリがフォアグラウンドにない場合にもです。 RTDB の予約データを同期フローに組み込む部分では、Cloud Function を利用しました。RTDB 内のユーザーの予約データが変更されると、Cloud Function によってエンドポイントが更新され、Firebase Cloud Messagingのダウンストリーム メッセージがトリガーされてすべてのユーザーの端末に送られます。その後、スケジュールによるデータの同期が行われます。

今年のアプリには、I/O の進行状況を随時ユーザーに知らせる フィード機能もありました(アプリのユーザーのほとんどは現地にいなかったため、フィードがカンファレンスの状況を伝える窓になりました)。このフィード機能も RTDB を利用しており、単純な CMS を使ってサーバーにデータをプッシュしています。RTDB のフィードデータを Cloud Function で監視し、サーバー上でフィードデータが更新されると、Function が Cloud Messaging のダウンストリーム メッセージをクライアントに送信します。クライアントでは、新しいフィードアイテムが視覚的にユーザーに提示されます。

2015 年と 2016 年 の IOSched には、MVP アーキテクチャが採用されていましたが、今年も引き続き、このアーキテクチャを利用しています。このアーキテクチャによって、関心の分離やテストの促進が実現でき、一般的にコードも見やすくなって保守性も上がります。フィード機能では、Android Architecture Blueprintsから着想を得たさらに軽量な MVP 実装を試してみることにしました。これは、必要となるモジュール性を提供しつつ、とても簡単に概念化できるものです。ここでは、教育的な面と実用的な面の両方を目標とし、デベロッパーに別の MVP パターンを示すとともに、この機能のニーズを満たすアーキテクチャも提示したいと考えました。

また、IOSched で初めて Firebase Remote Configが多用されました。かつては、WiFi 情報、シャトル便のスケジュール、ライドシェアリングの割引コードなど、セッション以外のデータがカンファレンスの前や最中に変更されたことをユーザーにお知らせするのは難しいことでした。単にアプリ内のデフォルト値をアップデートできるようにしたいだけなので、アプリのアップデートを強制するのは現実的ではありません。この問題は、Remote Config を使って簡単に解決できました。

最終的には、3 層のシステムでユーザーに変更を通知する形になりました。
  1. カンファレンス データやユーザーデータの変更は、Cloud Messaging とデータ同期経由で伝達されます(ping-and-fetch モデル)。
  2. フィードデータの変更は、RTDB で管理します。
  3. アプリ内定数の変更は、Remote Config で管理します。

今後の計画

2017 年版のコードがリリースされましたが、今後実施する作業も残っています。まず、バックグラウンド処理の最新パターンに従うようにコードを更新する予定です(そして、アプリを「O」対応にします)。さらに、Android の Architecture Componentsを採用して、アプリ全体の設計をシンプルなものにする予定です。デベロッパーの皆さんは、コードの変化を GitHubでフォローできます。



Reviewed by Takeshi Hagikura - Developer Relations Team

AMP Ads の読み込みがさらに高速化

$
0
0
この記事は AMP Project プロダクト マネージャー、Vamsee Jasti による Accelerated Mobile Pages Project の記事 "Even Faster Loading Ads in AMP" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

以前にもお話ししたように、ウェブページでの広告の動作に対処しなければ、ウェブのすべてを改善することにはなりません。今年の Google I/O では、AMP 広告についてのセッションを開催し、AMP ページで広告の基本機能をサポートするところから、ユーザーやサイトオーナー、広告主にとって本当に優れた広告エクスペリエンスを実現する AMP ページに至るために必要な道のりについてお話ししました。セッションで説明したように、これを達成するまでには次の 3 つのフェーズがあります。


最初のフェーズは、2 年ほど前に AMP Project が開始されたときに完了しています。そして先週時点でフェーズ 2 が完了し、このロードマップのマイルストーンをもう 1 つ達成できました。本投稿の以降の部分では、フェーズ 2 で実現したことを説明します。

AdZerk、DoubleClick、AdSense、TripleLift などの主要な広告ネットワークは、すでに AMP Ads を提供してフェーズ 2 で構築されたインフラストラクチャのメリットを活用しています。これによって、AMP Ads のレンダリングが高速になるだけでなく、AMP ページに表示される通常の広告も早くなっています。

Fast Fetch のリリース

フェーズ 2 で追加された一番の目玉機能が「Fast Fetch」です。Fast Fetch を使うと、広告をリクエストするタイミングと、広告のレスポンスをレンダリングするタイミングを分離できます。これによって、ページのライフサイクルのかなり早い段階ですべてのスロットの広告をリクエストでき、その広告はユーザーが見る直前までレンダリングされなくなります。

これは、私たちが「Delayed Fetch」と呼んでいる従来の広告リクエスト メカニズムの対局にあたるものです。Delayed Fetch では、広告のリクエストとレンダリングは 1 回のアクションで行われます。そのため、広告が読み込まれている間、ユーザーには「読み込みインジケータ」が表示されることになります。Delayed Fetch には、他にも制約があります。通常のページのコンテンツの読み込みと競合するのを避けるため、ランタイムは少なくとも 1 秒間はページ上の次の広告スロットをリクエストしません。


Fast Fetch では、ページのライフサイクルのかなり早い段階で広告がリクエストされるため、ページのレンダリングや、広告サーバーでのクリエイティブの選択が並列に実行されます。

Fast Fetch は、Delayed Fetch と比較して 50 パーセンタイルで 850 ミリ秒、90 パーセンタイルで 2.7 秒高速です。


AMP Ads の協調レンダリング

広告レスポンスが AMP 形式である場合(AMP Ads)、AMP ランタイムは広告を即座にレンダリングします。レスポンスが通常の広告である場合、ランタイムはページの残りのコンテンツが読み込まれるのを待つ必要があります。AMP 広告ではパフォーマンスが保証されているのでそのようなことが可能ですが、非 AMP 広告にはそのような保証はありません。



DoubleClick と AdSense の実験によると、AMP Ads は 50 パーセンタイルで 1.6 秒、90 パーセンタイルで最大 5 秒早く読み込まれます。


広告が画面に早く表示されるほど、広告の視認性も向上します。ブランドが多くの人の目に触れることになるので、これは広告主にとって有益です。また、視認性の向上によってユーザーが広告を開くチャンスが増えるため、成果型の広告主にとっても有益です。

Fast Fetch の新機能のリリース

多くのサイトオーナーが、主要サイトのコンテンツを AMP 形式で提供する実験を行っています。そのようなサイトオーナーの作業をサポートするため、AMP の Fast Fetch には、さらに高度な広告機能が追加される予定となっています。たとえば、次のようなものです。
  • AMP ページでの競合広告の排除やブロック
  • 設定した頻度で広告を更新する機能
  • リアルタイムで広告リクエストに広告サーバーのターゲット情報を含める拡張機能のサポート

    サイトオーナー(または広告主)の皆さまへ

    DoubleClick と AdSense のおかげで、AMP ページから広告リクエストが送られる際に、一定の条件を満たす広告は自動的に AMP に変換されます。AMP に変換可能な形式が増えるにつれて、自動変換される広告も増加することが考えられます。その結果、何も変更しなくても、皆さまのページに高い視認性とクリックスルー率を持つ広告が提供されることになります。

    クリエイティブを制作している広告主(またはサイトオーナー)の皆さまへ

    広告を制作している方は(サイトオーナーであるか広告主であるかにかかわらず)、AMP Ads への切り替えをご検討ください。視認性やユーザー エクスペリエンスが高い高速な広告によるメリットを受けることができます。まずは、社内のクリエイティブ制作者に、こちらの AMP Ads デベロッパーのよくある質問を確認してもらってください。

    クリエイティブ アセットの制作を外注している場合は、AMP クリエイティブの制作に特化した JoyStick Interactiveなどの代理店に依頼することができます。広告制作ツールを使ってアセットを作成している場合は、Celtra の Ad Creator を使って AMP Ads を制作することをご検討ください。Google Web Designerなどの他のツールでも、近日中に AMP 広告がサポートされます。

    広告技術プラットフォームの皆さまへ

    DoubleClick や Adsense の広告タグは、Fast Fetch を利用して劇的にレイテンシを削減しています。私たちは、すべての広告ネットワークが Fast Fetch に移行することを望んでいます。移行をサポートするガイドはこちらです。AMP Ads に署名したい方は、Cloudflare の Firebolt サービスを利用できます。自分で署名したい方は、Githubをご覧ください。

    「Cloudflare Firebolt を使うと、どんな広告ネットワークでも、署名した広告を世界に提供できます。追加の作業はほとんど発生しません」と Cloudflare のプロダクト戦略責任者である Dane Knecht 氏は述べています。「私たちは、インターネットをよりよくするという使命の一環として、Firebolt のグローバルな AMP 広告エクスペリエンスをさらに高速で安全なものへと強化しています。それによって、コンバージョン率を向上させることができます」


    また、AMP Ads は DoubleClick Ad Exchange(Real Time Bidding 経由)をサポートしており、DSP は RTB 経由で AMP 広告を提供できるようになっています。

    AMP での広告は大きく進化しており、フェーズ 3 に入ったことをうれしく思っています。このフェーズでは、次のようなことを行う予定です。 


    • 自動変換して AMP Ads を配信できるよう広告ネットワークを強化 
    • 広告サーバーでカスタムメイド AMP Ads のアップロードと配信をサポート 
    • クリエイティブ制作者が AMP Ads を制作する際に役立つ機能の構築 
    • デフォルトで AMP Ads を出力するように、さらに多くの広告制作ツールと連携



    いつものように、皆さまのフィードバックは大歓迎です。ウェブの進化に向けて、上記の取り組みにご協力いただける方もお待ちしています。


    Reviewed by Yoshifumi Yamaguchi - Developer Relations Team

    Android O でもっと安全にアプリを入手できるようにする

    $
    0
    0
    この記事は Android Security プロダクト マネージャー、Edward Cunningham による Android Developers Blog の記事 "Making it safer to get apps on Android O" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

    鋭い観察力を持った Android O ユーザーの皆さんは、[Allow unknown sources] という設定がなくなっていることにお気づきでしょう。これは、Android の初期のころから存在していた設定で、Google Play などの初期登録されているストア以外からアプリをインストールしやすくするものです。本投稿では、新しく追加された Install unknown appsパーミッションと、これが Android ユーザーとデベロッパーの双方にもたらすセキュリティ上のメリットについて説明します。

    今年は、常に動作して端末を被害から守る包括的なセキュリティ サービスである Google Play プロテクトが導入されました。Google Play は、依然として Android ユーザーがアプリをダウンロードできる安全な場所です。有害な可能性があるアプリ(PHA)の大半は、サードパーティの提供元に由来しています。

    PHA の作成者がよく使うのは、悪意のあるダウンローダー経由でアプリを配信する方法です。たとえば、悪意のあるコードを含まないゲームアプリから、重要なセキュリティ アップデートに偽装した PHA をインストールするように通知します(悪意のあるダウンローダーの詳細については、2016 年 Android セキュリティ総括をご覧ください)。提供元不明のアプリのインストールを有効にしたユーザーは、このような偽装した動作の被害に遭いやすくなります。

    左(Android O 以前): システムアップデートに偽装した PHA のインストール画面。
    右(Android O): ユーザーは、PHA のインストール前に、インストールを行うアプリにパーミッションを付与する必要があります。

    Android O では、Install unknown appsパーミッションが追加され、提供元不明のアプリのインストールが安全になっています。このパーミッションは、他のランタイム パーミッションと同じく、インストールしようとするアプリに関連付けられています。そのため、ユーザーがそのインストール提供元を利用するパーミッションを付与してから、アプリのインストールの確認画面が表示されるようになります。Android O 以降を実行している端末では、あらかじめ許可を得ていない悪意のあるダウンローダーがユーザーを欺いてアプリをインストールさせることはできません。

    この新しいパーミッションによって、ユーザーにとっての透明性や制御範囲が向上し、信頼できる提供元によるアプリのインストールを有効化する処理も効率化されます。Settings アプリには、ユーザーがインストールを許可した提供元不明のアプリの一覧が表示されます。特定のアプリに付与したパーミッションは、いつでも取り消すことができます。

    提供元不明のアプリのインストールを許可したアプリはいつでも確認できます。パーミッションを付与する処理を簡単にするため、セットアップのフローの中でユーザーをパーミッション画面に飛ばすこともできます。


    デベロッパーにとっての変更点

    Package Installer 経由で別のアプリをダウンロードおよびインストールするアプリでこの新しい動作を利用するには、いくつかの変更が必要になる場合があります。targetSdkLevelが 26 以降のアプリで別のアプリをインストールするには、次のようにしてマニフェスト ファイルに REQUEST_INSTALL_PACKAGESパーミッションを含める必要があります。
    <uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />

    このパーミッションを宣言していないアプリは、別のアプリをインストールすることはできません。これは、別のアプリのインストールを想定していないアプリには便利なセキュリティ保護になります。ACTION_MANAGE_UNKNOWN_APP_SOURCES Intent アクションを利用して、実際にインストールを行う前に Install unknown appsパーミッション画面を表示することもできます。また、PackageManager の canRequestPackageInstalls() API を利用して、このパーミッションの状態を問い合わせることもできます。

    Google Play で配布するアプリから別のアプリのインストールやアップデートを行う場合は、Play ポリシーが適用されることも忘れないようにしてください。大半の場合、このような動作は不適切です。Play Store のアプリの掲載情報ページへのディープリンクを使うようにしてください。

    提供元不明のアプリのインストールについての詳しい情報は、アップデートされた公開ガイドをご覧ください。また、Android O で強化されたセキュリティについては、他の投稿にもご注目ください。


    Reviewed by Yuichi Araki - Developer Relations Team

    ConstraintLayout がもたらすパフォーマンスのメリットを理解する

    $
    0
    0
    この記事はデベロッパー プログラム エンジニア、Takeshi Hagikura  による Android Developers Blog の記事 "Understanding the performance benefits of using ConstraintLayout" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
    
    昨年の Google I/O で発表されてからも、ConstraintLayoutのレイアウトの安定性やレイアウト エディタでのサポートの改善は続いています。Chain の導入や Ratio によるサイズ設定など、ConstraintLayoutならではの新機能も追加され、さまざまな種類のレイアウトが作りやすくなっています。こういった機能に加え、ConstraintLayoutには大きなパフォーマンス上のメリットがあります。本投稿では、このパフォーマンスの改善がもたらすメリットについて説明します。

    Android がビューを描画する方法

    ConstraintLayoutのパフォーマンスを深く理解するため、まずは Android がどのようにビューを描画しているのかについて見てみましょう。

    ユーザーが Android のビューにフォーカスを当てると、Android フレームワークの指示でビューが描画されます。この描画プロセスは、次の 3 つのフェーズで構成されます。

    1. Measure
      システムが上から順にビューツリーをたどり、各 ViewGroupとビュー要素の大きさを決定します。ViewGroupを測定する際は、その子要素も測定します。
    2. Layout
      再度、上から順にビューツリーをたどり、各 ViewGroupについて測定フェーズで求めたサイズから子要素の位置を決定します。
    3. Draw
      システムはもう一度上から順にビューツリーをたどります。ビューツリーの各オブジェクトに対して Canvasオブジェクトが作成され、GPU に描画コマンドのリストが送られます。このコマンドには、最初の 2 つのフェーズで求めた ViewGroupおよび Viewオブジェクトのサイズと位置が含まれます。
    図 1.  Measure フェーズでビューツリーをたどる例

    描画プロセス内の各フェーズでは、上から順にビューツリーをたどる処理が必要です。そのため、ビュー階層に別のビューが埋め込まれている(ネストしている)ビューが多いほど、端末がビューを描画する際に必要となる時間と計算能力が増加します。つまり、Android アプリのレイアウトでフラットな階層を維持すれば、高速で反応の早いユーザー インターフェースを実現できます。

    従来型のレイアウト階層にかかるコスト

    以上の説明に留意した上で、LinearLayoutオブジェクトと RelativeLayoutオブジェクトを使って従来型のレイアウト階層を作成してみましょう。



    図 2. サンプル レイアウト

    ここでは、上のイメージのようなレイアウトを作成することを考えてみます。従来型のレイアウトを使って作成する場合、要素の階層を含む XML ファイルは次のようになります(この例では、属性は省いています)。
    <RelativeLayout>
    <ImageView />
    <ImageView />
    <RelativeLayout>
    <TextView />
    <LinearLayout>
    <TextView />
    <RelativeLayout>
    <EditText />
    </RelativeLayout>
    </LinearLayout>
    <LinearLayout>
    <TextView />
    <RelativeLayout>
    <EditText />
    </RelativeLayout>
    </LinearLayout>
    <TextView />
    </RelativeLayout>
    <LinearLayout >
    <Button />
    <Button />
    </LinearLayout>
    </RelativeLayout>

    通常、このような種類のビュー階層には改善の余地がありますが、どのような形であっても、いくつかのネストしたビューを作成する必要があります。

    先ほど説明したように、ネストした階層はパフォーマンス悪化の原因となる場合があります。では、ネストしたビューが実際にどのように UI のパフォーマンスに影響するかについて、Android Studio の Systraceツールを使って見てみましょう。各 ViewGroupConstraintLayoutRelativeLayout)についてプログラムから Measure フェーズと Layout フェーズを呼び出し、それぞれが実行されている間に Systrace が呼び出されるようにします。次のコマンドを実行すると、時間がかかっているイベントが記録された、HTML ファイルが生成されます。これには、20 秒間に発生した標準より大幅に時間がかかっている Measure や Layout のパスなどが含まれます。
    python $ANDROID_HOME/platform-tools/systrace/systrace.py --time=20 -o ~/trace.html gfx view res

    Systrace の使用方法の詳細は、Systrace で UI のパフォーマンスを分析するためのガイドをご覧ください。

    Systrace は、このレイアウトに関する(たくさんの)パフォーマンスの問題を自動的に報告するだけでなく、それを修正する方法も提案してくれます。[Alerts] タブをクリックすると、このビュー階層の描画には、 Measure フェーズと Layout フェーズで 80 回ものパスで標準より大幅に時間がかかっていることがわかります。

    Measure フェーズと Layout フェーズでコストがかかる多くの処理が呼び出されるというのは、理想からはほど遠いものです。描画に必要な作業が多すぎると、ユーザーが気づくようなフレーム スキップが発生する可能性もあります。結論として、このレイアウトはパフォーマンスが悪いことがわかります。これは、ビュー階層がネストされていることと、各子要素について 2 回測定を行う必要があるという RelativeLayoutの特性が原因となっています。
    図 3. Systrace で RelativeLayoutを利用したレイアウトについてのアラートを確認

    この測定に使ったコードは GitHub レポジトリから確認できます。

    ConstraintLayout オブジェクトがもたらすメリット

    ConstraintLayoutを使ってレイアウトを作成すると、XML ファイルには次のような要素が含まれることになります(今回も属性は省略します)。
    <android.support.constraint.ConstraintLayout>
    <ImageView />
    <ImageView />
    <TextView />
    <EditText />
    <TextView />
    <TextView />
    <EditText />
    <Button />
    <Button />
    <TextView />
    </android.support.constraint.ConstraintLayout>

    この例からわかるように、レイアウトの階層は完全にフラットになります。ConstraintLayoutを使うと、View要素や ViewGroup要素をネストさせずに複雑なレイアウトを作成できます。

    たとえば、レイアウトの中ほどにある TextViewEditTextに注目してみましょう。
    RelativeLayoutを使う場合は、新しい ViewGroupを作成して EditTextと TextView の縦方向の位置を合わせる必要があります。
    <LinearLayout
    android:id="@+id/camera_area"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="horizontal"
    android:layout_below="@id/title" >

    <TextView
    android:text="@string/camera"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_gravity="center_vertical"
    android:id="@+id/cameraLabel"
    android:labelFor="@+id/cameraType"
    android:layout_marginStart="16dp" />

    <RelativeLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content">

    <EditText
    android:id="@+id/cameraType"
    android:ems="10"
    android:inputType="textPersonName"
    android:text="@string/camera_value"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:layout_centerVertical="true"
    android:layout_marginTop="8dp"
    android:layout_marginStart="8dp"
    android:layout_marginEnd="8dp" />
    </RelativeLayout>
    </LinearLayout>

    しかし、ConstraintLayoutを使う場合は、TextViewのベースラインを EditTextと合わせるという制約を追加するだけで同じ効果が得られます。別の ViewGroupを作成する必要はありません。
    図 4. EditText と TextView の制約

    <TextView

    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    app:layout_constraintLeft_creator="1"
    app:layout_constraintBaseline_creator="1"
    app:layout_constraintLeft_toLeftOf="@+id/activity_main_done"
    app:layout_constraintBaseline_toBaselineOf="@+id/cameraType" />

    ConstraintLayoutを使ったレイアウトに対して Systrace ツールを実行すると、同じ 20 秒間でコストがかかる Measure および Layout での標準より時間がかかっているパスがかなり少なくなっていることがわかります。このパフォーマンスの向上は当然です。ビュー階層がフラットになっているからです。
    図 5. Systrace で ConstraintLayoutを利用したレイアウトについてのアラートを確認

    なお、先ほどのレイアウトの ConstraintLayout版は、レイアウト エディタだけを使い、XML を直接編集することなく作りました。

    パフォーマンスの違いを測定する

    ConstraintLayoutRelativeLayoutの 2 種類のレイアウトについて、Android 7.0(API レベル 24)で導入された OnFrameMetricsAvailableListenerを使ってすべての Measure と Layout のパスにかかる時間を分析してみました。このクラスを使うと、アプリの UI レンダリングについてフレームごとのタイミング情報を収集できます。

    次のコードを呼び出すと、フレームごとの UI アクションの記録を開始します。
    window.addOnFrameMetricsAvailableListener(
    frameMetricsAvailableListener, frameMetricsHandler);

    タイミング情報が利用できるようになると、frameMetricsAvailableListener() コールバックが呼び出されます。今回は、Measure と Layout のパフォーマンスを取得したいので、実際のフレームの所要時間を取得する際に FrameMetrics.LAYOUT_MEASURE_DURATIONを呼び出します。
    Window.OnFrameMetricsAvailableListener {
    _, frameMetrics, _ ->
    val frameMetricsCopy = FrameMetrics(frameMetrics);
    // Layout measure duration in nanoseconds
    val layoutMeasureDurationNs =
    frameMetricsCopy.getMetric(FrameMetrics.LAYOUT_MEASURE_DURATION);

    FrameMetricsで取得できるその他のタイプの所要時間情報の詳細については、FrameMetrics API リファレンスをご覧ください。


    測定結果: 高速なのは ConstraintLayout

    パフォーマンスの比較から、ConstraintLayoutRelativeLayoutより計測フェーズと配置フェーズが約 40% 早くなっていることがわかります。
    図 6. 計測と配置(単位: ミリ秒、100 フレームの平均)

    この結果からわかるように、ConstraintLayoutの方が従来型のレイアウトよりも高速である可能性が高いと言えます。さらに、ConstraintLayout オブジェクトがもたらすメリットのセクションで説明したように、ConstraintLayoutには複雑でパフォーマンスのよいレイアウトを作成するための他の機能も備わっています。詳しくは、ConstraintLayout による応答性が高い UI の作成ガイドをご覧ください。アプリのレイアウトをデザインする際には、ConstraintLayoutを使うことをお勧めします。ConstraintLayoutを使うと、以前は深くネストさせなければならなかったほとんどすべての場合で、使いやすく最適なパフォーマンスを提供できるレイアウトを実現できます。

    付録: 測定環境


    上記の測定は、すべて以下の環境で実施しました。


    端末 Nexus 5X
    Android バージョン 8.0
    ConstraintLayout バージョン 1.0.2


    次のステップ


    デベロッパー ガイドAPI リファレンス ドキュメントMedium の記事を確認し、ConstraintLayoutができることを理解しましょう。また、ConstraintLayoutのアルファ リリース以降の数か月間で、フィードバックや問題をお送りくださった皆さん、どうもありがとうございました。おかげさまで今年初め、本番環境で利用できる バージョン 1.0ConstraintLayoutをリリースできました。ConstraintLayoutの改善はこれからも続きますので引き続き Android Issue Trackerからフィードバックをお送りください。



    Reviewed by Takeshi Hagikura - Developer Relations Team

    Wear 2.0 のアプリデザインを改善する

    $
    0
    0
    この記事は Google Play アプリ品質コンサルタント、Steven Tepper による Android Developers Blog の記事 "How to improve app design for Wear 2.0" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 
     
    2 月にリリースされた Wear 2.0には、新しいハードウェア機能の追加サポート、新しいマテリアル デザイン テーマの採用、ガイドライン、シンプルになった縦方向 UI パターンが含まれています。さらに、ウォッチフェイスの追加機能 APIも導入され、容易にアプリからウォッチフェイスにデータを提供したり、ウォッチフェイスに外部データを組み込めるようになりました。もう 1 つの大きなアップデートは、Wear 2.0 をターゲットにしたアプリがスタンドアロン モードで動作できるようになり、スマートフォンのコンパニオン アプリとの接続が不要になったことです。  
    Wear 2.0 端末用にアプリを最適化するにあたっては、ナビゲーション、通知、ウォッチフェイスの追加機能 API、スタンドアロン機能のデザインについて、いくつかの点を考慮する必要があります。  

    ナビゲーション

    1. シンプルで頻繁に使用しないナビゲーションには WearableDrawerLayoutナビゲーションドロワーを使います。シンプルなナビゲーションとは、アプリの設定へのアクセス、ユーザーの切り替え、ログアウトなどのタスクですWear 2.0 でこれを実装するには、画面上部から下方向にスワイプしてアプリの別のビューやセクションに切り替えたり、画面下部から上方向にスワイプして状況依存アクション用のアクション ドロワーを設定します。
    2. ナビゲーションドロワーをシングルページ ドロワーとして表示し、ユーザーがすばやくビューのナビゲーションを行えるようにします。ナビゲーションドロワーは、マルチページまたはシングルページ ドロワーとして表示できます。シングルページ レイアウトは、ユーザーがアプリで 7 個以下のビューをすばやく移動する際に便利です。アプリでシングルページ ドロワーを使う場合、このレイアウトにはラベルとなるテキストは表示されないため、アイコンのデザインを明確でわかりやすいものにすることが重要です。移動先が 7 個以上のビューである場合は、アイコンで簡単に表示することはできません。マルチページ ドロワー レイアウトを利用してください。
    3. アプリに 2 ~ 3 種類のアクションが個別に存在する場合は、複数のアプリ ランチャーを使用します。たとえば、さまざまなオプション、アクション、ビューがあるアクティビティ トラッキングと、トラッキングしたアクティビティの履歴の分析や管理の両方の機能をサポートするアプリの場合、これらのタスクを扱うために複数のアプリ ランチャーを使うことができます。または、アプリにシンプルなホーム画面がある場合は、これらの機能を画面の下に一列に並べて配置することもできます。
    4. アクション ドロワーの上部でピークを使用して、プライマリ アクションにすばやくアクセスできるようにします。ビューに関連付けられているプライマリ アクションがない場合は、デフォルトの動作をオーバーライドしてオーバーフロー ボタンでピークするようにし、ボタンがタップされた際に、ビューの下部にすべてのアクションを表示します。

    Wear 2.0 端末では、アプリでこういった新しい UI パターンを活用して、一貫性のあるユーザー エクスペリエンスを提供できます。Wear のナビゲーションとアクションについてのトレーニング リソースや、ナビゲーションおよびアクションドロワーのマテリアル デザインの仕様もご覧ください。  

    通知


    Wear 2.0 では、シンプルな縦方向のナビゲーション パターンが使われており、横方向にスワイプして通知アクションを表示するジェスチャーはなくなっています。通知アクションは、単一のプライマリ アクションとして、適宜通知の下部に表示されます。プライマリ アクションがない場合は、通知が展開されて縦スクロールが可能な単一のビューにオプションが表示されます。  
    通知は、大きな変更を行わなくても 1.x 端末と 2.0 端末の両方で動作しますが、外見はまったく異なります。  

    Wear 2.0 端末向けにアプリを作成する場合は、次のベスト プラクティスを適用すれば通知のユーザー エクスペリエンスを改善できます。  
    1. 展開できる通知をサポートします。ユーザーが時計上で多くのコンテンツを見ることができるように、BigTextStyleを使います。
    2. 通知の表示に折りたたみ可能なビューを使用します(適切な場合)。可能な場合は、setContentIntent() を利用して折りたたまれた通知ビューに通知のプライマリ アクションを追加します。
    3. メッセージング アプリでは MessagingStyleを利用します。展開した通知では、このスタイルを利用してチャットアプリのような高度なエクスペリエンスを提供します。
    4. Wear 1.0 ユーザー向けの指示をアップデートします。横方向にスワイプしてカードを操作する説明(Wear 1.x パターン)を削除します。
    5. インライン アクションを利用して通知を拡張します。これによって、通知をタップして展開し、詳細を表示しなくてもアクションを行えるようになります。メッセージの通知に対するアクションでは、Smart Reply プリセット、音声、キーボード入力など数種類の入力方法を利用できます。これらの機能を活用して追加機能を提供し、ユーザーの満足度を高めましょう。

    詳細については、通知にウェアラブル機能を追加するをご覧ください。  

    ウォッチフェイスの追加機能

    ウォッチフェイス デベロッパーやサードパーティ データ プロバイダは、Wear 2.0 のウォッチフェイスの追加機能 API を使ってユーザーが求めている大事な情報を一目でわかる形で簡単に提示できます。この API をサポートしているウォッチフェイスは、外見を完全に制御しつつ、時計にインストールされている任意のデータ プロバイダを使用するように設定できます。ウォッチフェイスの追加機能 API をサポートしているアプリは、ウォッチフェイスの追加機能をサポートしている任意のウォッチフェイス上でデータを公開できます。こういったウォッチフェイスの追加機能は、データ プロバイダの設定とウォッチフェイスに割り当てられているスペースに応じて、さまざまな形態(短いテキスト、アイコン、範囲値、長いテキスト、小さなイメージ、大きなイメージ)で表示できます。  

    ウォッチフェイスの追加機能をサポートする場合は、この機能がウォッチフェイス全体のデザインと一致し、さらにデータ型を適切に扱えるように、以下の点に注意してウォッチフェイスを作成することをおすすめします。  
    1. Wear 2.0 SDK の TextRendererクラスを使用します。これによって、ウォッチフェイスの追加機能内のテキストが縮小されて境界内に収まるようになります。テキストベースのウォッチフェイスの追加機能の境界を越えた場合は、動的に改行や文字列の省略が行われます。
    2. ComplicationDrawableクラスから、ウォッチフェイスの追加機能の背景色、形、境界線、フォント オプションを指定します。これによって、ウォッチフェイスの追加機能がウォッチフェイスをレンダリングする方法を完全に制御できます。
    3. ユーザーが設定メニューからウォッチフェイスの追加機能を設定または調整できるように、ウォッチフェイスをデザインします。このような設定を追加する方法については、GitHub の ウォッチフェイス サンプルをご覧ください。
    4. データ プロバイダ テスト スイートアプリを使ってダミーデータをウォッチフェイスの追加機能にフィードします。これによって、ウォッチフェイスの追加機能ですべてのレンダリングが適切に行われ、フォントが境界内でフォーマットされることを確認できます。
    5. ウォッチフェイスの追加機能のデータを提供するには、ComplicationProviderServiceを使ってデータを公開します。ここでは、アプリがウォッチフェイスの追加機能に提供する ComplicationDataの種類を定義および設定するだけです。

    Wear 端末のスタンドアロン機能

    1. コンパニオン アプリがインストールされておらず、android.hardware.type.watch ハードウェア機能フラグを使用している場合に、アプリが単独で動作するようにします。この機能を使うと、スマートフォンのコンパニオン アプリをインストールしていなくても Wear 端末から直接アプリを検索してインストールできるようになります。ユーザー エクスペリエンスが損なわれないように、単独でもアプリが適切に動作するようにします。
    2. ウェアラブル アプリでログイン認証や主な機能を使う際に、スマートフォン アプリに依存しないようにします。複雑な入力や認証(パスワードの入力など)が必要な場合は、ウェアラブル アプリからコンパニオンのスマートフォンに向かわせることはできますが、アカウントやパスワードの入力には、アプリよりもウェブ UI を利用するようにします。
    3. 別の目的でアプリをサポートするためにスマートフォンにコンパニオン アプリを表示する必要がある場合、CapabilityApiを使います。この方法は、ユーザーのコンパニオン端末で Play Store の適切な掲載情報を開き、不足しているアプリをインストールするために使用します。それ以外の場合は、Wear のビルトイン Wi-Fi や GPS などの接続機能を使って、アプリが単独で動作できるようにします。
    4. Play Store 掲載情報に、コンパニオン アプリの要件や Wear アプリの機能について説明を加えます。この説明によって、ユーザーが機能を予測したり正しいアプリをインストールできるようになり、最高のエクスペリエンスを提供できます。
    5. ウェアラブル アプリがスマートフォンのコンパニオンと連携せずに動作できる場合は、マニフェストに com.google.android.wearable.standaloneフラグを設定します。このフラグは、Android または iOS のコンパニオン スマートフォンとペア設定していなくても、ウェアラブル アプリをインストールするだけで完全に動作することを示します。

    本投稿では多くのことを取り上げましたが、アプリやゲームを最適化し、Wear の最新パターンや機能を活用するためのリソースは他にもあります。質の高い Wear アプリを作るために、品質ガイドラインをレビューし、デベロッパー トレーニング ドキュメントに目を通してウェアラブル アプリ開発ウェアラブル アプリ デザインのベスト プラクティスを学習してください。  



    Reviewed by Yoshifumi Yamaguchi - Developer Relations Team
    Viewing all 2204 articles
    Browse latest View live