Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

Google I/O 2018初日キャッチアップ所感

普通にぐっすり寝て朝起きてからTLと公式ブログあたりを見ながらキャッチアップした。現地のみなさんには感謝しかない :pray:

色々あったので雑に所感をまとめておきたい。間違いもあると思うので何かあれば優しく指摘してくれると嬉しい。

App Bundle

developer.android.com

新しいapp publishingの仕組みで、ユーザーがダウンロードするアプリのサイズを小さくできるのがメリットっぽい。公式ページの Stop managing multiple APKs という力強いタイトルが印象的だった。

自分の所属しているKyashのアプリでは、multiple apkで5個のアプリに分割することでアプリサイズが1/3くらいになっていたのだけど、それも必要なくなるのか。「Good bye Multiple apk」というPRを作る日も近い。

このApp Bundleの目指すところはアプリの肥大化を防ぐというところで、multiple apk以外にもDeliver features on-demandという機能ごとに配布する仕組みというのを用意している。ユーザーの属性ごとに分けた時に、新規ユーザーにとっては使わないような機能を別モジュールに分けておいて、そのユーザーが必要になったタイミングでfeature moduleをダウンロードして使うことができるという話のようだ。Kyashの中では今のところそんなに使わなくてもいいかなーと思ったけど、メルカリでは本人確認の部分だけ切り出すみたいな使い道がありそう。使いどころベストマッチだ。

Enable modules to run instantly, without install と言っているのは、Instant Appsのことだろうか。Instant Appsなー、Instant Appsを導入したら視聴時間が5倍に増えたという動画アプリの話がちらっと出ていたけど、正直あんまり実感がなくてなんでそうなるんだ?って印象である。Web版リリースしてるならWeb見ればよくない?Instant Appsの何が優位なのだろうか。そもそもWebがない場合とか、操作感の違いをユーザーが敏感に感じ取って数字に出るとか?いまだによくわかっていない。

発表の様子を見るかぎり、on demand機能を使おうが使うまいが機能ごとに細かくfeature moduleを切っておくのは筋が良さそうだなと感じた。Instant appsだけだと設計難しいし管理が煩雑になるしあんまりメリットないんじゃないかと思っていたけど、どうやら世はfeature multi module時代らしい。slicesのように一部の機能を外だしすることを考えても、分けておく方がよいのだろう。KyashではAuthと送金部分をfeature moduleに分けておくと、今後面白いことをしやすいのかもしれないと思った。マルチモジュールの実践についてはkgmyshinさんの本を読もうな

kgmyshin.booth.pm

ちなみにdynamic deliveryはAndroid5.0以上のみっぽい。すでにminSDKを21にしていたKyashでAndroid開発したい人ウォンテッド。

A fundamental component of Dynamic Delivery is the split APK mechanism available on Android 5.0 (API level 21) and higher.

ConstraintLayout

すぎょい。アニメーションエディタすぎょい。 morphをあんな感じでいじれたら楽しいだろうなと感じさせるデモだった。自分はまだGUIエディタを信じきれないところが大きいのだけれど、ConstraintLayoutのchainくらいはGUIを使い始めているし、ちょっとずつGUIとも仲良くしていかないといかんなと思った。

AbsoluteLayoutが死んだらしい?RelativeLayoutの番も近いので、Goodbye RelativeLayoutというIssueを立てた。こういうのは一日一善でちょっとずつ書き換えていくのがよい。

Navigation Editor

すぎょい。これが欲しかったという人も多いのではないか。これもGUIかーみたいな気持ちにちょっとなったけど、xml依存の考えは捨てて仲良くなるのが良いのだろう。

Navigation Editorからの派生か、できればSingle Activityにしとけよみたいなスライドもちらっと見た。まじか。 別にできなくはないけど、Fragmentだけでやっていくのかーという気持ちになった。Navigationいい感じに使えば問題ないのだろうか。Navigationに関してはすぐにCodeLabをやっておいたほうがよさそう。まあ公式にSingle Activityの方がいいと思うで、みたいな感じで言ってくれるのはありがたい。

↑ と思ったけど自分の勘違いで、むしろ逆に画面遷移にFragmentむやみに使うなってことらしい。安心した

twitter.com

Material2

相変わらずドキュメントが充実していてすごい。Sketchのプラグインもあるとはいたれりつくせりだと思った。 個人的には指針にブレがなければ変化に対してはとてもポジティブな印象である。Flutter向けのコンポーネントも公開されてる。

Material themingはカスタマイズするための指針という認識であってるのだろうか。エディタも用意されてるらしい

material.io

年々ユーザーが迷いなく使えるように手厚くしてくれている気がする。ありがたい。 個人的に気になるのは、このエディタで編集したテーマをそのままコードにエクスポートできるのかというところ。 Material designが出てきた時にさ、テーマでいい感じに見た目が共通化できるって話になってすげええって思ったけど、結局primaryColorってどこに適用されるんだっけ?とかこの色ここに反映されんの?!みたいになってつらかった思い出がある。今回そのへんも解決されると嬉しいなと思った。

これからしばらくGitHubでMaterial Design2ショーケースみたいなサンプルアプリが爆増しそうな予感。

Gallaryというデザイン共有ツールもよさそう。弊社デザイナー氏に共有したら、興味を持ってはいたものの、また覚えること増えるのかw週末やっていき!みたいなことを言っていた。わかる。めっちゃわかる。本当にいろいろ変わって大変だよね。一緒にやっていこうな。

Google Assistant

普通に人間じゃんと思った。むしろここまできたら次はキャラづけしていくしかないやろ。 サイコパスのキャンディーとかドミネーターとかタチコマとか夢が広がる話であるが、おそらくそういうことはやらなそう。

真面目な話をすると、Google Homeの対応とか早めにちゃんと考えて実装しておくのがよさそうだと思った。 Kyashで「Kyashでkobakeiに1000円送金して」とか言ってできるようにしておくのがいいかも。嫁さんに話したら「なんで声に出してそんなこと言わなきゃいけないんだ、恥ずかしいじゃん」とか言われそうだけど。


Material Design2はもっとキャッチアップしたい。 この発表の内容、こう取り入れたら本業アプリでも活かせそうだねみたいな話を社内メンバーとできるのは楽しいなと思った。とりあえずApp Bundleは迷わず対応しておけばいいんじゃないかな。と言ってもdeliver feature on demandをやらない限り実際にやることはほとんどないけども。