Medoly
ちょっと思いついた事を実装。
再生キュー項目の長押しメニュー内容変更
再生キューの曲を長押しした際のメニューに「先頭に移動」と「末尾に移動」を追加。個人的に少しほしかったので。
代わりに「再生」を除外。再生は項目をタップすれば良いだけの話なので必要性は低いかな…と。
検索画面のジャンル表示高速化
検索のジャンル画面の表示を少し高速化しました。
Androidのメディアデータベースは、一つの曲が複数のジャンルを保持できる構成になっています。
各ジャンルに含まれている曲数を表示させるため、今までは各ジャンルそれぞれについて曲数をカウントするという事をやっていたため、やや処理が遅くなっていました。当然、ジャンル数が多いと時間がかかります。
最近ちょっと調べてみたところ、検索URIに「content://media/external/audio/genres/all/members」を用いることで、ジャンルIDと楽曲IDの紐付けを行うテーブルにアクセスできる事が分かりました（ちなみに「audio_genres_map_noid」というビューを参照している。実体は「audio_genres_map」テーブルの模様）。
これをジャンルIDでグループ化して、各グループのカウントを取得することで、ジャンルに含まれる曲数を素早く取得できるようになりました。
ちなみに、プレイリストも同様の処理を行うつもりでしたが、同様ののURIが見当たりません…。
検索画面のストレージ表示高速化
検索のストレージ画面の表示を高速化しました。
これも曲数カウント絡みで、従来はテーブルからカレントディレクトリに含まれるメディアを全て取得し、Javaのコードで項目をカウントするという力業で曲数を取得していました。当然、曲数が増えると処理に時間がかかるようになります。ディレクトリの階層が浅くなり、サブディレクトリに含まれるメディアが増えていくと、それに合わせて表示に時間がかかるようになります。
変更後は、SQLiteのGROUP BYとCOUNT関数を活用するようにしました。ただし、SQLiteは文字列長に合わせた柔軟なグループ化ができない（私が知らない）ので、以下のような感じのSQL処理を行うようにしました。
START = カレントディレクトリパスの文字列長
LENGTH = カレントディレクトリに含まれる最大ファイル・フォルダ文字列長
SELECT [ファイルパス], SUBSTR([ファイルパス], START, LENGTH) AS subpath, COUNT(subpath) as count
FROM [メディアテーブル]
WHERE [ファイルパス] LIKE カレントディレクトリ%
GROUP BY subpath
上記の内容は大雑把なイメージですが、とりあえずSQLで可能な範囲でざっくり纏めてしまうというのが基本的な方針です。もちろん、同一のサブフォルダが複数に分割される場合もありますが、細かいカウントの合計値はJavaの処理で行っています。
なお、この処理の特性上、カレントディレクトリに一つでも長い名前のファイル・フォルダが含まれていると処理の効率が悪くなります。
ただ、ほとんどの場合は表示が高速化されますし、上位ディレクトリに行く程表示が遅くなる従来の問題は無くなります。
検索画面のジャンル・プレイリストのカウントが正しく表示されない問題修正
これは、カウントする処理が誤っていたバグです。
検索画面で一つでもチェックが入っていた場合に、タップ挙動をチェックの変更とする
検索画面で、リスト上に一つでもチェックが入っていた場合、項目タップの挙動をチェックのON/OFF切換とするようにしました。ディレクトリのタップ動作によりチェックが全てクリアされてしまうため、誤操作により何度もチェックをやり直す羽目になる問題があったためです。