5年も現場から離れている。以前のAndroid開発は、個人的な開発ではあった。
ツールはEclipseだった。
久しぶりに帰ってきて、ツールをAndroidStudioにした。と、言うかEclipseのandroidプラグインの提供は終わっていたので、仕方なくの所もある。
以前Eclipseでの開発では、AndroidStudioもあったが、これは、メモリバカ食い、CPUバカ食いなので、個人的なCPUの開発環境では、使う事を躊躇した。
さて、数年ぶりに帰って来て、唯一の選択肢としてAndroidStudioにした訳だが、自動展開（デフォルト）されるコードには、思いもよらないコードが展開されている。
以前Snackbarだけでなく、Jetpackを使った？画面遷移の仕組みが展開されていた！
ここ２週間以上 NavController とはなんだ！と悩んでいた。JavaもJava８になっていて、ラムダ式があったりで、今までJetpackの存在を分かっていなかった。
5年も現場から離れている。以前のAndroid開発は、個人的な開発ではあった。
ツールはEclipseだった。
久しぶりに帰ってきて、ツールをAndroidStudioにした。と、言うかEclipseのandroidプラグインの提供は終わっていたので、仕方なくの所もある。
以前Eclipseでの開発では、AndroidStudioもあったが、これは、メモリバカ食い、CPUバカ食いなので、個人的なCPUの開発環境では、使う事を躊躇した。
さて、数年ぶりに帰って来て、唯一の選択肢としてAndroidStudioにした訳だが、自動展開（デフォルト）されるコードには、思いもよらないコードが展開されている。
以前んSnackbarだけでなく、Jetpackを使った？画面遷移の仕組みが展開されていた！
ここ２週間以上 NavController とはなんだ！と悩んでいた。JavaもJava８になっていて、ラムダ式があったりで、今までJetpackの存在を分かっていなかった。
ググって調べれば、すぐに分かる事だったが、妙なプライドが邪魔をして、調べずに分かろうとしていた。コードを十分に見ていれば分かる事だと、自身を過信していた。
調べたら、Jetpackを使って、画面遷移などについて安全、簡単？に定義できるもののようだ？一読しただけなので真には理解していないので今後変わる認識かもしれないが？
画面間でのデータの安全な受け渡しやトランザクションの管理をするみたいだ？
個人的に楽しみ？ながら開発するのにも安全、安心な所謂「ASID（原子性、一貫性、独立性、永続性）」を心配するのはどうなのか？でも簡単に実現できるなら必要かな？
でも、それで自動生成されるコードにデフォルトで含まれると、迷う悩む人（私）が居る。
Snackbarも自動生成させるものによって、デフォルトで組み込まれる事が分かった！
５年は、やはりLightYearなのかな？反省！
最近AndroidStudioでスマフォアプリ作成を再開した。バージョンは2021.2 まあ最新に近い。Java8対応かな？
（以前はEclipse＋AndroidSKD？で開発していたが、現在はEclipseにJavaをプラスするSDK？は提供されていない？）
ここで（という訳でなく）ラムダ式とかsnackbarとか見慣れないものが出てきた。AndroidStudioで自動生成させて出てきたのだが．．．
Java8近辺以降で（これらは）出てきたものらしい？正確には出現時期は調べていない。
Javaで開発をしている時は、JavaSoftからOracleにJavaが移行される時期で、更にOracleは次期バージョンからは有料化するとの噂もあった。今はどうなっているのか分からないし、調べつもりはない。
その時以降、最新Javaは近寄らない（有料化には対応できない）として開発を行ってきて、今はリタイヤモード。
さて、Snackbarは、調べるとToastの様なショートメッセージを表示する機能だそうだ。詳しい機能は調べていない。
まず、ここから不満を言いたい。開発コードをスリム化し無駄を省くと努力してきた。それが生成デフォルトで使わないかもしれないコードが共に生成されるのは「やりすぎ」！設定で変えられるかも知れないがデフォルトでは「生成しない」が当たり前と思った。
コードインスペクションをする時の観点は、誰が（一定程度のスキル前提は当たり前だが）見ても分かりやすく（意図が明示的である）、無駄なコードは取り除く、あるいは（実行）効率を考えると、抽象的過ぎるのはやめるとか、例えば、掛け算より足し算を繰り返す方が早い場合とか．．．
様々なオキテ（ルール）があった（はずだ！）それはどうなっているの？？？
ラムダ式は、
”Javaのラムダ式(lambda expression)とは、関数型インターフェイスを実装したクラスのインスタンスを、ごく短いコーディング量でとても簡単に作れてしまう文法のことです。”とある。
これは実装時の効率化に資するJava8以降の新規機能のようだ。
オブジェクト指向（古いかも？）から言えば、クラス設計（インタフェース設計も含む）をキチンと行い、クラスごとの責任範囲を決めてから実装するという習慣を大事にしてきたものから見ると、安直であると思ってしまう。
実装時に必要な機能を設計し忘れたので、設計まで戻らずに実装してしまう様に見える。
まぁ「設計まで戻って」ではイテレーション開発ではないが、不十分な設計も許容されてしまう。極端に言えば、とりあえず実装。設計は不要。に見える。
多用すれば、適当さを助長する事になるのを危惧する。
昨日出会って驚いた事！しばらくすると、「便利さ」に負けている私がいるかもしれない？！
