CLDC+MIDP+携帯電話用Javaスレッド part 8

1 名前：デフォルトの名無しさん [2008/03/20(木) 21:43:54 ] J2ME CLDC+MIDPベースの携帯電話用Java(主にEZアプリ、Vアプリ）に関するスレッドです。 質問でも議論でも何でもこい、と。質問は公式資料をよく読んでからにしましょう。 前スレ： CLDC+MIDP+携帯電話用Javaスレッド part 7 pc11.2ch.net/test/read.cgi/tech/1180010672/ 過去スレ 携帯JAVAのスレッド pc2.2ch.net/test/read.cgi/tech/1011977260/(DAT落ち) CLDC+MIDP+携帯電話用Javaスレッド part 2 pc5.2ch.net/test/read.cgi/tech/1070858996/ CLDC+MIDP+携帯電話用Javaスレッド part 3 pc5.2ch.net/test/read.cgi/tech/1091798483/ CLDC+MIDP+携帯電話用Javaスレッド part 4 pc8.2ch.net/test/read.cgi/tech/1108781476/ CLDC+MIDP+携帯電話用Javaスレッド part 5 pc8.2ch.net/test/read.cgi/tech/1132493827/ CLDC+MIDP+携帯電話用Javaスレッド part 6 pc11.2ch.net/test/read.cgi/tech/1155174514/ -- Java一般に関しては： 【初心者】Java質問･相談スレッド113【大歓迎】 pc11.2ch.net/test/read.cgi/tech/1204363011/ NTT DoCoMoのiモード携帯電話用Java(iアプリ)については： iモード携帯電話用Java(iアプリ) Part16 pc11.2ch.net/test/read.cgi/tech/1198816379/ >>2-5あたりにリンク集･;(`ε()ﾞ 357 名前：デフォルトの名無しさん mailto:sage [2008/06/30(月) 20:51:44 ] S!アプリを作っているのですが、703SHにてOutOfErrorが出てしまいます。 OutOfErrorなのでリソースを削るのが定石だと思うのですが、 実機でRuntime#freeMemory()とRuntime#totalMemory()を使ってメモリ状況をモニタリングしていると、 突然freeMemory()が増える(使用メモリが減る)タイミングがあります。 起動時に大きくリソースを読み込み、4MBのヒープの3.7MB前後をしばらく推移し、 その状態でリソースを読み替えの場面を行き来するとOutOfErrorが起きやすいのですが、 freeMemory()が増えたあとは2Mあたりを推移し、上記場面でのOutOfErrorは今現在発生していません。 freeMemory()が増えるタイミングまちまちで、大きくリソースを読み込んだ後1・2分程放置することで基本的になります。 この時に起きているであろう解放を明示的に起こす方法はありますでしょうか？ 読み込み時は1ファイル毎にSystem.gc()を読んでおりますが、効果はありませんでした。 MEXA Emulator及び905SHでは、大きくリソースを読み込んだ後から既に2Mあたりを推移すると言う状況です。 何かご存知でありましたらご教授をお願い致します。 358 名前：357 mailto:sage [2008/06/30(月) 21:01:04 ] MicroEdition-Profile: MIDP-2.0 MicroEdition-Configuration: CLDC-1.1 MIDxlet-API: JSCL-1.2.2 を対象に開発を行っています。 他不足情報があるかもしれませんが、恐れ入りますがよろしくお願い致します。 359 名前：デフォルトの名無しさん mailto:sage [2008/06/30(月) 21:45:58 ] GCの実装の問題だからどうしようもないと思うんだけど。 リソースのサイズ減らすしかないんじゃない？ 360 名前：デフォルトの名無しさん mailto:sage [2008/06/30(月) 22:39:31 ] んだね あとは自分の実装を見直してみること gc呼んでも全く効果なしなら別に原因があるとも考えられる 361 名前：デフォルトの名無しさん mailto:sage [2008/07/01(火) 19:58:59 ] 1ファイル毎など生ぬるい。毎フレームだ。 362 名前：デフォルトの名無しさん mailto:sage [2008/07/01(火) 23:29:12 ] そんなことしてもだいたいキューに溜められるだけなんだが 363 名前：デフォルトの名無しさん mailto:sage [2008/07/02(水) 01:16:07 ] 何作ってるか知らんが一度に数メガ単位のリソース読むなんて非常識 364 名前：デフォルトの名無しさん mailto:sage [2008/07/04(金) 18:08:24 ] 待ち受けとかノベル系のアプリ作っててふと思ったのですが、長時間キー操作がないとアプリの処理速度って遅くなりません？ で、関係ないキーとか押してみるとまた速度が元に戻る…の繰り返し。 これを解決するには一定時間ごとにアプリ側に制御を渡すような処理が必要なんでしょうか？ 365 名前：デフォルトの名無しさん mailto:sage [2008/07/04(金) 18:52:38 ] 電池馬鹿食いの待ち受けになりそうだなｗ 366 名前：デフォルトの名無しさん mailto:sage [2008/07/04(金) 18:58:05 ] ノベルゲームってキー待ちじゃないの 入力がない間に処理が遅くなるってわかるの？ 367 名前：デフォルトの名無しさん mailto:sage [2008/07/04(金) 20:06:12 ] >>366 キャラがアニメーションしてるとかじゃねーの？ 368 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 03:09:14 ] 携帯電話の本質から考えると当然の仕様じゃないかと思う 参考までに現行の一般的な携帯の初期設定だと、 数十秒操作がないとバックライトも消えて低電力モードに移る しかし勝手アプリでその辺りの制御をできるとは考えにくい 素人に電池馬鹿食いアプリ作られて困るのは各キャリアだからね 369 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 03:52:47 ] ？ バックライトの制御くらい普通にできるんじゃないの？ 370 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 14:21:04 ] 実装はどうあれ、10ms以上ならsleep()入れてくれさえすりゃいいんだが なんでループぶん回すかな、みんな… 371 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 15:12:59 ] >>369 バックライトやバイブの制御などは簡単に出来るのですが、それでアプリ側に処理を移したつもりでも、描画速度がガタ落ちしてるんですよね。 ループで延々と描画を続けるアプリはみんなこんな感じなのかな… 372 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 15:36:58 ] >>371 繰り返す処理の内容にもよるから一概には言えない 373 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 22:43:00 ] 可変FPSにして余った分sleepしてる 374 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 01:24:40 ] >>369 少し言い方悪かったね 分かりやすく言うとCPUの省電力動作の移行に関する操作までは できないということ でも省電力移行する程の期間で出力が必要な実装なんて 個人的にはあまり聞いたことが無い 375 名前：371 mailto:sage [2008/07/06(日) 14:30:40 ] >>372 シューティングゲームを作っているんですが、whileでぶん回しながら 自機、敵機の描画し、Thread.sleep(50)でウェイトをかけています。 通常ゲーム中のキー操作がある場合は速度が遅くなる事はないのですが、 ステージ間のアニメーション(敵機が決められた軌道上をスクロールする) が長い箇所の場合20秒程あるんです。 要するにユーザがキー操作をせず描画処理だけが続く時間が最大20秒ほど あるという事です。で、この時に徐々に速度が遅くなっていき、最後らへんには 見るも無残な速度になってしまいます。 途中、関係のないキーを押下してみたりしてアプリ側に処理が移ると速度が 元に戻ります。 376 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 16:21:38 ] >>375 上の人も言ってるけど ユーザビリティ的に考慮する必要は無いと思うよ 携帯のゲームやったことあるなら分かるでそ？ 377 名前：371 mailto:sage [2008/07/06(日) 18:09:29 ] >>376 なるほど…。 という事は勝手アプリを作る上で、数十秒程度のアニメーションは難しいという事ですよね。 色々ありがとうございました！ 378 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 18:35:42 ] 軽いモーションならまだしも、数十秒もあるアニメーションならムービーにして再生したほうが早いんじゃねえの 379 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 21:58:33 ] >>376 携帯使うときって基本バックライトが消えそうになったら 適当なキーを押すという使い方が一般的だからな もちろんマニアックな設定をしてる人以外で 380 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 22:41:13 ] しかしそう考えると、ゲーム開始前で決定キーの 入力待ちの状態とかってあるじゃん。 アクションゲームとかそこでデモっぽいのが 流れてたりするけど、あれも放置してると速度が 遅くなるって事なのかな？ あんま携帯ゲームしないからよく分からないや。 381 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 23:28:39 ] 携帯ゲーの場合デモ自体流さないな。 容量の関係とかで。 せいぜいタイトルで選択アイコンが点滅かアニメするだけ。 382 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 01:48:57 ] 色々試してみたらdoja端末だとバックライトが消えても処理は重くならず OAP端末だと暫く待つと重くなる。適当なﾌﾘｰｱﾌﾟﾘをDLしてみても同じく。 特にRPGで常に手足がてくてくなってるｱﾌﾟﾘを見てたら明らかに手足の 速度が遅くなってﾜﾛﾀ(笑) まぁ機種による可能性大だが…。 383 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 11:06:56 ] >>371 ガベージコレクションを自動的な発生に任せていると重くなる事があるけど、それかな？ 適当な所でSystem.gc()してみ？ 384 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 11:09:12 ] BREWは動作遅くなるのが仕様 Docomo、Softbankならおかしい 385 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 11:46:57 ] AOPはJBlend on BREWだからなぁ 386 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 13:18:42 ] 本当にBREWはビチ糞だな。 387 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 13:20:56 ] 個人的にはゲリじゃなくて便秘の方かな。 388 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 19:16:54 ] System.gc();は毎フレームやれってばっちゃが言ってた。 東芝の場合はしらんって怒られました 389 名前：デフォルトの名無しさん mailto:sage [2008/07/08(火) 21:55:08 ] softbankで　famiJSCL　使ってる人に質問 rom　の内部読み込みはうまくいくけど 外部読み込みで「romの読み込みに失敗しました」 となります 対処法をご存知の方お願いします 390 名前：389 mailto:sage [2008/07/08(火) 23:14:52 ] ちなみにMEXA_EMULATORのコンソールには 起動エラー: java.lang.SecurityException: com.j_phone.io.Connector.StorageConnection.read was denied と表示されます 391 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 00:17:44 ] famiJSCLって何？ Trustedでインストールしてないとか？ 392 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 00:43:52 ] ググったけどスレ違いすぎる 393 名前：389 mailto:sage [2008/07/09(水) 01:18:36 ] やはりここもスレ違いでしたか 失礼いたしました ちなみに　Trusted　でインストールしたら無事起動しましたが 実機ではやはりエラーが出ます 394 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 15:45:08 ] >famiJSCL www.geocities.jp/v904shmania/#famiJSCL --- 引用 ファミコン＆ディスクシステムえみゅ 395 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 18:45:20 ] スレ違いで悪いけど、famiJSCLやゲームギアのって音有りになってるが 音源はどうやってエミュレートしてるのか気になる spf？mmf？MIDI？ 396 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 19:25:10 ] デコンパイルしてソース読めば？ 397 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 20:01:36 ] >>396 そのつもりだったけどfamiJSCLのダウンロード先が見つからないんだ・・ 398 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 21:22:37 ] >>397 smaf-phrase "famiJSCL"でググったら最初に見付かるサイトの最後の方にzipあるよ。 399 名前：357 mailto:sage [2008/07/09(水) 22:44:49 ] 今さらですが、取り合えずはなんとかは出来ましたのでご報告致します。 エミュや実機の動作の差分を見ていたところ、 703SHではゲーム用インナーのコンストラクタに入るところで急激に増えていました。 このクラスのメンバには一番多く変数が定義されており、 コピーコンストラクタで変数を大量に生成した後には703SHでは増えている感じでした (エミュ・905SH・813SHでは約900KBに対し703SHでは約2MB)。 コンストラクタに入ったときにGCを呼んでも解放されなかったため、 　new byte[Runtime.getRuntime().freeMemory()] を2回呼ぶことで空きメモリが必要である事を主張し解放を促しました。 これにより前記の領域を解放させることが出来ました。 タイミングによってはOutOfMemoryErrorが出るので、安全策として、 ここの部分でのみErrorをcatchしています。 Errorの性質上、かなり気持ち悪い実装となりましたが、 現状ではこの方法で回避するとこが出来ました。 400 名前：357 mailto:sage [2008/07/09(水) 22:45:46 ] >>359 そのGCの実装の差異を何とか吸収出来る様なテクニックがあればと思いまして。。。 >>360 GCで解放されているものもあり、全く効果が無いわけではありませんでした。 ただ、もっと解放して欲しい領域には及んではくれませんでしたが。 >>361 1フレームに1ファイル読み込んでGCを呼んでおります。 >>363 リソース自体は300K程度で、 SH問題で動的なものもあり、 起動時に読み込むのは200K程です。 と言うわけで、怒鳴られてしまいそうな実装ですが、一応解決したました。 どうもありがとうございました。 401 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 22:55:18 ] (´∀`)　 ｽﾊﾟｰﾝ! 　　 ⊂彡☆)´Д`)っ>>399 402 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 01:21:06 ] この流れでエミュエミュ言うから、うぜぇと思たら… でもこれは駄目だろ 703shの実装以前に、何かが決定的に間違ってるはず 何がどれだけメモリを食ってるのかちゃんと調べたのか？ 403 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 09:52:43 ] 循環参照でもして、メモリーリークしてるんじゃね？ 404 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 10:39:35 ] いくらなんでも弱参照カウンタくらい実装してるだろVMが。 マーク&スイープだったりするぞ。 405 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 11:05:35 ] バグでガベコレがうまく働かない機種があったけど それが703shだったかは忘れてしまった 406 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 16:57:14 ] >>404 いまどきの、コンパクションすら行わない速度だけを求めた糞VMが、そんなことしてるかね？ アプリが終了するときはしっかりやってそうだが。 407 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 00:39:41 ] S!アプリのJSCL-1.1.x以降はメモリコンパクションをサポートしているらしいが？ 408 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 01:01:31 ] >>357はキャンバススレッドにベターッと全てを実装してたりしてなｗｗｗ 409 名前：400 mailto:sage [2008/07/11(金) 01:12:44 ] >>402 自分のコードに絶対的な自信を持っているわけではありませんが、 ただ、元々Dojaからの移植でDoja版は問題なく動作をしており、 納品済みで公開されております。 Softbank版ではクライアントの方でチェックされている中で703SHのみ OutOfMemoryErrorが出ると言う報告のものでありました。 なので、元のコード自体に決定的な間違いがあるとは思い難いと思っています。 最も、メモリ容量の推移についてを先方にチェックしてもらっているわけではないので、 報告が無いことが703SHと同様の動作をしてないことと等価では無いとも思いますが。 703SHは一旦の対応で返却してしまったため、次の機会に"何"が"どれだけ" 食っているかを調べたいと思います。 今回は大幅に増えるタイミングタイミングがメンバ変数の初期化子しか 無い状態だったので、また対応の時間もあまり無く、深く追うことができませんでした。 >>403 メンバ変数はint等の値型の多次元配列がほとんどで、 メンバに参照を保持するようなメンバは持っていません。 また、メンバ変数の配列はコンストラクタ等で生成した後は解放しないで、 新たに作ることなく使いまわしているので、リークしそうなものがほとんど無い状態です。 410 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 01:27:17 ] J2MEで巨大な多次元配列とな 411 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 11:51:06 ] いまどきのKVMならコンパクション実装してるぞ。 412 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 13:21:42 ] >>411 そうなの？ 少なくともDoCoMoは昔は実装してたのに、901あたりから一切コンパクションしなくなった 速さ優先のもよう 413 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 18:03:36 ] >>412 むしろP900、N900はコンパクション無いことが明記されているよ。 普通に組んでたら断片化を起こしているはずだし、 最近の物はほとんどコンパクションに対応してると思うよ ttp://www.nttdocomo.co.jp/binary/pdf/service/imode/make/content/iappli/caution/n900is_iappli_notes_ver1.pdf ttp://www.nttdocomo.co.jp/binary/pdf/service/imode/make/content/iappli/caution/p900iv_iappli_notes_ver1.pdf 414 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 19:30:29 ] 聞きかじった情報を信じるほど怖いことはない 415 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 21:17:14 ] >>409 プロならカバレッジ取るなりしてちょっとは自分で考えろ たかが数100kのソースコードだろ 416 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 20:25:32 ] >>413 明記されてんのは知ってるよｗ だが901か902からは全社コンパクション未対応だよ FPS60出す化け物携帯にコンパクションなんて対応してねーっての メモリー潤沢だからコンパクションが必要な場面はほとんどないけどな 417 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 22:32:34 ] >>416 ソースは？ 60FPSってどのアプリよ SHの画像メモリはちゃんとコンパクション されているみたいだが 418 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 22:59:45 ] どっちが本当かは知らんけど、ドコモの902以降だったらマリオくらいだと60FPS出せるね 419 名前：デフォルトの名無しさん mailto:sage [2008/07/13(日) 04:59:11 ] コンパクションするかどうかは、プログラムを組んで確認してみればわかること。 420 名前：デフォルトの名無しさん mailto:sage [2008/07/13(日) 06:07:08 ] コンパクションしてるかってどうやって検証すんの？ 421 名前：デフォルトの名無しさん mailto:sage [2008/07/13(日) 09:43:08 ] 1M 10KB 1M 10LB 422 名前：デフォルトの名無しさん mailto:sage [2008/07/13(日) 09:43:38 ] 1Ｍ　10ＫＢ　1Ｍ　10ＫＢ って確保してうめうくしたあと、ＧＣして、その後2Ｍとろうとしてみればいいんじゃね？ 423 名前：デフォルトの名無しさん mailto:sage [2008/07/15(火) 03:04:56 ] ■■■■■■■■　　　■=new int[1048576/4] ■□■□■□■□　　　□=null System.gc() new int[2097152/4] 424 名前：デフォルトの名無しさん mailto:sage [2008/07/16(水) 03:15:57 ] なるほと理解した 425 名前：デフォルトの名無しさん mailto:sage [2008/07/17(木) 01:56:42 ] ろれつが回らない口調が流行ってるのか？ 426 名前：デフォルトの名無しさん mailto:sage [2008/07/17(木) 02:48:40 ] 解放しちゃらめぇ〜 427 名前：デフォルトの名無しさん [2008/07/17(木) 08:09:58 ] はーいたらちゃんです 428 名前：デフォルトの名無しさん mailto:sage [2008/07/17(木) 22:43:45 ] プログラマーは赤ちゃん返り 429 名前：デフォルトの名無しさん [2008/07/19(土) 11:18:15 ] 現在、ソケット通信を行うS!アプリを作成中です。 エミュレーターでは動作しサーバープログラムと通信できるのですが、 実機（921SH）では下記の記述部分でSecurityExceptionが発生してしまいます。 Connector.open("socket://[IPアドレス]:[ポート番号]"); jadファイルとMANIFESTファイルには MIDlet-Permissions: javax.microedition.io.Connector.socket と記述しています。 エラーの内容は javax.microedition.io.Connector.socket was denied です。 原因をご存知であれば、ご教授お願い致します。 430 名前：デフォルトの名無しさん mailto:sage [2008/07/19(土) 12:57:23 ] >>429 Socketアクセス出来ればメールも詐称しまくり送りまくりだよねえ。 フリーソフトにマルウェアとして仕込めば自分の手を汚さずに。 431 名前：デフォルトの名無しさん mailto:mmm [2008/07/19(土) 13:52:14 ] socket通信はできないんですか？ 432 名前：デフォルトの名無しさん mailto:sage [2008/07/19(土) 13:52:41 ] >>430 なぜわかった？w 433 名前：デフォルトの名無しさん mailto:sage [2008/07/19(土) 13:53:52 ] >>431 そういうことをやりたいならS!なんて忘れることだ。 434 名前：デフォルトの名無しさん [2008/07/19(土) 13:59:36 ] k-tai.impress.co.jp/cda/article/news_toppage/36823.html これはどういう意味なんでしょうか？ 435 名前：デフォルトの名無しさん mailto:sage [2008/07/19(土) 22:18:58 ] TCP/IP直叩き出来るようになる。 436 名前：デフォルトの名無しさん mailto:sage [2008/07/19(土) 22:42:22 ] 許された人達には 437 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 00:02:57 ] >>432 お前みたいなヒヨッコがクラッカー気取りで変なもの組もうとするから 規制がアホみたいに厳しくなるのですよ 438 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 09:35:52 ] >>436 あまりにもアレすぎて、ほとんどの人たちは許されませんでした 439 名前：デフォルトの名無しさん mailto:sage [2008/07/21(月) 00:43:40 ] 一部の公認アプリのみがsocket通信可能ということですか？ 440 名前：デフォルトの名無しさん mailto:sage [2008/07/21(月) 02:36:48 ] >>437 もともと禁止されていたんです。 私のせいで規制されたような言い方はやめてくださいw 441 名前：デフォルトの名無しさん mailto:sage [2008/07/21(月) 02:43:50 ] >>439 こんなところで質問する暇があるなら職場の先輩にでも聞くといい 442 名前：デフォルトの名無しさん mailto:sage [2008/07/21(月) 15:34:16 ] ググれカスで十分だ 443 名前：デフォルトの名無しさん mailto:sage [2008/07/22(火) 00:41:55 ] socket通信？仕様書も読めないのか？ 日本語とgoogleの使い方から勉強しろよ。 444 名前：デフォルトの名無しさん mailto:sage [2008/07/22(火) 01:19:17 ] ググれカスがわからないからgooできいてきました 445 名前：デフォルトの名無しさん mailto:sage [2008/07/22(火) 19:19:31 ] ｸﾏｰ!! 446 名前：デフォルトの名無しさん [2008/07/22(火) 21:06:19 ] TextSS 447 名前：デフォルトの名無しさん mailto:sage [2008/07/22(火) 21:12:17 ] >>439 　そういうことです。 sに相談してくださいな 448 名前：デフォルトの名無しさん mailto:sage [2008/07/23(水) 15:05:59 ] Softbank端末で、S!アプリからモーションコントロールセンサーを使いたいと思って調べてみたんだが、 そのAPIに対応している端末が904SHしか見当たらない。 センサーそのものは搭載していても、MEXA経由でアプリにインターフェース公開しているのが 904SHだけしかないって理解でOKですか？ だとしたらなんとも残念だ。 449 名前：デフォルトの名無しさん mailto:sage [2008/07/24(木) 11:51:26 ] >>そのAPIに対応している端末が904SHしか見当たらない。 センサーそのものを搭載している端末で出来なかったの？ どういう情報で"見当たらな"かったのだろうか 450 名前：デフォルトの名無しさん mailto:sage [2008/07/24(木) 15:38:32 ] >>449 Softbank開発者向けのサイトMobile Creation（ttp://creation.mb.softbank.jp/）で 「端末情報 MIDP2.0対応端末編 PartXX」のPDF資料を一通りさらったんだけど 「モーションコントロール対応可否」という項目が×ばかりだった。 たとえばセンサーは確かに搭載されているはずの921SHでも×になってた。 451 名前：デフォルトの名無しさん [2008/07/28(月) 23:17:52 ] MEXAエミュレータでソフトキーを押すと、keyPressのほうにも通知がくるのはバグ？ 452 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 09:31:32 ] >>451 バグではないよ。 ただ、実機だと端末によってキーコードが違うんじゃなかったっけ？ 453 名前：デフォルトの名無しさん mailto:sage [2008/07/30(水) 01:38:10 ] 違うよ 454 名前：デフォルトの名無しさん [2008/07/30(水) 10:51:15 ] iアプリのcom.nttdocomo.util.Phoneにあたる機能って S!アプリにはないんですか？ USIMのIDが取得したいんですけど。 455 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 22:35:05 ] >>454 無い。 というかDojaだってUSIMのIDなんて取れない。 456 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 23:59:45 ] そのものじゃないけど、それに準じた固有IDは取れるじゃん。 457 名前：デフォルトの名無しさん mailto:sage [2008/08/01(金) 21:30:18 ] 準じとらん。 USIMのIDと端末のIDじゃ根本的に別物だろう。紐付くわけでもなし。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef