言い訳タイム

 Android言い訳タイム。(AlbumShuffle)
 iOSアプリのgroove(Android版はない)を見せて貰ったりしながら話を聞いてきた。UIはやっぱり難しいね。まぁ勿論うちはそんなでかいアプリと競うつもりはないので、ランダムアルバムというメイン機能を軸にやりたいことを明確にしていければいいなとは思っていますが。

・Random Selectなるボタン
 まぁ正直自分も悩んだんですが、はっきり言って何コレ分かり難いよねと。
 機能的には「トラックリストの中から開始位置をランダムで選んでスタートする」というまぁ一応名前そのままではあるんですが。
 そもそも何でこれが出来たかというと、元々アルバムをランダムで選択する機能から始まって、その中のトラック再生順もランダム化する「shuffle track」がついたと。その上で楽曲選択機能を入れるという時に、アルバムだけ選んでスタートすれば何の苦労も無かった訳ですが、普通に考えればトラックも選択したくなるよねと。ただそうするとshuffle trackモード時のシャッフルスタートはどうするのということで、それ用のボタンを置いたと。でもって今度は通常再生モードの時にどうしようかというところで、要はトラック選択がお任せになるという意味でまとまるなということで、最終的に「開始位置をランダムで選んでスタートする」=「Random Select」という名称になりましたと。ワカリニクイネ!

 通常モードの時はボタンを消して、shuffle trackの時だけ「Shuffle Start」というそのものずばりの名称にしておけば何の苦労も無かった気もするんですが、モードで機能が切り替わるより意味合いが統一される方が良いかなと考えたりもしたというか。
 それ以外にも幾つか代案、妥協案を考えたりはしたけれど、なかなかどれもこれという結論に行き着かず。
 うーん。
 まぁ少なくとも今のバージョンはやってしまった感が激しいので、確実に手直しをする予定ということで、今はごめんなさい。

・アルバム選択UI
 実のところ今まで2G分くらいのアルバムしか入れていなかったのだけれど、今回アプリがそれっぽくなったことで調子に乗ってアルバムをガンガン突っ込んでみたら、案の定アルバム選択がもうただの一覧ではやってられない(笑)。
 ただこれこそどういうUIが良いのだろうか。
 超絶極個人的な話をすると、自分はフォルダである程度の分類を作っていて(ゲーム、アニメ、洋楽なんちゃらとか)、そのフィルタをかますだけでもアルバムの絞り込みの役には立つのだけれど、これは一般的には全く成り立たない話なので論外だろうと思う。(PCのfoobar2000ではフォルダでフィルタして指定フォルダ以下ランダムなどとやっている。作業BGM=ゲーム音楽な自分としてはこういう使い方は便利なのだけれど)。まぁこれはそもそもID3タグの「ジャンル」が正しく機能していればそれで行う筈のもの。だけどあれは死にタグだろうし。
 そうすると、あと使われるのはやっぱりアーティスト分類くらい。アーティストで括って二階層の展開式リストにするのも一つの手ではあるけれど。ただそれでも一覧がダラーッと連なることにやはり変わりはない。
 結局「検索を入れてくれればいい」と言われたけど、やっぱりそれくらいしかないのかなぁ。自分もPCの方のライブラリはそれこそ(要らないものも)一杯あって、曲を探す時は検索上等だし。ただスマフォで文字入力はかったるくて出来ればやりたくないという思いもあるのが大変悩ましい。
 うーん。

・Serviceの終了処理
 pauseのまま待機状態というのが常のこのアプリの機能的に終了タイミングがないので、serviceの終了はもうシステムの強制終了(例のno longer want)にお任せという状態だったのだけれど、これがどうにもおかしい。
 前から薄々気になってはいたけれど、START_NOT_STICKY指定で立ち上げている筈のこのserviceを強制終了させても(no longer wantを食らっても)、どういう訳か再起動が掛かる。それこそ消しても消してもゾンビのように立ち上がる(苦笑)。ただまぁStartCommandの方は走っていなくてただCreateされているだけなので、動作的にCPUに何の負担を掛けているという訳でもない(筈)。ただやはりこのゾンビっぷりは何処ぞの行儀の悪いソフトのように思われそうでどうにもなぁと。それにメモリも食うしね。
 そもそもSTART_NOT_STICKYなのに再起動されるのは、どうもBindを使った時に発生する模様。bind時にAUTO_CREATEさせているので(してなくてもなんだけど)、kill後にcreateだけ走るというのは何となく合致する。ただunbindしてもその状態から抜け出せないのがどうなのかという所ではありますが。調べてみたけれど解決法は見付からなくて。後はもうservice側できちんとstopselfするしかない感じ。

 うーん、今はレジューム処理もあるし、pause後に適当にタイマ張って待機状態が長く続いたらstopさせちゃおうかなぁ。そこでタイマ処理が暴発して再生中に強制stopする訳ですね、分かります(ぉ)。
 まぁやはり何かしらの形で終了処理まできちんと持って行きたいというのもヘボグラマ(ヘボいプログラマ)的にありまして。なので今はBT切断という「明らかにもう使わないよね」というタイミングだけ終了処理を走らせてます。上記の話はBT未使用時。


 などとグダグダ書き並べてしまいましたが。
 手を入れないといけない部分は一杯あるけれど、ただ機能的には一応成り立っているので、ちょっとそれより違うこともやりたい自分がいるというか。弄るなら何気に結構弄らないといけないもんで。その葛藤を表現してみましたということで。

AlbumShuffle 0.07

 Androidランダム再生。
 そろそろ上げようかと思う度にバグを見付けたり何か気付いて弄り始めたりして一向に収まりがつかないのだけれど、そろそろ一旦キリをつけたいのでここで締めることにする。

 という訳で、ver0.07。
>AlbumShuffle007.apk (※提供元不明のアプリを許可で)

# 因みに今回は(ようやっと)リリースビルドしてみたので、旧版を入れている場合は一旦削除願います。

 今回も思いのほか色々弄ってしまった。
・アルバムアート表示
・アルバム~トラック選択
・fix: トラックソートにファイル名順追加
・fix: 状態保存 (rewind)
・fix: notification起動時(既存のものをlaunch)
・fix: service終了処理を若干修正


 以下個別に。
・アルバムアート表示
img
 どうせコンテンツプロバイダから取ってくるだけの話なので表示してみた。
 曲名表示の裏に置くしかなかったので強制的に半輝度表示です。別にいいよね。
 因みにアルバムアートはこれまで全く使ってなかったけど、このテストの為に入れました。表示してみるとまぁ悪くないなぁと。

・アルバム~トラック選択
img img
 shuffle(next-album)ボタンの隣のplaylistボタンで起動。アルバム及びトラック選択できるようにしました。リストの強調表示は現在演奏中のアルバム・トラック。曲の切り替わり時にちゃんと反映しますよ(無駄に)。
 アルバム選択に関しては、今はただアルバムを一覧にしてるだけなのでライブラリが沢山ある場合の操作性が酷く悪そうですが、この辺のUIは後日課題。
 あとトラックも選択出来るようにしたけれど、自分はshuffle-track常用なのでランダムでスタート出来るようにrandom-selectボタンを据えてありまする。いい置き場もなくて幅食っちゃってるのでリストが狭いかも。あとアイコンがイマイチしっくり来ない。shuffleする訳ではないのでこれじゃない方がいいと思うんだけど、”icon random”で検索してもこれしか出てこないし、どうしたものか。
 尚、トラック選択は内部で作成したプレイリストの該当位置にジャンプするものなので、shuffle-trackの場合、最悪リストの一番最後になって即アルバムが終わる可能性もありますが。今のところ仕様ということで。

 因みに機能実装はすぐだったんだけど、リスト表示関連で色々すったもんだありました。

・fix: トラックソートにファイル名順追加
 トラック番号ソートしかしてなかったので、一応ファイル名ソートも追加。
 トラック番号がない/おかしい時の回避用に。

・fix: 状態保存 (rewind)
 やっぱり漏れがありましたねと(笑)。

・fix: notification起動時(既存のものをlaunch)
 サンプルそのままだとNotificationから呼び出す度にActivityがポコポコ立ち上がることに気付いたので修正。一個しか立ち上がらないように。

・fix: service終了処理を若干修正
 少し手直ししてみた。バグってないといいね(オチ)。

 以下、開発寄りのお話。

・targetSdkVersion
 を15(ICS v4.0)にした。
 ので本格的にGB(v2.3)でバグらないといいね。
 minSdkVersionは10のまま。多分もっと下でも行けるかもしれないけど個人環境的に保証出来ないので。

・ListViewの強調表示
 前回エントリのお話。
 activate機能がv3からと知らず、代わりにcheckedを使おうとしたら軽く嵌った。

・drawableが一部表示されず
 軽い気持ちでエミュレータでGB(v2.3)の動作確認をしてみたら、random-selectボタンだけが何故か表示されないという謎の現象に遭遇。
 まぁ結局、Android側のバグだったんですけどね(苦笑)。(>参考
 drawableリソースの先頭のものが参照出来なくなると。読めている画面もあるので特定条件があるのかと思うけどそこは知らない。対処法としてはdrawableフォルダにdummyファイルを置くこと。アルファベット順で先頭になるように。(因みにeclipseは_付きを何故か上に表示するけどリソース順は違うので注意)

 他にもこういう訳の分からないバグがあるのかなぁと思うとやっぱり各バージョンごとに確認しないといけないのだろうね。
 というかエミュと実機でしっかり同じくバグるというのが微妙に笑えた。てっきり最初はエミュだけの表示バグかと思ったくらい。

・アルバム選択リスト
 ListViewにimageを入れる場合は非同期でやるとか、画像キャッシュを使うとか、色々断片的に情報を掻き集めながら改修を重ねていたのだけれど、実のところ公式資料に一通りのことがきちんと書かれていた(苦笑)。

 なんでまぁあまり書くこともなくなってしまった気がしますが、一応、
 途中ですったもんだやっている最中、どうしても微妙なカクつきが取れない気がして、android:hardwareAccelerated をonにしたらやっと滑らかになったということもあった。まぁそこからまた作り替えたのでよく分からなくなりましたが。それにtargetSdkVersionを上げると勝手にonになるので意識する必要はないのかも。
 因みにonになっているとデフォルトの背景に微妙にグラデが掛かる。(画面によっては色合いが悪いので黒に塗り潰してますが)

・LruCache
 折角なので上記のLruCacheを使ってみたのだけど、これはapi12以降なので互換用ライブラリを入れた。
 お陰でアプリサイズが一気に倍以上に膨らんでしまった。ちぇ。

・画像サイズ調整
 基本的には上記の話に準じているけれど、bitmap読み込み時のスケール(間引き)だけでは大雑把でメモリサイズが膨らむので、実際の必要サイズにまで縮小(Bitmap.createScaledBitmap)してある。まぁその分処理が遅くなるので随分悩んだけれど、どうせ読み込みは最初の一回だけだし。この縮小をやらないと手持ちのデータでも倍近く差が出るので。
 この辺、どうせ縮小するならと実サイズからそのまま処理するとbitmap一時生成が重くて、やっぱりスケール読込みしてから改めてリサイズするという実に二度手間なことに。読み込みと任意縮小を一気に出来ればいい気がするんだけど、分からず。

・notification起動
 これはSingleTaskでも用は足りたんだけど、折角なのでLauncherで既存インスタンスがあればそれをそのまま立ち上げるようにした(参考)。要はhomeに置かれるアプリアイコンと同じ形にすると。成る程。

・ActionBar(タイトルバー)
 今回ボタンを追加したけれど、こうやってボタンが増えてくるとそれが幾つも並ぶよりはActionBarを利用するように考えていった方がいいのだろうなぁと。
 まぁ今はこの先どう変わっていくかまだ何とも言えないところがあるので、もう少し機能的に整理出来てからかなということで見送った。
 因みにActionBar自体はv3以降の機能だけれど、v2でも使えるライブラリがあるので、やるならこれを試してみると思う。>コチラ
 というかデフォルトだとボタンが無駄にでかすぎるとかあるのだけれど、カスタマイズできるのかなぁ。

・横画面とかタブレットとか
 レイアウトがめんどくさいので今はportrait(縦)固定にしちゃってますが、対応したところでどうせ横画面でリストなんて操作しづらいだけだしなぁ。まぁめんどくさがっちゃいけないんですが(汗)。
 まぁタブレットは逆に横画面がデフォなので、それこそ残念なことになるんですが(使う人がいるかはともかく)
 ただタブレットはどちらにしろ大画面でレイアウトが合わなくなるので、本当はそれ用に考えないといけないし。この辺、fragmentで両対応みたいな話もあるけれど、そう上手いこと共用の構造が取れるとは限らないし、それよりもタブレットは個別に作り込んでHD版としてしまっているアプリも見掛けるので、結局はそれが開発側の回答なんじゃないかなと思う。
 まぁlandscape(横)対応だけはしておいた方がいいよねやっぱ。


 そんなこんなで。意外に勉強になりました。
 あとそうそう、これを言い忘れていた。なんかアプリっぽくなってきたね(笑)。

貴重な和製TF枠が

 ニコ動でやっているビーストウォーズネオの配信が週5になってしまったので見るだけで疲れてしまった(笑)。いや一気に見る必要性は何処にもないのだけど、大抵ギリギリまで忘れているので。。。

 終盤に向けてストーリー展開が始まったんだけど、まぁ要素的には面白いんだけどねぇ、と思わされるところ。マグマトロンがようやく動き出した時は結構期待して見てたんだけど、実に残念な結果になってしまって切ない。というか当時の記憶からすっぽ抜けていたのにも納得(笑)。部下の動向なんかも含めてもうちょっと面白く出来たろうになぁ。下手にユニクロン(の代役)で話を進めるより、最後まで彼等中心でやって欲しかった。
 あとやっぱり脚本の安定性がもう少しあれば。台詞周りで前後の繋がりがバラバラだったりして、こういうのは真面目に話が進んでいる中では余計にアラが目立つ。まぁこの時期の低予算アニメにはよくある形という感じだったけれど。前作II(セカンド)も同じように酷い脚本は一杯あったけれど、あれは最終回ギリギリまでほのぼの日常系を貫いていた(いやストーリー展開していたハズなんだけど(笑))ので、楽しむべき所をすぱっと切り分けて楽しめたんじゃないかと思う。

 ともあれ、この流れで是非カーロボまで見たかったね。ジュン子さんを(そこか)。

 配信チャンネル自体が今月でなくなってしまうようで、やっぱりネットで有料配信は流行らないよね。ましてやニコ動で。無料期間が過ぎたら誰も見なくなる以外ないに決まっている。素直に広告ベースで配信できなかったのかなぁ。海の向こうじゃ上手くやっていると聞くけれど、日本ではどうしてこう上手くやれないのか。
 まぁ自分はCSで流してくれればそっちでいいんですけどね。でも和製TFなんてまず流れてこないからなぁ。いっそHub(Hasbro社のチャンネル)が日本上陸して、歴代TFを片っ端から掻き集めて垂れ流してくれれば幾らでも見るのになぁ、などと思いつつ。

state_activatedの罠

 Android進捗。
 粗方やりたい所は組めたと思うけど、若干気になる点があるので確認中。

 しかし今回は妙なところで嵌ってしまった。実働的には大したことはないけど気分的に。
 ListViewで選択行に色付けをするだけの簡単なお仕事を5分くらいで済まそうと思ったら、何だかさっぱり動かない。それというのも、自分はAndroidでUI周りを弄り始めたのは主にタブレットからなので当たり前のように使ってしまっていたけれど、state_activatedってHC(v3)からの機能なのね。
 しかもこれは今思えばなるほど馬鹿な話だけれど、プロジェクトのplatformのjarはICS(v4.0)に切り替えていたけどtargetSdkVersionを指定していなかったので、minSdkVersionに指定したGB(v2.3)に引っ張られて下位互換モードで動いていたという。だから旧OSでもエラーにならないしかといって新OSでも動作しないしで、一体どいうことかと実に無駄な時間を過ごしてしまった。はははのは。

 でまぁstate_activatedが使えないならstate_checkedを使えばいいじゃない、と思ったのだけれどこれまたさっぱり動かない。ListView自体はcheck状態を保持出来ているけれど、各行のviewでstateが取れない。
 どうやらstate_checkedを使うには各行のviewにCheckableを実装し、自分でcheck状態を保持して、尚かつdrawableStateにstate_checkedをマージせよと参考。分かってしまえば成る程ではあるけれど、こんな単純な処理でも実に原始的なことをやらされるのだなぁと。しかも公式サンプルだとstateの処理はサボっているから分からないし(何だかな)。
 まぁこれを見かねてactivateが追加された訳で、ラクになったよね良かったねということなのですが。ただ新OSでしか動かないので、v2がまだシェアの大半を占める現状では結局古い実装方式を取るしかない。他にもv3やv4で扱いやすくなったものは結構あって、こういうのを見る度にさっさとv2も駆逐されてしまえと思ってしまう。
 それに、こういった変遷を知らないと、webサイトで情報を集めても何処か話が噛み合わなかったりすることが多くて、特に今はv2以前の情報が大半を占めるからかなり困る。googleが短期間でころころ変えすぎなんじゃないかとも思うけれど、過渡期はこんなものなのかなぁ。

 まぁそんなバージョン問題のゴタゴタなんぞより、リストのスクロールが酷くカクカクなもんで、あれやこれやと手を入れてやっと標準プレーヤと同等の自然なスクロールになったよ、などとやっている方が実に建設的且つ健康的で良いやね。