Technically Impossible

Lets look at the weak link in your statement. Anything "Technically Impossible" basically means we haven't figured out how yet.

Android Jetpackプログラミング

Android Jetpackプログラミング Android Studio 4 + Kotlin対応
しばらく触っていない技術へのキャッチアップとして、今回はAndroidを再訪した。開発言語がJavaからKotlinへ、ライブラリもJetpackがリリースされ、キャッチアップの程度は「おさらい」を超えて、「やり直し」の範囲に達するものだった。

再訪の道案内として選んだのが、今回の書籍だった。Androidにブランクのある開発者が今時の方法を学ぶため、特に次の話題を目的とする書籍としては、とても良い内容の書籍だった。

  • Kotlin入門
  • Kotlin + JetpackでのMVVM開発

しかし、その良さを実感するには、次のことを読者自ら行うことを暗黙の前提としている。

  • 公式サイトのリファレンスを参照し、
  • 執筆時点と現在の差分を、自力で解消する。

それは、本書の主題に基づくならば、本質的には必要もないのに、deprecated、あるいはalpha、dev段階の要素技術を紹介する、出版側の迂闊さもあれば、Androidを取り巻く要素技術の変化の大きさ、早さにも由来している。

読みどころ、順番を読者が考えて読み進めるならば良書だが、先頭から真面目に取り組めば、無用に疲弊させられる特徴から、物言いのために投稿したくなった。

まず追補を読み、3章へ進む。

この書籍の第1版は、2020年9月29日に出版されている。のだが、この文章を書いている2021年5月15日時点では、紹介されているいくつかの要素技術が、すでに本書の通りでは通じない状況になっている。そして、そのような要素技術が1~2章にまとめられている。

一方、追補として末尾に掲載されている「Kotlin基礎文法入門」は、とても分かりやすく、体系的にまとめられたサマリーだ。すでに何らかの開発言語に馴染んだ人物であれば、文法と構文さえ把握してしまえば、後は必要とする機能をリファレンスを参照しながら自習することができる。その文法と構文(Kotlinの場合は関数やクラス、nullの扱い)を、40ページで理解することができる。
これが把握できれば、3~5章で紹介されるJetpackを用いたMVVM開発、データベース・アクセスを、本書に沿って学習を進めることは容易なはずだ。順当に読み進めるならば、まず追補を読み、そして3章へ進むことになる。

1~2章は無用

何かを学ぶとき、余計なことを考えることなく、学習対象を理解することだけに集中したい、と学習者なら思うはずだ。そこに無用なストレスを生じる

  • 理解に苦しむ表現、要素
  • 説明と現実とのギャップ

があれば、学習の障害になるだけでなく、学習意欲もそがれてしまうリスクもある。そのような障害で構成されているのが、1~2章だ。

1章では、Kotlinを用いた開発手法の違いを、次の順序で紹介し、変化を例示している。

  1. Kotlinを用いた開発
  2. Vew Bindingを用いた開発
  3. kotlin-android-extensionsを用いた開発

すでにkotlin-android-extensionはdeprecatedだ。

Kotlin Android Extensions is deprecated, which means that using Kotlin synthetics for view binding is no longer supported.

Migrate from Kotlin synthetics to Jetpack view binding

そして厄介なことに、1章のコードは3章以降に使いまわすのだ。この事情を反映して、3章以降はView Bindingを用いたコードを前提に読み進めることになるのだが、この判断は書籍中で触れられることはなく、読者が自ら判断しなければならない。
読者には、このような文中で触れられていない事柄について、自ら調べ、現実に即して読み進める能力を、暗黙に求められている。

そして2章ではJetpack Composerを用いた開発を紹介している。現時点でも、この要素技術はdev、alphaの段階にあり、Canary版のAndroid Studioを必要としている。加えて、依存関係にあるパッケージのほぼ全てがリファクタリングされており、読者は公式サイトのリファレンスを参照して、修正箇所を自ら特定し、書き直さなければならない。具体的には、このような具合だ。
developer.android.com

サンプル・コードとして例示されているbuild.gradleに記述された依存関係は、全て新しいArtifactで置換する必要がある。
GIYF (Google Is Your Friend)、公式サイトを参照するのはエンジニアとして常識、と考える人もいるのだろうが、程度は人それぞれだし、本書に手がかりすら紹介されない、このような情報に自力で辿り着くのは、特に初学者にとっては酷な話ではないだろうか。

1~2章は本書にとって本質的な価値を提供することはなく、むしろ読者にとって有害に作用しているのではないか、と私は感じた。率直に言って、1~2章は無用だし、仮に必要としても本書の先頭に位置するほどの内容ではないと思う。それならば、追補と掲載位置を交換すべき話題とも思った。

このように、決して万人向きの書籍ではないのだが、地雷的な存在である1~2章をあらかじめ察知できていれば、内容の良い3~5章と追補に意識を集中できる。

余談

とはいえ、本書の内容以前に驚かされるのがAndroidを取り巻く環境の変化だ。ヴァージョンの異なるAndroidに加え、異なるベンダー仕様が加わり、カオスな状況は10年以上続いている。
アプリ開発者を悩ませるOSの断片化が行き着く末(石川温氏寄稿) - 週刊アスキー

さらにAndroid Auto、Android TVなど適用範囲も拡大しており、状況の拡大はAndroidスマートフォンの断片化に限定されない。そのような状況を改善する取り組みの一つがJetpackなのだが、結局のところ、

  • alpha、dev、deprecatedの短いサイクル、
  • 各段階の進展に伴う変更
  • 変更の混在

という状況が避けられなければ、いくら単一ライブラリ・スイートをリリースしたところで、何も事態は改善されないし、むしろ新しいカオス要因を持ち込んでいるだけだと思うのだ。

Android開発を生業としている人たちの苦労を察すると、同情したくなる。同時に、Android開発はユーザー自身の必要の範囲にとどめ、仕事にすべきではないな、とも思う。
ユーザー自身の必要の範囲の開発と言えば、真っ先に思い浮かべるのはスクリプティングだ。先日の投稿で触れた通り、SL4Aのプロジェクト停止によってAndroidが喪失したものは、とても大きい。
数年ぶりのAndroid Studio 新規プロジェクトの初回ビルドで生じるGradleの問題 - Technically Impossible