Medoly – Google Play の Android アプリ
ソートアイコン変更
![]() |
変更前 |
![]() |
変更後 |
![]() |
変更前 |
![]() |
変更後 |
Medoly Ver.1.2.0をリリースしました。
個人的な感覚では1.5.0ぐらいまでバージョンをすっ飛ばしたいところですが、表面上は大して変わり映えしないので1.2.0で。
今回のバージョンで再生キューの内部的な処理を大幅に見直しました。というか、ほぼ別物です。別物ですが、表面上は特に変わってないと思います。そういう風に作ったので。
今までは再生キューの内容をファイルパスで保持し、アプリ起動時にファイルパスから読み込んでいました。アプリ起動時に進捗ダイアログが表示されるのはそのためでした。ところが、当然読み込みに時間はかかります。
これが問題になるのは、リモートコントローラやウィジェットを利用する場合です。再生ボタンを押すと、その時にアプリが起動して読込処理が走るため、再生キューに多くの曲が登録されているとボタンを押しても反応しない等の問題があったり、よく分からないエラーが発生することがしばしばでした。
そんなわけで、再生キューの内容をSQLiteのテーブルで定義し、そこからCursorLoaderを利用して逐次読み込みすることにしました。アプリの根幹部分をゴッソリ入替えたので、この改造でほぼ1ヶ月ぐらい費やしてます。
そのため、起動時の再生キュー読込処理は無くなりました。その代わり、 端末の性能が低いと再生キューのスクロールが多少もたつく事があるかもしれません。それを気にするほど大量に再生キューを登録する利用をしているかどうかは分かりませんが。
また、編集モードのキュー入替え時に再生キューリストが一瞬だけちらつくのはコレに伴う影響です。従来メモリに保持してたものをテーブルに保持させた結果、書き換え&画面更新で処理が遅れてしまうためです。…もしかしたら何かの解決策があるかもしれませんが、現状はそこまで調べ切れてないため、仕様とさせてください。
あと、再生キュー登録時の進捗バーが無くなったのもとりあえず仕様です。処理が変わったことで以前のような進捗バーを出すことが出来なくなってしまったため、表示をやめました。そもそも、100曲登録する程度なら大した時間はかからないので。1000曲ぐらい登録するとやや時間はかかりますが。頑張れば表示出来ないことは無いですが、それによって登録処理が遅くなっても本末転倒なので…。
表面的に一番大きな変更点は、ついにウィジェットが追加されたこと。とりあえずレイアウト別に2種類あります。サイズが可変(最小サイズは2×1)なので、好みに応じて適当に拡大・縮小してご利用ください。Androidのバージョンによっては変なレイアウトになる可能性もありますが…。
Medoly Ver.1.1.5をリリースしました。
オマケ機能を追加したので、バージョンを0.0.5飛ばしました。(オマケなので…)
Medoly Ver.1.1.0及び1.1.1をリリースしました。
バージョンを1.1.10にしようとも思いましたが、機能が追加されたのでバージョンを 0.1あげました。
主な変更点は以下の通り。
大体機能としては以上のような感じです。
ちなみに、1.1.1は1.1.0のバグフィックスです。非常に初歩的なミスにより、時間のタイマーを解除しても終了時間に達した時点でアプリが終了するという問題があったためで…。
ちなみにAndroidのデータベースは、一つの曲が複数のプレイリスト/ジャンルに所属でき、アーティストやアルバム等のプロパティとは処理が少し異なります。それらを上手く処理するために、一部でSQLを直接書いています(本来、プログラムの安全性の観点からあまり好ましくはないのでしょうが…)。その結果、内部ではなかなかに面倒なSQLが組み上がってます。
Android携帯に登録されているプレイリストを取得する時の罠 – 理ろぐ
リピート再生(単曲再生)している時に、次へ/前へボタンを押した際に、再度同じ曲を再生する動きだったのですが、よく考えたらその動きおかしい…というわけで、次へ/前へを押したら再生キューの次/前の曲を再生するよう変更。ちなみに、再生キューの動きは全部自前で制御してるので、わざわざそういう動きを作ってたということになります。
…あんまりきちんと考えてなかった。
docomo のGalaxy S。3年ぐらい前に発売された、 Android 2.2の頃のスマートフォンが流行り始めた頃の端末。中古で5000円ぐらい。ジャンクならもっと安いかも。
自分はdocomoの回線契約は無いし、そもそもこれは純粋にアップデートするとAndroid 2.3までしか入らない。ところがこの端末、ストレージ容量も多く、今でも色々弄られ続けてる端末なので、これにカスタマイズされたAndroidをインストールする事ができる。自分が入れたのは、CyanogenMod という有名なカスタムOS。現状最新の CyanogenMod 11をインストールし、Android 4.4の環境で動作させている。
これを開発用端末にしてる理由は、
第一に安上がりに最新(or 過去バージョン)のAndroid環境が手に入ること。
第二に、古めの端末で自アプリがサポートしてるAndroidのバージョンが動く中では下限に近いスペックと考えられるため、アプリのベンチマークに適任なこと。
第三にディスプレイが狭いため、画面のレイアウトを考える上で参考になること。
…といった辺りが挙げられる。まぁ正直、一番目の理由が8割ぐらいですが。 元々、ストア配信のバージョンと、開発バージョンでアプリが競合してしまって、開発バージョンを入れるための開発用端末が別途欲しくなったのが発端だったので、動けば何でも良く、安上がりであることが何よりも重要だった、という経緯もあります。
なお、CyanogenMod自体は問題なく動作し、3年前の端末とは思えないほど動作も快適です。重い処理を走らせるとちょっと厳しいかもしれませんが、実用的には問題ないレベル。
ちなみに、Cyanogen Mod自体はサポートも無いし、動作しなくても自分で何とかせざるを得なく、大変面倒なので、メインの端末で使うのはちょっとお勧めしません。
![]() |
Galaxy SでAndroid 4.4 |
これは要望が上がったので追加。
再生中に歌詞の表示タイミング(オフセット)を調整することができますが、これを曲毎に毎回リセットせず、保存できるようにしました。ただ、これはズレがある歌詞に対して微調整をするための機能だったので、オプション扱いとします。設定画面でリセットする/しないは切り替えられます。
サムネイルの作成処理を少し見直しました。エラーのサムネイルを読み飛ばすようにしたので、エラーとなるサムネイルが沢山存在する場合に、再生キューのスクロールが高速化されます。…されるはずです。
アプリ起動時に、初回タブ画面が再生キューの状態からタブを切り替えると、タブ画面ではなくタブウィジェットがタブ画面に引っ張られるようにアニメーションしてしまうという問題がありました。原因がさっぱり分からなかったのですが、tabhostのタブ変更イベント( TabHost.OnTabChangeListener )の設定タイミングを、タブ登録の前に持ってきたところ発生しなくなりました。
操作開始前にTabHost.OnTabChangeListener を1回以上発生させておく必要があるのかなぁ、という予測。
以下の内容は、現在のところ自分で認識している問題です。原因調査中です。
再生キューのサムネイル生成時に、エラーが発生する場合があったので修正しました。
こちらで再現することができないのですが、AndroidのDBにあるメディア情報と実際のファイル状態に齟齬があると発生するような感じです。とりあえずエラーの発生箇所は分かるので、問題が起きないようにプログラムを変更しました。