まだRoomでデータ操作ができていません

Roomの事を知るにつれて、Roomカバーしている（しようとしている）範疇は結構大きいことにため息しか出ません。

言葉の定義もわざと独自性をだしているのか、自動翻訳に頼っているためなのか分かりませんが、結局これってあれの事だよね的なことなのですが、そうは言ってもAndroidアプリだとこの機能もいるよね、とかそんな感じ。しかもなんか自動的に用意してくれ「そう」な感じはするものの、ほんとに任せて大丈夫なの？とか。

実際問題としてローカルはSQLite3のサンプルしかないわけで、じゃあ実際に別のデータベースに直接アクセスできるの？とかいまだに疑問だったりしています。

そうこうしていると、段々と切実な問題が。AndroidのコンポーネントというかクラスってAndroidが都合の良いように作られていてアプリの都合はお構いなしなのが災いしているのか、Viewの構築の手法もViewModelを組み込んでどうのこうのとかあるようで…今までそういうのは避けてきたわけですが、やはりメインストリームもその辺を何とかする必要があると思った結果なのかもろもろがJetPackと呼ばれているものなのかな？と。

で、どうしてもデータベースアクセスが前提となるとViewModelを使うべきなのはわかりました。が、ViewModel自体は副産物の様で、実際はAndroidのインスタンスのライフサイクルにテコ入れしてもう少し切り離されたものを実装した結果、ViewModelというものが必要になった感じです。

これを使えば、無駄にApplicationクラスを肥大化させることなくアプリレベルのグローバルな単一のしかも安全なライフサイクルを持ったクラスが存在できるようになります。

良くも悪くもというか悪事なことですが、極論を言ってしまえばApplicationクラスを肥大化させることでかなり自由にアプリは作れます。しかしAndroid自体はそういうことを激しく拒絶しています。そもそも論として各クラスはそれなりに存在することが良しとされる世界。しかもできるだけクラスは小さく、かつ相互依存は極力避けることが望ましい。

なのでApplicationクラスにアプリ自体の機能を持つことなど言語道断と言うことですｗ

そしてRoomもそうなのですがViewModelをさわるとjavaだけで書こうとすると足かせにしかならず、自ずとkotlinで書くしかないかなと感じるわけで…いままでkotlinで作った方が楽になりそうだな？とかそんな感じだったのですが、ここまでくるとjavaで書こうとするとなんかえらい大変じゃない？とかなってしまいました。そしてkotlinの壁と言うわけです。lazyって何？とかもう壁しか見えませんｗ