title to php.net

menu 総合掲示板 日記 リンク iαppli 開発&Tips C/C++全般 Java全般 Windowsアプリ 組込 i-αppli Webアプリ PHP 組込入門 ロジック
1400387

--機種別--
≪イメージ作成の失敗≫
≪ストリームのオープン≫

--Doja--
≪ファイル名とpublicクラス≫
≪HTTP通信時のContent-Type≫
≪DoJaのCalendarクラス≫
≪iアプリのHTTP通信≫

--ふりちゃライブラリ--
≪ローカルファイルシステム≫
≪リモートファイルシステム≫


開発日誌っす

i-αppli

機種別
≪イメージ作成の失敗≫
SHとかSOとかでは問題ないんだけど、Nとかだと画面サイズより大きいイメージを作成しようとすると、失敗する。

≪ストリームのオープン≫
SHとかSOとかだと、ストリームのリードとかでコケてクローズできなくても、他のストリームはオープンできる。Nとかでは再オープンはできない。

Doja
≪ファイル名とpublicクラス≫
「各ファイル中で宣言できるpublicクラスは一つだけ」で、「その名称はファイル名と同一でなければならない」というのがjavaのオキテらしいですが、コレ大文字と小文字も識別するみたいです。例えば、ファイル名がfoo.javaでpublicクラスがFooだと、コンパイルエラーになっちゃった。

≪HTTP通信時のContent-Type≫
HTTP通信時のContent-Typeはtext/plainじゃなく、application/x-www-form-urlencodedじゃなきゃだめらしい。

≪DoJaのCalendarクラス≫
deactivate()寸前でset(MONTH...)やると、java.lang.IllegalArgumentExceptionが発生。なぜ?しょうがないからCalendarクラス再生成。

≪iアプリのHTTP通信≫
iアプリのHTTP通信がうまくいかんのですよ。POSTでパラメータが渡らない。なぜ? で色々調べたら、ココに回答が。具体的には、setRequestProperty("Content-Type" "text/plaim")がまずかった。setRequestProperty("Content-Type" "application/x-www-form-urlencoded")じゃなきゃならん。DoCoMoのドキュメント間違ってるじゃん。まったく。

ふりちゃライブラリ
≪ローカルファイルシステム≫
スクラッチパッドは全体が一個のファイルという扱いなので、内部的にファイルシステムを形成した方が使いやすい。
オーソドックスではあるが有効な手としては、FATファイルシステムを形成する事。
とは言ってもサイズ的な制約もあるし、ほとんどのアプリの性格上、実行中にサイズが伸張していくファイルも無いので、ディレクトリエントリ型ファイルシステムかな。(FATファイルシステムの説明は、「組込入門」に譲ります)

クリックすると、拡大します 図ス-1

いきなり図が出ちゃいましたが、図ス-1が全貌ですな。言葉は無力です。

先頭部分には「ファイル情報」をおきます。

クリックすると、拡大します 図ス-2

「シグネチャは」このファイルシステムを識別するものになります。この場合は「FSFO」の文字列が書かれています。
これが書かれて居なければ、知らないファイルシステムだという事になるので初期化が必要になる訳です。
バージョン番号とかもあったりするとマイグレーションができたりします。
次に「ディレクトリエントリ数」を置いています。
後ろに続くディレクトリエントリの数を指定して、その後に続くデータの開始位置を計算するためです。
データ開始オフセットを置いてもいいです。

次にディレクトリエントリの構造を決定しなければなりません。

クリックすると、拡大します 図ス-3

ファイル名は伝統的に8.3形式にしてあります(12文字)。ユニコード表現なので、24バイトになります。
続いてオフセット4バイト、ファイルサイズ4バイトとなります。
ディレクトリ位置計算を簡単にするため、16バイトの整数倍がお勧め。今回は32バイトとなっている。

オフセットはこのファイルのデータが「図ス-1」で言うところの「データ開始位置」から何バイト後から始まっているかを示す。(最初のファイルは0となる)
動作中にファイルの長さが変わるファイルシステムを前提としていないのでクラスタ単位では無く、バイト単位で詰められて格納される。
サイズはこのファイル自体のバイトサイズを示す。

クラスタ方式で無い場合、ストレージのスペース効率は改善されるが、ファイルサイズを変更したり、ファイルを削除する場合にはパフォーマンスが落ちる。
今回はファイルのサイズ変更は想定していないが、削除された跡地を整地する必要はあるため、「ガーベッジコレクション」の機能が必要となる。

実装サンプルとして参考程度に紹介するが、このまま組み込んで問題が起きても責任はとらない。
クラスは、
  • DirEntry
  • ScratchFile
で構成される。
DirEntryはディレクトリ構造を補完するクラスなので、非常に簡単な構造になっている。
ScratchFileクラスが実態なので、その関数は、
  • ScratchFile()
  • Initialize()
  • GetLastError()
  • CheckSize()
  • GetTotalSize()
  • GetFreeSize()
  • Format()
  • Mount()
  • IsMounted()
  • GetDirs()
  • GetDirName(int idx)
  • GetOpenName(String filename)
  • MakeFile(String filename int size)
  • DeleteFile(String filename)
  • GetFileSize(String filename)
使い方としては、Initialize()を呼んだ後、Mount()を呼んでtrueが返れば、使用可能。
falseが返れば、Format()を呼ぶ必要がある。
ファイルの読み書きはココではできないので、GetOpenName()に8.3形式のファイル名を渡せば、Connector.openOutputStream()等で使用する、「scratchpad:///0;pos=」を返す様に実装してある。
DeleteFile()はファイル削除後、ガーベッジコレクションも行う。(この時のアプリ強制終了は未対応)

あ、今気が付いたけど、GetTotalSize()とGeFreeSize()は、事前にCheckSize()呼んどかないと機能しない。
CheckSize()は、スクラッチパッドのサイズを自動で調べる関数。(苦労して作った割りには、意味無いかも)

筆者の環境では、リモートファイルシステムと連動するので、ローカルに無ければ、リモートに取りに行ってローカルに保存し、次からはローカルになるようになっている。

≪リモートファイルシステム≫