携帯アプリ開発
取り敢ずやるか！！
・
・
・
ＡＵ Java離脱！！すでに実行環境搭載しない機種続々と・・・・orz
・
・
・
仕方ないやるか！！
まずDoCoMoから
関連サイト：http://www.nttdocomo.co.jp/p_s/imode/make/java/index.html
：http://java.sun.com/j2se/1.4.2/ja/
：http://www.eclipse.org/downloads/index.php
作成してから３年は持たすアプリ作りが目標なので「DoJa-4.0」をターゲットに開発していきます。
「iαppli Development Kit for DoJa-4.0 Ver.2.05 」と言う開発ツールがあるので
ダウンロードして、インストールします。
失敗、Ｊ２ＭＥがいるのかな？ Ｊ２ＳＥがいるみたい、ＭＥは付属してるっぽい。
Java(TM) 2 SDK, Standard Edition 1.4.2_10をダウンロードし、インストール。
学生時代java1.0.xでアップレットを作って遊んでたんですが、新しいバージョンがでるたびに
使えないメソッドが出てきて、あきらめて以来なので、ちょっと恐ろしいｗ
再度i iαppli-SDKをインストール・・・を今はやりのEclipseのプラグインがある・・・。
まず、Eclipseを入れてみようｗ
最新は3.1.2ですが、iαppli-SDKのプラグインが3.0と書いてあるので、3.0.2をダウンロードします。
同じページに「3.0.1_Translations」と言うリンクがあり、何やら日本語になりそうなので、ダウンロード。
圧縮ファイルを展開すると「eclipse」フォルダが出てきます。
どうやらインストール形式では内容なので、c:\program files\eclipse3.0として設置します。
3.0.1_Translationsも解凍すると「features」と「plugins」フォルダができるのでそれをeclipse3.0に
コピー、で実行・・・・orz 起動しない、リンクは3.0.1となってるけど、本体は3.0.xってなってるから
行けると思ったのに、こうなったら3.1.1でチャレンジ！！
あれっ、今度はエラーにならないけど、日本語にならない？
まぁこれはいっか。
そしてようやくiαppli-SDKをインストール 。
なんかDojaでコンパイルしようとするとエラーがでます。
結局「iαppli-SDK」で行くことにします。
よって、開発ツールは秀丸でｗ
【環境設定】
70XシリーズがDoJa4.0LE プロファイル なんて物を搭載していて
スクラッチパッドの容量が200K・・・900シリーズが400Kだったのに半減＞＜
仕方ないので、ギリギリまで200Kで行ってみよう。
単純に1024*200=204,800なので、安全のため200,000Kをスクラッチパッドとして確保
プロジェクトを作成します。
作成するとインストールディレクトリの中のappsの中にフォルダ「C:\iDKDoJa4.0\apps\step1」ができます。
この中の
「bin」・・・・実行ファイルやダウンロードサンプルHTML等が入ります。
「res」・・・・リソースファイル（画像や音）をここに入れます。
「sp」 ・・・・スクラッチパッドに入れたデータが格納されます（バイナリ）
「src」・・・・ソースが入ります。
「temp」・・・・たぶんエミュレーター作業用
ADF設定で「SPsize」を200000に設定
「UseNetwork」に「http」とhttp通信をする事を宣言
ネットワーク設定で、ADFのURLを取得するデータと同じサーバに。
↑をしておかないと、JAVAはセキュリティ仕様が高いので別サーバのデータを操作できません。
【step1 リソース取得テスト】
まずは、
「ウェブサーバを経由しての文字・画像を取得」
「スクラッチパッドへの保存」
「リソースからの画像表示」
の実験を行います。
ちょっとめんどくさいので、コメントつけているのでソースを見てくださいw→ step1.java
んで「ビルド」をすると「Download.html」「step1.jam」「step1.jar」ができているので
これをサーバにアップしてください。
必ず、データを取得するサーバと同じサーバに設置してください。
「http://machtype.com/~flesh_gogo/mobile-appli/step1/Download.html」
↑を携帯でアクセスしようとしたけど、めんどくさかったのでＱＲコードを作りました。
これができれば、何とか「実現」ができそうです。 よかった＾＾；
Update 2005/11/24
上へ トップページへ
【step2 機種ごとの誤差〜フォント〜】
step1でエミュレータと実機での誤差を修正しているのですが
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
//エミュレーターより実機は上に2pixcelほど不可視領域がある。
//でもなぜか画像は調整の必要がない。
intAdjustHeight = 2;
graMain.drawString("リソースイメージ", 0, 10 + intAdjustHeight);
ここで言う実機とはN900iなのですが、会社の携帯N901iSではまた違いました。
iアプリの仕様書を見てみると
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
ｉアプリのダウンロードを各機種毎に適切にコントロールするために、
ｉアプリ対応携帯電話では 次のような機構が利用可能になっています。
1. 携帯電話からのHTTP リクエストには、携帯電話の機種を判別するための
User-Agent リクエストヘッダ が含まれています。
Web サーバー側ではｉアプリのダウンロード用HTML を表示する際に、
User-Agentの内容に基づいてユーザーに適切なｉアプリを提示するよう
ナビゲートすることができます。
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
つまり、初回起動時にWEBサーバから機種調整値のようなものを取得しないと
だめなようです。
初回起動ー＞WEBサーバにアクセスー＞機種判定・調整値を取得ー＞スクラッチパッドに調整値を書き込み
つまり、スクラッチパッドの格納設計をしないとだめのようです。
画面のサイズが240x240なので、1調整値につき2byteでOK
| 番地 | 項目名 | デフォルト | 説明 |
| 0x0001 | Initialize | 0x00 | 初期設定が終わっていれば01を立てる |
| 0x0002 | FontAdjustTop | 0x00 | フォントを画面の上からピクセル調整値 |
| 0x0003 | FontAdjustLeft | 0x00 | フォントを画面の左からピクセル調整値 |
| 0x0004 | FontAdjustHeight | 0x00 | フォントの高さ調整値 |
| 0x0005 | FontAdjustWidth | 0x00 | フォンとの幅調整値 |
とりあえず、実験としてこれで行き後々出てきたスクラッチパッド項目は最後につなぎ合わせて一つにする事に。
作成するもの、
・調整値をダミーで出力するCGI
・スクラッチバッドの出し入れ関数
【User-Agent調査】
自分のブラウザ：Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919
Firefox/1.0.7
N901iS ：DoCoMo/2.0 N901iS(c100;TB;W24H12)
N900i ：DoCoMo/2.0 N900i(c100;TC;W24;H12)
【fontadjustpoint.cgi】機種ごとにフォント調整値を返すCGIを↓のような感じで作る。
if($ENV{'HTTP_USER_AGENT'} =~ /N901i/)
{
print "02000000";
}
else
{#デフォルト
print "00000000";
}
これをWEBサーバから取得して、スクラッチパッドに書き込みむ処理を書いたのですが
エミュレーターと実機の動作の違いで数日迷宮入りしました。
それは、「HttpConnection」と「InputStream」の連動性の違いでした。
エミュレーターでは「httpConn.openInputStream()」で「InputStream」を取得した後
「HttpConnection」を閉じても「InputStream」にデータが残っていたのですが、実機では
「HttpConnection」を閉じると同時に「InputStream」も閉じられているようで「read」をかけた時点で
「IOException」がスローされます。
step2.java ←エミュレーターではＯＫ
step2_2.java ←実機でもＯＫ
あ〜参ったね＾＾；
「http://machtype.com/~flesh_gogo/mobile-appli/step2_2/Download.html」
Update 2005/11/26
上へ トップページへ
【step3 画面展開】
現在の画面から次の画面に移り変わるときのモーションを作ってみます。
image1.gifとimage2.gifを用意し、image1.gifとimage2.gifを左スクロールで入れ替えてみます。
 |
 |
image1.gif |
image2.gif |
ただ単に、image1.gifの座標を左にずらしていくだけだと、機種の処理速度によって
速さが変わってしまいますので、タイマー処理をします。
CanvasクラスにRunnableインターフェースをimplementsします。
これにより、スレッドを発行し「public void run()」を呼び出し
run()内で左スクロールを記述します。
このrun()内で無限ループをさせ、スレッドのスリープメソッド「Thread.sleep(10);」で
待ちをかけることにより、定期的に実行されるタイマー処理を実現するようです。
step3.java ←試行錯誤中なので色々無駄なコードがありますが、そこは大目に見てください。
「http://machtype.com/~flesh_gogo/mobile-appli/step3/Download.html」
Update 2005/11/27
上へ トップページへ
【step4 キーイベント】
アプリケーションを開発する上で、ユーザの操作に対する反応は欠かせません。
そこで、今回はキーイベント処理を行います。
Doja APIのDisplayクラスでイベントが定義されています。
【2005/5/31現在 Doja-4.0 APIリファレンス編 抜粋】
| フィールドの概要 | |
| static int | FINGER_MOVED_EVENT [iアプリオプションAPI] 指紋センサのイベントを表すイベントタイプです(=0x41)。 |
| static int | KEY_0 数字キー0を表します(=0x00)。 |
| static int | KEY_1 数字キー1を表します(=0x01)。 |
| static int | KEY_2 数字キー2を表します(=0x02)。 |
| static int | KEY_3 数字キー3を表します(=0x03)。 |
| static int | KEY_4 数字キー4を表します(=0x04)。 |
| static int | KEY_5 数字キー5を表します(=0x05)。 |
| static int | KEY_6 数字キー6を表します(=0x06)。 |
| static int | KEY_7 数字キー7を表します(=0x07)。 |
| static int | KEY_8 数字キー8を表します(=0x08)。 |
| static int | KEY_9 数字キー9を表します(=0x09)。 |
| static int | KEY_ASTERISK アスタリスクキーを表します(=0x0a)。 |
| static int | KEY_CAMERA_SELECT [iアプリオプションAPI] カメラに関連して選択/決定の操作を行うキーを表します(=0x3b)。 |
| static int | KEY_CAMERA_ZOOM_IN [iアプリオプションAPI] カメラのズームイン操作を行うキーを表します(=0x39)。 |
| static int | KEY_CAMERA_ZOOM_OUT [iアプリオプションAPI] カメラのズームアウト操作を行うキーを表します(=0x3a)。 |
| static int | KEY_CLEAR [iアプリオプションAPI] クリアキーを表します(=0x20)。 |
| static int | KEY_DOWN 下方向キーを表します(=0x13)。 |
| static int | KEY_IAPP 待ち受けiアプリの切り替えキーを表します(=0x18)。 |
| static int | KEY_LEFT 左方向キーを表します(=0x10)。 |
| static int | KEY_LOWER_LEFT [iアプリオプションAPI] 左下キーを表します(=0x1d)。 |
| static int | KEY_LOWER_RIGHT [iアプリオプションAPI] 右下キーを表します(=0x1c)。 |
| static int | KEY_MAIL [iアプリオプションAPI] メールキーを表します(=0x21)。 |
| static int | KEY_MEMO [iアプリオプションAPI] メモキーを表します(=0x22)。 |
| static int | KEY_MY_SELECT [iアプリオプションAPI] My セレクトキーを表します(=0x35)。 |
| static int | KEY_PAGE_DOWN [iアプリオプションAPI] ページダウンキーを表します(=0x1f)。 |
| static int | KEY_PAGE_UP [iアプリオプションAPI] ページアップキーを表します(=0x1e)。 |
| static int | KEY_POUND パウンドキーを表します(=0x0b)。 |
| static int | KEY_PRESSED_EVENT キーダウンイベントを表すイベントタイプです(=0)。 |
| static int | KEY_RELEASED_EVENT キーアップイベントを表すイベントタイプです(=1)。 |
| static int | KEY_RIGHT 右方向キーを表します(=0x12)。 |
| static int | KEY_ROLL_LEFT [iアプリオプションAPI] 左ロールキーを表します(=0x30)。 |
| static int | KEY_ROLL_RIGHT [iアプリオプションAPI] 右ロールキーを表します(=0x31)。 |
| static int | KEY_SELECT 選択/決定キーを表します(=0x14)。 |
| static int | KEY_SOFT1 ソフトキー1を表します(=0x15)。 |
| static int | KEY_SOFT2 ソフトキー2を表します(=0x16)。 |
| static int | KEY_SUB1 [iアプリオプションAPI] 背面キー1を表します(=0x32)。 |
| static int | KEY_SUB2 [iアプリオプションAPI] 背面キー2を表します(=0x33)。 |
| static int | KEY_SUB3 [iアプリオプションAPI] 背面キー3を表します(=0x34)。 |
| static int | KEY_UP 上方向キーを表します(=0x11)。 |
| static int | KEY_UPPER_LEFT [iアプリオプションAPI] 左上キーを表します(=0x1a)。 |
| static int | KEY_UPPER_RIGHT [iアプリオプションAPI] 右上キーを表します(=0x1b)。 |
| static int | KEY_VOICE [iアプリオプションAPI] ボイスキーを表します(=0x27)。 |
| protected static int | MAX_OPTION_KEY オプションキーコードの最大値です(=0x3f)。 |
| protected static int | MAX_VENDOR_EVENT ベンダイベントの最大値です(=127)。 |
| protected static int | MAX_VENDOR_KEY 推奨されていません。 |
| static int | MEDIA_EVENT メディアイベントを表すイベントタイプです(=8)。 |
| protected static int | MIN_OPTION_KEY オプションキーコードの最小値です(=0x1a)。 |
| protected static int | MIN_VENDOR_EVENT ベンダイベントの最小値です(=64)。 |
| protected static int | MIN_VENDOR_KEY 推奨されていません。 |
| static int | POINTER_MOVED_EVENT [iアプリオプションAPI] ポインティングデバイスの操作開始イベントを表すイベントタイプです(=64)。 |
| static int | RESET_VM_EVENT リセットイベントを表すイベントタイプです(=5)。 |
| static int | RESUME_VM_EVENT レジュームイベントを表すイベントタイプです(=4)。 |
| static int | TIMER_EXPIRED_EVENT タイマーイベントを表すイベントタイプです(=7)。 |
| static int | UPDATE_VM_EVENT アップデートイベントを表すイベントタイプです(=6)。 |
これによるとタイマーイベントなるものもあるので、ここで書いたタイマー処理よりもっといい方法があるかもしれません。
しかし、なぜかサンプルではほとんどスレッドを使っているので、そのまま行きます。
イベントを取得するには、Canvasクラス内でプロセスイベントをオーバーライトすることにより
Displayクラスのイベントが取得できるようです。
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
public void processEvent(int intType,int intParam)
{//プロセスイベントを取得
if(intType == Display.KEY_RELEASED_EVENT)
{//キーアップイベントの時
if(intParam == Display.KEY_UP)
{
System.out.println("上押した");
}
}
}
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
↑こんな感じでOK。
今回は、結構簡単でしたね。
step4.java
「http://machtype.com/~flesh_gogo/mobile-appli/step4/Download.html」
Update 2005/11/28
上へ トップページへ
【step5 リソースの節約】
一番はじめに書いたように、ギリギリまで「DoJa4.0LE プロファイル」対応に使用と思っているのですが
スクラッチパッドの400->200ダウンより、もっとひどいことがありました。
なんと本体のJarが100->30にダウンしているのです。つまりまるっきり505i-506iの容量なのです。
しかし、70Xiは901i以降に発売していると言う状況なので、ユーザにと手みれば「何でみれないの！！」の
クレームがくるのが必至！！
なので、できるだけリソースは節約していくことにします。
 |
| image1.gif 1,600バイト |
これをただ単に表示するものをビルドすると step5.jar 2,900バイト
しかしこれを以下のように面倒くさいグラデーションの一部分だけをリソースにし
プログラムで横に並べ、下の部分は四角で塗りつぶしてみます。
 |
image1.gif 266バイト |
おっ、この時点でリソースが16%にダウン。い〜いよかん♪
っが！！、ビルドしてみると step5_1.jar 1,645バイト、56%減にしかなってない。
約半減したにはしたのだが、ちょっとショック。
おそらく、画像に対するコードの比率が高いからこう言う結果になったのでしょう。
悔しいので実験です。
リソースを空にし、その部分は四角で塗りつぶしてみます。
step5_2.jar 1,130バイト！！、やっぱり＾＾
step5 - step5_2 = 2,900 - 1,130 = 1,770
step5_1 - step5_2 = 1,645 - 1,130 = 515
コードの部分を抜いて考えると、71%の減量になってます。
84 %までは行かないものの、かなりの節約ができそうです。
※上記の値はWinXP pro sp1にて計測
サーバやクライアントのファイルシステムにより、多少の前後あり。
step5.java step5.jar
「http://machtype.com/~flesh_gogo/mobile-appli/step5/Download.html」
step5_1.java
step5_1.jar
「http://machtype.com/~flesh_gogo/mobile-appli/step5_1/Download.html」
step5_2.java
step5_2.jar
「http://machtype.com/~flesh_gogo/mobile-appli/step5_2/Download.html」
だいぶ、開発できそうなネタがそろってきました。
もう一踏ん張りで、会社で開発開始できそう＾＾；
Update 2005/11/28
上へ トップページへ
【step6 Imageクラスの罠】
Imageクラスで困った問題に陥ったのでここで紹介しておきます。
ただ、やり方が間違えているだけでもっと良い方法があるかもしれませんが・・・。
まずImageクラスを初期化しようとしたときに
ディスプレイサイズ 240x240
imgMain = Image.createImage(240, 480);
とディスプレイサイズより大きくImageを取得しスクロールさせていたのですが
機種によってはディスプレイサイズより大きいImageを取得するとエラーで動作してくれません。
エラーが起きる機種を対象機種からはずせばいいが・・・そうもいきませんので。
ImageTest.java
上へ トップページへ