IO関連動画をいろいろ見る
バイクがバイク屋に行ってしまったのと雨なのとそろそろ見るかという事で、今回のGoogle IOとかその周辺の動画を見ていく事にする。
What’s new in AndroidStudio 3.1
これはIOじゃない気もするが、見ておこう。
動画の内容としてはなんて事無いし見なくても良いが、普段使うツールなのでバージョン事情を知っておくのは悪くない。D8は試してみよう。
What’s New Android P Developer Preview 2
Screen readerってなんじゃろ？ そろそろ新規のAPIとかのサンプルコードは全部Kotlinでプレゼンやってよ、という気がする。 Javaのコードは読みたく無いよ。
non sdkのトーストとexceptionはpreviewでやらずに移行バージョン作ってよ…
Vulkanちょっと楽しみね。どんな感じなんじゃろ。
Pは全体的に大した事無いな。しばらく自分はNougatでいいかなぁ。
IOの動画も見ておく。
パッケージネームにバージョン番号入れてたの駄目だったわ、とか今更かよっ！って内容だな。治るのは良い事だが、Support Libraryの素人臭さはいろいろ酷い。
Jet Packアーキテクチャ、といって半分以上がArchitecture Componentなのはなんというか、すぐ新しい名前つけて新しいフリするの辞めてよ…という印象が湧くなぁ。こういうの、その場で新しい風を装うのに良いと思ってるかもしれないが、あとで積み重なると困るんだよなぁ。
バッテリ方向に頑張るのはいいね。このバケットというのがどのくらいの副作用かは使ってみないと良くわからんが。
バックグラウンドでマイク触れないのはどうなんだろうね。自分が使ってるアプリで困る人は居ないかな。
Background text measurmentか。 アイデアは良さそうだが使い物になる感じに仕上がるかね？
linkifyで機械学習使った賢い奴、か。 へー、どんなもんかね。お手並み拝見、って感じ。
cutoutはいまいちありがたみがわからんかった。
slicesは完全にCompound documentです、ありがとうございます、という感じだが、何が新しいのだろう。Searchとインテグレーション出来るだけ、ならダサいな。
NDK r17のプロファイラは試してみたいな。64bitビルドやり直す必要はあるのでそろそろ乗り換え作業かのぅ。
ImgageDecoderは確かに現状は実用的にはかなり面倒なコードをいろいろ書く必要があるが、これでうまく行くかは信じがたい気もするな。 うまく行くなら使うが、結局細かいコードの対応が要るなら乗り換える気も起こらん。 この辺は評価してみないと分からんねぇ。
メディア方面はいろいろ出来る事増えそうね。よしよし。
NN APIは前から見てるので知らん事は無い感じだな。早く普及してくれ、って感じね。
全体的に、今回のIOはこの動画だけ見て、他はフォローアップする必要は大して無さそうだな。 暇なんで見とくが。
Android Jetpack: Manage UI navigation with Navigation Controller
Jetpackは名前だけのはったりっぽいが、Navigationは見ておこう。
navigation graphをXMLで定義する！ それがうまく行かなかったからModalStack作ったのに！
第一印象はわかってねーな、という感じだが、どうか？
Fragmentなのか！結局画面の遷移を代表させるのか！ ひでぇ話だなぁ、これ。
ActivityManagerServiceがFragmentを管理出来ないので、アプリ間の連携が挟まるといかにもうまく行かなさそうだが。 AccountManagerとかどうする気なんだ？
ただこの画面遷移図とXMLが一対一対応してるのはさすが大企業ね。 ガラケー時代にこういうのあったらいいねぇ、といいつつ結局作れなかったんだよなぁ。
おぉ、このあとActivityの話があるのか。
NavHost！これじゃあアプリ間の連携の遷移が定義出来ないじゃん！ 分かってねーなぁ。これじゃスマホは駄目なんだよ。 これでいいなら誰も最初からActivityなんて作らんがな。
さすがにこれは自分でアプリ作ってる奴が作ったとは思えん。 という事で自分はしばらく近づかないでおこう。
Architecture Componentのチームもいかにも分かってない感じだが、たぶんアプリ側のライブラリとかフレームワークやってる連中は外から来た人たちなんだろうねぇ。
NavControllerというのは、画面遷移では無いが自分もstate machineとして同じようなの作ってるな。 自分はBundleを引数で渡しているが。
なるほど、内部ではバックスタックに積むのか。
お、やはり引数はBundleで渡すのか。そうなるよね。
ここの型チェックはオーバーキルじゃないかねぇ。 そしてXMLで型を指定とかセンスねーなぁ。 こういう所でコード生成するのはビルドプロセスを複雑にしてトラブルを増やすんだがなぁ。
こういう作りだと、Fragment間の依存をハードコードし辛いのだよね。 依存が明確な時にそれをハードコードし辛いフレームワークは駄目だ。
DeepLinkで必要なのはuriの標準とその実装をまずGoogleのアプリが全部提供する事じゃないの！？
intent-filter生成してくれるのはいいね。
全体的に、これじゃ駄目だと思うが、必要な要素は結構含まれているので、ちゃんと使い物になる日はくるかもしれない。
今は使う気がしないが、Google DriveとかGMailとかギャラリーあたりがこれでちゃんと作られたら考えてやろう、という気はする。
Architecture Componentもそうだが、まず自分たちが使えよなぁ。
ただ昔自分たちが作ろうと夢見た物を作るだけの体力はあるので、最終的に出来上がる物と、その帰結は興味あるな。 スマホのUI遷移の問題をGoogleは解決出来るか！？
Lead language designerが話すという事で聴いてみる。 kotilnは入門的な話はもううんざりなので、ある程度使ってる人向けの話を聴きたいねぇ。
最初の例はもういいだろう。一年前ならいざしらず。 次のdataクラスもいいだろう。 なんでこんなレベルの話を今年にわざわざやるのだろうか。
Delegateの例は普段使ってないので聴く価値はあった。
getFirstWordは最初からこう書くからなぁ、という事でimpressiveでは無いが、この位ならやる価値はある気もする。
elvisのreturnとかもあって良いな。
お、alsoは知らなかったな。
coroutineの進捗はちょっと興味あるところね。
話自体は他の言語で聞き飽きた奴だが、 suspendでcontが渡ってくるのはかっこいいね。
extentionでラップ出来るのは良いな。 FuelのRxJavaとのインテグレーションもそうだが、こうやってつなげられるってのはkotlin wayだよな。
結局coroutine周辺の固まり具合は分からなかったが、そろそろ使えるようになるかね。
動画見終わった。
序盤はもういいよ、って話題だが、途中からは結構良かった。 学ぶ事があるって感じじゃないが、たまにこういうのを見ていく事でkotiln的な考え方というのに慣れていくのは必要な事やね。
sweeting Kotlin development with Andrid KTX
一応kotlinつながりでKTXを軽く聞こう。 といってもJetpackの最初の奴での例がしょぼかったのであまり期待してないが。
destructuringの例とか、isDigitsOnlyが見つかるようになる、とか、 kotlinを知るという点では悪くないね。 インテリセンスの話はC# で随分昔に見た奴ではあるが。
sqlite-ktxなんてのがあるのか。 Ankoとはどう違うのかね。 NIHだから、という理由だけで再開発してたらめっちゃださいよな。
priecipleの話はKotlinだけしか興味無い人間にとっては微妙だよなぁ。 Javaを経由するとinliningとか効かなくなるし、Java的なデザインに引きずられるし。
この辺はデザイン決めてる奴が大企業的な腰抜けって感じだな。 長い目で見るとこういう妥協はライブラリの寿命を縮めるので自分は評価しない。 という事で、KTXは使ってもいいがそんな好きにはなれないな。
onApiの話は別段説得力は感じないな。 else使いたくなったらif文使えばいいだけで。 良く使うならsingle usecaseでも正当化されるだろう。そういう程度の判断から逃げるのはデザインとしてやはりださい。
ただ保守的なところから始めるという方針は理解出来た。良し悪しは同意しないが、方針だ、という事で受け止めておく。
ここまで動画を見たKTXの印象としては「無いよりある方がいいが、大企業がやるには向いてなさそうなのでコミュニティに任せたら？」という感じ。 なんでフットワークとろい大企業がこんな小さい便利ライブラリを保守的に作るのか。
なんかAndroid関連はコミュニティとの協業下手だよなぁ。 この辺は外で社員が仕事でやればいいのにねぇ。
独自言語じゃなくてKotlin採用したところは偉いが。
お、ExtentionFunctionアノテーションなんてあるのか。 もうKotlinしか使う気無いので使う日は来ないだろうが、フレームワークのアノテーションが増えたらいいね。
KtName！へー。こんなのあるんだ。 この手のアノテーション足していくのはGoogleにやって欲しいところだよな。
DefaultValue！KtxDefaultじゃないのか。
Javaのシグニチャは読みにくくなるが、 これは妥当なトレードオフと思う。
見終わった。動画としては見る価値があった。
6月6日
今日は雨なので動画デー。
Build the new, modular Android App Bundle
Google Play Dynamic Deliveryというのが出来て、それを実現する為にapkの元となるアーカイブファイルが出来たのか。
Dynamic Deliveryを先に見る方が良さそうだが、面倒なのでこのまま最後まで見てしまおう。
protobufかー。なるほど、AOT的な変換をしたいのね。
どうって事無いがこういうのちゃんとやるって大切ね。
100万ダウンロード以上のアプリだけ、ってのはプレゼンとしてはどうなの。
App Bundleの方は大した内容じゃないので5分くらいで説明してくれたらいいのに。
apkのsign keyをplayに登録するってのはこの為か。なるほど。 2つキーが必要なのはかったるいな。
いやいや、QAチームじゃなくてもapk選べる必要はあるんじゃね？ 良かった、bundle toolってのがあるのか。
え？コマンドラインしか無いの？ASからデバッグ実行する時に特定のsplit構成を選びたいんじゃないか？
ASインテグレーション無いのか(´・ω・｀)
ほぉ、modularize。
splitInstallManagerのコードはめんどくさいなぁ。 なるべく使わないで生きていこう。
deferredInstallってどう使うのかなぁ。
SplitCompatって何やるんだろ？
見終わった。 これは見ておいて良かった。 64bit対応する時はApp Bundleにするだろうからねぇ。
Getting started with App Actions
最近Googleの検索バーはフォーカス当ててすぐ入力すると、サジェスチョンがきたあとにクリアしやがるので品質として大変不満を持ってるから、これにインテグレートってあんまり気が乗らないが、どうなんだろう。
インテントとの違いはいつ話してくれるのだろう？
おー、NLPするのか。それは面白いね。
なるほど、intentのリストを登録するのか。
Smart Text Selectionなんて出来たのか。
関係ないがデモがCABじゃないんだがもう辞めたのか？
On device NLP！(・∀・)ｲｲﾈ!!
モデルの所は差し替えられないのかね？ 自分の自然言語処理入れたいが。
うーむ、このブロック図ではその辺はいじれなさそうだなぁ。 そこはもうちょっと自分もMLさせてくれよ。 全体的にML出来ない開発者の事しか考えてない仕組みだなぁ。情けない。
intentカタログはいいな。ようやく作る気になったか、って感じだが。
actions.xmlで登録されたDBは他のアプリも使えるのかしら？ 独自のランチャー作りたい、とか。
courseraのデモとか面白いが、自分はassistant、あんま使わないんだよなぁ。 最初は面白がって使ってたが、天気予報とかがyahooの奴の方が当たる、とかそういう理由で。
actionは面白いと思うけど、下々のデベロッパはactionを提供するだけ、って態度は気に食わないな。 検索アプリがこんなバグったままのくせに生意気だぞ！という気がする。 せめてbottleneckはよこしてくれよ。
6月10日
Best practices for text on Android
新機能の話を期待して見てたら全然新機能の話じゃなかったが、下の方のモジュールとか良く知らなかったので勉強になった。
Spannable周辺はパフォーマンス的に今のデータ構造では使い物にならないと思ってるが。
おぉ、customのspanの解説！(・∀・)ｲｲﾈ!!
はえーよっ！（笑）
これリアルタイムで見た人はさっぱりついていけなかっただろうなぁ。
関係ないがこのねーちゃんはやけに表情豊かね。
Spannable周辺は実際に触るとまた全然印象違うので、この動画だけ見て判断しちゃダメよん。
span1000個以上は普通のユースケースでは無い、とか言うが、シンタックスハイライトとかでは全然普通だよ！ 分かってねーなぁ。 こういう、実際は良くあるという事を理解してないライブラリ解説は本当にださい。
ただSpannableStringBuilderを使うのが正しい、というのは知らなんだ。 名前やAPIドキュメントからは分からないからね。 自分はいつも用途限定用の自作のクラスを作ってたが、今度Builderも試してみよう。
そうそう、getSpansはめちゃくちゃ遅いんだよね。 nextSpanTransitionも遅いが。
annotation、こんなのあるんだ。知らなんだ。
line spaceがPで直ったの、いまさらではあるがいいね。 あれはバグだったのか。
elagantとかは日本語だと何が起こるのか良く分からんな。まぁ影響無しか。
おぉ、この角の丸いバックグラウンドの例は良いね。spanを入れてその位置をレイアウトから取る。 これは似たような事良くやる。
measureが重いんだよ！って話はいいね。そうそう。もっと言うとwordwrapとかあの辺が重いんだよなぁ。
でLayoutクラスのgetDesiredWidth使うとspan情報含んだmeasureが出来るのか。 この手の自分でやる時は部分的なフォント指定とかやりたい、と思った事無いが、知識として知っておこう。
TextViewで文字数は1024文字まで、となってるが、エディタみたいにテキストファイルを表示したい、みたいな時はどうするのが彼らの推奨なのかね。 自作しろってんならそれは良いのだが、その時何を使い回すことを想定してるのか、とか聞きたいな。
precomputed text。私、こういうの好きよ。
何かを隠して綺麗に書けるけど遅いです、というのはモバイル的にはろくでもない。
関係ないけどここでWeakReference使うのいいね。 これまで自分はタグにいろいろ入れてチェックしてたが、こっちの方が賢いな。
お、長いテキストの話がある！(・∀・)ｲｲﾈ!!
やはりRecyclerViewで切るのが彼らの推奨なのか。 これは自分も考えたのだか、またぐ所の処理が面倒そうなのでやめたのだよねぇ。
え、こんだけ？ うー、これでは作るの大変ね。
本当に経験たくさんあるなら信じてやってみてもいいが、たまに僕の考えたさいきょうのデザイン（実績なし）とかの場合もあるからなぁ。
RecyclerViewでのSpannableFactoryの話とかはなかなか良い。 この辺はコード追っかけて毎回似たようなの入れてるけど、オフィシャルの推奨方法があると無駄な試行錯誤の回数が減らせて良いね。 最初からこうしといてよ、という気もするが。
全体的にこの動画の人たちは分かってる感じするね。 jetなんちゃらとは偉い違いだ。
LinkfyCompat（笑）
最初からこうしとけよ、って感じだが、必要な事をこうしてやってくのは大切だよね。
web viewとかの高機能なViewで、全部中でよろしくやってくれる世界はモバイルには不向きという事だよなぁ。
TextLinks.Request.Builder！ヘヴィなAPIだなぁ。 MSみたいだ。
ま、ちゃんとやろうとするとこうなるんだよね。
見終わった！良い動画だった！今の所IO 2018のベスト動画。
6月15日
Migrate your existing app to target Android Oreo and above
無駄に笑いを取ろうとして滑るのが見てて辛いが、アプリ屋としてはこういう話題も気になる所。
長い処理をやるならServiceはもうやめた方がいいのか。 ソースコードのインデクシングとか画像を空白除去してpdfにしたりする時はWorkManagerに乗り換えるべきなのね。 そのうち直そう。
お前らはWorkManagerを持ち上げるのをネタにしてるが、そのJobScheduler作ったのお前らやん… 謝罪しろとは言わんがその態度は無いんじゃないか？
あら、Forground ServiceはOKなのか。 その間に裏に行ってもいいのかね？ 立ち上げる時に裏にいなければいいのかな？
不愉快な所は多い動画だが、内容は悪くない。 こういう動画は定期的に発信して欲しいね。 一部速すぎるのでもうちょっとちゃんと伝えようとしてくれて良いと思う。
それにしてもテストして問題を報告しろって最近いっつも言ってるが、さすがに傲慢な態度じゃないかねぇ。 別にもっとマシなmigrateパス用意すりゃいいだけな事も結構あると思うんだか。