iモード携帯電話用Java(iアプリ) Part17

iモード携帯電話用Java(iアプリ) Part17 at TECH

1:デフォルトの名無しさん
08/04/02 13:21:44
NTT DoCoMoのiモード携帯電話用Javaに関する話題を扱うスレッドです。

※DoCoMo以外は下記スレへ。
CLDC+MIDP+携帯電話用Javaスレッド part 8
ｽﾚﾘﾝｸ(tech板)

■ iアプリ特有ではなくJava一般に関する質問はこちらへ
【初心者】Java質問･相談スレッド113【大歓迎】
ｽﾚﾘﾝｸ(tech板)

■関連スレ
【日本携帯】Mascot Capsule/Micro3D【標準】
ｽﾚﾘﾝｸ(tech板)

2:デフォルトの名無しさん
08/04/02 13:22:37
過去スレ
Part 1 URLﾘﾝｸ(piza2.2ch.net)
Part 2 URLﾘﾝｸ(pc3.2ch.net)
Part 3 ｽﾚﾘﾝｸ(tech板)
Part 4 ｽﾚﾘﾝｸ(tech板)
Part 5 ｽﾚﾘﾝｸ(tech板)
Part 6 ｽﾚﾘﾝｸ(tech板)
Part 7 ｽﾚﾘﾝｸ(tech板)
Part 8 ｽﾚﾘﾝｸ(tech板)
Part 9 ｽﾚﾘﾝｸ(tech板)
Part 10 ｽﾚﾘﾝｸ(tech板)
Part 11 ｽﾚﾘﾝｸ(tech板)
Part 12 ｽﾚﾘﾝｸ(tech板)
Part 13 ｽﾚﾘﾝｸ(tech板)
Part 14 ｽﾚﾘﾝｸ(tech板)
Pert 15 ｽﾚﾘﾝｸ(tech板)
Part16 ｽﾚﾘﾝｸ(tech板)

3:デフォルトの名無しさん
08/04/02 13:23:11
■ 開発環境

NTT DoCoMo - iアプリコンテンツの作成について
URLﾘﾝｸ(www.nttdocomo.co.jp)
Java[tm] 2 Platform, Standard Edition v 1.4
URLﾘﾝｸ(java.sun.com)
CLDC仕様書日本語版
URLﾘﾝｸ(java.sun.com)
Eclipse.org
URLﾘﾝｸ(www.eclipse.org)

■ 機種依存情報

ん・ぱか工房（iアプリ機種依存情報）
URLﾘﾝｸ(www.saturn.dti.ne.jp)
NTT DoCoMo - アプリケーション作成上の注意点
URLﾘﾝｸ(www.nttdocomo.co.jp)
Overflow! さかきけいのページ（504iまでの機種依存情報つきAPIリファレンスあり）
URLﾘﾝｸ(godwood.allnet.ne.jp)

■ アプリを省サイズ化するツール（ObfuscatorまたはOptimizer）

Java Blender
URLﾘﾝｸ(homepage.mac.com)
jarg - Java Archive Grinder
URLﾘﾝｸ(jarg.sourceforge.net)

4:デフォルトの名無しさん
08/04/02 13:23:56
■ 主なアプリ配布サイト

ギガアプリ
URLﾘﾝｸ(g-appli.net)
アプリ★ゲット
URLﾘﾝｸ(appget.com)
ゲームチャンネルi
URLﾘﾝｸ(appli.channel.or.jp)

■ 携帯関連ニュース

ITmedia：モバイル
URLﾘﾝｸ(www.itmedia.co.jp)
ケータイ Watch
URLﾘﾝｸ(k-tai.impress.co.jp)
Nekomaru What's New
URLﾘﾝｸ(snget.hp.infoseek.co.jp)

■ 関連板

携帯・ＰＨＳ
URLﾘﾝｸ(hobby10.2ch.net)
携帯機種
URLﾘﾝｸ(hobby10.2ch.net)
携帯コンテンツ
URLﾘﾝｸ(hobby10.2ch.net)
携帯電話ゲー
URLﾘﾝｸ(hobby10.2ch.net)

5:デフォルトの名無しさん
08/04/02 13:25:39
テンプレ終わり。

>>1のまとめサイトは全く使われてなかったので削除した。
3以降のリンク先等はチェックしてないのでリンク切れてたらｽﾏｿ

6:デフォルトの名無しさん
08/04/02 22:55:08
GPS機能はトラステッドiアプリのみと書いてあったんですが、
勝手アプリでGPS機能を使う方法って全くないんでしょうか？

ブラウザで↓のリンクを踏むと、アドレスに位置情報が送られるようですが。
<A HREF="http://アドレス" lcs>
iアプリでGPS使う方法はないでしょうか。

7:デフォルトの名無しさん
08/04/03 10:14:27
ブラウザ連携でアプリに引数として緯度経度を渡すなら何とか。
アプリ単独では無理なもんは無理･;(`ε()ﾞ

8:デフォルトの名無しさん
08/04/03 10:15:36
真っ当な方法では無いな。
公式のアプリからトラステッドIDを盗めばできるかもしれんが、
多分不正アクセスで書類送検･;(`ε()ﾞ

9:デフォルトの名無しさん
08/04/03 16:21:05
>>1
乙･;(`ε()ﾞ

10:デフォルトの名無しさん
08/04/03 17:31:52
Java全くわからないのですが、
Webカメラに撮った映像をパソコン経由で携帯のアプリで見ることは可能ですか？
後、携帯の赤外線とBlue toothを使って直でマイコンなどに送受信は可能ですか？
直でなくてもいいんですが・・実現できそうですか？
教えてください。

11:デフォルトの名無しさん
08/04/03 17:34:22
できそう･;(`ε()ﾞ

12:デフォルトの名無しさん
08/04/03 18:19:04
>>11
すいません。
できればどれを利用すればできるなど、具体的に教えていただけますか？

13:デフォルトの名無しさん
08/04/03 18:33:02
>>12
わからないのなら黙っていてください

14:デフォルトの名無しさん
08/04/03 18:35:44
>>12
既に仕事のレベルだから、携帯アプリ作ってる会社に聞きに行くと良い･;(`ε()ﾞ

15:デフォルトの名無しさん
08/04/03 19:00:53
つーかアプリ使えば今でも出来るだろ。
携帯コンテンツ板にでも行ってこい。

16:デフォルトの名無しさん
08/04/03 19:25:35
>>10
> Webカメラに撮った映像をパソコン経由で携帯のアプリで見ることは可能ですか？
URLﾘﾝｸ(www.sunmoon.co.jp)

17:デフォルトの名無しさん
08/04/03 19:56:48
>>16さん
すいません。
やはり自作では難しそうですね。
本当にどうもありがとうございました。

18:デフォルトの名無しさん
08/04/03 22:30:27
>>8
トラステッドIDだけあっても使えん。
あれはID発行時に申請したサーバの特定パスに置かれたjad以外に使用してもダウンロードエラーになる。

>>10
自宅サーバを立てられるなら、ニコニコモバイルの手法でいける。

19:デフォルトの名無しさん
08/04/03 22:48:20
>>18
君、S!アプリも作ってるね。

20:デフォルトの名無しさん
08/04/04 00:04:36
S!というかMIDPだな

21:デフォルトの名無しさん
08/04/04 00:11:21
Doja4.0とDoja5.1でデバッグ性能ちがうのか？

22:デフォルトの名無しさん
08/04/04 00:22:30
dispose呼ばなくても解放されてるよな？
と前スレで釣りのような疑問を投げかけた俺。
テストコードを書いて5.1エミュで試してみたが、
やはりdisposeではなくGC回収タイミングで解放されとる。
これ実機では挙動違ったりするの？誰か教えて。
URLﾘﾝｸ(www.uploda.org)

あと>>1乙、だがまたProGuard載ってないお･;(`ε(ﾞc=(^o^c)

23:デフォルトの名無しさん
08/04/04 00:37:35
>>18さん
ニコニコモバイルの手法とはどのような手法ですか？

24:デフォルトの名無しさん
08/04/04 07:48:09
>>19
失敬。
jad→jamね。

>>23
サーバPC側で動画（この場合はWebカメラの映像）をコマ毎にJPEG画像に変換。
アプリからサーバへリクエスト→画像ファイル(数枚～十数枚を１ファイルにパックしたもの)を取得。
で、パラパラ漫画の要領で表示。これを繰り返す。

ニコニコ公式の資料で結構詳しく解説してたような気がする。
音声を考えず、対応機種も絞ればアプリ自体は簡単に作れるっしょ。

サーバサイドの知識も必要になるけど。

25:デフォルトの名無しさん
08/04/04 14:11:12
>>22
VM実装依存

26:デフォルトの名無しさん
08/04/04 22:44:09
>>24さん
ありがとうございます。
検討してみます

27:デフォルトの名無しさん
08/04/05 11:33:17
プログラミングしたことないんだけど、とりあえず開発環境は整えた
何をすればいいのか全くわかりません
とりあえずゲーム作ってみたいんだけどどうすればいいの？

28:デフォルトの名無しさん
08/04/05 11:42:32
>>27
とりあえず、サンプルでついてるCarRaceをいじって
何をいじるとどう変るのかを楽しんでみる･;(`ε()ﾞ

だが、このスレで聞くよりも他の初心者スレ探して
聞いた方がいいかもというかそうするべき。
このスレは意外と初心者に厳しいｗ

29:デフォルトの名無しさん
08/04/05 11:43:04
いきなりiアプリから入るのか？
Javaの入門書を先に読む方がいいと思うぞ

30:27
08/04/05 11:50:31
>>28
ありがとうございます
あのゲームを作るのにこんなにたくさんのソースを書く必要があると知って衝撃を受けました
コツコツ弄ってみます

>>29
明日図書館で入門書借りてきます
ありがとうございます

31:デフォルトの名無しさん
08/04/05 11:51:36
俺は言語のみの入門書って殆ど読んだ事無いな。
初めて読んだのも日高徹/青山学なゲームプログラミングの本だし･;(`ε()ﾞ

32:デフォルトの名無しさん
08/04/05 12:17:28
　doja　入門
でググってみるといいかも。

ステップとしてはこんな感じかな。

１．Javaの基本を理解する
２．HelloWorldを実機で動かしてみる
３．簡単なサンプルをいじってみる
４．公式PDFの開発ガイドにざっと目を通す
５．CLDCのAPIリファレンスを何となく眺める
６．DoJaのAPIリファレンスを何となく眺める
７．自分で作ってみる

先は長いだろうが頑張れ！

33:デフォルトの名無しさん
08/04/05 12:17:47
入門書碌に読まずに人に聞いてばっかでここまで来た俺はきっと危ないコード生産機・・・

34:デフォルトの名無しさん
08/04/05 12:51:42
>>22,25
建前はそうだけど、ほとんどの機種でVMは共通だから、
最近の機種だったら、GCでdisposeされるんじゃないの？

35:デフォルトの名無しさん
08/04/05 12:59:14
俺の理解では

・GCは浮いている値（どこからも参照されてないメモリ）を解放する＝nullを突っ込んでおけば勝手に解放される
・disposeすると次にGCが動いた時に解放される

だと思ってたんだけど違う？

36:デフォルトの名無しさん
08/04/05 13:01:06
VMの実装がどうなってるかによるが、俺はそんな内部の事までは知らない。
そこまで知っている人が居るかも分からんが。

37:デフォルトの名無しさん
08/04/05 13:28:21
むしろ知らなくていいのがJavaのはずなんだろうけど、現実問題そうもいかないんだよね・・・

38:デフォルトの名無しさん
08/04/05 13:56:47
そこまでdispose入れたくない理由も無いなら
素直に入れとけば良いって話だが、
dispose入れると容量オーバーするとかなら南無。

39:デフォルトの名無しさん
08/04/05 15:48:38
>>35
>＝nullを突っ込んでおけば勝手に解放される
イコールはさすがに行きすぎの気がする。

disposeは>>38と同じ意見かな。

40:デフォルトの名無しさん
08/04/05 20:02:13
ＧＣは命令を発行しても端末によっては実行されないからな。

ひどい端末になると実際にnewなどで足りなくなった時に初めて実際にＧＣが実行されるという

41:デフォルトの名無しさん
08/04/05 20:04:03
>>40
最近の端末でもそんなのあるの？

42:デフォルトの名無しさん
08/04/05 20:06:10
最近かどうかは置いといてそういう端末があるのは事実だよ。

43:デフォルトの名無しさん
08/04/05 23:25:47
>>41
最近の端末は、そもそもコンパクションをしないわけですがｗ

44:デフォルトの名無しさん
08/04/06 13:16:13
Eclipse3.2を使っているんですが、DoJa3.5SDKを使うと、
Eclipseプラグインが上手く動作しません。

DoJa5.0SDKならEclipse3.2でも動くんですが、
アプリはDoJa3.5の携帯に対応させたいです。
DoJa5.0SDKを使っても問題ないでしょうか？
（DoJa5.0の機能を使わなければDoJa3.5SDKを使うのと変わらない？）

45:44
08/04/06 13:18:07
追記：
実際にDoJa5.0SDKで作ったアプリを、
DoJa3.5の携帯で動かしてみたところ、
普通に動くことは確認しました。

46:デフォルトの名無しさん
08/04/06 18:54:31
>>44
DoJa5.0SDKのビルドの設定でDoJa3.5を選べば大丈夫では？？

47:デフォルトの名無しさん
08/04/06 23:52:33
>>46
float使ってなきゃそれでオケだと思う

48:デフォルトの名無しさん
08/04/07 20:44:24
>>46
どこで選べるのか分からん＞＜

49:デフォルトの名無しさん
08/04/07 21:00:11
>>48
DoJa5.1用だと
設定＞エミュレータ環境設定＞ビルドの設定＞ターゲットプロファイル

50:デフォルトの名無しさん
08/04/07 21:55:11
>>49
ありがとう＞＜
この設定ってEclipseからの起動でも反映されるのかな？＞＜

51:50
08/04/07 21:59:30
反映されてた＞＜
ありがとう＞＜

52:デフォルトの名無しさん
08/04/07 22:11:06
上手くいってよかったな。
後は中学校をきちんと卒業するだけだ。

53:デフォルトの名無しさん
08/04/07 22:18:59
>>52
今日から中学校だったんだ。

54:デフォルトの名無しさん
08/04/08 15:57:50
>>53
それはすごいな
高校の頃からこーゆーのにハマった俺なんかとは圧倒的に差がつくわけだ…
最近の若い人達がむちゃくちゃ出来るのは
やり始めた時期が違うから、なのですねえ

55:デフォルトの名無しさん
08/04/08 16:23:47
iアプリのダウンロードゲームで
「オタマジャクシのようなくねくねした物体が、洞窟の壁にあたらない様に進むゲーム」
って何て言うゲームでしたっけ?

56:デフォルトの名無しさん
08/04/08 16:24:03
インターネットに触れやすいし、ソフトもあふれてるからねぇ、
後若い方が時間もあるし、勢いがあるよね・・・
昔の俺もクソみたいな環境でよくちまちま作ってたよ。今は腰が重すぐる

57:デフォルトの名無しさん
08/04/08 16:24:40
>>55
SFCaveこと精子ゲーム

58:デフォルトの名無しさん
08/04/08 16:29:07
>>57
あなた神ですよね?
有り難う御座います。

59:デフォルトの名無しさん
08/04/09 00:32:24
どっかのSunかなんかのドキュメントで、nullを入れることでGCで回収され易くなることは書いてあったけど、
その為にnullをいれるならコード自体を見直すべきだ、な感じなこともことも書いてあった。

60:デフォルトの名無しさん
08/04/09 01:31:21
>>59
回収されやすいというか何というか
null入れないとunreachableにならなければ
そりゃ回収されないわな。
逆に、nullにしなくても(スコープ抜けるとかで)unreachableになれば回収される。

61:デフォルトの名無しさん
08/04/09 02:40:48
CLDCではどうか分からないけど、J2SEのオブジェクトのライフタイムとかそんな
資料だったか、GCで開放されるメモリはある程度段階的で、GCすれば全ての
浮いたメモリが即開放されるわけじゃないって書いてあった覚えがある。
だからこそ内部で半固定的に保持し続けるようなリソースは、開放するための手段が
あればできるだけ使ったほうがいいんだと思うなあ。

62:デフォルトの名無しさん
08/04/09 10:28:52
単純に考えれば
a=new A ←→ a=nullなんじゃないの？

63:デフォルトの名無しさん
08/04/09 15:30:33
disposeも内部ではnull代入だけとか？ｗ

64:デフォルトの名無しさん
08/04/09 16:11:56
>>63
こんなの見つけた。
URLﾘﾝｸ(www.ibm.com)

想像でしかないが、staticなクラス変数のリストなんかに
メモリを確保するような作りだと、外部から明示的に不要な
参照を切る処理をしないとだめなのではないかな。
（Cのmallocとfreeの思想だぬ）
そのへんはVMの実装で、フォローする/しないがあるんだと思う。

65:デフォルトの名無しさん
08/04/09 17:40:43
デジカメで撮影した画像を
microSDでFOMA端末に移して
その画像をselectEntry()で選んでサーバに送信するiアプリを作りたいんだけど
１．selectEntry()で選択できる画像の制限に関する情報
２．selectEntry()で選択した画像のデータサイズをcamera.getImageLength()みたいに取得する方法
が分かる方、資料の在り処とかでもいいので教えてください

１．はそもそもバッテン表示で選べなかったり、選んでみてもUIExceptionとエラーが返ってきたりとかして困ってます

66:デフォルトの名無しさん
08/04/09 23:20:15
>>65
方法1
ImageStore#getInputStream()でInputStreamを取得
ByteArrayOutputStreamを生成する
EOFExceptionが出るまでByteArrayOutputStream#write()にInputStream#read()する
ByteArrayOutputStream#size()がファイルサイズ

方法2
ImageStore#getInputStream()でInputStreamを取得
取得直後のInputStream#available()をファイルサイズとみなす。

試してないし、特に後者は果たしてファイルサイズと評価して良いのか悪いのか、明示されていないのでわからんし。
前者は普通にバイナリを作成してるからメモリを食う。
思い付くところでこんなところ。詳しくはjavadocを嫁。うぷするみたいだし、方法1で良いと思うが

67:デフォルトの名無しさん
08/04/10 00:45:47
iアプリGPS利用しようと思っていろいろ調べたら
位置情報をiモードブラウザでアップしてiアプリからDLすることでできるっぽい！！
と意気込んで試したら、、、
LAUNCH_BROWSER_SUSPENDがオプションAPIということに気付く。。。
＃P905iで確認

もう一度iアプリ起動してサーバからDLするしかないんですかね？
ブラウザの起動でタダでさえ手間がかかるのに
iアプリの再起動も必要となるとはorz
それとも他に方法があるなら教えてください

68:デフォルトの名無しさん
08/04/10 00:52:52
>>61
それって世代別GCのこといってるのかな？
だったらその通りだよ。
だけど、さすがにメモリが足りなくなりそうになったら、到達不能なものは全部開放されるよ(full GC)。
ちなみに、CLDCのVMは、世代別GCは搭載されてないとおもう。

69:デフォルトの名無しさん
08/04/10 08:52:04
>>67
そもそもi-modeブラウザとiアプリを同時に起動できる端末なんて少ないよ。
ほとんどの端末がi-modeブラウザを起動させるときはiアプリを落とさなきゃならない。無論P905iも。
出来るのはN(903i以降)くらいだった希ガス

とりあえず、非トラステッドでもi-modeブラウザとiアプリを使ってGPSを利用してるアプリは少なくないから、まずはその動作の様を確認するべきかと。

サスペンドの解釈を間違えてると思うし、S!アプリみたいな一時停止機能はiアプリでは期待出来ないよ

70:67
08/04/10 20:17:57
>>69
ありがとう
勝手アプリでGPS使ってるの見つけれんかった。。。

ちょっと考えたけど、ブラウザから再起動させるやり方がベストか

71:デフォルトの名無しさん
08/04/10 21:38:30
カメラを起動して写真に位置情報つけて読み込むという荒業を試す俺。

72:デフォルトの名無しさん
08/04/10 22:01:41
com.nttdocomo.ui.GraphicsにgetFontメソッドがないのは
激しく不便な気がするのですが、普通の人はそうでもないんでしょうか。

73:デフォルトの名無しさん
08/04/10 22:26:27
com.nttdocomo.ui.Fontにあるからいいじゃん

74:デフォルトの名無しさん
08/04/10 22:54:54
>>70
GoogleMapはそうだよ。
ついこないだトラステッド化したけど、それ以前はブラウザ経由で位置情報取得してた。

75:デフォルトの名無しさん
08/04/10 23:47:04
>>72
Graphicsにいつ設定したかわからないFontを取得したいと思うのは
そもそも設計自体がどうかと思うかな。基本的にGraphicsは書き込む(set)する対象であって
読み込む(get)する対象じゃないし。
Fontが必要ならメンバとして保持しておけば良い。

76:デフォルトの名無しさん
08/04/11 00:06:30
FontはdrawStringする前に必ず正しいものをセットするもんだしなぁ。

まぁgetOriginXとか無いのは不便だなーと思うときもあるよ。
だからラッパークラス作ったしｗ

77:デフォルトの名無しさん
08/04/11 00:54:12
わかりません

78:デフォルトの名無しさん
08/04/11 06:55:31
>>75
その考え方で設計がおかしいと言い切るのは思慮に欠けていると思う。
俺は逆に、自分の処理でsetして必要な処理が完了したら以前の状態へ戻すべきだと考える。

/** デバッグ情報を描画 */
void drawDebugInfo(){
　Font oldFont = g.getFont();
　g.setFont(小さなフォント);
　g.drawString(デバッグ文字列);
　g.setFont(oldFont);
}

/** ゲームメッセージを描画 */
void drawGameMessage(){
　g.setFont(大きなフォント);
　g.drawString(ゲームメッセージ1);
　drawDebugInfo();
　g.drawString(ゲームメッセージ2);
　// ↑setFontし直す必要が無い
}

この場合drawDebugInfoの内部実装を意識せずに済むというのは
汎用的な機能メソッドとして使えるなどのメリットになると思う。
まあ、これはGraphicsのcopyを作って使ってもいいんだけど、
処理の大きさを考えると、使った分戻すってのが最小限で良いと思うんだ。
てかMIDPにもgetはあるしね。

>>76
うちもラッパー作って最近公開したよ。個人的に凄くタイムリーな話題だった。

あと今更だが、>>72はsetFontの対という意味でのgetFontのことを言ってるのか？
それとも>>73の意味のことを言っていたのか？どっちだ、不安になってきたぞ。

79:65
08/04/11 09:09:12
66さんありがとう、方法１で画像のサイズが取れました

あと71さん
そもそも画像に位置情報埋め込めない端末とか
普通に写真取るときは埋め込めるのに、iアプリから起動したカメラだと埋め込めなくなる端末とか
これはうろ覚えだけど、せっかく埋め込んだのに送信時にわざわざ位置情報消してくれる端末とか
あったよ

80:デフォルトの名無しさん
08/04/11 09:43:03
>>76
俺はMIDPにあるgetClip～が無いのが不便だと思ったのでラッパー作った。

81:デフォルトの名無しさん
08/04/11 11:00:06
実機無いんで分からないんですが
Connector.openにGUID=ON渡したらiモードIDきちんと送られますか?

82:72
08/04/12 00:19:27
>>78
setFontの対という意味でのgetFontのことです。
説明不足ですみません。
java.awt.Graphicsにもjavax.microedition.lcdui.Graphicsにもあるのに
これだけにはないんですよね。

getFontではないにしろ、どうやら他の人も自分と似たような
不便さを感じていたようで。
自分もラッパークラスを作ってみます。
どうもありがとうございました。

83:デフォルトの名無しさん
08/04/12 10:35:50
>>81
結論から言うとできるようだ。
というか、お前Docomoユーザの友達いねーの？

84:71
08/04/12 10:56:02
>>79
まぁ、そうだろうとはおもった。
Nではできてるんだけど、他はどれぐらいできのだろうか。
根っこが同じのPぐらいしか無理なんだろうか。
APIにはやれと言わんばかりのメソッドあるのにな。

85:デフォルトの名無しさん
08/04/12 11:06:44
しーっ！

86:デフォルトの名無しさん
08/04/12 17:28:55
それがドキュモクオリティー

87:デフォルトの名無しさん
08/04/13 23:30:47
みなさんが低レベルAPIでコンボボックスを使いたいとき
どのような実装にしていますか？もしくはしますか？
ソースレベルで書いてもらえるとベスト！

88:デフォルトの名無しさん
08/04/14 00:15:00
（；＾ω＾）

89:デフォルトの名無しさん
08/04/14 00:24:31
>>87
ソースレベルでも何も文字列持ってそれ表示するだけじゃねぇか。
何が分からないんだか分からん。

とりあえず本名と所属を言え、まずはそれからだ。

90:デフォルトの名無しさん
08/04/14 00:26:42
>>87
また、ゆとりを装った仕事を人任せにする人か。

91:87
08/04/14 01:11:55
>>89
んっと、PanelならListBox.CHOICE使えばいいと思うんですが
Canvasで同じようなことしようとするのに容易な方法あります？
ちなみに、趣味でやってるだけで会社の仕事じゃないどす

92:デフォルトの名無しさん
08/04/14 06:42:48
無い

93:75
08/04/14 14:25:22
>>78
その考えも間違ってはいないと思うけど、
必ず戻すことを保証するように作っているかどうかが問題だと思う。

>>drawDebugInfo();
>>g.drawString(ゲームメッセージ2);
ここの部分で、drawDebugInfo();が描画を破壊している恐れがあることを考えると
、g.drawString(ゲームメッセージ2);はそのまま自分の表示したい設定もせずに
描画することが危険であると思える。
実際にメソッド内でどこまでGraphicsオブジェクトが書き換わるかわからない訳だし。

この例で考えるのであればdrawDebugInfo();の引数にFontを渡してやって、
drawDebugInfo()の最後で渡されたFontに復元することを保証するメソッドとして作る
という書き方もできる。その場合は引数は増えるけどGraphicsにsetFontは要らない。

94:デフォルトの名無しさん
08/04/14 14:44:44
constがないJavaでやっている以上、不毛な議論だろそれは。

95:デフォルトの名無しさん
08/04/14 15:17:56
DoJa5.1でiアプリを開発している者です。
iアプリに関しては初心者です。

今やりたいのが、
文字列と画像(複数)をいっぺんにサーブレットに送信すること。
ＵＲＬに引数をつけるのは、セキュリティ上アウトなんです。

OutputStreamに文字列もバイナリも含めて送信し
（バイナリは文字列として）、
サーブレット側でその文字列を切り分けてみましたが
画像は壊れてしまいました。
（文字列は正しく取得できましたが）

そもそも私がやろうとしていることって、
iアプリで実現可能なんでしょうか？

分かる方、教えて下さい。

96:デフォルトの名無しさん
08/04/14 15:30:49
容量の限界はあるが、可能。
バイナリデータは送信可能。あとはどういうフォーマットで送るかは自由。
失敗したというのなら、送信容量を越えていたか、プログラムミス。

97:デフォルトの名無しさん
08/04/14 15:42:24
多分送信容量と予想して
jguidefordoja5_x_071101.pdf のP115 読んでみ？

98:95
08/04/14 17:42:32
>>96
>>97

レスありがとうございます。
容量は問題ないので(ちょこっと文字列と画像15KB)、
プログラムミスだと思います。
実現可能だと分かっただけでも嬉しいです。
もうちょっと頑張ってみます。

99:デフォルトの名無しさん
08/04/14 18:02:10
初心者って事なら、Image#toStringとかして
streamに突っ込んだんじゃないの？
元のgifなりjpegファイルなりのbyte配列を送信しないとダメよ。

100:95
08/04/14 19:20:11
>>99
レスありがとうございます。
iアプリからサーブレットへの接続部分はこんな感じです。
(パート１)

// カメラオブジェクトの取得
Camera camera = Camera.getCamera(0);
// byte[]のimgに撮影画像のバイナリを格納する
InputStream w_in = camera.getInputStream(0);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
byte[] buff=new byte[1024];
int size;
try {
while ((size=w_in.read(buff))!=-1) {
baos.write(buff,0,size);
}
baos.flush();
baos.close();
w_in.close();
} catch (IOException e) {
e.printStackTrace();
}
byte[] img = baos.toByteArray();

101:95
08/04/14 19:21:16
(パート２)
// HTTP POSTのリクエストボディに格納する文字列を取得
String postData = "key="+strKey+"&img="+ new String(img);
// 出力先への接続を設定
HttpConnection w_connect = (HttpConnection) Connector.open(URL,Connector.READ_WRITE, true);
// 要求メソッドとコンテンツタイプを設定
w_connect.setRequestMethod(HttpConnection.POST);
// 出力ストリームを取得
wo_stream = w_connect.openOutputStream();
// 出力ストリームへ書き込む
wo_stream.write(postData.getBytes(););
// 接続
w_connect.connect();

どうでしょうか・・・？

102:デフォルトの名無しさん
08/04/14 20:30:00
new String(img)なんてしたら、データが壊れるだろｗ
文字列で表現できないバイトが出現した瞬間に終わる
素直に

String str = "key="+strKey+"&img=";
wo_stream.write(str.getBytes());
wo_stream.write(img);

とバイナリのまま送っておけ。
サーブレット側で「xxx=」で自動切り分けする機能とか使っちゃダメだぞ。自前でやれ。

103:デフォルトの名無しさん
08/04/14 20:48:24
これはひどい

104:95
08/04/14 20:55:47
>>102

バイナリをStringにしてはダメということでしょうか？
そうすると、サーブレット側もダメっぽいです・・・。

protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
try{
/** アプリからの情報を受信 **/
// 入力ストリームを取得
InputStream wi_buffer = request.getInputStream();
// StringBufferインスタンスを作成
StringBuffer w_StringBuffer = new StringBuffer();
// 送信されたストリームを読取
String w_PostData = "";
int w_char;
while ((w_char = wi_buffer.read()) != -1) {
w_StringBuffer.append((char)w_char);
}
w_PostData = (String)w_StringBuffer.toString();
// 画像データの取得
byte[] image = w_PostData.substring(w_PostData.indexOf("img=")+4).getBytes();

こんな感じなのですが･･･。

105:デフォルトの名無しさん
08/04/14 21:41:44
バイナリをStringにするとかありえないだろ
byte配列にして送って、文字列だけStringに変換すりゃいいじゃん

106:87
08/04/14 21:59:50
>>92
やっぱ簡単には無理ですよね？
一応、簡単そうなダイアログボックスのクラス作ってみたけど、
コンボボックスの考え方もこんな感じで問題ないですか？？
まぁ素直に用意されてるDialog使えってのはあると思うけど
自作だと色とか初期フォーカスとかカスタマイズできるんで。。。
ただ、Display.setCurrent()での画面切り替えでちらつくのはどうにかならんかなぁ

class DialogBox extends Canvas{
　　public void paint(Graphics g){
　　　　g.lock();
　　　　g.setRGBPixels(0, 0, Display.getWidth(), Display.getHeight(), g_pixels, 0);　// 前画面を描画
　　　　// ダイアログ背景、タイトル、メッセージ、ボタンの描画
　　　　g.unlock(true);
　　}
　　public void show(){
　　　　g_frame = Display.getCurrent();
　　　　g_pixels = (((Canvas)g_frame).getGraphics()).getRGBPixels(0, 0, Display.getWidth(), Display.getHeight(), null, 0);
　　　　Display.setCurrent(this);
　　}
　　public void processEvent(int type, int param){
　　　　if((type == Display.KEY_RELEASED_EVENT) && (param == Display.KEY_SELECT)){
　　　　　　Display.setCurrent(g_frame);
　　　　}
　　　　if((type == Display.KEY_PRESSED_EVENT) && ((param == Display.KEY_LEFT) || (param == Display.KEY_UP) || (param == Display.KEY_RIGHT) || (param == Display.KEY_DOWN))){
　　　　　　// ボタンフォーカスの移動
　　　　　　repaint();
　　　　}
　　}
}

107:デフォルトの名無しさん
08/04/14 22:35:32
どうしても文字列で送りたいならBase64にでもエンコードすれば？
自分でエンコードしなきゃいけないし、通信量も増えるけど。

108:デフォルトの名無しさん
08/04/14 23:00:18
つまり、iアプリ初心者ではなくJava初心者という落ちか。

109:デフォルトの名無しさん
08/04/14 23:01:37
いつものことさ

110:デフォルトの名無しさん
08/04/14 23:24:10
仕方あるまい。
Javaをマスターしていればiアプリの質問は出ないだろうし逆も同じだ。
通信周りが違うと言っても、比較的簡単な部類だし。

111:デフォルトの名無しさん
08/04/15 00:21:24
>>107
BASE64はDoJaにAPIがあった気がするが……

まぁ95は取り合えずjavaの基本から勉強しなおした方がいいな

112:95
08/04/15 01:59:18
そうですね。確かにJAVAの修行が足りませんね。
何はともあれ、皆さんの助言のお陰で、
どうすれば良いのか分かりました。
ありがとうございました。

113:デフォルトの名無しさん
08/04/15 10:01:58
どっちかというとプログラミング以前の計算機科学基礎ができないのでは？

114:デフォルトの名無しさん
08/04/15 10:20:40
自分の世代が8bitパソコンのBASICで試行錯誤しながら基礎を学んだ様に、
いまどきのコンピュータキッズは携帯電話のJavaで基礎を学んでるのかも。

115:デフォルトの名無しさん
08/04/15 11:42:15
恒例のゆとりＶＳオジサンですか

116:デフォルトの名無しさん
08/04/15 11:54:36
お前ら試行錯誤してあと一歩のとこまで来てる初心者を滅多打ちしてんじゃねーよｗ

>>95
アプリとサーブレット、こんな感じのフォーマットでやってみ。

0-3 バイト文字列長
4～文字列
その後ろに
0-3 バイト画像ファイルサイズ
4～画像のバイナリ

現状 key= とか邪魔。
ちゃんとPOSTでバイナリと文字列送りたいなら、
BASE64エンコードするなりマルチパートで送らないとダメ。

117:114
08/04/15 12:03:43
>>115
いや、「初心者叱るな来た道だもの」と言いたい訳よ。

118:95
08/04/15 12:26:42
たった今、動作確認しました。
文字列は文字化けせず、画像も壊れることなく、
ちゃんとサーバに送信できました。

サーブレット側で、
まずは入力ストリームからbyte配列を取得しました。
それから"key="とか"&img="とかをbyte配列にしたものを手がかりに、
入力ストリームのbyte配列を切り分けていきました。
で、文字列情報はStringに直しました。

一応これで、やりたかったことは実現できましたので、
助言して下さった方々に感謝します。

119:95
08/04/15 12:30:21
あと116さん、惚れました（116=男性という前提でw）。
どうもありがとう。

120:デフォルトの名無しさん
08/04/15 12:48:47
ｱｰｯ!!

121:デフォルトの名無しさん
08/04/15 13:05:05
ネットで牝アピールとかしないほうがいいよ・・・

122:デフォルトの名無しさん
08/04/15 13:10:14
おいおい、惚れた掘られたの話は他所でやってくれよ(´ー｀)y-~~

123:デフォルトの名無しさん
08/04/15 13:11:10
裏技
URLﾘﾝｸ(jpan.jp)

124:デフォルトの名無しさん
08/04/15 13:11:45
裏技ｷﾀ━━(ﾟ∀ﾟ)━━ !!

125:デフォルトの名無しさん
08/04/16 14:59:49
こんにちは。
最近iアプリ開発に携わることになりました。
で、iアプリでもTDDを行いたいと考えているのですが、
どなたかJMUnitをDojaに移植した方はおらっしゃいませんか？

126:デフォルトの名無しさん
08/04/16 19:59:15
(‘ω‘)

127:デフォルトの名無しさん
08/04/16 23:32:42
東京ディズニー

ダンジョン( ﾟДﾟ )

128:デフォルトの名無しさん
08/04/17 00:19:05
三月磨臼を探すアレか

129:デフォルトの名無しさん
08/04/17 03:17:47
ゆとりの俺は「TDD」という用語がわからなくて検索してみたんだ

TDD = 時分割複信 (Time Division Duplex)
URLﾘﾝｸ(e-words.jp)

TDD = テスト駆動開発（Test-Driven Development)
URLﾘﾝｸ(www.atmarkit.co.jp)

JMUnitも知らないから検索してみたんだ

JMUnit = MIDPで作られたオープンアプリ用の単体テストフレームワーク
URLﾘﾝｸ(blog.livedoor.jp)

どうやらここで言ってるTDDとは「テスト駆動開発」という意味らしい
Wikipedia項目ﾘﾝｸ

130:デフォルトの名無しさん
08/04/17 03:25:05
で、移植したらどうなるっての？

131:デフォルトの名無しさん
08/04/17 10:19:09
邪神復活

132:デフォルトの名無しさん
08/04/19 00:08:21
移植して何がしたいのか、返答によってまたコメントが変わるよな。何がしたいか解らない今は言うことないし

133:デフォルトの名無しさん
08/04/19 22:14:39
ケータイの3D機能って全機種に搭載されているわりにあまり使われてないような気がするのですが、
やっぱり非力だから？

3Dの解説してるサイトや、面白い使い方してるアプリを知ってる方居ませんか？

134:デフォルトの名無しさん
08/04/19 22:15:36
>>133
非力と思うなら、
最新機種で人気ゲームをダウンロードしてみることだ。

135:デフォルトの名無しさん
08/04/20 01:01:58
面白いかどうかは別としてリッジレーサーにはびびった

136:デフォルトの名無しさん
08/04/20 01:05:44
>>133
勝手アプリだとOpenGL使えないから厳しい
マスコットカプセルは問題外だし

137:デフォルトの名無しさん
08/04/20 02:27:45
今の最新機種の3D性能は初代PSの6割くらいはあるよな？
それだけの物が作れるかは別として。

138:デフォルトの名無しさん
08/04/20 02:29:18
>>134
いえ、リッジレーサーや鉄拳やバイオハザードなんかは確かによく動いてると思うのですが、
勝手アプリで3Dを生かしたアプリをあまり見ない（気がする）のはなんでかなーと。

ゲームに限れば、3Dゲームは2Dゲームより操作が複雑になりがち
→ケータイのキーでは操作性が悪い

ってのはあるかもしれませんが。

>>135
P905iにプリインストールされてるヤツですかね？
あれは確かにすごいと思いました。

>>136
勝手アプリはマスコットカプセル以外の選択肢ないですよね？
（ドコモがOpenGLをトラステッドのみに制限する意味もよくワカランのですが）
マスコットカプセルはどのあたりが問題外なんでしょう？

139:デフォルトの名無しさん
08/04/20 02:53:35
やっぱ、コマーシャルプロダクトに閉じてる点じゃないかな。

140:デフォルトの名無しさん
08/04/20 10:24:39
>>138
かじれば分かるだろうけど、作りづらい上にろくなもんできないだろ。
少なくとも俺みたいなへたれには

141:デフォルトの名無しさん
08/04/21 01:29:07
java言語の3Dじゃ鉄拳とかリッジレーサーのような動きは出せない

他の言語は携帯端末を破壊する恐れがあるので個人では使用できない

142:デフォルトの名無しさん
08/04/21 02:57:29
java言語の3D？

143:デフォルトの名無しさん
08/04/21 03:26:23
キャンバスに自力で書くんじゃね？

144:デフォルトの名無しさん
08/04/21 04:16:26
>>141
チューリング先生、出番です。

145:デフォルトの名無しさん
08/04/21 07:57:44
>>142はPのリッジレーサーを知らないのか

146:デフォルトの名無しさん
08/04/21 07:58:05
>>142じゃなくて>>141だった

147:デフォルトの名無しさん
08/04/21 08:16:15
じゃあ俺はN88BASICの3D作るわ

148:デフォルトの名無しさん
08/04/21 10:22:33
あったなー、N88BASIC用の３D
意味も分からずにサンプルソース打ち込んでたの思い出したｗ

＞3Dを生かしたアプリ
というのがそもそも何かが分からん。

149:デフォルトの名無しさん
08/04/21 10:54:54
>>142
大手ゲームメーカーがjavaでアプリ作ってると思ってるのか？
C言語で作ってるに決まってんだろ

150:デフォルトの名無しさん
08/04/21 12:07:03
>>141
>>149

151:デフォルトの名無しさん
08/04/21 12:17:56
iアプリってのはDoJaプロファイルに従って作成されたJavaアプリケーションのことじゃないの？
何でC言語が出てくるんだ

152:デフォルトの名無しさん
08/04/21 13:28:44
>>149
大手ゲームメーカーはマシン語で作ってるに決まってる

153:デフォルトの名無しさん
08/04/21 13:49:28
俺も携帯の仮想マシンで動かせるC言語が欲しい。
誰か頂戴。

154:デフォルトの名無しさん
08/04/21 14:08:16
つ au

155:デフォルトの名無しさん
08/04/21 16:23:23
>>153
Java仮想マシン用のバイナリを吐くCコンパイラって、あるんじゃないの？
gccならターゲット定義が簡単だし。

156:デフォルトの名無しさん
08/04/21 16:33:47
iアプリってSDカード経由でインストールできますか？

157:デフォルトの名無しさん
08/04/21 20:54:54
>>155何それ・・・、メソッド全部staticってこと・・・？

158:デフォルトの名無しさん
08/04/21 21:25:44
質問が終わったらいつものくだらない雑談になると

159:デフォルトの名無しさん
08/04/21 22:01:31
D905iってjpg偽装ならアプリからデータ吐き出せる？
偽装gifだとデータ壊れるみたいなんだが。

160:デフォルトの名無しさん
08/04/21 22:12:17
話はループする

161:デフォルトの名無しさん
08/04/22 01:24:41
過去ログ見ればよくねー？

162:デフォルトの名無しさん
08/04/22 10:39:15
過去ログ読んだけど結局答え出てなかったなw

163:デフォルトの名無しさん
08/04/22 12:21:33
gifピクセルに入れればいいって話があったはずだが

164:デフォルトの名無しさん
08/04/22 13:07:11
バイナリコメントじゃなくて、テキストコメントにすればOKって結論じゃなかったっけか

165:デフォルトの名無しさん
08/04/22 13:15:01
ぶっちゃけサンプルソース欲しいな
よくわかんね

166:デフォルトの名無しさん
08/04/22 13:25:58
>>165
これくらい分からなくてどうする。
参考ページは幾らでも見つかるぞ。

167:デフォルトの名無しさん
08/04/22 13:34:50
サンプルソースで考える楽しみを奪うなんて酷すぎる(´；ω；｀)

168:デフォルトの名無しさん
08/04/22 21:36:39
お前ら手厳しいなｗ

169:デフォルトの名無しさん
08/04/23 16:56:57
アプリが1MBまでになった今リソースをネットからダウンロードする意味ってあるんですか？
例えば、RPGではマップの配列をダウンロードして使う場合もあると思うんですが
もう中に組み込んじゃった方が便利だと思うんです
ネットからダウンロードというのは昔容量が少なかったときの苦肉の策で今使う意味は
ないような気がするんですが、どうなんでしょうか？

170:デフォルトの名無しさん
08/04/23 17:03:53
１M超えるデータでも扱えるやん

171:デフォルトの名無しさん
08/04/23 17:06:50
え？今はスクラッチパッドも含めて1MBだから意味ないんじゃないでしょうか？

172:デフォルトの名無しさん
08/04/23 17:09:56
何度も通信して落としてきたらいいやん

173:デフォルトの名無しさん
08/04/23 17:11:08
>>171
SDカードにデータを保存できる

174:デフォルトの名無しさん
08/04/23 17:14:24
あーそういうことですか
今言いたかったのは初回起動時に通信してデータをダウンロードする場合の話で
一時的に使うデータをダウンロードするのはそういうのが必要なアプリならいいんじゃないでしょうか

175:デフォルトの名無しさん
08/04/23 17:17:33
そもそも1回の通信で150kbまでしか落とせないはずだが緩和されたの？

176:デフォルトの名無しさん
08/04/23 17:19:16
ちなみに>>174は>>172さんへのレスです

177:デフォルトの名無しさん
08/04/23 17:24:27
>>175
150kbを何度も繰り返せばいい。

>>174
最初にリソース全部落として、それ以降変更が無いのであれば
リソースに組み込んでも良いと思う。

178:デフォルトの名無しさん
08/04/23 17:41:29
リソースをVer管理して、認証時に自己照合させる。
リソースVerが違っていたらリソースをDLしなおさせる。

ってやっておくと、全プレイヤーに常に最新のリソースを使わせることができるので便利。

179:デフォルトの名無しさん
08/04/23 18:19:48
>>169
単に900とか古い機種対応が面倒だから
古い機種にあわせて新しいのも同じ仕様って事だと思う。
少なくともウチはそんな理由。

180:デフォルトの名無しさん
08/04/23 18:30:01
さすがにまだ903以降のメガアプリオンリーというわけには行かないんじゃないかな
3以降なのにメガアプリ未対応なショボいケータイもあったりするからなぁ

181:デフォルトの名無しさん
08/04/23 18:32:48
仕様変更とか来たときにスクラッチパッド使用の方が
逃げ場が多いってのもあるかな。

リソース作製側にサイズ制限も伝えやすいし。

182:デフォルトの名無しさん
08/04/25 11:01:11
スレ違いだったらゴメンナサイ。

今、ｉアプリを作成していて、JARサイズが100Kを超えてしまってます。
※ProGuardも使用していて、100Kを超えます。

そこで、7zipを使えば良いと聞き、試してみましたが、正常に動作しません。
ちなみに方法は、
・Jarファイルの拡張子をzipに変更
・そのzipファイルをいったん解凍
・出来たフォルダを7zipで再圧縮
・7zipファイルの拡張子をjarに変更

これをプロジェクトの中のjarファイルと入れ替え、jamファイル内のAppSizeを変更して、エミュで実行させたのですが、

java.lang.ClassNotFoundException: exb

と表示され、起動しませんでした。

何が間違っているのでしょうか。

もし、分かる方いらっしゃいましたら、アドバイスお願いいたします。

183:デフォルトの名無しさん
08/04/25 12:52:29
Windows以外のOSで7zipする

184:デフォルトの名無しさん
08/04/25 13:10:05
jarg使えば

185:デフォルトの名無しさん
08/04/25 13:41:03
>183
アドバイスありがとうございます。
Windows以外で７Zipすれば良いのですか？
開発環境はWindowsなのにですか？
あと、Windows以外の環境がありません・・・。
（Win2000です）

＞184
ありがとうございます。
jargってproGuardよりもコンパクトになるんですか？
後で試してみます。

でも、出来るなら、クラスファイルの圧縮（→jargやproGuard）以外にも、圧縮できる方法を探しています。

186:デフォルトの名無しさん
08/04/25 13:46:07
>>185
コード自体の見直し

187:デフォルトの名無しさん
08/04/25 14:42:24
>186
ありがとうございます。

もちろん、コード自体の見直しも行います。
（ちなみに現在でも、プリプロを使って定数を数値に置き換え等はやっています）
が、さらに小さくする為に7zipでの再圧縮のやり方が知りたいのです。

188:デフォルトの名無しさん
08/04/25 15:08:42
>>182
ZIP形式で圧縮してる？
コマンドライン版なら -tzip を指定。

189:デフォルトの名無しさん
08/04/25 15:26:17
>188
ありがとうございます。

圧縮形式はZIPを指定しました。
ちなみに、7Zipツールの設定は、
書庫形式：ZIP
圧縮レベル：最高
圧縮メソッド：Defalt
辞書サイズ：32KB
語長：32
となっておりました。

何か間違っていますでしょうか？

190:デフォルトの名無しさん
08/04/25 15:42:51
レベル：超圧縮
語長：256
とか

191:デフォルトの名無しさん
08/04/25 21:30:43
Windows上だとファイル名が大文字と小文字で区別しないからおかしなことになる

192:デフォルトの名無しさん
08/04/25 22:05:03
これマジで圧縮率良いよ。仕事で使うのなら買うのも良いかもしれない。
URLﾘﾝｸ(www.s-cradle.com)

問題はiアプリを開発しまくる企業じゃないと購入するにはちょっとお高い・・・

193:デフォルトの名無しさん
08/04/25 23:15:35
メガアプリな世の中で、もはや圧縮はべつにって感じ

194:デフォルトの名無しさん
08/04/25 23:22:04
>>192
費用対効果薄すぎw
jarを30kに収める時代は終わったのだよ

195:デフォルトの名無しさん
08/04/26 00:14:51
質問なのですが、
Eclipse+Dojaで自分で作成したクラスをまとめて
オリジナルのクラスライブラリ（jarファイル）として、
次回作るアプリに組み込みたいと考えています。

Doja用のクラスライブラリをEclipse上で作成するには
どのようにすればよいのでしょうか？

次ページ