あけましておめでとうございます

テレビ番組を見なくなりもう１０年以上 テレビは見ないので地上波チューナーのないブラウン管テレビがあるだけです。

除夜の鐘の音もなく、近所の門松もほぼ絶滅状態（そもそも私は飾りつけなど一切やってませんｗ）。正直年始年末の空気も肌身に感じることは無くなりました。コロナ以前は少しは休みと言う雰囲気で実感はしていましたが、コロナ政策でなんか世の中滅茶苦茶な感じで。

そんな年末、ネタは結構あったのですが、ついつい筆ならぬキーボードが近くて遠い存在にｗ

年末掃除に気合いを入れるはずが、親指に血豆を作ってしまい水仕事は痛そうだったのでかなりさぼり気味に。とどめに給湯管からの水漏れ…いつものところだと思っていたら意外なところから漏れやがってて、納戸となっている部屋の天井からポタポタしているのに気づき水がかかってしまった荷物を避難させたり掃除などをしてから天井をぶち抜いて…施工不良部分を発見。見るからにこれ手抜き工事。素人が見ても今までよく漏れてなかったなと感心する感じ。

簡単な応急処置じゃダメなので結構本腰を入れないとダメそうというところですが、何とかやり過ごさないとと。この２日ほどは水道使う時間以外は元栓を閉めて凌いでいます。

そんなおおごとになる前にぼっち・ざ・ろっく！を見始めそれに感化されて練習なんてしたことのないベースを取り出してみました。去年の年末辺りもなんかベンベケやって遊んで記憶がありますが、その時は遊びすぎて指が腫れあがって幕を閉じていました。そもそも中古で買ったベースで購入時期は…高校生のころだったと思う。買って満足した感じで練習もほぼやってませんｗ。ただ、ドラムとは違い、エレキベースはアンプにつながなくても普通に音は出るし、なんかもっと前からハマってればよかったかもと気が付きました。

で、弦なんか張り替えたこともないわけで、去年遊んだ時にチューナーを買ってみたところいくらチューニングしてもチューニングしたそばから音がズレていくという。いくら緩めていたとはいえ中古で買った時のままの弦…錆びてはいないもののさすがにと思いつつも、「練習だけなら」とそのままにしてありました。そして去年の年末（2022年）にとうとうチューニング中に２弦が切れました。今思えばオクターブずれて合わせてた気がしますｗそりゃ切れるわｗ慌ててアマゾンで探すとなんと翌日（３１日）に配達されるという。思わず安めの物を注文。ついでに今までストラップなしで座って遊んでいたのですが、弾きやすい高さにならないのと、もしかして立って演奏したほうが楽なのでは？と思い立ちついでに注文。３１日に配達されるものでそこそこ使えそうなものを選びました。

安めの弦はレビューを見る限り最悪油がベトベトかもしれないものの、そこそこ使えそうということで注文しました。届いてすぐにググって弦の張り方を調べて張り直し、チューニングも問題なくできたのでストラップもつけて練習してみました。

今まで右手の位置が安定できなかったので、弦を弾くときに目視しないとまともに弾けなかったのですが、立って演奏することで見なくても安定して弾けるようになり、左手も意外と見なくてもどこの弦を押さえているのかわかる感じに。ストラップ最高ですｗ

２０年以上遅い気がしますが、練習頑張ろうｗ

と、年が明け、昨日緩めた弦を再度チューニング中に１弦を切ってしまいました…

慌てて張り替えて念のために丸めておいて１弦を張り直し何とかしのぎました。

かなりドン引きですが、チューニングで弦の順番を勘違いしてチューニングしてしまい、どうも弦が張りすぎているなぁとは思いつつも、最後に１弦を張っている最中に逝きました…

今まで弦が切れるときって死ぬほど危ない状態になるんじゃないかと思っていましたが、かなり地味に切れます。てかこんな短期間に弦を切ってしまうなんてアホすぎますがｗ

安価な弦なので気軽に試せそうなのであれなんですが、３種類の弦があって、柔らかそうな方が軽く押さえるだけでいけそうなのかな？よくわからないのでとりあえずレギュラーと言う名の一番堅そうなのを買ったわけですが。柔らかいと伸びるのが速いとかはありそうだけど。またポチろう…

windows11のメモ帳

一般的にはおそらくWindows10のメモ帳とWindows11のメモ帳ではWindows11の方が受けはいいとは思う。

ですが！

今までできたことができなくなるって結構致命的だったりします。

検索や置換でタブを含みたい場合は、コピーでクリップボードに入れてから入力フィールドにペーストすれば検索や置換が行えます。これが地味に効果的な場面も多く、微妙な表示が行われるものの、これはWindows11の現時点でのメモ帳でも行えました。

普通の人はこれぐらいだと思うのですが、環境設定や結構強引なプログラムソースなどはテキストファイルを一旦メモ帳に張り付けてから部分的に（とはいえ結構な行数）を一気に置換えたりする作業を行ったりします。その時に地味に改行コードを含めて置換えたりするんですが、これがWindows11のメモ帳ではできなかったり…クソですねｗ

なぜ改行コードを含めるかと言えば、行頭や行末に一括で挿入することができるのですが、これが行えなくなると地味に苦痛な作業を永遠に行う羽目になったりします。

 

ちなみに、Windows10のメモ帳の実行ファイルをWindows11上にもってきても動きませんでした。Vistaの時はできた記憶があるのだが…

まぁメモ帳だけでなく、地味に他のアプリもクソ化されてたりするのが痛い…その代わり便利になってる点があるといいのですけど。実感ないですねｗ

Caused by: org.jetbrains.org.objectweb.asm.MethodTooLargeException: Method too large:

最近 記述言語仕様が緩くなっていたので相当やばい作り方でなければ目にすることのなくなった様なコンパイル時エラーが出てきました。

相当やばい書き方…ちょうどしてますｗ

本来であればデータファイルやテーブルに落として使用するデータを、表計算のデータを　CSV風にテキストにしてArray<Any?>として配列として取り込んでます。

そんな阿漕な配列を使ってデータを捏ね繰り回していました。

読み込み仕様を悩んだ場合は、結局値を直に変数として記述すれば扱えるわけですが、クラスの形で作って記述していたところ、途中でエラーが出てしまいました。

class SrouceData {
    companion object {
        val array_data1 = arrayOf(
            :
            :
        )
        val array_data2 = arrayOf(
            :
            :
        )
        :
    }
}

回避策はないかとクラスの枠を取っ払って（言い方が違ってる気がするが）グローバル変数的にしてみても結果はわからず。扱い上はグローバルレベルで一つのクラスとして扱われている気配。

何をやってもダメそうなので、結局データクラスを分離することでエラーが出なくなりました。

class SrouceData1 {
    companion object {
        val array_data1 = arrayOf(
            :
            :
        )
        :
    }
}

class SrouceData2 {
    companion object {
        val array_data2 = arrayOf(
            :
            :
        )
        :
    }
}

一つの配列の限界が来てしまった場合はどうすればいいのか分かりませんが、今回は一つのktファイル内で２つのクラスに分割するだけで回避できました。

Material3 Previewで試してみた

構造が少し異なってたので、もしかすると全く歯が立たないかと思われたものの、意外とあっさりとDrawerを組み込めたので早速確認してみました。

Android12だと少し表示が異なっていましたが、おそらくそれ以前のものはDrawer周りの表示は変わってなさそう。

とりあえず手持ちのAndroid12の画面

アクションバーが表示されていない状態でドロワーが思いっきり画面名いっぱいの大きさで表示されるようになりました。この辺はAndroid自体がアプリが基本的に全画面の表示を行うことを前提にシフトした結果だと思います。まぁ現行のMaterialベースだと中途半端になっていて、Drawerのヘッダが欠けて表示されていたのであれだったんですが。

なにもせずアクションバーが表示された場合は、こんな感じ。これはほぼ現行のものと変わらない状態に。

最後はテーマに<item name="windowActionModeOverlay">true</item>を含めた場合。これもほぼ現行のものと変わらない感じ。

詳しく見てないのではっきりしませんが、Material3はシステムナビゲーションバーの下に入り込む感じになっているのが大きく違ってそうです。

そもそも論になりますが、どうもAndroidのUIは現行のIOSのものに移行しようとしているのが伝わってきます。と、するとDrawer排除の流れは必然なのかもしれないが、正直IOSの操作を見ているとイマイチ直感的でない感じがしています。画面が小さければおそらくIOSのジェスチャーベースの操作の方が一貫性が保てる感じがします。

ただ、そこまで小さな画面でなければ現行の形の方が扱いやすいとは思うんだけど。どうなんでしょうかね？特にタブレットでジェスチャベースって疲れる気がするんですが。  

結局、どうするか悩みどころですねぇ。Drawer使わないほうがいいのかな？とはいえ、アクションバーも単純にtoolbarを上書きする形で実装すればよさげな感じはしてるｗ調べてないけどありそうな感じ。

Android: NavControllerとDrawerとAppBar(ActionBar) 未解決

最近の流れではAppBar(ActionBar)の中にToolbarを含め、そのToolbarがナビゲーションボタンやメニューを包括しています。

Drawerが無ければほぼ問題がないのですが、やはりDrawerは欲しいわけで。

実際のアプリではRecyclerViewで選択させたときにアクションモードを開始して問題が発生しました。問題を単純化させるために新規プロジェクトで作成してDrawerの雛形からアクションモードを発生させて試してみましたが結果は変わらず。

ちなみに最新情報を検索するのが面倒で開発環境はステーブルを使うようになっています。

何が問題になっているのかと言えば、単純にアクションモードを開始するとこんな感じに

これはこれで若干の問題があるのですがｗ、それはさておき、ここでアクションモードを設定してDrawerを開くと、

こんな感じに。

状況としてはずりっと画面がズレてToolbarの上部にアクションバーが表示され痛い感じに。

一般受けが良さそうではないので、一般的な形にするにはテーマに次の一行加えて

<item name="windowActionModeOverlay">true</item>

実行するといい感じにToolbarに重なって表示されるようになり、いい感じです。

このいい感じになった状態でDrawerを開くと…

なんかもう仕様書で「ツールバーに重ねて表示」とか書いてPGがやっつけで作ったような感じに。

 仕様書を書いた側は違うんだよなぁとか言いたい感じです。

最新のGMAILアプリを見る限りこの辺の表示方法がガラッと変わっているので全く参考になりませんでしたが、ＵＩのガイドラインを無視すれば、そもそもDrawerをToolbarに重ねなければ表示上問題ないような気がします。スタックオーバーフローにもツールバーに重ねない方法は？という質問が上がっていますし、同様の結論を持っている人がいるようです。

テーマからレイアウトまで手を入れればこの辺は解決するのですが、カスタマイズすると結構核心部で痛い目を見るのであまり手を加えたくないのも事実。てか、この辺の仕様はもう変わらないんだろうなぁ…テーマやレイアウトで切り分けてるくせに、肝心の処理がその構造にべったりだったりして結局すべてに手を加えないといけないっていうクソめんどくささ。

なんかどこかに一発で綺麗になってくれそうな解決策ないかな？新しいマテリアルベースにするとこの辺変わったりするのかな？