アーカイブ

メディアの読み込み時に進捗ダイアログを表示するようにしました。具体的には、検索画面からメディアの登録時、起動時の再読込時、プレイリスト読込み時の3点です。起動時以外は進捗バーが出ます。なお、ダイアログ表示中にキャンセルを押すとキャンセル可能です。

今までは、全てのメディアを読み込むまで一切の操作ができなかったため、曲数が多いとアプリが固まってしまう事象への対策です。 ちなみに、再生キューに一気に数百曲とか放り込むような無茶な使い方をするような自分のための機能です。

画面の表示更新とメディアの読込でマルチスレッドで動かす必要があり、これに対応させるために読み込み処理部分を大幅に組み直しました。正直、1.0.8から大分組み直してます。感覚的には1.2か1.3ぐらいでも良いような気がしますが、表面的に目だって異なるのはこのダイアログぐらいなので、1.0.9です。個人的に、バージョンの付け方はユーザーが感じる機能向上に合わせて付けるものと思ってますので…。
恐らく、これに伴って再生キューに2重に登録される 不具合が解消されたと思います。多分そんな気がします。…されてるといいなぁ。
また、この変更によって何かしらの不具合が発生する可能性がありますが、その場合は、ご報告いただけると幸いです。

なお、何となく想像はつくかと思いますが、現在は再生キューの中身を丸ごとアプリで保持してます（サムネイル除く）。本当はSQLiteデータベースを用いて、逐次読み込みで対応させるところだと思いますが、最初に作った時にそこまで考えていなかったので…。この方法なら恐らく、今の起動時の読み込み処理は無くなり、キュー追加も早くなるかもしれません。ただ一方で、再生キューのスクロールが引っかかるような動きになるかもしれません…が、そこまでキューにたくさん曲を入れる人はそんなにいないような気がするので、その辺の影響はあまり考えなくても良いような。
とりあえず、その辺りはまた組み直すつもりですが、今はこのままで。

検索条件にプレイリストやジャンルが含まれていた場合、検索に失敗してアプリが落ちる場合があった問題を修正。これは、プレイリストやジャンルのキーの列名が「_id」となっており、さらに曲のキーも「_id」となっていたため、これらを組み合わせると列が重複してしまいSQLがエラーを吐くというものです。
これに対し、曲の検索条件に「title_key」キーを使用したり、名前にテーブル名を含めたりして、問題が起きないように修正しました。

ちなみにAndroidのデータベースは、一つの曲が複数のプレイリスト/ジャンルに所属でき、アーティストやアルバム等のプロパティとは処理が少し異なります。それらを上手く処理するために、一部でSQLを直接書いています（本来、プログラムの安全性の観点からあまり好ましくはないのでしょうが…）。その結果、内部ではなかなかに面倒なSQLが組み上がってます。

なお、下記サイトによると、テーブル名が一部異なる端末も世の中には存在するようで、そういった端末では確実にエラーが起きます。もしそのような端末があった場合は御一報ください。（下記の情報はAndroid 2.x端末の話なので、最初から本アプリは動作しません。）

リピート再生時の次へ/前へボタンの挙動変更

リピート再生（単曲再生）している時に、次へ/前へボタンを押した際に、再度同じ曲を再生する動きだったのですが、よく考えたらその動きおかしい…というわけで、次へ/前へを押したら再生キューの次/前の曲を再生するよう変更。ちなみに、再生キューの動きは全部自前で制御してるので、わざわざそういう動きを作ってたということになります。
…あんまりきちんと考えてなかった。

プロパティタブメニューの対象に無い項目を非表示

その他

現在把握してる問題

• Android 4.4 (KitKat)で、スクロールのつまみが表示されない。これはAndroid側の問題臭い。
• ごく希に、何もしてない時にプロセスが暴走してる事がある模様。再現性がなくて確認できない。多分、上記の読込処理に関連した問題だと思ってる。バックグラウンドのサービスが起動した時に読込処理が走って、何かやってるのかなぁ、と推測。とりあえず、上記に書いた読み込み処理の変更した後で考えることにする。