Konifar's ZATSU

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

Google for Mobile雑感

Google for Mobileに行ってきたので思ったことをつらつらと雑にまとめてみる。間違ってたら指摘ほしい。

Firebaseのクラッシュレポート

Firebaseの話は同僚ががっつり聞いてそうだったので興味があるやつ1つしか聞かなかった。と言ってもFirebaseの力の入れようは半端ない感じで、他のセッションでもチラホラ話が出ていた。印象に残ったのは「クラッシュレポートを送ってくれたユーザーに、修正後にFirebaseのPushでお知らせできる」という話だった。

FirebaseはAnalyticsやPush、RemoteConfigなどおよそグロースに必要なものは全部揃っているという感じで、その機能一つ一つは独立しているが色々な場面で連携すると非常に強力だなぁと思った。今はCrashlyticsでもええやんと思われるかもしれないが、そのうちFirebaseの方がユーザーと対話できるし良いみたいな流れになりそう。

ストアレビューを良くするTips

いいアプリを作ろうみたいなそりゃそうだよねという話なのかなと思ったら、ストアの新しい機能を使うといいよという話で最高だった。レビューに返信をするとユーザーが評価を変えてくれるというのは前に実践して実感もあったんだけど、数字でどのくらい改善しているかを見れたのはとてもよかった。

また、レビューを取得するAPIができていたのいうのは今日一番の収穫だったかもしれない。zendeskとも連携できる。レビュー返信のPOSTもAPIになってるのか気になるところ。

テストラボ

テストラボ、あんまりキャッチアップしてなくて、テストシナリオを用意する必要があるんだと思っていたらただapkをアップロードしたら自動でモンキーテストをしまくってくれるとのことだった。ログイン画面がある場合でも、何かやり方があるらしい。導入コストが低そうでよかった。

また、GooglePlayDeveloperConsole上でリリース前にテストレポートを出してくれる機能がついたらしい。apkをアップロードするだけで20機種くらいでテストしてどの機種でクラッシュしたとか出してくれる。スクショもコンソール上から見れるらしくて至れり尽くせりという感じだった。値段を聞いておけばよかったが、まぁ見たらすぐ書いてあるだろうしいいかという感じ。もし無料だとしたら震えるしかない。

ConstraintLayout

Google I/Oの時よりattributesがすっきりしてた。GUIで作ったxmlをコードレビューする時に大変そう問題は、今後の改善に期待とのこと。ぜひなんとかしてほしい。とは言っても、今のところ自分はRelativeLayoutでいいじゃんという気持ちが拭えない。一度ConstraintLayout縛りで何か作ってみたら考えが変わるかもしれない。

FlexboxLayout

超すごいLinearLayout。デモを見てもとにかく最高という感じだった。軽量なのもよい。たぶん実践投入すると思う。

Mobile Vision API

顔認識とかバーコード認識とか文字認識とかのやつ。オフラインでも動くの知らなかった。ただし最初の一回目はファイルをダウンロードする必要があるらしい。どのくらいのサイズなのかはわからないけどあまり大きくはないとのこと。visionSamples/googly-eyesというのを見れば、だいたいの実装方法はわかるらしい。文字認識が一番気になるので何か試してみたい。余談だけど、最近サンプルで何かを試すというのはすごく不毛な気がしているのでアイデア考えてちゃんとしたアプリを作って試したいところである。

Material Motion

マテリアルデザインのモーションについての話。理論的になぜそうしてるかみたいな話もあって面白かった。欲を言うなら、どう実装するかのコードの話も聞きたかった。モーションについては少し実装してみたことがあるのだけど、いくつかはInterpolatorの指定で何とかなる。ただし、Viewをドラッグしたときの抵抗というか、View同士が関連するような動きは自前で実装しないといけない。いきいきとしたアニメーション素敵だなぁと思う一方で、実装を考えるだけで吐きそうになった。全然関係ないけど、Material Spec更新されたら何らかの方法で知りたい。

雑感

  • 朝早かったのと移動も長かったこともあってわりと疲れてしまって、休憩して仕事してた。体力をつけなければいけないなと思った。
  • もう少しコードがある発表があれば最高だなと思った。まぁそのへんは自分自身で試してアウトプットしていくべきなのだろう。
  • Office Hourをもう少し活用すればよかった。自分自身の予習がたりなかったっぽい。Office Hourがあるなら色々試してハマってから全部聞いて解決する場として使えばよかった。次は気をつけたい。
  • 2年前に一緒に働いてたアイルランド人のエンジニアに会ったり、まだ自分がプログラミングをしてない時にバイトで一緒だった友だちに遭遇したりして、非常に感慨深いものがあった。

松亭での会話を雑にまとめてみる

松亭という居酒屋で月一くらいで飲んでるんだけど、なんかいい話してるからまとめとかないともったいないと感じることがあった。まぁくだらない話がほとんどな気もするけどとりあえず雑にまとめてみた。

基本的に会話の内容雑だしまとまりがないし、飲みの場の会話というのは言葉にするものではないなという学びはあった。もし面白かったという人がいたらまた書くかもしれないし書かないかもしれない。

君の名は。

「君の名は。の先行上映落ちましたね」
「つらい」
「8月の試写会でリベンジしましょう」

Realm

「Production導入してるRealmちょっとつらいんですよね」
「何がつらいんです?」
「バージョンが0.8.2くらいで、マイグレーションとかのドキュメントも古いの探さなきゃいけなくて、もともとやってた人はいなくて、バージョンアップできる状態でもなくて」
「つらい」

コミュニケーション

「結局問題になるのはコミュニケーション」
「設計の話なんかしてる場合じゃないですよ」
「クリーン・コミュニケーション・アーキテクチャだ」

メルカリアッテ

「そういやメルカリアッテのベッド、ドタキャンされたんですよね?」
「そうなんですよ、取引はなしで、みたいな軽い感じで。でもその後同じベッドが同じ値段で出品されてて」
「民度がやばい」
「これどうやって対策すればいいんでしょうね」
「メルカリはすごい」

近所の話

「目の前の家が廃墟ってことに気づいたんですよね」
「え、廃墟っぽくない感じなんですか?」
「いや、廃墟っぽい感じです」
「なるほど?」
「で、その玄関を見ないと家に入れないっていう」
「つらそう」
「まぁ今週引っ越すのでもう大丈夫なんですけど、徒歩5分のところに引っ越すからまだ見に行くこともできる」
「見に行かないほうがいいんじゃ」

SHIROBAKOアドベントカレンダー

「一年半分終わりましたねぇ。まずい。そろそろアドベントカレンダー練らなきゃ」
「SHIROBAKOアドベントカレンダー今年もやりますか」
「今年は3人かもしれない」
「やっていきましょう」

@keiji_ariyamaさん

@keiji_ariyamaさんの奥さんは眼鏡かけてるらしい」
「マジですか」
「本当によかった。危なく有山さんのことを信じられなくなるところだった」

Kotlin

「ProductionでKotlinつらい」
「ビルドの時間が長いんですよね」
「気持ちよくかけるんだけど、気持ちよくない時間の方がトータルで見ると多い」
「適当にビルドしてるんじゃないかってくらいちゃんと動かないこと多い」
「KotlinもDataBindingも生成されるJavaコードはstaticメソッドで愚直な感じだったりしますよね」
「やっぱりJavaでいいんじゃ」

ヒロアカ

「ヒロアカよかった。最高だった」
「見せ場がうまい。ワクワクする」
「オールマイト最高」

松亭

「そういえば、ちょうど松亭来て一年ですね」
「なんだかんだ20回くらい来ましたね」
「一年前はあのライブラリ作ったくらいかぁ」
「自分は初めてのAndroidライブラリ作ったところだったかも」
「当時のチャット見返してみたら、1回目の二週間後にもう一度松亭来てますね」
「ハイペースだ」

魔女化

「この二年で2回魔女化しましたね」
「今は有象無象に戻りました」
「けど現在地の設定は『佳境』になったままですね」
「更新忘れてた」

メンヘラツイート

@red_fat_darumaがメンヘラツイートすると、全部僕に言ってるのかなって気持ちになってちょっと不安になる」
「なるほど」

Test Recorder

「EspressoのTest Recorder使ってみましたって記事出てきてますね」
「逆にTest Recorder作ってみましたみたいな記事よさそう」
「『Googleから発表されましたね、便利そうですね、自分も作ってみましたバーン』的な」
「ARuFaさんみたいなノリで書いてほしい」

社内ブログ

あのTechブログ記事ぶっとんでましたね」
「ちゃんとアニプレックスに許可取ってるところがよかった」
「しかもあれLuaでしょ?Luaとかマイクラで正方形にすげえ掘るやつしか作ったことない」
「あのブログ採用になってるんですか?」
「あーたまにブログ見てたって人来ますよ」
「Techブログは全部真面目じゃなくてもいいってことか」
「いくつかの真面目なワードで上位取れたら、あとはぶっ飛んだ感じの好きなこと書く感じでもいいのかも」

チーム開発

「チーム開発とか言ってるくせに1万行のプルリク出してしまった」
「感謝の1万行プルリク」

Androidとデザイナーさん

「Androidは特殊ですよねぇ」
「基本的にアンドロイドが悪い。デザイナーさんは悪くない」
「正しい」

R社

「老害が残らない」
「いい」
「営業がすごい」
「いい」

海外のネタ

「日本でウケる小ネタ、海外メンバーには伝わらない」
「むずかしそう」
「海外の鉄板ネタは現地の言語を話すことですよ。Tsuraiとか」

破壊

「既存の仕組み壊したい時ある」
「コミュニケーションむずい」
「いっそ社訓に破壊を楽しめとかあったら楽そう」

ハンターハンター

「ハンターハンター止まっちゃいましたね」
「せめて暗黒大陸にはたどり着いてほしかった」
「まさかコルトピが0コマで死ぬとは」
「ヒソカ、何気に能力普通だし努力家なのでは」
「団長もクラピカもチートすぎるんですよ」
「セーラームーンになってもいいから続けてほしい」
「タキシード仮面が首だけになるの見たい」

ラブライブ

「ラブライブサンシャインよかった」
「圧倒的な金を感じましたね」
「無印ラブライブより全然CGもよかった」
「無印ラブライブって言葉があるのか」
「穂乃果のせいで嫁の機嫌が悪くなるからラブライブ見れない」
「やはりこにふぁーさんの嫁と僕は感覚が似ている」
「穂乃果がスタートアップ企業立ち上げる話ならよかった」

銀魂実写化

「銀魂実写化しますね」
「あー小栗旬ですよね」
「監督誰です?」
「勇者ヨシヒコの人ですね」
「よさそう」
「けどアレは山田孝之だからよかったのかな」
「山田孝之は最高」

小説

「石田衣良、ふと気がついたんですけどほとんど官能小説ですよね」
「うつくしいこどもの帯は衝撃だった」
「乙一は無駄な文が一行もない」
「乙一の失われる物語は僕の人生で最高の小説。けど二度と読みたくない」
「重松清のとんび、1日で一気に読んでボロ泣きしました」

雑談の価値

「人の飲み会の話垣間見てみたい」
「Podcastで聞きたい」
「雑談も聞く人によっては価値を感じてくれる人はいそうですよね」
「アニメ制作現場の雑談とかめっちゃ聞きたい」
「特定の人に価値があることってありますよね」
「黒川さんも、岡野さんがミスドでぱないのーとTweetするのを楽しみにしてたりしますもんね」
「あれに価値を感じる人がいたのツボだった」

インフラ

「最近インフラやってる。今日プルリク送った」
「うらやましい」
「インフラは個人の運用規模じゃなかなか経験しづらいですからね」

Androidの知識

「知ってるか知らないかだけの違いみたいな感じはありますよね」
「それも本当にAndroidの癖だけの話というか」
「勉強会もワークアラウンド集的な感じになりがちですね」

Androidのリソース

「Androidのリソースがintなの本当につらい」
「型だったらよかった」
「なぜenumを使わないのか」

つらい時の拠り所

「一時期つらい時にARuFaさんのダンス見てた」
「つらい時見るもの持ってるといいですよね」
「自分はデュララジですかね」

SAO

「見たくなってきた」
「ガンゲイルの藍井エイル最高だった」
「エクスカリバー編が平和で好きなんですよねぇ」
「朝田さん!朝田さん!じゃないんですね」
「アリシゼーション編どうするんでしょうね?」
「だいぶ削るんじゃないですかね」
「あれもつらい話だからなぁ。キリトずっと出ないし」
「きっと愛のある感じに仕上げてくれる予感はある」

5分アニメ

「5分アニメだと、Blu-ray全一巻なんですよね」
「全一巻いいね。そういう人生送りたい」

デプロイゲートTシャツ

「デプロイゲートTシャツ可愛い」
「あ、これ自分で作った」
「マジですか」
「嘘です」
「雑すぎでは」

無駄な議論を減らすために使ってる言葉

雑にまとめるので何かあったら直接言ってほしい。⇒ @konifar

チームで仕事をしていると、なんかあんまり意味のないことで議論している事態に陥ることがある。こういうのは議論の中心にいるとわかりにくいが、少し引いて眺めてみると「それそんなに重要なんだっけ?俺たちはこんなに時間使って何を決めようとしてるんだっけ?」という状態になってることも多い。

例えばAとBどっちがいいですかね?という意見の時、正直どちらでもいいと皆が思ってるのにAとBのそれぞれのいいところや懸念点なんかを皆で話しこんでしまっているみたいな。こういう時に難しいのは、単に「それどっちでもよくないですか?」みたいな言い方をすると場が凍って空気が悪くなるという点である。もちろんそういう本質的なことを言ってくれる人はありがたい存在なんだけど、言うタイミングが少し遅くなると「俺たちはなぜこんな無駄な時間を…」みたいな感じになることがある。かと言って指摘しないと時間の無駄だしチーム全体としてもよくない。

大事なのは、なんかこの議論無駄じゃない?と思った時に柔らかく指摘する言葉の引き出しを持っておくことだと思う。自分がわりとよく使う言葉をまとめておこうと思う。

  • 「絶対にこっちがいいみたいなこだわりある人います?いなければとりあえずAでいいんじゃないですかね」
  • 「目的は◯◯ですよね?今話してることは目的からちょっと遠そうな気がするんで、次いきませんか?」
  • 「それぞれやってみたらどのくらいかかるんですか?1日くらいなら両方やっちゃえばいいんじゃないですか?」
  • 「正直やってみないとわからないのでやってみましょう」
  • 「すみません、問題はなんでしたっけ?」
  • 「どっちの結論になったとしても、やること変わらなくないですか?今すぐやっていくぞ」
  • 「自分は絶対こっちがいいです。強い反対意見のある人いますか?」
  • 「これ情報少なくて今決めにくそうなので、この会議では決定するために必要な情報は何かだけ認識合わせましょう」
  • 「これ今全員で話す必要ありますか?もしなければこのあと何人かで話した方がよさそう」
  • 「時間かからなそうだし、やってみて怒られたら戻せばいいんじゃないですか?」
  • 「2~3時間くらいでできると思うし、PullRequest出しとくんで動いてる物見ながら話しましょう」

小さなチームだととにかく行動した方がいいことも多い。実は議論する時間に作業したら終わるくらいのボリュームのこともある。もちろん組織の風土によって変わるだろうけど、無駄な議論は減らしていきたいというのは共通の問題意識だと思う。それぞれの雰囲気に合わせてやんわりと「俺たちが今話してることはみんなそんなに大事に思ってるのか?議論した結果行動が変わるのか?とにかく行動した方が早いんじゃないのか?」ということを指摘しあえれば最高の環境になるんじゃないかと思う。

ちなみにこれは個人の意見だけども、逆に凍りつきやすい言葉は「そもそも」で、言われた方はわりとイラッとすることが多い印象。使うときは代替案の提示が必須だと思う。

期待値のコントロール

どんな状況においても、期待値のコントロールができる人は強い。

期待値のコントロールと言うと、口でごまかしていい感じに丸く収めることでしょと思う人かもしれない。たしかにそういうやり方を取ることもあるが、本質は違う。自分の主張も相手の主張もある中で落としどころを決めなければいけない時に、お互いに納得できる方法を常に考えて相手に動いてもらうということだ。

ここで重要なのは、自分が変わることをいったんあえて考えずに相手を動かすことに頭を使うことだ。仕事ではよくあることだが、相手の期待に応えようとなんでもかんでも自分が解決しようとする人がいる。余裕があるうちはいくらでもやればいいが、自分のキャパを超え始める時にはやり方を変えなければいけない。すなわち、自分の立場を主張しつつも相手も満足させるということだ。ブチャラティのような辛さがあるが、期待値のコントロールを念頭におくといろいろと生きやすくなる。

仕事をしていて「なんであいつはこんなこともしてくれないんだよ」と思うことがあるかもしれない。しかし、それは相手からすると十分にやっている状態なのかもしれない。自分の期待値が相手に伝わっていないのだ。こうなるとお互いに不幸だ。すれ違いでイライラが募って、知らないうちに険悪になる。大人の険悪さというのは子どもの喧嘩よりタチが悪くて、腹の探り合い、本音と建前が入り混じる。これは一緒に仕事をする上では健全とは言えない。

仕事だけに限ったことではない。学校の先生、病院の医師、コンビニの店員すべてで、期待値の相違によるいざこざは発生する。

大人であれば、期待値はコントロールできるようにしたい。逆にそれができないとつらい。細かいところでいうと「あの人は17時に帰る。けど8時には会社にいる」みたいなキャラを定着させるというのもその1つだ。

期待値のコントロールが難しいのは、相手に譲歩してもらわなければいけないこともあるというところにある。伝え方、タイミング、それまでのコミュニケーションなど工夫しないといけないことも多い。「それは私の仕事じゃないです」みたいな言い方をしてしまうと相手は受け入れてくれない。素直に物をいうのは大事だけれど、言い方には注意を払う必要もある。チャットならエモーティコンを使ってやわらかく伝えるのも手だ。

逆にめんどくさいと思うかもしれないが、まぁトータルで見ると期待値コントロールのコストの方が低い。期待値のコントロールがうまくいっていないと感じたら、自分が期待していることと相手が期待していることを聞き出して素直にぶつけ合わせてみるのがいい。最初に「俺はあの時とかむかついてた。あなたも言い方むかついたら言ってくれ頼む」とか言うと、意外と打ち解けていい雰囲気になったりするのでオススメ。

Androidのプロダクトにguavaを入れたくない

雑に考えをまとめるので間違いがあったら教えてほしい。むしろguava入れたら最高だったけど?みたいな話があったら聞きたい。

guavaの何が嫌かといえば、一言で言えばその大きさである。便利そうなものがガッツリたっぷり入っている。まぁ実際便利だし、使いたいクラスもある。けどそれ以上にデメリットが大きいと感じてしまう。

デメリットの1つはアプリ自体のサイズの増加。メソッド数はproguardで削減できるとはいえ、ビルドの時間には影響するだろうなぁ嫌だなぁと感じてしまう。

もう1つはロックインの問題。guavaを導入したい理由はいろいろあると思うけれど、たぶんguavaのほんの一部の機能を使いたいだけってのがほとんどだと思う。自分は、それだけのためにguava入れて大丈夫?最初は軽い気持ちだったんです…みたいなことにならない?と不安に感じてしまう。

特にチームで開発する場合、guavaのような便利でマッチョなライブラリを入れてしまうと各人のコードにブレが生じがちだ。ある人はguava最高じゃんどんどん使うぞという思考で開発してくるかもしれないし、またある人はguavaはこの機能だけ使おうなみたいな認識でいるかもしれない。もちろんコード規約やチーム内の認識あわせで工夫できる部分ではあるけれど、意外と苦労する部分だったりする。そしてそういうブレのあるコードが一度マージされると、それを皮切りにしてどんどん統一感がなくなっていくこともある。

これはguavaに限った話ではなくて、ライブラリをどう選定するかという指針の話かもしれない。自分は何でもできるマッチョなライブラリは敬遠する傾向にある。用法用量を守って正しくお使いくださいという話ではあるのだけれど、経験上そういう指針を維持していくのはわりとコストがかかると感じている。便利なものを見つけたら喜んで使ってしまうのは人の常なのである。ライブラリは提示した課題をスマートに解決してるものがいい。余談だが、最近のButterKnifeはわりと太ってきたと感じることもある。

guava入れるなら、まずは何を解決したいのかを明確にしたい。そしてそれはguavaじゃないといけないのかをよく考えたい。正直、guavaじゃなくても自作できることが多いんじゃないかと思っているし、あるいはguavaの一部機能だけを切り出したライト版もいくつかあるので検討してもいいかもしれない。

余程の理由がない限り、guavaをプロダクトに導入したくない。

Google I/Oで発表されたConstraintLayoutで感じたこと

Google I/Oで発表されたConstraintLayoutはわりと衝撃だったので感じたことを雑にまとめておこうと思う。

ConstraintLayoutはより簡単にレイアウトを組むために登場した新しいViewGroupという理解である。詳細は、圧倒的当事者意識によって書かれた以下の記事にまとまっている。

qiita.com

tech.recruit-mp.co.jp

ConstraintLayoutは、UI Builderを使ってGUIで簡単にレイアウトを組むことができる。簡単に、というと少し語弊があるかもしれない。正確に言えば、「簡単にレイアウトを組むことができるようになるかもしれない」という可能性を秘めたレイアウト。今はまだツールも少しバギーらしいが、これからの進化に期待という感じ。

もしConstraintLayoutが進化していくとしたら、Viewの作り方が従来とはガラリと変わるのではないかと思っている。というのも、ConstraintLayoutのxmlのattributesを見てみると、これは人間の手で修正するものではないなと感じたからだ。~absoluteX、~absoluteYのようなやばそうな属性もあるし、位置関係を表すconstraintLeft~などの属性もRelativeLayoutよりも複雑な印象。

まず感じたのは、細かいところ修正したいときにxml修正するのしんどそうだなという不安だった。俺たちはいつまでxmlを書かなきゃいけないんだよと思う一方で、Viewを思った通りに作れるGUIインターフェースは信じきれていないのだ。これはswingのGUIを作るときにプレビューと実物がだいぶ違ったりと裏切られてきた経験によるところが大きい。Android StudioのUI Builderを信じて使ってみるべきなのかまだ判断がつかない。

ConstraintLayoutをUI Builderで作ることの売りとして、自動的にネストの少ないxmlを生成してくれるというパフォーマンス上のメリットが挙げられている。自分はこれがあんまりピンときていない。そもそもネストによるViewの描画速度はそんなに神経質にならなければいけないほど大きいものではないと思っているからだ。もちろん、RecyclerViewのアイテムなどの繰り返し箇所や、アニメーションが絡むところは意識する必要がある。しかし、I/Oの例に挙げられたようなViewでは気にしなくてもいいんじゃないの?というのが正直な感想である。

やはりConstraintLayoutの価値というのは、GUIで簡単にレイアウトを組むことができるようになるかもしれないというところにあると思う。今後ConstraintLayoutが主流になっていくことを考えて、UI Builderと仲良くなって何かあればフィードバックを送るのがいいかもしれない。

Viewの表示、非表示の切り替えや画面の回転など細かい部分を考えると、RelativeLayoutやLinearLayoutの方が楽なこともありそうだが、まずはConstraintLayout + UI Builderでできることを把握してデザイナーさんに共有することで、逆に無理をしないViewを作るように心がけるのもありかもなぁと思った。

あと個人的に気になったのは、ConstraintLayoutのattributesの名前が~Start、~Endではなく~Left、~Rightだったことだ。あれ…?RTLは…?と思ったが、これは何かしら仕組みが用意されていると信じたい。

以上!

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

Google I/Oは現地には行かず日本で鬼のように寝て朝からざっとキャッチアップした。速報がたくさん出ていて圧倒的感謝というしかない。

いくつか感じたことを雑にメモしておこうと思う。

Firebase Cloud Messaging

GCMじゃなくてFirebaseでプッシュ通知を受け取れるというやつ。FacebookのParseを思い出したが、管理画面見てみたらほぼParseと同じだった。Parseといえば、GooglePlayの入っていない廉価端末や海賊版端末でもプッシュ通知を受け取ることができたところが最高だったが、Firebaseでも可能なんだろうか。海外だと水道は通ってないけどAndroid端末は持ってるみたいな人もいて、そういう人は1000円くらいで買える端末を使っていたりする。そういう端末にもプッシュ通知を届けられるのはわりとアツい。

Firebaseの他の進化

なんかFirebaseいろいろ進化してた。AnalyticsがついたりBugTrackingがついたり、Fabric要らなくなるのでは?と思ってしまった。個人的にはあまりに全部のせの仕組みは好きじゃないので、モジュールで分けてくれたりするとありがたい。Parseみたいに「もうみんな死ぬしかないじゃない!」ってなるのも嫌だし。とはいえ、I/Oのセッションを眺めてもFirebaseに力を入れている感じだし一度がっつり使ってみないとなと思った。

Instant apps

インストールしなくても検索結果からアプリが使えるという謎技術。どういう仕組みかはよくわかってないけど、バイナリを落として使うらしい。バイナリ落とすとなるとネットワークよわい環境だとどうなんだろうかと思った。どこかでアプリの実態があって、端末はシンクライアントとして動作するという方法よりはサクサク動きそうなのでいいのかもしれない。気になるのは、今までWeb版を作っていたところをInstant appsにした方がいいのかよくわからんというところ。まぁiOSも考えるとWeb版は作っといた方がいいのかもしれないが、Instant appsでアプリのインストール率を上げて継続率も高めるみたいなことを考えた場合、どう棲み分ければいいのか考えないといけない気がする。

あとInstant appsの登場で、ネイティブの立ち位置がよくわからなくなった。自分は今までWebの進化がすごすぎてこれはまたWeb回帰していくんだろうなぁとぼんやり考えていた。最近のGoogleのWebサービスや海外のECサービスなんかを触っているとわかるが、もうアプリとほとんど見分けがつかない。ブラウザさえあれば動作するWebでここまでできるならWebでええやんと思っていた。けどInstant appsでアプリをWeb側に持ってくるみたいなことになってきたので、これどうなんの?というのが正直な感想である。

Android Studio 2.2

なんかいろいろ速くなったらしい。Layout DesignerはStoryBoardみたいな感じなのかなと思ったけどまだよくわからない。自分は「考えるな、感じろ」みたいな感じでxmlだけでガーッと組むことが多くて、そのやり方に慣れてしまったのでなんともいえないところ。こういうのは、便利な機能が信頼できないと使わなくなっていく。Instant runもそうだった。しかし、使ってフィードバックしないとIDEも進化しないので、みんなで育てていこうな!みたいな心持ちでやっていきたい。


まとめをざっと見て感じた印象でしかないので、間違いもあるかもしれない。

ちなみにAndroid Nはニッキ飴がいいと思います。赤坂からは以上です。