うーん、世の営業はいい加減だ。
一般に、ＢＲＥＷ(auのEZアプリ）のソースコードは、Ｃで書きます（もしくはＣ＋＋，Ｃが多い）。
で、 あるＣのプログラムがあります。このとき、
「ソースがあれば、大丈夫、コンパイルすれば動きますよ！」
と、豪語した営業がいるそうな。。。
おいおい、そしたら、ＢＲＥＷ対応パッケージソフトなんて、つくんの簡単ジャン！
KDE for BREWとか、GNOME FOR BREWとかできんのかい！！
営業って、いいかげんだよね!!
あるＣプログラムをＢＲＥＷに移植するのに、すくなくとも、いますぐ思いつくこととして、こんな作業がある（もっとあると思うけど）
■■ そのプログラムがＧＵＩを含んでいる
作り直したほうが早いと思う
■■ そのプログラムが、ファイルインターフェースを含んでいる
fopenなどのファイル関数部分を、ラッパーにして、中身をＢＲＥＷの関数で書く。
つまり、fopenなどのファイルの関数は、BREWではIFILE関数になるので、その部分を
FILE *fopen(char *fname,char *attr)
{
//ここに、プログラムを書いてね！
//えらーのときは
return NULL;
}
みたいなかんじで、プログラムを、オープンから、読み書き、クローズ、色々かくことになる。もちろん
typedef struct _FILE
{
IFileMgr *pIFileMgr;
IFile *pIFile;
} FILE;
っていうかんじで、FILE構造体の中に、IFILEMGRと、IFILEのポインタを持っておき、それを使って操作する。ただし、この場合、アプリのフォルダにあるファイルになる。共通のデータフォルダアクセスは、また違う関数を使ってラップすることになるので注意（とくに、ここがBREW2.1とBREW3.1で仕様が変わっているので注意）
■■ そのプログラムが、SOCKET、ＨＴＴＰ通信有
ラッパー関数を作って、その中身をHTTPは、IWeb関数、SOCKETは、ISocketで記述するということは、ファイルと同じだが、そもそも、その通信ができるかどうか確認すること。
つまり、ＢＲＥＷのサービス概要1.0版では、
一定時間内に無操作状態が続いた場合はユーザへネットワーク接続を継続するか否かの「継
続確認用ポップアップ」画面を表示し、ユーザの許可が得られない場合にはその後の接続保持の為の
パケット送出等ユーザ操作を契機とした通信の再開以外を一切禁止します。なお、このパケット送出
を停止するまでの無操作タイマー時間を「5 分間」と規定します。
という規定がある（８２ページ）。
逆に言うと、５分以上、つなぎっぱなしにしているアプリはない。
なので、ずーっとつなぎっぱなしにしていて大丈夫かどうかのテストが必要（これ以外の情報をしゃべるとまずいかもしんないので、言わないが、とにかく、確認してみよう！問題点が出てくる場合がある）
■■ それ以外の入出力がある
そもそも、できるかどうかを考えよう。
このとき、ＳＤＫがあるかないかを確認すること。
たとえば、USBの端子があるということと、USBを操作できる（ＳＤＫに、その関数がある＋その機種がその関数に対応している）ということは、まったく別問題である。
■■ それ以外の、ふつうのソース部分
以下の注意が必要（思いついたもの）
●メモリー関係：memcpy(a,b,100);といった関数が、MEMCPY(a,b,100);になるように、大文字の関数になっているので、ラップするか、ヘッダーファイルで置き換えるように定義する。
●staticでとっているところ：BREWは、基本的にStatic禁止なので、staticにしなくてもすむように書き換える。
●計算：浮動小数点になると、関数を使わなければいけないという仕様がある（あった？）。
そのため、そこの計算をおきかえるわけだが、215.6+312.3のように、計算は、関数と違い単純にラップをかけられない（operatorでかけられないよねえ。。たぶん？？かけられるのかな？？）
なんで、そこの部分、書き換えになる。最新版（ＢＲＥＷ３．１）でも、浮動小数点をやるときには、関数使わないといけないかどうかについては、未確認。
■■ 作業の進め方。
とりあえず、ARMコンパイラで、小さな部分に分けて、コンパイルして、エラーになったら、上記の対策を行うことになる。
てなわけで、単にコードをリコンパイルすればいいだけじゃなくって、結構細かい作業がはいる。
そういうことを頭に入れないで、営業が適当なことを言うと。。こまったちゃんになる。
まあ、ＢＲＥＷに限ったことじゃ、ないけどね。。
アクセス
トータル
ランキング
