RecyclerViewでアプリ開発を行う軌跡を動画にしました。
前編では、ChatGPTで得たサンプルをインプリ（コピペ）する手順です。
昨年暮れからChatGPTを使い始めましたが、そもそも、RecyclerViewの理解ができるまでは、
サンプルを得る事はしませんでした。理解するまでには、結構長い時間がかかりました。
AndroidStudioの操作の理解も併せてですが．．．
動画は、下記キーワードで検索すると出てくると思います。
こんなタイトル画面です。
RecycleViewに関して、理解不足や浅い理解があると思います。
ご覧になって、ご指摘があれば宜しくお願いします。
現在RecyclerViewについてブログ原案を作成中。
説明のために、知識を再整理したり必須な事を再確認していると
だんだんと内容が分かってくる。「再」整理、「再」確認は重要だと
改めて気づいたしだい。
また改めて「Java」と「AndroidStudio」とは異なる環境と気付かされた。
Eclipseを使用して、10年前に初めてAndroidアプリを作っていた時は、Javaの延長ととらえていた。
しかし、AndroidStudioは、JavaをベースのAndroidアプリ作成ツールと感じられる。
オブジェクト指向も利用できるが、方法論にこだわる事を要求する「ツール」ではない。
最近は、Javaを始めた（Java1.2だったか？）頃、COBOLのコーディングルールや、
言語の限界から来たであろう？制約（別角度からは方法論と言っても良いかも？）
にこだわるCOBOLラー達を前にして、何故、新しい考え方やルールを怖がっているのだ？
と思ったものだ。その轍を踏んでしまっている自分が居る！？
IT技術者は、柔軟に考え方さえ変えて、最終目的を実現できる人材のはずだ！
新しいブログが立ちあがったら、検索キーワードを記述するので、
ぜひぜひ見に来てください。
反省の弁
2023年1月頃に現在のアプリは出来ていたが、クリックリスナーを入れようとして、ドツボにハマった。
その後youtubeで探すとrecyclerviewの記事が多数有ることが分かった。皆、英語でのアップだ！更に検索するとヒンズー語（インド人向け？）もある！
日本語の記事は、当時は見つからなかった。
（現在は、少しあるが、エントリーレベルである。webでは、多く（日本語）見つかるが、googleの記事以外は、ほとんどエントリーレベル）
最近まで、迷い道を歩き続けていたが、やっと1月まで戻れた。迷ったら元に戻る事が大切だ！
反省点の一つが自身のスキルの過信だと思う。コードに手を入れる時は現状を保存するのが常道だが、直ぐにインブリできるから大丈夫と思い、どんどん修正して、迷い道にハマった！
これから
日本語での、まともな？recyclerViewの記事をyoutubeにアップすると共にwebとタイアップする記事も上げる事とした。
日本語でも、まともな？アプリで使っている事を示す。
その宣言（大袈裟？）です！
なんでRecyclerViewなのか？
今回はAndroidStudioの使える機能は「とことん使う」方針で臨んだ。１つは、10年程前の利用では、アベンドの繰り返しで全く使えなかった。当時はEclipse＋Androidフィーチャーで開発した。
今回は「どうだろうか？」という10年程の進化の状況を確認したかった。
更に、定年後3年余りの経過で自身のスキルも落ちているだろうし、Javaの進化状況も追いかけてはいなかったので、最新にスキルをUPする気持ちがあった。
それで、生成された（した）コードを、必ず、追いかけて自分のスキルをブラシアップする（できる？）大前提だった。
複数の画面があるアプリを生成すると、画面毎のActivityではなく、画面群はFragementで構成されていた。実は、このシチュエーションは、10年前に作成したアプリで、経験済だった。10年前のAndroidでは、画面毎にActivityを構成するネット記事が多くあり、最初のアプリではActivityだらけになり、重いアプリとなったので、窮余の策でFragementで構成した経験があった。
今回AndroidStudioで生成したアプリがFragementで構成されている事が自身の方向性が正しかったと言われた様で嬉しかった。
そしてRecyclerViewに突き当たった。開発予定のアプリは、概略、猫（コネちゃん）のトランザクション（日々の食事など）の記録入力とそれのリスト形式での表示。定型入力だけでなく、音声入力でも行える形にした。
プランした昨年12月では、「音声入力」に時間がかかると思い、ネット検索を多数して、実現方法を学んだ。コピペが多かったが、内容を理解して進められた。
困難は余りなかった。音声入力では、Googleの機能を利用するインタフェース部分のコーディングだから、コードを読んでも分かりやすかった。
リスト形式で表示する部分に、初めて見る「RecyclerView」があった！
ネットの記事を参照すると様々な記事があったが、私の求めている内容はなかった。
クリックイベントを取り込み画面遷移（別画面表示）もなかった？探し方が悪い？
ネット記事を参考に、コード修正を繰り返す悪循環！！！コードが動かなくなった。
知りたかった事
RecyclerViewでの登場人物（クラス）の役割とタイミングを知ることが出来ない！
探すうちにYoutubeで英語で解説されている。英語は、今ではTOEIC600ぐらい。
早口で喋る説明は理解出来ない！！！
たどり着いた場所
RecyclerView周りのコードでは、どの記事にも説明されるクラス群は登場している。
しかし、Googleの（私より才能のある人々が）生成したコードは難解だ。
迷い道にはまった輩が言うと遠吠えになるが、私のオブジェクト指向とは異なる。
例えば、インナークラスを使ったり、Staticメソッド、アトリビュートを使ったりしている。アプリを軽く、早く、つまり重くないアプリを生成している。クラス関係が、パット見分からない。AndroidStudioは、飾っておけるアプリでなく、直ぐに使えるアプリを生成するツールだ！生成されたコードを参考にはなるが、美しいコードではない。
それでもポストエディットでどちらでも焼きなおす事ができる。
それを前提にこれから、アプリ生成、エディット等を語って行きます。
時間があれば、お読み下さい。但し、ある量で区切るので、複数記事になる事とアップ間隔が一定ではない事をお知らせします。
AndroidStudio迷い道です！
クラスの中のクラス、インナークラスを主たるクラスの中に定義する事で不要なケアレスミスを防ぐ事ができる。
AndroidStudioで、作成アプリに似たテンプレートを選択し、それを改造して最終アプリを完成させる。
例えば、データの塊を管理するPlaceItemHolderクラス中にデータの構成を定義するPlaceItemクラスを定義する。
このシチュエーションで、学ぶことが多数ある。リスキリングではないけれど、思い出している？なにを？
相当昔の苦い思い出。テストでは、コンパイルエラーがでなかったのに、テスト用ロードモジュールをコンパイルしたら、
何故か？コンパイルエラーが出てしまった。大騒ぎになった．．．（ホスト開発）
原因は自分のソースがコールしているサブルーチンのスペックが変更されていた。
変更されたサブルーチンのオブジェクトが古いままでのリンケージ（分かるかな？）ではOKだったのだ！
それからは、（そして当たり前になったが）ロードモジュールを一か所に集めてコンパイルする事になった。
これで新旧のオブジェクトが混じることなくなったが、全てをコンパイルするので実時間が必要になった。
まぁ当時は定時が午後１０時（ブラックである）だったので障害にはならなかったが。
時代は下って、PCで開発を行う環境が当たり前になって、同じ新旧が原因で実行時エラーが起こる事が多くなった。
解決策は、やはり一か所に集めたソースコードをPCに持ってきて全コンパイルではあった。
（Cでの開発）
時間がかかるのが、今度は、障害になってきた。PCの能力の低かった事が本当の？原因？？
更に時代は過ぎて、Javaでは、インタフェースを変えずに中身（機能）を変えることが常識となった。
呼んでいる（メッセージを送る）相手が最新なのかどうかが問題になったね。そこで、コンパイル単位を決め、
ファイルに複数クラスを定義し、同時にコンパイルする事で新旧の矛盾が起こらないようにした。
PC主体で分散開発をする場合、責任範囲毎にコンパイル単位を決めるが、ファイルを構成するクラス数が
多くなり、取り扱いを慎重にしなければいけなくなった。ソース管理も必要になった。
数多くのソース管理ソフトが出てきたね。これはケアレスミスである「取り違え」を防ぐ効果がある。
USでは（私の環境以外？）では常識なのか、Googleでは常識なのか？
学ぶ事が多くて、咀嚼が終わるまで先に進めません。
画面表示にRecyclerを使う予定だが、今までなんとなく敬遠している。
良く考えると、勤務していた頃は「開発標準」が開発チーム全員に暗黙のルールとしてあったが、
こうして独りで「好きなように」きまぐれ開発をしていると、陥る穴？に落ちてしまった。
要するに、開発画面を頭の中だけで考えて、それに合った画面が実機テストででないと、コードを直ぐに
いじってしまう。コードをいじり始めると、「木を見て森を見ず」になっている。
画面設計書を、キチンと書くことが必要と再確認してしまった。早速書くことにする！
