頑張ってコード修正をしている。マオです。

相変わらずユーザインターフェイスに苦労している開発ですが、もう一個ほど困ってた事があったんだ。
何かというと「コードの大幅な改良しての実験が出来ない」というもの。
もし実験して最悪な結果を出したら戻すようにしたい所だけど、その最悪の結果ってすぐ発覚するとは限らないんだよね。
例えば機能をいくつも追加して、初めて気付くとかあったりする。
で、大幅改良をしたいけど出来なかったんだよね。
さすがに手動によるコードコピーも面倒なんで、バージョン管理システムを入れる事にした。
有名所はCVSで、ここ数年でSubversionって管理システムがシェアを占めてきたけど、個人でやってるだけなんでこの二つは規模が少し大きすぎるんだよね。
色々と鯖を建てなきゃいけないみたいだし、もう少し単純な感じの管理システムを探してみた。
管理システムの一つにGitというのがあって、これだとEclipse用のプラグインにEGitというのがあって、これを突っ込むだけでバージョン管理が簡単に出来ちゃうみたいなのだ。
ってな訳でサクっといれた。
使い方は簡単で、今ではガンガンコード修正やっちゃってます。

結果は使用メモリが半分以下になったり、大幅なメニュー改変しちゃったりと大活躍。
後はこの修正が後に響かない事を祈るだけ＞＜

半分はパクリみたいなもんだが。マオです。

順調にプログラムが出来上がってるように見えるんだけど、一番の難関はグラフィック面だったりするんだよね。
Androidには基本的なアイコンとかのリソースはあるんだけど、それだけでは操作全ての表現は出来ないし、そもそもバージョンによって図形が変わったりするのでマニュアルを書く時なんかは少し困る。
ってな訳で、自作しなきゃいけないんだよね。
機能を増やすたびにこんな苦労をしないといけないとは・・・＞＜

で、この手のグラフィックを作るのに便利なのはベクター系のエディタなんだよね。
有名なのはAdobeのIllustratorなんだけど、単品で7万円。
さすがに買う気にならないので、何か良い物は無いかと思って捜してInkscapeというオープンソースのエディタが見つかった。
日本語化もされてて普通に使えちゃった(インストーラー版だとエラーで使えなかったけど)ので、これとGIMPがあれば画像に関しては問題がなさそうだな。

いつになったら、アプリが公開できるようになるんだろうか？(笑)

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

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

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

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

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

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

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

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

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

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

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

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