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

iモード携帯電話用Jav ..

533:デフォルトの名無しさん
07/11/07 22:19:43
docomoのオフィシャルサイトからの情報だけど？

URLﾘﾝｸ(www.nttdocomo.co.jp)
URLﾘﾝｸ(www.nttdocomo.co.jp)
URLﾘﾝｸ(www.nttdocomo.co.jp)
上記以外は自分でurl調べてサイトの方みてくれ
全部メガiアプリになってるから

534:デフォルトの名無しさん
07/11/07 22:24:31
ちなみにL704iはDoJa-3.5LEだが500Kアプリと記載されてるので
実際の500K(500K以内であればJARとスクラッチパッドのサイズ比は自由)アプリか100+400Kアプリかどうかは判別できない

535:デフォルトの名無しさん
07/11/07 23:38:16
ちょっと前に、start()での無限ループ+processEvent()は実装依存と言
う話がありましたが、仕様を満たすには、start()のメインループ部分を
別スレッドにしちゃうとかで解決できるんでしょうか?

この場合、IApplicationにRunnableを実装して、run()にメインループを押
し込んじゃえばいいんでしょうか?

Canvasを使うの初めてなんで、どうせ創るなら仕様を満足した方がいい
かと思って。

536:デフォルトの名無しさん
07/11/08 00:29:14
>>498
個人的考えだけど、携帯Javaは今後携帯電話向けFLASH+AS3かFLASH+AIRの
つなぎとして生きて消えていくしかないよ

ドコモも「共通仕様? 利益にならんでしょ」と言っちゃう会社だしな
サンは知らんが、当のドコモはもうやる気ないだろうし、アプリ関係はアドビに任せたいだろ
BREWの進化の早さっぷり見てれば、数社で独自仕様をさっさと進化させて
金に換えれる方がいいじゃないか。MIDPの停滞ぷりをみよ

537:デフォルトの名無しさん
07/11/08 01:02:56
doja5.0で一部のアプリ実行時にwindowsがエラーを吐いて実行できないようになった

resフォルダにでかい画像ファイルなんかを入れて再コンパイル
ソースを適当に組み替えて再コンパイル
のどちらかの方法で一応実行できる様にはなる

どうやら最近あったwindowsアップデートの影響らしいんだけど
皆はどうですか？

538:デフォルトの名無しさん
07/11/08 03:04:42
　　∩＿＿＿∩　　　　　　　　｜
　　 | ノ＼　　　　ヽ　　　　　　　|
　　/　　●゛　　● |　　　　　　　|
　 |　∪　　( _●_)　ミ　　　　　　j
　彡､　　　|∪|　　 |　　　　　　Ｊ
/　　　　 ∩ノ ⊃　ヽ　　　　>>536
(　＼　／＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼／＿＿＿／

539:デフォルトの名無しさん
07/11/08 03:07:18
どう見ても釣りだな
でなければかなり偏ってる
いずれにしろ参考にならない

540:デフォルトの名無しさん
07/11/08 10:05:09
なあ、ゲームとかの画像とか音楽データとか挿入動画みたいのをSDに入れてそれを再生するってできんの？
Bindingにしかアクセスできないんだけど調査不足？それとも気のせい？
全部をダウンロードさせるのって結構面倒なんだけど

541:デフォルトの名無しさん
07/11/08 12:47:19
エスパーきぼんぬっすか

542:デフォルトの名無しさん
07/11/08 13:25:42
>>501
前スレをみて少しやり方を変えたら問題が解決しました。
ありがとうございました。

543:デフォルトの名無しさん
07/11/08 14:08:53
DoCoMoから落とせる5.Xコンテンツ開発ガイドに、
９０５はdoja５．１って書いてあるな。

これが公式発表みたいなもんかね。

544:デフォルトの名無しさん
07/11/08 19:19:00
N904i について聞きたいのですが、この機種、私が試した範囲ではSystem.gc()してもメモリーを一切解放してくれません
しかもそのまま使いつづけていくと劇的に処理速度が低下していき、FPS60なんて保ってられず・・・
みなさんどのように対策してますか？

同じアプリでもN903iやF903iは問題なく開放されました

・開放されてない
System.getRuntime().getFreeMemory() で空きを調査して、空きが増えることは一切なく減る一方
String str = "ほげ";
str = null;
System.gc();
をループさせるだけでも、どんどん"ほげ"がメモリーリーク（と呼んでもいいかも）していきメモリーがガンガン減っていく

・ループ
IApplicationのstart()内で無限ループしている状態

545:ｆｒ
07/11/08 19:20:26
携帯裏アプリ
ポケモンが熱い
URLﾘﾝｸ(62.xmbs.jp)

546:デフォルトの名無しさん
07/11/08 19:59:15
>>544
そもそも、文字列リテラルの代入だけではピープは消費しない
携帯でなくても、Java SEで試せばわかる
それなのにピープの空き容量が変わるということは、どこか別のところに問題がある

やるならこう
String str = new String("ほげ");

547:デフォルトの名無しさん
07/11/08 20:29:06
>>546
ごめん、思い出しながらコード書いたもので間違えた
とりあえず、newしたものをnullいれて、System.gc()しても空きメモリーが回復しないのは確かでした

他携帯なら問題なかった（903だけではなく、いろんな901や902でも試した）ので、コードに問題があるとはあまり思えないところです

548:デフォルトの名無しさん
07/11/08 21:23:24
すまんがピープﾜﾛﾀ

549:デフォルトの名無しさん
07/11/08 21:24:52
>>546
何を覗くんだ？

550:デフォルトの名無しさん
07/11/08 21:30:15
>544
System.gc()のあとにThread.sleep()入れても意味ないかな。わからんが。

どうにもならなかったら
高速性を要求されるところでは、なるべくメモリを動的に確保しないようにする
で対策なのかな。（対策って言うんかこれ）

551:デフォルトの名無しさん
07/11/08 22:25:11
>>550
問題は、高速性を要求されなくなったから「さあ溜まってたゴミを捨てようか」と思っても捨てられないこと
N904に正式に対応する場合、起動時に全て静的にとるなんていう馬鹿コードになる可能性が・・・

552:デフォルトの名無しさん
07/11/08 22:34:21
>>551
FPS60がどのくらいまで落ち込むの？止まるの？

553:デフォルトの名無しさん
07/11/08 22:53:55
数分で、FPS20くらいまではとりあえず落ちましたね
はっきりいってボロボロです

耐久テストしてるので明日また報告します

554:デフォルトの名無しさん
07/11/08 22:56:07
スタックが一つポップされるまで回収対象にならないとか

555:デフォルトの名無しさん
07/11/08 23:40:24
fpsを数字の前に持ってくるな。気持ち悪い。

556:デフォルトの名無しさん
07/11/08 23:48:06
>>544
その機種が壊れてるんだよ
初期出荷の携帯はシステムにバグが多い
アップデートする必要があるかもしれないからＤＳに聞いてみるといい

557:デフォルトの名無しさん
07/11/09 00:19:10
>>556
その可能性もありますね
OSアップデートで修正される（初期出荷時には間に合わなかった？）かもと
正直こんな仕様じゃ、既存リリースのアプリが何一つまともに動きませんからね

・Thread.sleepを入れてみる
・IApplication#start()の中で無限ループするのをやめてみる
・OSをアップデートしてみる

明日これらを試してみますが、他にもアイデアがあればよろしくお願いします

558:デフォルトの名無しさん
07/11/09 01:35:08
>>554に1票

559:デフォルトの名無しさん
07/11/09 09:19:34
原因わかりました
メモリー量を画面に表示していたのですが、その際
g = img.getGraphics();
g.drawString(略);
g.dispose();

を行なっており、原因はこれです
N904iはgetGraphicsしたGraphicsを、きちんとdisposeしてもリークさせるようです
解決策としては一度作ったGraphicsは生成しなおさないということになりますが、複数持ちたい場合困りますね・・・

560:デフォルトの名無しさん
07/11/10 12:10:00
N904i使いだけどこの機種フリーズ、再起動、電源落ちは当たり前
絶対バグありまくりだよ

561:デフォルトの名無しさん
07/11/10 13:37:10
交換しろよ
そんな症状は出ない

562:デフォルトの名無しさん
07/11/10 14:39:00
>>559
imgも一緒に開放(dispose)してもリークする？

563:デフォルトの名無しさん
07/11/10 20:15:58
iチャネルに関すると思われるエラーが最近多い
長く使うと携帯は壊れるものなのかもしれない

564:デフォルトの名無しさん
07/11/10 23:31:42
bitrotかも。

565:クリフト
07/11/12 14:08:21
Doja4.1でD800iDS用のタッチパネル式アプリを作成しています。
タッチアクションの処理をボタンの長押しにするには下のソースコードをどう変形すればよいでしょうか？

// タッチアクションの処理
public final void touchControlAction (TouchControl source, int type, int x, int y) {
// Rightボタンの押下
if (source == rightButton && type == TouchControlListener.CLICKED) {
i++;

566:デフォルトの名無しさん
07/11/12 14:14:55
>>565
使ったこと無いけどメインループ作れって事で。

if( source == rightButton ) {
bRight = type == TouchControlListener.CLICKED;
}

メインループ
if( bRight ) {
i++;
}

567:クリフト
07/11/12 18:42:51
>>566
ありがとうございます。
うまくいきませんね。もうチョイがんばってみます。

568:デフォルトの名無しさん
07/11/12 19:40:41
>>567
うまくいかないって touchControlAction の中に
ループ作ってるってオチじゃないよな？

569:デフォルトの名無しさん
07/11/12 19:57:52
(PC不可)
URLﾘﾝｸ(polpe.com?g=12jfasd345sdf)<)
URLﾘﾝｸ(polpe.com?g=4h6d54h64h6sr)<)

570:デフォルトの名無しさん
07/11/13 01:22:29
携帯Javaアプリやってるわけではないのですが、皆さんに質問。

携帯Javaの利点ってなんでしょう？私も組み込みプログラマ
の端くれでCでitronやLinuxで開発しています。で、結構
速度の要求だけは顧客から来るので、省メモリコピーなどに
腐心していて、C++ですら使いたくても使えないような状況なんです。

組み込みJavaの利点って、汎用のフレームワークがあるから
という、単なるプラットフォームの問題だけなのかな？
だとしたら、ソフトバンクやGoogleなんかが提唱しようとしている、
OpenKODE(OpenGL/ES)ベースのプラットフォームが、無償で提供されて、
高速だったりすると、そっちのほうがよかったりするのかな。

素朴な疑問です。

571:デフォルトの名無しさん
07/11/13 01:32:58
誤爆ですよね
スレ一覧よく見てください

572:デフォルトの名無しさん
07/11/13 02:01:40
>>570
int foo[5];　みたいな配列で　foo[10]=8;　とかやったらどうなるかって事

573:デフォルトの名無しさん
07/11/13 03:11:04
>>571
そんなにスレ違いとも、おもわないんだが。

574:デフォルトの名無しさん
07/11/13 04:30:34
Javaをよく知らなくて>1が分からなかったのなら仕方がない

575:デフォルトの名無しさん
07/11/13 07:58:14
>>570
Javaにどんだけ利点があろうがなかろうがウンコだろうがiMODEで商売しようと思ったら
Java使うしかないんです＞＜
汎用フレームワークがあるっていうかそれしかないっていうか

576:デフォルトの名無しさん
07/11/13 09:20:44
本物の技術者なら、目の前のオモチャで遊ばないなんて。
面白いぞ、たとえ実用性は二の次でも。

577:デフォルトの名無しさん
07/11/13 09:42:22
>>570
そんな現状動かないものを考慮してもしょうがない
携帯アプリを作る選択肢が携帯JavaかFlashかJSしかない
ただそれだけ

578:デフォルトの名無しさん
07/11/13 11:15:11
速度か速かろうと遅かろうと、ユーザーにとっては面白ければなんでもいいわけで。

579:デフォルトの名無しさん
07/11/13 13:00:03
よくマジレスするなと感心させられますｗ

580:デフォルトの名無しさん
07/11/13 15:29:39
>>570
セキュリティを管理するOS が無かった昔の携帯電話で、
セキュリティの問題なくアプリを動かすには
　(a) Java 等のサンドボックスで守る方式
　(b) BREW等の検証済みの公式アプリしか使わせない方式
のどっちかが必要だったわけです。
いまでも実際には似たようなもんで、ネイティブコードのアプリを実行
できる式の携帯電話は大抵ハックされてるよね。

581:デフォルトの名無しさん
07/11/13 20:13:46
>>577
GoogleのアンドロイドSDKが公開されましたね。
URLﾘﾝｸ(code.google.com)

予想通りOpenGL/ES採用しているっぽい。JavaのVM(Dalvik)が、
OpenGL/ESと並列で並べられているということは、携帯Java
を追い落とそうという意志が感じられないでもない。

582:デフォルトの名無しさん
07/11/13 20:23:33
移植ﾒﾝﾄﾞｸｾｰんだから余計なもん増やすなよ検閲エンジン

583:デフォルトの名無しさん
07/11/13 20:33:36
スレ違いはそろそろしんでください＾＾；

584:デフォルトの名無しさん
07/11/13 21:29:26
>>570
適当に作っても平気なのはかなりのメリットだな。
javaもC/C++に比べれば全然簡単だし、
学生が遊び感覚で作れるのはいいとおもう。

585:デフォルトの名無しさん
07/11/13 21:39:53
>>581
OpenGL/ESはドコモもすでに採用してるわけだが
JavaとOpenGL/ESを無料に関連付けて何がしたいんだろう?

586:デフォルトの名無しさん
07/11/13 21:45:11
アプリエミュでスリープ時間測定したらかなりずれたんだけど
エミュのバグでしょうか。
sleep(10)=16
sleep(20)=31
sleep(30)=31
sleep(40)=47
sleep(50)=63
sleep(60)=62
sleep(70)=78
sleep(80)=94
sleep(90)=94
sleep(100)=109
ちなみに実機だと正しくスリープしてました。

587:デフォルトの名無しさん
07/11/13 22:00:56
そーゆーもんだとおもう。
制度そんなに高く無いお

588:デフォルトの名無しさん
07/11/13 22:09:22
>>585
げっ、アンドロイドのアプリケーションフレームワーク部って
結局、全部Javaなんか・・・。

589:デフォルトの名無しさん
07/11/13 22:21:09
>>587
そーゆーもんなのか
ここまで違うとゲームの難易度に差が出て調整がしずらいな
自分の携帯はソフトバンクだから実機動作は友達に頼むしかないorz
一応実機
sleep(10)=10
sleep(20)=22
sleep(30)=31
sleep(40)=42
sleep(50)=52
sleep(60)=61
sleep(70)=71
sleep(80)=82
sleep(90)=92
sleep(100)=102

590:デフォルトの名無しさん
07/11/13 22:35:32
ドコモの携帯買おうぜ。キャリアとしてのソフトバンクって利点が少ない。
実機テストを一機種でしかしてないのにリリースするのはあんまり良くないし。

正直、ソフトバンクが人気でMNPで人が流れて行ってるのが不思議なくらい
あそこはまともじゃない企業なんだが・・・

591:デフォルトの名無しさん
07/11/14 07:44:11
>>586
Windowsのタイマーの精度が15.525msだから

592:デフォルトの名無しさん
07/11/14 10:25:28
>>589
sleepの精度は端末に依存だからちゃんと経過時間を計ってやらないとだめだよ

593:デフォルトの名無しさん
07/11/14 10:57:18
>>589
ちなみに、30kダウンロードすると約50円だから
友達無くさんようにな。

594:デフォルトの名無しさん
07/11/14 11:49:43
パケホーダイを勧めておけば

595:デフォルトの名無しさん
07/11/14 11:57:45
>>589
sleep時間が難易度に影響するような構造がそもそもおかしいんじゃ

596:デフォルトの名無しさん
07/11/14 12:44:43
キャラの移動速度を決める時や、格ゲーのコマンド入力監視みたいなのは
sleep()じゃなくてSystem.currentTimeMillis()使った方がいいってのが
以前にスレで出た気がする。

597:デフォルトの名無しさん
07/11/14 14:31:41
すいません。質問です。
byte配列に置いた文字列を随時読み込んで画面表示したいです。
Stringのコンストラクタなら文字コードも指定できて良い塩梅と思っていたら
作っているうち、newを連発しているのが気持ち悪くなってきてしまいました。

最終的にStringBufferにappendできれば良いかと考えて、byte[]をchar[]に
変換しようとしたところで詰まってまｓ。
byte[]に文字列を置いた場合は、どういう方法で変換・表示するのが格好良い？

598:デフォルトの名無しさん
07/11/14 15:26:34
>597
newを連発する意味がわからないな。
Stringのコンストラクタで文字列にしたら後はそれを保持してればいいのでは。

byte[]の中身が変化するというなら、その都度newするのは当然。
「new連発が気持ち悪い」と気にする必要はないよ。

それでも何かこだわりがあるならJava一般スレ行って聞いてみて。

599:デフォルトの名無しさん
07/11/14 16:19:38
>>598
スクラッチパッドに有る圧縮した文章を、こまめに伸張しつつ
ブックリーダ的に表示できないかな、と思っていたので、数秒
に一度は新しくStringを読んでくることになりそうです。

スレのちょっと前を読んでいたら、503iを試した時にSystem.gc()
がうまく動かないのと四月問題が嫌になってiアプリから離れた
記憶が蘇ってしまい、ちょっと疑心暗鬼気味になってしまった
ようです。
今のDoJaは大丈夫だから、どんどんnewすりゃいいじゃん、と
言われれば、本当にその通りだと思います。質問しておいて
なんですが。

600:デフォルトの名無しさん
07/11/14 16:34:24
「byteをStringに変換」って言い回ししてるけど、もしかしてStringをオブジェクトだと思ってないとか？
newがオブジェクトを確保することだと思ってないとか？

601:デフォルトの名無しさん
07/11/14 16:35:52
InputStreamReader　を使うといいんじゃない？たぶん。

602:デフォルトの名無しさん
07/11/14 16:52:26
>Stringのコンストラクタなら文字コードも指定できて
DoJaがサポートするのはSJISのみ

603:589
07/11/14 17:09:35
>>592
こんな感じでいいのかな？
long sleep1=0,sleep2=0;
int hosei=0;
wihle(true)
{
処理
int myTime=50; //50msスリープする
str.Millis=System.currentTimeMillis();
sleep1+=myTime-str.Millis+hosei;
if(sleep1>0)Thread.sleep(sleep1);
if(str.Millis-sleep2>myTime)hosei--;
if(str.Millis-sleep2<myTime)hosei++;
sleep1=sleep2=str.Millis; //現在の時間を記録
}

604:デフォルトの名無しさん
07/11/14 17:25:14
597です
InputStreamReaderとByteArrayInputStreamの組み合わせで解決したようです。
ありがとうございました。

配列をストリームとして読む発想が無かったようです。

605:デフォルトの名無しさん
07/11/14 17:27:14
>>589
いやsleep()に指定した時間分きちんとsleepすることが保障されてないわけだから
sleepがどうこうは関係なくて経過時間分の処理をする
time = 0
white(true) {
　start = System.currentTimeMillis();
　処理(移動などの処理はtime時間分の計算をする)
　time = System.currentTimeMillis() - time;
}
こんな感じ

606:デフォルトの名無しさん
07/11/14 17:28:58
>>603
アニメ処理等でなるべくきっちり合わせたいときは、ちょっと少なめにSleepしてから
ビジーループで目的時刻を待つと良いよ。

607:605
07/11/14 17:29:04
すまん…間違ったorz

time = 0
white(true) {
　start = System.currentTimeMillis();
　処理(移動などの処理はtime時間分の計算をする)
　time = System.currentTimeMillis() - start;
}

608:デフォルトの名無しさん
07/11/14 17:35:36
メインループの回転数を固定にしする方が賢いような気がするけど。
全部にtimeを掛けてたら大変だし。

609:589
07/11/14 17:39:03
>>606
ビジーループって電池食いそうで嫌だったけど
その手があったか
それで行ってみます

610:デフォルトの名無しさん
07/11/14 17:42:13
>>608
どうやって固定にするん？

611:デフォルトの名無しさん
07/11/14 17:50:11
>>610
前スレのFPS固定ロジックでいいんでないの？
sleepが嫌なら while(time > System.currentTimeMillis() ); みたいな感じで済む話だし。

座標計算だけならいいけど、sprite使ったアニメーションにまでtime掛けて管理とか、
どうしてもメインスレッドをsleepしたい場合やサスペンド対応考えると
time一個でどうにかすんのはムズいんじゃないかな。

まぁ時間で管理したほうが確実なんだけどさ。

612:デフォルトの名無しさん
07/11/14 19:35:15
>>591
げ、エミュって内部でタイマーなんて使ってんのか
System.currentTimeMillisですら16ms単位くらいで値よこすから、エミュだとデバッグしづらくなってきたんだよなぁ

ちなみに仕事では当然のようにビジーループ
「sleepにすると電池の消費が少なくなる」なんてのはP504iだけだったと記憶してる

613:589
07/11/14 20:07:29
>>612
ビジーループで時間計ったけどsleepの時と変わらなかったのは
System.currentTimeMillisでも16msだったからか

614:デフォルトの名無しさん
07/11/14 20:09:55
んなーこたーない

615:デフォルトの名無しさん
07/11/14 20:10:45
614は612のレスね

616:デフォルトの名無しさん
07/11/14 20:12:59
Vistaは1ms単位で測れるよ

617:デフォルトの名無しさん
07/11/14 20:16:10
>>613
実機でログ取るべき。
大抵は10msec単位またはもっと正確な値が取れる。

618:デフォルトの名無しさん
07/11/14 21:57:30
質問です
いままでiアプリではGIFとJPEGしか扱えないと思っていたのですが、PNGもいけるのでしょうか？
（これは実機で確かめればいいとしても）
対応画像形式一覧みたいなものをMediaImageの項などで探してみたのですが、見当たりません
どの資料かにまとまってますでしょうか？

619:デフォルトの名無しさん
07/11/14 22:33:28
Windows上でのエミュだけの問題ならtimeBeginPeriod(1)を呼ぶような
別のプロセスを立ち上げておけばいいんでない？
自分で作るのが面倒ならメディアプレイヤーで何か再生してやるとか
sleepの実装がWin32APIのSleepを呼んでるなら1ms単位になるはず

620:デフォルトの名無しさん
07/11/14 22:44:20
>618
iアプリ開発ガイド詳細編を読もう

621:デフォルトの名無しさん
07/11/14 23:28:01
>>612
　sleepにしてもバッテリ消費にはあまり影響ないのね。
描画(2D)を減らしたら消費減るのかな、とか興味があって、
1度検証してみたいとは思ってたけど結局やってないなぁ。

622:デフォルトの名無しさん
07/11/15 00:38:25
えっと、PNGは無理みたいですね
なんでいつまでたってもPNG対応しないんでしょう。SoftBank版と互換したいのに

623:デフォルトの名無しさん
07/11/15 00:46:58
いつになったら、って問題じゃないと思うよ
大人の事情だろう

624:デフォルトの名無しさん
07/11/15 00:49:03
単純にgifやjpegに変換して振り分けるのが吉

625:デフォルトの名無しさん
07/11/15 01:15:30
SoftBankがGIFを使える件

制限あるけど。

626:デフォルトの名無しさん
07/11/15 02:27:39
PNGが読み込めないのはドコモダケ

627:デフォルトの名無しさん
07/11/15 02:47:34
前すれログって読めないんすかねぇ･･･。
最初の方のフレーム制御関係を参照したかったんですが。

628:デフォルトの名無しさん
07/11/15 08:38:58
っ URLﾘﾝｸ(rag.life.coocan.jp)

629:デフォルトの名無しさん
07/11/15 09:08:29
PNGはフリーなんだから、大人の事情もなにもないと思うんだが

630:デフォルトの名無しさん
07/11/15 09:46:49
>>629
対応に関してのコストはどこから出るのでしょうか

631:デフォルトの名無しさん
07/11/15 11:38:05
630笑えるｗ

632:627
07/11/15 11:47:07
>>628
さんくすです！！

633:デフォルトの名無しさん
07/11/15 16:18:35
反論に困ったら「笑えるｗ」ｗｗｗｗ

634:デフォルトの名無しさん
07/11/15 18:45:13
>>627
過去ログ読もうとしたらよむ方法かかれてるでそ？

635:デフォルトの名無しさん
07/11/15 19:27:56
カメラが起動しようがムービープレイヤーが起動しようが
画像を表示させるってのはできるのかな？
ロゴとかをずっと表示させときたいんだけどさ

636:デフォルトの名無しさん
07/11/15 19:36:43
ネイティブの機能が起動しちゃったら無理。

637:デフォルトの名無しさん
07/11/15 21:16:40
>619
それ意味無い
おそらくエミュはShortTimer使ってる。もう完全にアホの仕事

ちなみにMSNMessengerがtimeBeginPeriod(1)してくれてるぞ。豆知識な

638:デフォルトの名無しさん
07/11/15 21:44:16
そこはWindows Media Playerだろ

639:デフォルトの名無しさん
07/11/16 00:35:35
スレのトピックスでアプリ省サイズ化ツールとしてJavaBlenderとjargが載っているけど、
ProGuardってマイナーなのかな？
ProGuard3.7を使ってて特に問題なさそうなのだけどトラブル経験ある人いるんかな。
4.0、4.1と出てるけどどうなんだろ。

640:デフォルトの名無しさん
07/11/16 00:54:31
proguardしか使ったことない。
他の2つは2年以上更新されてないから心配。

641:デフォルトの名無しさん
07/11/16 01:02:21
>ProGuardってマイナーなのかな

おいｗ

642:デフォルトの名無しさん
07/11/16 03:26:36
JavaBlenderは結構うまくいかないときが多い。
特に900以降の場合サポートされていないので、現在では使用していない。

今俺がやっているのは
ProGuard(3.10)→Jarg(バージョン忘れたが最新)→7-Zipだな

643:デフォルトの名無しさん
07/11/16 07:27:22
仕事でソフィアクレイドルの糞高い圧縮ツールを使ったら実際に圧縮率は良かった。
ただし圧縮率を上げまくると実機で動かない場合が出たが・・・

もしも購入出来る金があるのであればお勧め。

644:デフォルトの名無しさん
07/11/16 10:41:47
ProGuardはバージョンが上がって変換後のサイズが従来より
大きくなるケースがあるな。
具体的な不具合が出ない限りは小さくなるバージョン使ってるがｗ

645:デフォルトの名無しさん
07/11/16 11:11:57
カメラ起動ならフレーム撮影みたいな感じにすればまだロゴ出せるんじゃないか？
プレイヤーは正直思いつかない

646:デフォルトの名無しさん
07/11/16 21:52:32
proguardは4.0ですごくサイズが小さくなるようになった。
3.8と比べて2kくらいは減る。3.9/3.10は3.8よりでかくなる。
もうこれでないと100kにおさまらねぇｗｗｗ

647:デフォルトの名無しさん
07/11/17 09:05:18
実機でclearキーが押ささらないんだけどなんで？
ちなみにエミュでは正常に動く。
ちゃんと初回起動時に
PhoneSystem.setAttribute(PhoneSystem.DEV_KEYPAD, 1);
した。あと、実機はN904i

648:デフォルトの名無しさん
07/11/17 09:49:15
>>647
公式にある資料くらい見ろ。
(各機種オプションAPI・拡張API実装状況のPDF)
903/904/703/704ではクリアキーが実装されている機種はない。
そもそも、クリアキーはKEY_IAPPと同一キーではないのか？

649:452,470...
07/11/17 11:50:12
公式にある資料を読んでたら、基地局とか登録エリアとか携帯電話がつながる仕組みまで
理解しないと気がすまなくなってきた…

いや、そんなことを言いにきたのではなくて

Googke で「doja 5.0 N900is」で検索かけたら、
このスレの俺の発言が1ページ目に表示された。orz

Eclipse+Doja5.0でDoja3.5ｱﾌﾟﾘ作れるかどうか報告するといっておいて
実はまだ実行まで辿りつけないんです・・・ｽﾏｿ
ここまで、考えられるエラー全て見てきた気がする。orz

一度、eclipse は忘れて、Doja だけで作ってみよう。

650:649
07/11/17 15:17:34
当たり前なことかも知れないが、
Doja-5.0 DK で HelloWorld プロジェクト作ったら、正常に動いた。
始めて成功して感動した。
あとは、N900iS でも動くように、Doja-3.5 アプリを効率よく作る環境を整えるだけなのだが・・・

とりあえず、Doja-3.5 と Doja-5.0 の API リファレンスは用意した。
リファレンス見比べながら、3.5にない API を使ってしまわないようにしながら、
Doja-5.0 の機能を利用できればいいわけか・・・。

独り言はここまでにしときます。
ただ、Doja-5.0 DK でコンパイルしたとき、何故か JDK 1.5 compile ... と表示されたのが気になる。
確かに、うちのPCには、Java 1.5.0 と 1.4.2 と 1.6 が入ってるけれど・・・
JDK 1.6 の JAVA_HOME も設定したし、JDK 1.6 の Path も通したし問題はないはず。
（まだ問題が起きていないだけか）

　ま　ぁ　い　い　や。

エミュレータを動かせたので大満足。次はアップロード先を探さなきゃ・・・

チラ裏ｽﾏｿ

651:デフォルトの名無しさん
07/11/17 15:26:31
pathのほうが優先されてるだけじゃね？
頑張ってるみたいなんでもうひとつアドバイス。

・JDKインストール
・OS再起動
・Eclipseインストール（pleiadesのどれか適当に）
・iαppliToolインストール
・Eclipseを立ち上げてワークスペースをiαppliToolのappsに設定
・helloWorldプロジェクト作成
・srcフォルダにソースを作成
・実行→構成および実行でDoJa5.0アプリケーションのフィルタを作って実行
・動いたら apps/helloWorld/bin/ にある
　helloWorld.bin,helloWorld.jam,download.htmlの3つをサーバへアップロード
・携帯からdownload.htmlへ接続、アプリをダウンロード
・携帯でアプリ実行

で、どーよ？

652:デフォルトの名無しさん
07/11/17 15:58:17
progurdで圧縮するとアプリが終了してしまうんですが
原因はなんでしょうか。
System.gc()で終了したので消してみたら
次はImageのuse()の１６回目の呼び出しで終了しました。
catchも呼び出されません。

653:デフォルトの名無しさん
07/11/17 16:13:02
圧縮されたときにいやーんなコードを書くのが原因。

654:デフォルトの名無しさん
07/11/17 16:29:52
>> 652
proguardをかけた後、逆アセしてコード見てればいいんじゃねぇ？
時々変なコードに変換されているときあるから。
それでそれがローカル変数で問題になら、その変数をクラス変数に替えることで
正常に動作するというときもある。

655:デフォルトの名無しさん
07/11/17 16:50:56
「押ささらない」ってよく変換できたな。何弁？

656:デフォルトの名無しさん
07/11/17 16:59:52
北海道弁

657:652
07/11/17 18:06:58
>>654
みんなアセンブリとかも分かるのか
自分は分からないし圧縮しないと収まらない訳じゃないから諦めよう

658:654
07/11/17 19:49:16
>>657
逆アセって言い方が悪かったのかな？デコンパイルって言えばいいのかな？
jad.exeの引数にクラスファイル指定するだけだから簡単にできる。
出力されるソースも、ほぼjavaのソースと同じだ。

659:デフォルトの名無しさん
07/11/17 20:14:21
言い方が悪いっつーか逆アセとデコンパイルじゃ意味が違うじゃん

660:デフォルトの名無しさん
07/11/17 20:42:06
俺は許容が広いから「あぁ、そういういみなんだろうな」と理解できた。
>>658は、頭悪い上司を持つと苦労するタイプだろうw

661:デフォルトの名無しさん
07/11/17 20:51:06
>>651
神！ｔｙ！

あと2時間でサーバーへアップロードしないと
次の作業まで2週間待ちになってしまう。。。

とにかくも651に感謝m(｡_｡)m

662:デフォルトの名無しさん
07/11/17 21:27:51
>>651 の書いたとおりにやったら、動いた！！すごい

なんで動いたかよくわからないけど、今日はもう時間がないため
とりあえずアップできるサーバーを探さなければ・・・。

651の内容のうち、前半は既に済んでいたので、以下のみ行った。
・Eclipseを立ち上げてワークスペースをiαppliToolのappsに設定
　iαppliTool で指定している作業フォルダを設定した。

・helloWorldプロジェクト作成
　helloWorldプロジェクトは既にあったので、別名のプロジェクトを作成した。
　プロジェクトを作成した後、ウインドウ－設定で、Doja-5.0 のインストールフォルダを指定した。
　（これを設定しないと、クラスがうまく作れなかった）

・srcフォルダにソースを作成
　Eclipse でクラスを作ったら、自動的に作成された。
　クラスは、スーパークラスを com.nttdocomo.ui.Application とした。

・実行→構成および実行でDoJa5.0アプリケーションのフィルタを作って実行
　無事、動いた。

残りは、以下の作業だ。携帯が手元にないので；；　とりあえずサーバーへアップロードしたら
　場所移動して携帯でチェック。報告は明日以降になりますm(｡_｡)m

---残りの作業
・動いたら apps/helloWorld/bin/ にある
　helloWorld.bin,helloWorld.jam,download.htmlの3つをサーバへアップロード
・携帯からdownload.htmlへ接続、アプリをダウンロード
・携帯でアプリ実行

663:デフォルトの名無しさん
07/11/17 22:09:28
まったく、デコとかパイとか。

664:デフォルトの名無しさん
07/11/17 23:13:17
>>652
-dontoptimizeつけてみるとか

665:652
07/11/17 23:51:16
>>658
jadファイル自分の力と気力じゃ解読不能みたいでした。
>>664
それはもうつけました。
とゆうよりつけないと圧縮できませんでした。

666:デフォルトの名無しさん
07/11/18 01:30:01
proguardのバージョン変えてみるとか？

667:デフォルトの名無しさん
07/11/18 01:57:43
> そもそも、クリアキーはKEY_IAPPと同一キーではないのか？

うお、これでうまくいったよ！ありがとう！
つーかそんなとこに割り振られてるなんて気づかなかった・・・

668:652
07/11/18 10:49:18
proguardかけた後にjargかけたら出来るようになりました

669:デフォルトの名無しさん
07/11/18 13:31:16
>>668
それはProGuardの後にpreverifyをかけてなかっただけじゃないのか？

670:デフォルトの名無しさん
07/11/18 13:41:51
URLﾘﾝｸ(62.xmbs.jp)
裏アプリをやってみませんか？
ポケモンやドラクエ、マリオなど懐かしいゲームが携帯のアプリになって再登場(
゜∇゜)
やりたい人はURLを (・o・)ノ
URLﾘﾝｸ(62.xmbs.jp)

671:デフォルトの名無しさん
07/11/18 21:17:11
・・・サーバーにアップしたファイルのアクセス権をミスって2週間ダメにしたorz

672:デフォルトの名無しさん
07/11/20 02:42:56
リモート制御機能ってトラステッドアプリでしかダメだよね？

673:デフォルトの名無しさん
07/11/20 03:48:55
>>672
リモート制御機能とはなんですか

674:672
07/11/20 06:20:30
>>672
APIリファレンスに書いてあるんだけど、
開発ガイドには全く書いてない。

public class PushManager
プッシュ機能の管理オブジェクトを定義します。
リモート制御におけるプッシュ機能により、
サーバから i アプリにパラメータとパラメータを送信した時刻(パラメータ更新時刻)を渡すことができます。
渡されたパラメータとパラメータ更新時刻は、JAM が受信して保持します。
i アプリからは、JAM が保持するパラメータとパラメータ更新時刻を取得することができます。
また、i アプリ起動中やサスペンド中に JAM がパラメータを受信した場合には、
ParameterPushListener により定義されたリスナが呼び出されます。

エミュレーターのトラステッド動作設定にもリモート制御の項目が無いし、気になったもので、、。

675:デフォルトの名無しさん
07/11/20 11:02:07
>>674

それはマイボックス用のAPI

676:デフォルトの名無しさん
07/11/20 15:20:31
>>675
サンクス、
そんなサービスがあるとは知りませんでした。

677:デフォルトの名無しさん
07/11/22 09:18:11
ADF設定のTrustedAPIDって、
勝手アプリで設定しとくと、
実機じゃ正常動作できませんか？

678:デフォルトの名無しさん
07/11/22 10:52:11
できたらトラステッドの意味がねぇｗ

679:デフォルトの名無しさん
07/11/22 20:18:31
>>678
そりゃそうなんですけど。
TrustedAPIDの正誤をいつどこで確認してるのか気になったのです。

DL元ホスト（IPアドレス）とAPIDを一意に結び付けて、
DL時にdocomoのサーバに問い合わせるとか…？
くらいしか思いつかなかったのですが。

今試してみたらTrustedAPIDを書いてるとDL自体出来ないみたいです。

680:デフォルトの名無しさん
07/11/23 15:02:22
>>679
まあ、そんな仕組みだと思うけど。

681:デフォルトの名無しさん
07/11/26 09:59:07
Subversionでソース管理しようとしてるんですが、
コンパイルするとresディレクトリにある「.svn」ディレクトリもバイナリに含んでしまいます。

コンパイルオプションで特定のディレクトリ以下のファイルは含まないとかできないんですかね?

682:デフォルトの名無しさん
07/11/26 11:20:27
>>681
コンパイルはbatで行なってるんでしょ？
直前に.svnを別のところに退避させて、コンパイル終わったら戻すようにしたら？

683:デフォルトの名無しさん
07/11/26 11:29:01
今時バッチファイルでコンパイルしてる人いるの・・？
IDKかANTかと思ってたが。

684:681
07/11/26 15:23:11
>>682
コンパイルはbatじゃなくてふつーにIDKでやってます。
とりあえず開発時はそのままやってて、実機テスト&リリース時は別ディレクトリに移してコンパイルしてる状態。
この手間がちょっと面倒なんで改善できたらなぁと。

685:デフォルトの名無しさん
07/11/26 15:41:48
>コンパイルオプションで特定のディレクトリ以下のファイルは含まないとか

普通に出来ますが

686:デフォルトの名無しさん
07/11/26 15:42:14
>>681
俺は画像格納用のフォルダをresとは別に用意しておいて、
resフォルダはsvnの管理から外してる。
（spに詰めるバイナリ生成ツールがそこにあるからでもあるが）

まぁ、どっちにしても手間なんだけど
バッチ使いも結局バッチを書く手間はあるわけで、
自分にとってベターな方法を模索するのがいいんじゃないかと。

687:デフォルトの名無しさん
07/11/26 21:24:50
>>686
ｻﾝｸｽｺ
いろいろやってみます。

688:デフォルトの名無しさん
07/11/26 21:28:31
普通にbat使ってますがなにか

689:デフォルトの名無しさん
07/11/26 22:54:38
プリプロセッサやら、プロガードやら使うからbatが主流だろう。
というのは仕事としてやってる人の考え方だったのかな

IDKってコンパイルオプション指定なんてできたっけ？（JAM指定呼び出しでしかエミュレータ呼び出さないもんでｗ）

690:デフォルトの名無しさん
07/11/26 23:05:09
idkはビルドの前後にbat指定できなかったか

691:デフォルトの名無しさん
07/11/26 23:09:50
とりあえず俺はeclipseの出力jarにbatでオブファスケータかけてる

692:デフォルトの名無しさん
07/11/26 23:21:27
>>690
batの指定というよりビルドの前後にコマンドの指定ができる感じだな
とはいえｵﾌﾞﾌｧｽｹｰﾄしちゃうとコンパイル以外idkが自動でやってくれたのは全部やりなおしになるから存在意義が・・・

693:デフォルトの名無しさん
07/11/27 00:00:54
ていうか何十個もある端末用の個別のファイルをいちいち手作業でＧＵＩでクリックしてつくるとか考えられない。
途中で間違う可能性もあるし。

694:デフォルトの名無しさん
07/11/27 00:11:06
>>693
何十個っていったい何をそんなにわけてるの？
その状況が想像できないのだが…

695:デフォルトの名無しさん
07/11/27 00:32:45
>>694
相当昔の端末までサポートしてるなら不思議じゃないけど

696:デフォルトの名無しさん
07/11/27 01:45:15
>694
例えばSystem.getProperty()で取れないような機種別情報が必要なら
何十個もjarを作るかもしれんな。具体的にどんな情報かは知らないが。

それなら機種名を渡してサーバ上に用意した関連情報を引き出す
作りにすればグッと数を減らせるだろうけど、
通信できない（しちゃいけない）事情があるとか｡

697:デフォルトの名無しさん
07/11/27 02:20:02
つかサウンドデータだけでも十数個のセットになるやん

698:デフォルトの名無しさん
07/11/27 04:35:24
>>697
mova含めたら19種類、FOMA限定なら6種類かな？

URLﾘﾝｸ(www.hundredsoft.jp)

699:デフォルトの名無しさん
07/11/27 08:36:16
えっ？

700:デフォルトの名無しさん
07/11/27 08:36:31
今でも新規案件でmova対応ってあるの？
うちはもうfoma限定だなぁ。
サウンドは通信で取得するかアプリ上で分けるかだな。

701:686
07/11/27 13:55:28
>>689
一応俺もプロなんだがサイズに困るほどのアプリが殆どない。
圧縮するにしても100k超えることは滅多にないし
904で無圧縮状態でテストしてOKだったら圧縮して動作確認しておしまい。
毎度圧縮する必要性を感じないからIDKのみで十分。

>>700
たまーに勘違いな営業さんが「全キャリア全機種対応」とかほざいて
一応話聞いてみるとmovaも入ってたりするよね。
帰ってもらうけど。

702:デフォルトの名無しさん
07/11/27 13:56:03
画像が最後まで読めないです
com.nttdocomo.ui.UIExceptionが出てるんですけど
これは機種の問題ですかね？

703:デフォルトの名無しさん
07/11/27 15:15:59
>>700
mova含めないとサウンドデータだけで十数個のセットならないし
何十個もある端末用の個別のファイル作る必要性も微妙だし(1機種1ファイルのレベルになる)

704:デフォルトの名無しさん
07/11/27 23:25:27
Doja 4.1、902世代以降をターゲットにゲームとか作ってます。

Graphics2において、アフィン変換かけてgif画像を回転させて描画させているのですが、ジャギが気になります。
OP_ADDでアルファブレンドしたら若干マシにはなるのですが、描画数が多いので負荷が気になります。
もっと良い解決策はないでしょうか？

705:デフォルトの名無しさん
07/11/28 00:18:32
ありがちだけど、あらかじめ計算したパターンを持っちゃう。

706:デフォルトの名無しさん
07/11/28 00:27:07
>>704
DDT

707:デフォルトの名無しさん
07/11/28 00:41:58
DDTでもジャギは出るでしょ。
回し方の問題じゃないから。

708:デフォルトの名無しさん
07/11/28 03:27:29
回転させてもジャギが目立たないような色合いのグラフィックを描く。

709:デフォルトの名無しさん
07/11/28 04:46:22
100K超えることは滅多に無いってなんの話？

jarの話？アプリ全容量の話？

710:デフォルトの名無しさん
07/11/28 07:38:02
>>701
　画像や音声は全部通信でとってくるし、うちもJARは100K超えることはないかな。

今は音声だけカテゴリ分けしてるけど、VGA機種向けに画像も分けるようにしないと
いけなくなるんだろなぁ。

mova除外だけだと、FOMA701とか702なども対象になるけどそこら辺は含めるんかな。
30Kは物によっては相当きついよね。事前に収まるかどうか予測できるプロならいいけど
私にはできん。

711:デフォルトの名無しさん
07/11/28 10:18:15
ドコモ制限キツすぎる。。。

712:デフォルトの名無しさん
07/11/28 10:26:27
機種依存考えると頭がパンクしそうだぜ

713:デフォルトの名無しさん
07/11/28 10:32:16
>>711
制限的にはドコモが一番マシなんだが・・・

714:デフォルトの名無しさん
07/11/28 10:36:28
携帯アプリを匿名で配布したいと考えると
Docomoかauのオープンアプリになるわけだが、
auのオープンアプリの制限は半端じゃない('A`)

715:デフォルトの名無しさん
07/11/28 10:40:12
Sアプリの機種依存の多さは異常
公式資料が豊富だからまだ良いが

716:デフォルトの名無しさん
07/11/28 10:47:27
>>709
変な日本語書いて申し訳ない。
jarの話。

>>710
30Kはアプリ仕様からソースがどの程度の規模になるか推測して、
ソース5000行程度を目安にしてる。
まぁ感覚だからアテにできないけどねｗ

100Kの壁に苦しんでる人たちはどうしてるんかな。

717:デフォルトの名無しさん
07/11/28 10:49:50
迷わず仕様削減

718:デフォルトの名無しさん
07/11/28 20:24:43
勝手アプリだが
うちだとログとか見る限り7割のユーザーが903i,904iだから最悪メガアプリにして切捨てになるんじゃないかな
まぁまだ100Kの壁に当たってないけど

719:デフォルトの名無しさん
07/11/28 22:35:35
proguard（しかも4以降）をかまさないと100K超えるですよ。
さらに定期的に更新してるんで毎回どきどきですよ。

720:デフォルトの名無しさん
07/11/29 00:48:36
100K超えるプログラムってどんだけだよ

721:デフォルトの名無しさん
07/11/29 01:02:40
単機能のツール系アプリでも、UIやfool proof、例外処理にこだわると
結構サクッと100KiBの壁にぶつかるんだ、コレがorz

722:デフォルトの名無しさん
07/11/29 10:13:34
プリプロセス使わなければ簡単に100kくらい超えるでしょ？

723:デフォルトの名無しさん
07/11/29 13:11:20
超えねーよｗ

724:デフォルトの名無しさん
07/11/29 13:32:08
俺の今作っているのは173,292バイトになってるけど

725:デフォルトの名無しさん
07/11/29 13:33:42
規模と設計によって容量なんて大きく変わるから一概には言えない問題だろ

726:デフォルトの名無しさん
07/11/29 13:37:32
100k超えるってﾔｼは
まさかとは思うけど文字列とかデータ配列とかはjarに入れてないよね？

727:デフォルトの名無しさん
07/11/29 13:45:06
今調べたら俺が仕事で作った奴で最もでかかったアプリは
クラス数200オーバーで画像リソース200kくらい混みで
Jarサイズが600kだった('A`)

728:デフォルトの名無しさん
07/11/29 16:15:26
クラスをガツンガツン使えるような時代になったのはいいことだ。
はやくFOMA以下を切り捨てたい・・・・orz

729:デフォルトの名無しさん
07/11/29 17:19:12
>>728
FOMA以下ってことはFOMAも捨てるってことでおｋ？ｗ

730:デフォルトの名無しさん
07/11/29 17:27:47
createImageの作り方がどうしてもわからんす
どっかサンプル置いてるとこないですかね？
sampleから理解するのは得意なんですけど

731:デフォルトの名無しさん
07/11/29 19:05:37
Image image = Image.createImage(640, 480);

732:デフォルトの名無しさん
07/11/29 20:29:33
>>731
質問をよく見るんだ！
createImageの使い方ではなく、作り方を聞いている！

733:デフォルトの名無しさん
07/11/29 20:48:32
public class Image {
public static Image createImage(int x, int y) {
return null;
}
}

734:デフォルトの名無しさん
07/11/29 20:49:56
>>733
GJだ！

735:デフォルトの名無しさん
07/11/29 21:04:23
>>733
完璧だな

public class Image {
public Image() {
}
public static Image createImage(int x, int y) {
return new Image();
}
}
の方が良い気はするが

736:デフォルトの名無しさん
07/11/29 21:20:26
DoJa 5.0 の Ver3 以上のエミュレータについての質問です。
コマンドプロンプトから DoJa.exe を実行した場合に
System.out.println の結果が表示されないようです。
また doja.exe -version 等、何らかの出力が期待されるオプションをつけて起動しても、
コンソールに何も出力されません。

これはエミュレータのバグでしょうか？それとも何か出力を受け取る方法があるのでしょうか？

737:デフォルトの名無しさん
07/11/29 22:57:08
>>736
エミュのバグだと思われる。
たぶん直感アプリのために使っているのだろうけれど
基本的には、Ver3.00を使わないか、Doja5.1のエミュで間に合わせる。
どうしてもVer3.00でなければならない場合、あらかじめエミュを立ち上げておいて
アプリの実行位置にプロジェクトの場所を合わせておき、コンパイルの後に
エミュの起動ボタンで実行するようにする。

738:デフォルトの名無しさん
07/11/29 23:01:43
アプリから
画像データとサウンドデータと表示座標データとテクスチャ座標データと文字列データ
を切り離しても100Kに収まらず、アプリ連携で機能も切り離して、
それでも100Kぎりぎりな今日この頃。

739:デフォルトの名無しさん
07/11/29 23:38:51
>738
企画が悪いんだろう
iアプリ100KBに向かないアプリを無理に作ってるとしか

740:デフォルトの名無しさん
07/11/30 00:27:04
>>739
2年以上バージョンアップを繰り返してるからねぇ。まぁしょうがない。

741:デフォルトの名無しさん
07/11/30 00:50:08
クラスが増えると、
たいした機能が無くてもアプリサイズが増えるね。

保守性にかかわるから、クラスは気にせず作りたい…。

742:デフォルトの名無しさん
07/11/30 02:07:50
>>738
常に速度が要求されないなら高度なスクリプトエンジンを組んでコードごとSP側に退避するべし

743:デフォルトの名無しさん
07/11/30 05:08:43
MediaSound sound=MediaManager.getSound("resource:///sound.mld");
でリソース内のmldを読み込んでいるのですが、

メモリ内に存在するmld形式のバイナリデータを getSoundに渡す方法ってありますでしょうか？

次ページ