Androidについては真面目に書くか。書けるのか？例えば、Androidの素晴らしいところを挙げてみるとか。

• Support Library
• targetSdkVersion
• Gradle
• Navigation Component

Support Libraryは、OSの機能やOSにバンドルされてる各ライブラリに依存した良い感じのUIやサービスを、OSのバージョン間の差異を吸収しつつ、OSにバンドルされてるものとは別のライブラリとして提供してくれるもの。iOSと違ってシェアが新しいほうへ移る速度が遅いので、いつまでも2系やら4系やらのサポートを切れずに泣く泣く対応してる開発者への救いの手をGoogleから出してくれていた、という見方は微妙で、古いOSの延命道具の提供を通じてAndroidの諸々のエコシステムを支えていたし、支えているというのが実態だと思う。もしSupport Libraryが無ければ2系、4系、5系をもっと早く切れたのに……、とかよく考えていた。でもSupport Libraryが無ければ、Android全体がもっと微妙なものになっていたかもしれない。実際の影響力という意味では何にも分からないし、アレのほうが重要だったでしょってのを思い出せていない可能性もありそう。なにはともあれ、プラットフォーム運営としてやるべきことをやる、みたいなことをGoogleがちゃんとやってるのすごいよね。誰が始めたんだろう。

targetSdkVersionは、えーと、ちゃんと書こうとするの面倒くさいな。ちょっと遠回りをする。昔々、AndroidにAsyncTaskというその名の通り非同期処理を行うためのクラスがあって、これの実行スレッドが最初（Android 1.5）は1つでした。1.6から複数スレッドで複数タスクが並行に実行されるように変わりました。（ちなみに、スレッドプールのスレッド数がたしかOS固定ではないから、実際はスレッド1つという端末もあったはず。1.6の時点では1スレッドの端末のほうが多かったかもしれないね。）でも並行処理は難しくてみんな間違うから、Android 3.0でシングルスレッドに戻しました。という話があります。

こんな豪快な変更ができる背景と考えてよさそうなものの1つがtargetSdkVersionというわけ。上述のようにAndroid 3.0以降ではシングルスレッドで実行されることになってるんだけど、targetSdkVersionをAndroidの2系（実際の値はAPIレベルなので5～10のどれか）に設定してビルドされたアプリでは2系の挙動をすることになっていて、Android 3.0の端末でもAsyncTaskの各タスクは複数スレッドで実行される（可能性がある）のだ。「targetSdkVersionすごいでしょ」って話をするのに、今の話が全部真実である必要はないんだけど、実際にAndroidのコードを読んで、実行スレッド数までtargetSdkVersionが制御してるのに感動した記憶がある。記憶違いだったらすまぬ。AsyncTaskはもうdeprecatedになってしまって、時代の流れを感じるね。

Gradleがビルドツールとしてどれだけ優れてるのかは置いといて、現代の普通のビルドツールを使ってるというだけで嬉しいよね。というレベルの話。

Navigation Componentは登場直後にイマイチだなと思っていた点が改善されたと知って使ってみたら、こういうの欲しかったんだよ、こういうのでいいんだよ、という感動があった。それと同時に、自分の情熱が消火されていくのを感じた。画面遷移とその依存グラフをコードで良い感じに表現したいという気持ちがあって多少やっていて、いろいろ考えていきたいなと考えていた矢先、ある種の完成系を見た気になって終了してしまった。XMLとGUIでの表現より例えばKotlin DSLのほうが都合良い場合もあるだろうし、いろんな方向性があるんだろうけどね。かつて「バンドやりたいとか思わない？」と聞いたら「いやあ俺はいいかな」と答えてた同級生がいて、彼は（自分が知る限りだと）桑田佳祐とドリームシアターが好きだから「そんな完成されたものを聴いてたら自分でやろうと思わないよな」みたいなことを勝手に考えていたんだけど、そういうやつになった。というのもあって挙げたけど、別にAndroidの素晴らしいところかどうかは微妙だね。これが出てくるまでに何年かかったのよ。

じゃあ今日はこんなところで。