ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

BREWでシステムを設計仕様としているSEさんへ、IDataFolderに気をつけろ!

2006-01-30 23:06:06 | ケータイ

 長井秀和風に

 ケータイの、BREW3.1アプリで、データフォルダにデータを置こうとしているシステムを設計しているSEさんは、気をつけろ!

 IDataFolderのOpenのモードはCreateとReadで、Createに、存在するファイル名を入れると、勝手に新しいファイル名にして、違うファイルが作成される。
 「あ、やば!!」と思ってDeleteってやると、エラーコード20番(サポートしていない)だ!

 「あれ、これって、ファイル削除とか、上書きとか、どーやるんだ!?」って、気づいたときには、もう、後戻りできないくらい、プロジェクトが進んでいる!間違いない。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

業務アプリと、ケータイでのファイル読み込みタイミングの違い(その場で待たせるか、先読みするか)

2006-01-30 17:39:20 | 開発ネタ

 業務アプリの場合、ファイルを読み込みをするのに(仮に大量データで、読み込み待ちになっても)、わざわざ、読み込み部分をforkして、バックグラウンドで先読みさせておくということは、あんまりしないと思う。

 しかし、ケータイの場合、データフォルダに読むファイルがある場合や、イメージファイル(JPEGなど)の場合は、ファイルをバックグラウンドで読み込ませ、読み終わったら、コールバックするという手法をとることがある(JPEGでない場合にはそうしなくてもいい。BREW2.1の場合、データフォルダファイルのバック、フォアは、実は端末依存(31日追加)V3.1には、問題がある(ここまで))。

 したがって、コールバック関数内で、読み終わったらフラグをあげて、フラグがあがっていたら先に進み、フラグが上がっていなかったら、待ちになる。

 しかし、直前に読んで待ちにするのも、ユーザーレスポンス的に、なんなんで、先読みしておいて、データが必要になる前に、読み込み完了になるようにしておく。

 ただ、じゃあ、先読みはいつからやる?っていわれてもねえ。。

 作ってみて、調整してみないとわかんない。。




 つー意味が、業務アプリだけしかやんない人には、通じなかったりする。

 大量データがあり、そいつを、ソートして云々とか、いろいろ時間がかかっても、業務アプリの場合、先読みして、バックでやっておくということは、あまりしないと思う。
 その場で、やる(処理時間中、ユーザーを待たす)。
 なので、どのタイミングで読むというのは、仕様上、明確に書かれる。


 ケータイの場合、そこで、ゲームなり、作業なりが、とまるとまずいので、バックでよんでおく。

 このとき、読み始めのタイミングは、はっきりしない。とにかく、必要なときまでに読んでればいいし、それが間に合わなかったら、いろんなところで、時間稼ぎしたりする。なので、あんまり、仕様上、読み始めのタイミングが明確にかかれなくても、「ここまでに必要」っていうのがわかれば、よかったりする。

 っていうことが、この前、話し通じなかったので、ここに、かいておいてみたりする。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

PHPのGCを使うため、減色処理することを考えてみる(その1:31日修正)

2006-01-30 12:08:41 | PHP

 PHPで、GCを使って、前に画像をだしたとき、インデックスカラーにしないとうまくいかなかった。

 なので、今日は、減色処理の方法について、しらべてみた。
(はじめは、そのつもりだった・・あとで、減色しなくても、いい気がした)




 まず、減色処理一般のお話は、ここ

で、ImageMagicというフリーソフトで減色処理できる
ImageMagicのサイトはここ
http://www.imagemagick.org/script/index.php


使い方はここ




プログラムの話。
このひとは、距離を求めている。ただ、この人もかいてるけど、グラデのところだと、トーンジャンプしちゃうよねえ。。
 
うーんと、初めにあげたのを見ると。ディザ法?それって、網点だよねえ・・・

あみてん??そっか(@_@)!あみてんにすればいいんじゃん(^^)

・つまり、1ドットを(かりに)4ドットで表現する。

・元のRが0のときは、4ドットRは0、
 元のRが1のときは、3ドットRは0、1ドットRは4
 元のRが2のときは、2ドットRは0、2ドットRは4
 元のRが3のときは、1ドットRは0、3ドットRは4
 元のRが4のときは、4ドットRは4

とすると、
(以下、31日修正)
R一色につき、4ドットとびにすると、256/4=64階調、
これが、3色なので、
64の3乗>>256(>_<!)

逆に、256に収まるようにするとすると、
1色6階調、って、さすがにそれだと、おおきな網点になってしまう。
(あるいは、間引くか?)

 なので、この考えは、無理ですね(>_<!)

 ほかの方法を、気が向いたら、今度書きます

(以上、31日修正)

 とりあえず、思いついたことを、ここにメモした次第であります!
 (つーことで、これは、やってないのだ)


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする