2022年11月23日水曜日

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

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

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

本来であればデータファイルやテーブルに落として使用するデータを、表計算のデータを 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ファイル内で2つのクラスに分割するだけで回避できました。

2022年11月19日土曜日

Material3 Previewで試してみた

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

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

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

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

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

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

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

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

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

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

2022年11月18日金曜日

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

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

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

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

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

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

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

こんな感じに。

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

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

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

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

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

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

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

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

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

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

2022年11月8日火曜日

prime musicアプリ

昨日少し書き込んだところ、タイムリーなことに今日FireHD10のシステムアップデートがかかりました。アプリ更新で単独で更新がかかるかもと期待していたのですが、ファーム自体アップデートされたようです。

例の微妙なサービス改悪変更がしっかり反映されたのかな?

ちなみに昨日の夜に電源ケーブルを接続したまま再生していたところ、再生が止まることもなくいい感じで再生し続けてくれていました。

で、さっそくアプリを起動して再生してみると、いい感じに再生されている感じでした。が、それも20分ぐらいでしょうか…止まりましたw

何度か再生してみてもしばらくするとやはり止まる。

設定を見直していると、オプションの設定で「自動再生 曲が終わると似たような曲を自動再生します。」という見慣れぬ設定があったのでそれをオフに。

すると今度は曲と曲の間で止まり、なんとなく数十分そのまま放置していたら突然次の曲が流れ始めました…よくわからんw

曲と曲の間は、もしかすると回線とかシステム系の過負荷による無反応かもしれない。

2022/11/08 22:58

~~~~~

設定のキャッシュをクリアを実行して今朝prime musicを電源接続無しで使っていますが結構調子がいいかも。

サーバー過負荷でなければ、キャッシュのクリアが解決策かな?

TextInputLayout/TextInputEditTextではemsが効かない

EditTextで画面が狭いながらもラベルとなるTextViewを付けてみるとlabelForなる属性値に気づく…

確かそんな属性あったけどあんまり効果なかったような気がするのだが…で、検索してみるとこんなページが

編集可能なビューのラベル https://support.google.com/accessibility/android/answer/6378120?hl=ja

その中で、「ヒント: Android Design Support Library にある TextInputLayout を利用すると、EditText と関連するテキストラベルを管理しやすくなり、Android のユーザー補助サービスとの連携が向上します。」とあるので早速リンクから飛んでみるとページには

 DEPRECATED

文字が…むむむ、もう廃止されちゃってないのかな?と思ってさらに検索してみると、クラスのマッピングのページが引っかかりました。

一応androidxに取り込まれているようなのでちょっと使ってみました。が、画面幅いっぱいに広がっているので少し調整してみようとems属性に数字を入れてみたところ変化なし。

色々といじっているとlayout_widthへの設定はラッピングのTextInputLayoutの状態によって変更できなくなっているようで…なにやらこの辺の属性は柵がある様子。

少なくても表示エリアが少なくなるのと「編集可能なビューのラベル」を読む限りユーザー補助などに対しても結構有用そうなので使いたかったのだが…

Android Studio: リファクターで漏れる…

リファクター機能はしっかりとできていれば強力且つケアレスミスが発生しないのでとても有望なのですが、実装に問題があるととんでもないことになるとても危険な機能だったり。

そんなリファクター。私は過去に試しに使って痛い目を見て以来、信用ならない無駄な機能の代表格でした。

しかし、Androidの開発環境がエクリプスからAndroid Studio変わり、しばらくするとリファクターが実装されたときに試しに使ってみると、思いのほか結構しっかりと変更してくれて余計な変更などもなく無事に使え感動した記憶があります。なので、結構頻繁にリファクトしてたりしますが、巨大な範囲に及ぶ作業だとバックアップ取ってからやってますがw

個人的にはリファクターは名称の変更しか用はないのですが、たまに使っているsafe deleteとかは動作が若干怪しかったりするので、その辺は今までの経験則にのっとった方が無難だったりします。

で、調子に乗っていると漏れてました…ただ、結果がわかればこれは致し方ないかなあ?とか思える部分かな。

やったことはFragmentのレイアウトxmlの名前を変更したところ、kotlinのコードのimport部分のdatabindingのクラス名が漏れてました。

まぁ被害としてはコンパイル時にエラーが出て、書き換えてあげれば問題ないので実被害はほぼないのですが、それでもこの手の漏れは疲れているときに発生するときついかもなぁ…

リファクタによる変更でキツイ点は変更されてるなんて思ってもみないところで書き換わってたりすると発見するまでに結構時間経過が経っていて、バックアップやヒストリーが無いと戻せなくなりそうなところ。

2022年11月7日月曜日

アマゾンのアプリが挙動不審な件

前々から気になってたのですが、いつも利用しているprime videoとprime musicアプリがダメになっている点があります。

2022年11月1日火曜日

Android: EditText で例外が発生しアプリが落ちる

意外と簡単に例外が発生して愚痴りたいと思いますw

簡単な入力画面をAndroidで作ってみようかと思って試行錯誤する事、早数か月。

もしかしてAndroidでも事務処理系のアプリで結構できるかもと思い確認作業から始めてみると、