Flex、AIR、Java、Androidなど

日本語はこちら

※Screen Resolution 480*320(T-moblie G1, Dream, Hero, etc)

※Screen Resolution800*480(SmartQ5 etc)
This application shows photo slide show like digital photo frame provided by Flickr. I made it to turn SmartQ5 that will be shipped within Japan with Android OS installed.

新バージョンがあります。色々機能追加してMarketに公開しました。 > こちら

問題ないようなので署名済みapkを公開します。
公開にあたり、
■ MatsuConさま（アプリのアイコン）
■ DIGIらいふのま～さん(簡単署名のEasySignAPK　NOKIA E90時代にはブログ、M-FEP共に大変お世話になりました)
他、有益な情報を公開してくださっている多くの方々にこの場をお借りしてお礼を申し上げます。
また、何かございましたら2chandroid at gmail.comの方までご連絡頂ければと思います。
では、以下のリンクよりダウンロードして下さい。
※アプリケーション、プログラムを利用した事によるいかなる損害への一切の責任を負いません。ご利用は自己責任にてお願いいたします。
MatomeAndroid_signed.apk
新バージョンを公開しました。Marketより「ドロイドあんてな」等で検索してダウンロードして下さい。詳細はこちら。

署名済みですのでPCからでしたらダウンロード後
#adb install MatomeAndroid_signed.apk
または端末ブラウザから上記リンクを叩けばダウンロードが開始され、信頼できないソースからのアプリのインストールを許可していればインストールするかどうか聞かれますので問題なければインストールして下さい。

【以下ちょっとプログラミング的なこと】
基本的にサーバーはPerlのHatena::BookmarkCountとXML::FeedPPで書き、フィードを収集後日付でソートし、新しいものから順に出力しています。ですがたまに処理の途中でエラーを吐きストップしてしまう時があり、この場合は出力先のXMLファイルは更新されません。
その為、どこかのブログに何か問題があった場合、そのフィードが更新されない場合があります。あらかじめご了承下さい。
XMLは大体15k～20ｋ位です。150パケットくらいでしょうか。ai.softbankの方はお気をつけ下さい。
XMLは起動時にニュースのみ取得しようとし、取得できなければアラート、取得できれば配列に格納します。この状態ではニュース系以外のXMLは存在しませんのでXMLの再取得を行っても取得されるのはニュース系のみです。
その後新しいXMLを上部スピナーから選択するとそのXMLがサーバーからダウンロードされ、順次配列にpushされます。この状態でフィードの再取得を行うと配列に入っているsize分ダウンロードが行われます。（httpURLConnectionはIf-Modified-Sinceリクエストに対応しています）
ソートも同様に、配列に入っているもののみに適用されます。配列に入っているものをどのようにソートした状態でも新しいXMLを取得した時には日付順になっています。
Android側は特に難しいことはしていません。
XMLをhttpURLConnection.GETで読み、XMLPullParserで取得し配列に格納、ListViewにsetAdapterしているだけです。
バグ等ありましたらコメント、もしくは上記メールアドレスまでご連絡頂ければと思います。

PC、iPhone、Dev Phone全てで確認できました(笑)。
クリックすると・・・

こうなります。
なかなかないことでしょうから記念に。何があったのでしょうか？

KOGAN Agoraが発売無期延期になってからそのむしゃくしゃを晴らそうとして色々考えましたよ。
源泉徴収でお小遣いが少し増えたのもあり、5800XM見てみたり、Mac mini買おうとしたり、ホームシアターセット見てみたり、N97まで待ってみようかと考えたり。
ですがやはり一番面白そうで、弄ってみたいのはアレなんですよね。
また、搭載される予定のFlashはFlash liteベースではなくFlash player 10ベースだそうな。もう買うしかないでしょ。
まあ遊びながらスキルアップにも繋がるでしょうし、弄り倒したいと思います。
到着は遅くても１週間後位でしょうか。

※この記事は私が本を読み、頭で考えたことを将来完全に理解してから見直して笑ったりするためにそのまま羅列したものです。故に間違った理解や意味不明なこともたくさん出てくると思います。プログラミングを教えるような立場の方には有益かも(笑)？
Builderパターンの理解
まずメインクラスがあり、メインクラスがやりたいことは２つの異なるオブジェクトの生成。その際、オブジェクトの生成はBuilderクラスのサブクラスが行う。
メインクラスがオブジェクトを生成したい時は条件により違う処理が必要。条件によりサブクラスをインスタンス化しDirectorクラスに渡す。あとはメインクラス上ではサブクラスのインスタンスを渡されたDirectorクラスのメソッドでもってインスタンスが生成される。
Directorのコンストラクタの引数にはBuilderクラスが。なのでサブクラスを親クラスに代入するいつものパターン。これにより依存しない関係となる。サブクラスであれば親の抽象メソッドが定義されているのであとはDirectorクラスが共通のメソッドで持って処理を行う。
これだと新たな種類のBuilderのサブクラスを実装する必要がでてきた時も設計を変えるのはメインクラスだけでよい(条件を追加するだけでよい)。Directorクラスがなかった場合はサブクラスが独自の仕様を持つことが可能になり管理が難しくなる。
ものをBuildするのはbuilderクラスだということが重要。
自分なりの結論：

分かりにくかったので料理で例える。
例えばボタンを押せば冷奴と湯豆腐を作れる機械をプログラミングしたいと仮定する。この際の手順は命令役（機械の押されたボタンによって冷奴か湯豆腐のレシピを選択し、豆腐を送る）と、レシピ管理役（冷奴と湯豆腐のレシピを管理している）に分ける。処理の流れは冷奴のボタンが押されたとき命令役はレシピ管理役に豆腐と冷奴が注文されたという情報を渡し、作れと命令する。レシピ管理役は冷奴のレシピを取り出し、その通りに料理し返す。こんな感じ。こうしておくことで豆腐をいいものや安いものに変えたり、マーボー豆腐をメニューに加えたりということも簡単にできる。
だめな例は、命令役とレシピ管理役を置かず、冷奴係と湯豆腐係を置くこと。こうしてしまうと豆腐を変えようと思った時には全員を集めて通知しないといけないし、新しくマーボー係を入れても豆腐をどこから仕入れるかから教えないと(プログラミングしないと)いけなくなる。豆腐がどれかなどとなどにこだわらず、ただ渡された豆腐にレシピ管理役に言われた通り料理せよというのが一番上手な管理方法となる。