そろそろソースコード管理をするべきか。マオです。

順調にAndroidのLiveWallpaperを開発してるんですが、携帯端末はメモリが少ないから節約して設計する必要があるんですよ。
で、順調に作っているある日、データ類をメモリに保存して使っているので将来的にデータ量が増えた時にパンクするという予感が出てきたので改造したんですよ。
具体的には表示部分に使っているBitmapは繰り返し使うのでファイルにして保存しといて、それを読み込んで何度も再利用しようと考えたわけです。
ソース全体を変更してミスを直しながら動かしてみた。
メモリ消費が三倍になった☆
あれー、なんかおかしいぞー？
どうもファイルからの読み込みの方がメモリ消費が激しくてどうにもならないっぽいな・・・。
元に戻すか考えたいけど、元ソースファイルをいじってるから戻すの手動でやらないといけないんだよね。
もうこのまま行くしかないのだろうか。

とりあえず、目に見えて減ったのはパッケージのサイズだったりするけど、どうでもいいがな(笑)

デフォルト環境は問題無いんだけどな。マオです。

ここ最近、Androidの新しいウィジェットを作って遊んでるんだけど、大規模なデザイン修正をすると開発環境であるEclipceが固まったり強制終了したりと困った事になっていた。
で、バージョンがアレなのかなーと思って調べてみたら、使ってるの32bit版だったという罠。
もしかしてメモリとかそこらへんの問題だったのか？
バージョンアップしようと思ったんだけど、元々使ってたのってサードパーティ製の日本語化されたヤツで、最新版はまだ開発中だそうな。
ってな訳で、一応日本語化もされているっぽい本家の64bit最新版を入れてみた。
これで直るといいんだがな。

で、タイトルにある環境依存な話。
開発を投げ出しそうになったウィジェットが妥協を重ねた末に表示の部分のみ完成したんで、実機テストしたんですよ。
一応、開発初期にコンセプトがうまく動くかどうかのテストはしてうまく行ってたんだけど、サイズ調整とか何か色々弄った物を中間実機テストしたら動かないでやんの。
ログと睨めっこしながら色々と頑張ってみた所、ADW.Launcher固有の現象ってのが分かった。
デフォルトのホームだと問題なく動く。
対処法は見つけたんだけど、これで大丈夫と言い切れないんだよねぇ・・・。
後、他にも端末の縦横の向きが対処できない。
サイズが縦向き端末しか動かないので、多分auのアレでは動かないと思うんだよね。
この世の中で縦にしたり横にしたりと気分で動かす人っているのか？

プログラム系の記事の為に新しいカテゴリ「月面開発室」を作りました。
私も部屋も太陽の光に当たらない月面の状態になりつつあります。
タスケテー＞＜

各種リソースを使用する時に、自動生成されるgenフォルダにあるR.javaより「R.yyyy.xxxx」と名前を直接指定してリソースのIDを取り出す事がほとんどだが、例えば複数個あるViewに同じ処理を使用とする時にこの方法は面倒な事になる。
言語によっては、Viewをグループ化して配列にするんて方法があると思うけど、Androidにはこの機能が付いているのだろうか？
とりあえず、私が知っている方法としては以下の方法がある。

１．コードに配列を作って、予めIDを入れておく。
int[] res_id = {R.yyyy.xxxx0 , R.yyyy.xxxx1 , R.yyyy.xxxx2};

２．ViewのIDに連番を付けて、getIdentifierを使ってリソースIDを取得する。
Resources res = getResources();   //Widgetの場合はcontext.getRssources();を使う。
int res_id;
for(int i = 0; i < 3; i++) {
    res_id = res.getIdentifier("xxxx" + i, "yyyy", getPackageName());
}

前者はViewが増えるとメモリが、後者は処理手順が増えるのかしら・・・。
他にも「R.class.getClasses()」を使うという方法もあるけど割愛しとく。
興味がある人はググるといい。

こうじゃないとネ。マオです。

Calendarクラスの継承問題ですが、アッサリと解決してしまった。
実はCalendarクラスのサブクラスにGregorianCalendarクラスってのがあって、それを継承すれば既存ソースにタッチする事無く継承できる。
最初から気付いていればとも思っちゃったりしたが、Calendarクラスを色々いじってたお陰で、大体の中身の意味を把握できたのでこれは無駄じゃなかったな。
いじらなかったら、別の所で躓いてたと予測できる事態があったし・・・。
やっぱり、一日寝ると脳がちゃんと切り替わりますね。

困っている事。
祝日の判定は初期に実装した物がそのまま使えたんだけど、振替休日の判定の実装に悩んでます。
今までは一ヶ月のデータを溜め込んだ後に、日曜祝日の部分を探して次の平日に割り当てるというロジックしてたんだけど、今度は処理単位が1日ずつになってしまったので、処理時間が増えそうな予感。
って言っても、ミリ秒単位の話だと思うけどな(笑)

しかし、この手の入力と回答が沢山あるプログラムのチェックは自動化ツールが便利ですねー。
テスト用のプログラムを作っておけばボタンをポチッですから・・・。
一年の平日・祝日の総チェックを0.03秒してくれます。
変動型の祝日は嫌な予感がするから、三年分くらいテストしとこうかしら。

早く本体の開発に戻りたい所＞＜

綺麗に作ろうとすると手間がかかる。マオです。

良い感じにカレンダーウィジェットの開発が滞っています☆
細かい作業が多いのよ。
一つのマスに一杯部品が入ってるもんで、一箇所いじると全箇所一つずつ修正するという地獄の作業。
サイズとかのプロパティに関しては共有してるから一箇所で修正できるんだけど、個別に付けなきゃいけないプロパティは35箇所修正です＞＜
で、見事にレイアウト的なバグが見つかって10月の6週必要な所で、6週目が表示されないというのを見つけてしまって+7個追加の42箇所修正。
しかも、デザイン的な部分でマスにさらに部品を詰め込む作業が(略)

ここからは言語的な話。
カレンダーなのでCalendarクラスを多用してるんですが、これを継承して祝日も対応したいんだよね。
所がCalendarクラスを継承すると、便利なメソッドも自力で実装しなきゃいけない。
そのままの君が好きなのにッ！(馬鹿)
これ出来れば微妙なソースコードが色々とスッキリするんだけどなー。
いつもスパゲティなコードになりがちなので、ここらで綺麗にすれば後が楽なんだろうけど・・・。

完成が遠いな(遠い目)