差分

このページの2つのバージョン間の差分を表示します。

--- ハイハイスクールアドベンチャー_android版 [2025/09/20 08:06] – [独自の設定要素] araki
+++ ハイハイスクールアドベンチャー_android版 [2025/10/02 23:59] (現在) – [独自の設定要素] araki
@@ 行 35: / 行 35: @@
 Google Play Storeには登録していないので、インストールにはちょいとひと手間かかります。
-Android 12, 13, 14での動作は確認しましたが、他のバージョンでの動作については不明です。
+Android 16での動作は確認しましたが、他のバージョンでの動作については不明です。
 ===== ダウンロードとインストール =====
-こちらから[[https://www.wildtree.jp/~araki/HHSAdv120.apk|APKファイル]]をダウンロードして、インストールしてください。
+こちらから[[https://www.wildtree.jp/~araki/HHSAdv121.apk|APKファイル]]をダウンロードして、インストールしてください。
@@ 行 68: / 行 68: @@
 もう、SDLと同じでビットマップ作ってそれスクロールさせればいいんじゃない？
-と、GeminiとCopilotにそれぞれ聞いてみたら、Geminiは「いや、ビットマップは素材の用意が大変だしメモリも食うから RecyclerViewを活用するのがだ太しいやり方だ」といって、新しい方法を提案してきたが、SCrollViewと大差なかった。
+と、GeminiとCopilotにそれぞれ聞いてみたら、Geminiは「いや、ビットマップは素材の用意が大変だしメモリも食うから RecyclerViewを活用するのが正しいやり方だ」といって、新しい方法を提案してきたが、ScrollViewと大差なかった ー つまり期待してない動作しかしなかった。
 Copilotはビットマップを使う方法を速攻で提案してきて、ほぼ完ぺきだった。
@@ 行 76: / 行 76: @@
 それ以外は、およそ文句の付け所はなかったので、速攻で採用した。
-AIは便利だし、開発の大きな助けになってくれるが、時に頑固で時に忘れっぽくて、しかもGeminiのように効く相手を間違えると、いつまでも盛会にたどり着けなかったりもするので、うまく付き合わないといけない。
+AIは便利だし、開発の大きな助けになってくれるが、時に頑固で時に忘れっぽくて、しかもGeminiのように効く相手を間違えると、いつまでも正解にたどり着けなかったりもするので、うまく付き合わないといけない。
-((今回はGeminiが駄目だったが、Coplitが駄目なこともあるだろう。))
+((今回はGeminiが駄目だったが、Copilotが駄目なこともあるだろう。))
@@ 行 131: / 行 131: @@
 Kotlinの Byte型は**符号付8ビット整数**なのだ。
-C頭なわたしは、byte_tみたいなやつはすべからく符号なし8ビット整数だと思い込んでいたのだ。
+C頭なわたしは、byte_tみたいなやつはすべからく**符号なし8ビット整数**だと思い込んでいたのだ。
 地図や、先生などの画像データは、バイト配列で座標や色コードを格納している。
@@ 行 148: / 行 148: @@
 のように、いったん、UByte型((符号なし8ビット整数))に変換してから、整数に拡張すれば問題は起きない。
-肩の定義は言語ごとに類似性はあっても独自のものであるので、先入観はすててちゃんと調べないとダメ。
+型の定義は言語ごとに類似性はあっても独自のものであるので、先入観はすててちゃんと調べないとダメ。
 なお、バッファ自体を UByteArray にすれば、余計な toUByte()がいらなくなり、間違いも減りそうだが、UByteArrayを使おうとすると「それはExperimentalだから」といわれていろいろめんどくさいので、今回は採用していない。
@@ 行 287: / 行 287: @@
 結論から言うと、PreferenceCategory側でした。
-app:allwDividerAboveとapp:allowDividerBelowというパラメータがあって、これが線を引くかどうかの制御をしていました。
+app:allowDividerAboveとapp:allowDividerBelowというパラメータがあって、これが線を引くかどうかの制御をしていました。
 しかし、ほかの要素ではこれ特に指定してないのだから、allowDividerAboveが trueで、allowDividerBelowがfalseがデフォルト値じゃないのかって思うんですが、やや解せぬ思いは残りましたが、線は消せました。
@@ 行 313: / 行 313: @@
 このデザインをモノクロ化したものが、今回のアイコンとなっています。
+==== 処理のタイミング ====
+クレジットロールはActivityとして実装しています。
+呼び出しは Intent で行いますが、呼び出した時点で処理されるわけではなく、登録だけされて、呼び出しはユーザプログラム側の処理が済んでシステムに処理が戻されたタイミングになります。
+何がいいたいかというと、例えばゲームの開始時、オープニングのクレジットロールを呼び出すとともに、画面をゲームの初期画面に書き換えるのですが、オープニングの処理が始まる前に画面が書き換わるので、一瞬ちらっとゲームの開始画面が出た後にクレジットロールが始まります。
+かっこ悪い。
+暗転している裏で書き換えてほしいのに、舞台裏が見えちゃっているようでイケてません。
+エンディングでも同じで、タイトル画面に戻ってからクレジットロールが始まります。
+回避するためには、クレジットロール側の処理が終わって、Main Activityに処理が戻されるときに書き換えればいいことになります。
+具体的には、処理が戻ってくるときに onResume() が呼び出されるので、ここで適切な書き換えをすればいいことになります。
+単純に、ここに、オープニング処理から戻されたらしいならこれ、クリアしたらしいならこれ、という処理を書くと、スクリーンロックから復帰したり、タスクマネージャで別のアプリから戻されたときにも、onResume()が呼ばれるので、余計なタイミングでの呼び出しが発生することになります。
+そこで、onResumeOnce という ()->Unit 型の ArrayListを作って、クレジットロールを呼び出すときに、画面書き換えの一連の処理を登録して、onResume()側では呼び出したら捨ててしまうという処理にすればいいのではないかと考えてそのようにしています。
+<code kotlin>
+val onResumeOnce: ArrayList<()->Unit> = ArrayList<()->Unit>()
+...
+override fun onResume()
+{
+    ...
+    if (onResumeOnce.isEmpty()) return
+    for(f in onResumeOnce) {
+        f()
+    }
+    onResumeOnce.clear()
+}
+...
+onResumeOnce.add {
+  // 処理を書くと onResume()の中で一度だけ呼ばれます
+}
+</code>