ケータイとアプリと私

デベロッパ Tech Cradle - BREW / 携帯 Java 技術情報 -

リンク: デベロッパ Tech Cradle - BREW / 携帯 Java 技術情報 -.

 ソフィアクレイドルのBREWでのC++コーディングに関する技術ノウハウなど。

 ちぇっく。

 つーかですね。ここまでしてC++使わなくてもいいんじゃね?とか思うわけですが。過激なこと言うと、お前らコンパイラにお世話してもらわないとカプセル化ひとつできねーのかよ、と。

| | コメント (0) | トラックバック (0)

BREWの記事が書けない訳

 「ゲーム屋のためのBREW開発のキモ」という記事が頓挫している。

 もうモノの見事な尻切れトンボ。竜頭蛇尾。三日坊主ぶり。であるw

 実はあの記事を書いた少し後に「KDDIの正規開発者用ドキュメント」を手に入れられる資格を得たのだが、その公開用のものとは段違いの情報量にビックリw

 をいをい。こんなに違うのかよ、と。

 当然、開発者としてはそっち(正規版)に知識をリプレースするわけだが・・・。

 公開版の知識と正規版の知識がごっちゃになって、記事が書けませーんwww

 正規版は、当然NDAを結んで手に入れているわけであるから、ブログに書くわけにはいかない。書けるのは公開用の資料に基づいた記事のみ。しかもその記事は古かったり、間違っていたりで、どうしたもんだか・・・って感じ。

 BREWも3.xに上がって、ますます公開用資料は役に立たなくなっていってるしw 正直、開発者は公開用の資料を元にプログラミングしないほうがいいと思う。例えば、BREWで作った画像を待ち受け画面に転送できるかどうか公開用資料では判らない、とか。どういったものが作れるのかでさえ図るのが難しい。KDDIはどうやらこれ以上BREW開発者を増やしたくないらしいw

 そんなわけで、どう記事を書くべきか思案中である。BREWの仕事も一段落したので、経験を踏まえて書けることをぼちぼち整理しているので、もうちょっと待ってください。もう待ってる人いないだろうけどwww

| | コメント (2) | トラックバック (0)

なにげにhirax.netにリンクされててうわああああっ

 コレ

 がむばります。

| | コメント (0) | トラックバック (0)

ポインタテーブル使えませんかそうですか

 BREWに新たな発見。ポインタテーブル作れません!
 実行してからプログレッシブに作ることは可能なんだが、静的にテーブルを用意しておくのはダメだとさ。

const int foo = 1;
const int bar = 2;
const int * const tbl[] = { &foo, &bar };
↑ダメな例

 アンナァ・・・。ポインタテーブルなんてそこら中で必要だっつ-の。関数テーブルとかどうすんのよ。switch/caseでやれってか? それともC++で継承でござんすかい?
 一次が可変長な二次元テーブルとかもポインタテーブルでやるんですがね・・・。

 いろいろ調べてみて、原因はどうやら完全リロケータブルなコードにしておかなければいけないかららしい。つまり、実行時スタートアドレスが不明のため、リンカでアドレス解決できないものは全て×だと。だから、上記の例がstaticになっていると、PC相対でアドレスを決定できるので、OKになることがある(場所が遠くなったらダメ)。externalなシンボルは全部ダメ。

 やっかいなことに、エミュレータ上だとOKなんだよな。VC++でIntelコードだから。ARMコンパイラだとダメになる。だから、エミュレータ上でガンガンポインタテーブルを用意して、いざARMでビルドすると、鬼のようなエラーが!!! ぎゃああああぁぁぁ・・・・(憤死) 
 それにしても、エミュレータ上と実機上でマシンコードが異なる環境ってのはどうなのよ?

 他にもARMの自動make生成がANSI C strictなもんだから、warning吐く々々w ビットフィールドはintでないとダメだとか、()は(void)にしろだとか、warning撲滅運動員のワタクシと致しましては、売られたケンカ(warning)は買わなきゃ収まらねぇ。ま、makeを手で書き換えりゃいいんだけどね。メンドクセーANSI C の勉強にもなる からそのまんま。

 グローバル変数の問題は、GETAPPINSTATNCE()を引っ張ってくることで解決しそうなんだが、その関数(マクロ?)も機種依存で無効になることがあるらしく、おーまいごっです。

 とりあえず、御約束のassert()とかデバッグ用printf()とか(ほんのちょっぴり)安全なmalloc()/free()とか便利マクロを作る日々。なんかプラットフォームが新しくなるたびに作っているような気がするアルよw

| | コメント (0) | トラックバック (0)

Path最大長の罠

 をいをい。まだそんなものがあるのかよ・・・。

 というわけで、「CodeWarriorとJavaSDKと、Nokia開発スイートと、ARM開発スイートを入れたら、ユーザーPATHが取り込めなくなって、VisualStudioがコマンドで呼べなくなる罠」に嵌りかけますたw
 全てはARM様がクソ深いフォルダ構成で、クソ長いpathを登録したおかげでございます。これだから、毛党は頭がうわなにおするくぁwせdrftgyふじこl


 とはいえ、全て再インストールがめんどくせえ必要なものなので、フォルダ名をMSDOS形式にしてみたり、必要ないものは削除してみたり、といろいろやっていたところ、_default.PIFなるものがあることを発見。おや懐かしい「環境変数初期サイズ」なるものを「自動」から「最大値」にしてみたら、あっさり全部入りましたとさ。ふ~~(-∀-メ)

 そしていつものセリフを吐く。  「ゲイツ氏ね」

| | コメント (0) | トラックバック (0)

BREWウガー!!

 というわけで、BREWもやることになったので、カテゴリも新たにスタートなワタクシ。

 つかね。BREW凄いよ。マジで。

 ダメ過ぎて。

 一言で言うと、制約が多いC。
 APIは無理矢理オブジェクト指向風。標準関数壊滅。.bss破棄→グローバル変数/static変数使用不可。メインループ構築不可。スレッドなし。メモリプロテクションなし。エミュレータはIntelバイナリ、実機はARM7バイナリ。

 ウガー!!

 メモリリーク、リソースリークは素のCなのに、C++でラップしようとすると、staticメンバ×。vtbl×。標準ライブラリ×。例外×。STLもちろん×。

 ウガー!!!!

 ようするに「かなり慎重に作らないと、落とし穴多すぎやんけ!」という感じ。う~むむ・・・・。

 2chの関連スレッドでは阿鼻叫喚がw 曰く「BREWアプリはJavaアプリに比べて3倍大変」だとさ。まあ、自分が大変なのはいいんですがね。ごにょごにょ・・・。


 ようするに、C初心者/未経験者にBREWアプリを任せるのはアレでしょうか? ということだ。どーすか?どーなんだ?

| | コメント (0) | トラックバック (0)

中国携帯開発中・・・

 まあノキアたんでやってるんですがね。

 ほとんどMIDPのみで作れという感じ。ケータイのアプリの中では最もプアじゃなかろうか。
 最先端のMIDP2.0搭載機種なら、OpenGL ESまで動くし、JAR領域はメガオーダーだしで、凄いのが作れそうだけど、バリュー帯のシリーズ40だと、MIDP1.0。追加UIも大したこと無い。音楽BEEP単音だしな・・・。

 つーか、N-GAGEも似たようなものなんですけど、
 お前は、これでGBAとかに勝てると本気で思ってたのかと。
 一言で言って、ワンダースワン以下ですた。

 ところで、アテクシはiアプリから入ったわけですが、Dojaの所為で一部勉強しなおしですよ。独自仕様氏ね、という感じ。iアプリは日本語の資料が多いのはいいのだが、ワールドワイドで考えると、au、vodaの方がつぶしが効くのねん。

 むー、それにしても、もうそろそろ英文ドキュメントに慣れんとあかんなー。中国語も覚えなあかんのに・・・ウチュ

| | コメント (0) | トラックバック (0)

Java5.0最強説

オラ、久しぶりにワクワクしたぞ!

というわけでJava5.0ですが。
最強です。
新設された機能はこちらを参照。

 これで、俺的にC/C++から欲しかった機能はプリプロセッサだけになりました。
 元々Javaの構文はC/C++ほど破綻していない(というかC++が破綻しすぎw)ので、新機能でさらにすっきりと書けるようになり、機能面も満足で、かなり理想的な言語になった気がします。
 そろそろアセンブラ/C派だった俺も宗旨変えですかなw マジ、初心者にお勧めの言語になったと思います。

| | コメント (0) | トラックバック (0)

Doja-3.0と3.5(FOMA)との差異

  • HttpConnection#getRequestMethod:"HEAD"メソッドは無くなった。
  • Graphics#drawImage:アフィン変換が可能になった。
  • IApplication#SUSPEND_MULTITASK_APPLICATION:新設。
  • IApplication#LAUNCH_MAIL_RECEIVED:新設。他にもLAUNCH_MAIL_関連も新設多数。
  • IApplication#LAUNCH_MAILMENU:DOPAとFOMAでは動作が異なる。
  • IApplication#launch:動作追加。
  • ImageMapクラス:新設
  • MediaManager#getStreamingImage:新設。
  • Palleteクラス:新設。
  • PalletImageクラス:新設。
  • PhoneSystemクラス#THEME_AV_CALL_IN:新設。
  • PhoneSystem#getSoundTheme:TV電話着信音も更新可能。
  • Spriteクラス:新設。
  • SpriteSetクラス:新設。
  • VisualPresenter#PLAYER_MODE:新設。他にも新設多数。
  • Base64クラス:新設。
  • Phone#call:新設。

| | コメント (0) | トラックバック (0)

iアプリで通信、はじめの一歩(The Fighting!(嘘))

  • iアプリで使えるプロトコルはhttpだけ
  • リクエストラインのメソッドはGET/POST/HEADだけ
  • リクエストヘッダフィールドで使えるのは"Content-Type"と"If-Modified-Since"だけ
  • データの送受信は、HttpConnectonインターフェースで行う。以下は手順
    1. Connector#open()でコネクションを開く(HttpConnection#connect()までは実動しない)。その際のmodeは、POSTの場合、READ_WRITE。それ以外はREADを使う。
    2. setRequestMethod()でメソッドを設定
    3. setRequestProperty()でリクエストヘッダを設定(ex.受け取るデータのタイプをココで設定)。
    4. POSTの場合、OutPutStreamを開き、メッセージボディのデータを出力する。出力完了でclose()。
    5. HttpConnection#connect()で接続。すると、リクエストメッセージ(POSTではデータ込み)がサーバーに送られる。
    6. 必要に応じて、getHeaderField()でレスポンスヘッダフィールドを取得できる
    7. InputStreamを開く、read()でレスポンスメッセージのボディが取得できる。

CGIについてのはじめの知識

CGI プログラムは、実行されると標準出力に出力します。その出力がそのままブラウザに渡されます。 ただし、気を付けるのはまずヘッダを出力し、その後空行が必要なことです。(中略)
引数の取得は、GET の場合は環境変数 QUERY_STRING に代入されています。 POST の場合は標準入力から渡されます。 GET か POST かは 環境変数 REQUEST_METHOD でわかります。また、POST の場合は環境変数CONTENT_LENGTH にデータ長さが入っていますが、 EOF まで STDIN から読み込んでも構わないでしょう。
GET でも POST でも、データは URL エンコードされています。正規表現 [-a-zA-Z0-9_\*] 以外の文字は全て %xx という形 (xx は16進数表記) になって送られてきます。CGI プログラムでは、これを元の形に戻さないといけません。

| | コメント (0) | トラックバック (0)