ｉアプリでゲーム
■ このスレッドは過去ログ倉庫に格納されています
0001利用者側
01/11/06 19:30ID:???0357名前は開発中のものです。
02/05/28 19:30ID:???Google ToolBarでもインストールして、知らないキーワードは即検索するクセを
付けるといいよ。一見、必要のないように見える知識こそ、あとで重要になったり
することが多いから。
スレと関係ないのでsageときます。
0358エアリエル
02/05/28 19:53ID:OWQJ/ANEぐさっ！そんなするどいツッコミをいれなくとも、、パタッ。
ぽくぽくぽくちぃ～ん♪あいはてもうした。
、、と、冗談はおいといて、調べるということはHP見てくれると
いうことなわけで、、見てくれたらひょっとしたら買ってくれるかな～と。
さて、、それにしても、ただ「申しわけございません。」かな～？それとも
「何アクセスありました～申し訳ございません。」かな～？
きちんと誠意ある対応をしてくれるかで今後の行動が決まるんだけどな～♪
0359エアリエル
02/05/28 21:00ID:???Sleipnirブラウザ使ってるから検索しようと思えばいつでも出来るんですけど、
こういうのは御堅い仕様書みるより、人から優しく教えてもらった方が、
多少間違ってても覚えやすくていいんですよ～。
ところで、、504公式エミュレータで音鳴らせるの？
某有名メーリングリストで音が二つ同時に出ません何が原因でしょうか？！
って質問があったんですけど…、、ウチはそれ以前の問題で音出ないんですけど…。
0361名前は開発中のものです。
02/05/29 01:25ID:???電池の消費量についてはハードウェアとOSとVMの設計によると思われ。
0362haruka
02/05/29 01:50ID:???>>346の書いたコードがバグってたのか
それともN503iでは他のところにヘンな部分があってうまく動かないのか
全然切り分けできてないじゃん。
wait/notifyみたいにVM仕様の基本的な部分がバグっているってことは
さすがにないんじゃないかって思うんだけど。
0363名前は開発中のものです。
02/05/29 12:06ID:???KVMMarkからだけど、System.currentTimeMillis()の精度は
相変わらず100msくさいですな。とほほ。
0364名前は開発中のものです。
02/05/29 12:11ID:???0365346
02/05/29 13:41ID:???N503iでbox=10あたりからキー反応が鈍くなっていって、17あたりで完全に応答がなくなる。
カウンタは回り続けてるので、キーイベントそのものが来なくなるっぽい。
import com.nttdocomo.io.*;
import com.nttdocomo.ui.*;
import java.util.*;
class GameCanvas extends Canvas implements Runnable {
ShortTimer timer;
Thread thread;
Random random = new Random();
int count = 0;
int box = 0;
public void start() {
timer = ShortTimer.getShortTimer(this, 0, 100, true);
timer.start();
thread = new Thread(this);
thread.start();
}
0366346
02/05/29 13:42ID:???while (true) {
count++;
repaint();
try {
wait();
} catch (InterruptedException e) {
}
}
}
public void paint(Graphics g) {
g.lock();
g.clearRect(0, 0, 160, 160);
g.setColor(Graphics.getColorOfName(Graphics.YELLOW));
for (int i = 0; i < box; i++) {
g.fillRect(i, i, 100, 100);
}
g.setColor(Graphics.getColorOfName(Graphics.BLACK));
g.drawString("" + count, 30, 30);
g.drawString("" + box, 30, 60);
g.unlock(false);
}
0367346
02/05/29 13:42ID:???switch (type) {
case Display.TIMER_EXPIRED_EVENT:
notify();
return;
case Display.KEY_PRESSED_EVENT:
box++;
return;
}
}
}
public class Main extends IApplication {
GameCanvas canvas = new GameCanvas();
public void start() {
Display.setCurrent(canvas);
canvas.start();
}
}
0368346
02/05/29 13:50ID:???0369346
02/05/29 20:41ID:???鋭意修正中。
0370名前は開発中のものです。
02/05/29 23:11ID:???米Nazomi社，英ARM社を特許侵害で提訴
http://ne.nikkeibp.co.jp/DSP/2002/05/1000012875.html
＞Nazomi社は明言していないものの，ARM社が自社のCPUコア向けに開発したJavaバイト・コードのアクセラレータ回路「Jazelle」を対象しているとみられる。
Jazelleが訴えられたっぽい。
既にJazelleの採用された携帯は存在するのだろうか。
ところでNazomiって、謎だね・・・・寒・・・・いや、NAOMIの・・・・あぁ・・・
0371名前は開発中のものです。
02/05/30 11:05ID:???見たとこ癖のないごく普通の3DAPIだし、割と面白そう。
さて何を作ろう。
0372名前は開発中のものです。
02/05/31 09:26ID:JzeSZd8o俺の作ったiアプリ、503シリーズ、F504i、D504iでは動くんだが、
N504iは途中で止まってしまいます。
http://mightguy.tripod.co.jp/cupmen/
リンク先にソースも置いてあります。
何か気がついたところがあればアドバイスお願いします。
0373名前は開発中のものです。
02/05/31 09:50ID:???＞もしバグだったら、NECは謝罪と補償(ホームラン軒味噌味)をしる(藁
だってさ・・・・・ﾊｧ
0374haruka
02/05/31 09:54ID:???せめてどういう操作したら止まるのか書いてよ。
とりあえず
stimer.stop();
stimer.dispose();
stimer = null;
のあたりとか、
stimer = ShortTimer.getShortTimer(this, 0, timerSpan, false);
stimer.start();
が強烈に怪しいので、
メソッドprocessEventとfuncを synchronized にしてみたら
直ると思うんだけど、どうかな?
0375名前は開発中のものです。
02/05/31 10:01ID:???0376名前は開発中のものです。
02/05/31 10:33ID:???Doja2.0ドキュメントによると
＞getGraphics
＞public Graphics getGraphics()キャンバスに描画するためのグラフィクスオブジェクトを取得します。 取得されたグラフィックスオブジェクトは初期状態になっています。
＞[DoJa-1.0]
＞getGraphicsメソッドを呼び出すたびに新しいオブジェクトを生成するのか、予め 確保したオブジェクトを再使用するのかは機種依存です。
＞[DoJa-2.0]
＞getGraphicsメソッドを呼び出すたびに新しいオブジェクトを生成して返します。
って事なんだけど。
タイマー（とキー）イベントのたびにGraphicsオブジェクト作ってるみたいだけど、そーいうもんなの？
あと、repaintで無くpaintを呼び出すのはiAppli的には普通なの？
いちいちAA[]を作りなおしてるのはどうなんだろ。っていうか全体的に...
0377エアリエル
02/05/31 13:46ID:???stimer = null;
ここだと思う…。
disposeして存在を消し去ったのに、それに対しnullを入れようとしている…。
っていうか、null必要無いような気もするし、順番逆の気もするし…。
あり？paintメソッドを意図的に何回も呼び出す（生成）していいんだっけ？
それにしても、一般的なiアプリの作り方はこうなのか…
私はcのなかでg = this.getGraphics();としてpaintメソッドは空にするやり方だな～
ヘボヘボプログラマからの信用出来ない一言でした。
0378名前は開発中のものです。
02/05/31 13:53ID:???本当にヘボへボだね・・・・
0379378
02/05/31 14:01ID:???0380エアリエル
02/05/31 15:01ID:???_＿ っ っ
Gﾆ ･ ヽ.、 ／￣￣￣￣￣￣
´￣＼ Gﾆ ･ ノ`′＜ いぢめる？
（ へ ヽ/ 三;´￣ヽ ＼＿＿＿＿＿＿
＼__人__.（＿＿ヽ＿
0381名前は開発中のものです。
02/05/31 16:57ID:???＞元関係者（正確には下請け）としては、担当者しっかりチェックせい！
＞ですな。私らが関係してた時はこれでもか！というくらい厳しかったんですが…。
iAppli関連の調べものしてたらこういう書き込みを見つけたんですが、いったい何を担当してたんですか
0383名前は開発中のものです。
02/05/31 20:13ID:???この人ってプログラマなのだろうか？と疑問を持ったもんで。
0384372
02/05/31 22:45ID:???アプリを起動して３～５の何れかを押してカウントダウン開始
↓
N504iは何回やっても50秒くらい経つとエラーで止まる。
その間、携帯に全く触れなくてもエラーになる。
それ以外の端末は動作している(ように見える)。
>>375
バグの噂は携帯・ＰＨＳ板
http://cocoa.2ch.net/test/read.cgi/phs/1022643854/
の過去スレ。Part12(だったと思う)頃から何度か噂になってて、その内容は、
「当初5月上旬発売が延びたのは致命的なバグが取れないため」
というもの。
>>376
repaintを使ってない理由は
ttp://www.atmarkit.co.jp/fmobile/rensai/doja06/doja06.html#2
の記事を参考(信用)にしているため。
AA[]に関しては、jarファイルが大きくならない、かつスマートに書きなおせるなら
そのテクニックをご教授願いたい。
>>377
俺はサンデープログラマで、なおかつ
自己流でプログラム覚えちゃったので恐らく一般的な書き方ではないです。
0385372
02/05/31 22:45ID:???ttp://mightguy.tripod.co.jp/cupmen/a.lzh
・アプリが立ちあがると3分モードでカウント開始(キー入力によるイベントを無くした)
・paint(getGraphics()) -> repaint()
・邪魔なのでAAの表示を止める
が、症状は改善しません。
現在ドコモ提供の503用開発キットを使ってるんですが、
試しに、ドコモ提供の504用開発キットだで動かしてみたら
N504iと似た症状で異常終了してしまいます。
ドコモは503用アプリは504で動くと言っているけどこれが嘘なのかねぇ?
http://www.nttdocomo.co.jp/p_s/imode/java/qa.html#1-3
何が原因なのかもう少し追いかけて見ますわ。
0388名前は開発中のものです。
02/06/01 00:18ID:???すぐに端末のバグだとかエミュのバグだとか騒ぐのはみっともないぞ
ちょっと調べればどこでどう落ちてるのかわかるだろ
private void func(Graphics g)
{
・
・
case 0x1000:
stimer = ShortTimer.getShortTimer(this, 0, timerSpan, false);
↑
ここでUIExceptionが出て落ちてるんだよ
> UIException - [DoJa-2.0] 同一キャンバスで取得済みのタイマと
> 同一のIDを指定してタイマを生成しようとした場合に発生します(BUSY_RESOURCE)。
毎回毎回ShortTimerのオブジェクトを取得してるのは何のため？
stopとstartを繰り返せばいいんじゃないのか？
0389372
02/06/01 00:27ID:???stimer.dispose()
した後に
getShortTimer()
してるんですけど?
dispose()が利いてないのはバグなんじゃないですか?
0390名前は開発中のものです。
02/06/01 00:30ID:???あのー、そこまで絞れたら、わかりそうな気がするんだけど・・・・。
何回目のgetShortTimerで落ちてるかカウントしてみた？
>>388も言ってるけど（同一のID云々は誤りだと思うけど。disposeしてる訳だから。）、毎回getShortTimerを生成し直す必然性は何ですか？ソースがあったら教えてください。
repeatをtrueにして回しとくんじゃ問題が生じるの？
エミュだと問題無い/私はエミュでしか確認出来ないんで。
それと、paint()呼出し駆動というか、この場合だとpaint()からfunc()を呼んでるけど、そういうのって良くない気がするなぁ。paint()はあくまでも描画処理関連のみ、って風には作れないもんかね。
0391372
02/06/01 00:56ID:???>毎回getShortTimerを生成し直す必然性は何ですか？ソースがあったら教えてください。
根拠は
http://www.nttdocomo.co.jp/p_s/imode/java/pdf/jguide504_020517.pdf
73ページです。
ShortTimer timer;
を
timer.stop();
timer.dispose();
してるんで、使い終わったタイマーはdispose()しても良いって事では?
今回のカップ麺タイマー
ShortTimer.getShortTimer(this, 0, timerSpan, false);
なぜ、定数でなくてtimerSpanという変数を使ってたかというと
将来的にこの値を可変にして茹であがり間際にAAのアニメを
高速化しようと思ってたんですよ。
timerの間隔を変更するにはdispose()しなくちゃいけないですよね?
0392388
02/06/01 01:07ID:???stimer.dispose()でメモリは解放されてるが、
内部のタイマIDは解放されないんじゃないかな。
そもそもShortTimerは何度も生成するものじゃないと思う
タイマの間隔を調整するならThread.sleep()とかでやったほうがいいんじゃないか？
0393390
02/06/01 01:19ID:???で、dispose()が利いてないってのはどーかなー。
エミュでもわざわざ???回目のgetShortTimerで例外発生するように作ってある？ところを見ると・・・・まあ、バグというか、そういう「仕様」なんじゃないですかね・・・・・。
本当に何十回もタイマーを作りなおす必要あるの？ っていうか実機では何回目に落ちるか教えて欲しい。
あ、またレスが付いてた。
＞timerの間隔を変更するにはdispose()しなくちゃいけないですよね?
２種類の間隔が必要なら、タイマー２個（もちろん別々のIDで、複数を使い分ける/使いまわす）で済みそうだけど・・・・・ダメ？
（10種類なら10個）
73ページ見てみたけど、うーん。確かにこのゲームを何十回か繰り返して遊んでいるうちに落ちる可能性はありますね。
あるいは、Canvas１個あたりのタイマー数制限があるのかも。だとしたらCanvasごといちいち作りなおすってのはどう？（必要なら。）
ちなみに、同ページにprocessEvent()内の処理は極力短時間で終わらせろ、って書いてありますね。守った方が良いね。
0394372
02/06/01 01:50ID:???390さんがDOCOMOの関係者で「これは仕様です」と言うなら納得するけどね。
仕様書に書いてない仕様は「バグ」だと思うんだけど、どうですか?
http://www.nttdocomo.co.jp/p_s/imode/java/pdf/jguide504_020517.pdf
48ページ、一番上の項目はどうなるんだろう?
ttp://www2.airnet.ne.jp/~kenshi/tgmaking.html
の下の方みたいにresume()の際にShortTimer.dispose()
を推奨しているサイトをいくつか知ってるけど、
これを実践している503アプリは全滅しませんか?
0396390
02/06/01 02:24ID:???エミュでCanvasいちいち作りなおしを試してみたけど駄目だった。
>>395
うーん、実際にカウント表示するプログラムを動かしてくれればはっきりするんだけど・・・・250回くらいってのは、良い数字ではあるよね。255とか？
394にあるサイト行ってみたけど、推奨してる？「結果オーライ」としか読めないんだけど。
いちいち作りなおさなくちゃ正常に動きません、って風にも読めないし。
resume された時にstopしてるかどうか解らない？そうなの？startしたかどうかはフラグで判定すれば良いし、stopされたかどうか本当に解らないなら（rsume時にもstopしていない可能性があるなら）、とにかくstartを試みて例外はキャッチすれば良いんじゃ？
バグか仕様かは私の知ったことじゃないんで、メーカーに問い合わせるなりしてください。
私は、迂回策はあるだろうと意見してるだけで。
にしても、タイマー生成数限定が本当なら、正常に動かなくなるiアプリがけっこうあるかもね。
0397372
02/06/01 02:45ID:???・ShortTimerの確保と開放を連続して行うとN504iは250回程度、504エミュで100回で例外が出て終了する。
・503シリーズ、503エミュ、F504i、D504iではこの現象を確認できず。
・マニュアルにはこの件についての記述が無い。
・372自身はバグだと思うが、ドコモの仕様説もある。
>>390
>394にあるサイト行ってみたけど、推奨してる？「結果オーライ」としか読めないんだけど。
だから、ドコモの仕様書48ページ一番上に書いてある通りのプログラムでしょ?
「タイマーのインスタンスを破棄した上で再作成する必要があります。」
timer.dispose() -> timer.getShortTimer()
>バグか仕様かは私の知ったことじゃないんで、メーカーに問い合わせるなりしてください。
朝目が覚めたら、このスレのURL付けてメールしてみます。
DOCOMOの許可が下りればここで返事を公開するつもりなので、期待していてください。
最後に...
>>390 本当に何十回もタイマーを作りなおす必要あるの？
そこにdispose()があるからです。(藁
0398名前は開発中のものです。
02/06/01 03:04ID:???生成・破棄を繰り返さなければいけないという、プログラムの設計
自体が根本から激しく間違っている気がする。
0399名前は開発中のものです。
02/06/01 09:43ID:???いわゆる「クレイマー」だったと考えるべきなのかな。
それならそうと初めから言ってくれれば、時間を無駄にせずに済んだのに。
ただ、1分に1回の割合でタイマーを再生成するプログラムだとしても約250分使いつづければ落ちかもしれない訳で、問題だろうけどね。
或いはタイマーに限らず、他のネイティブリソースと合わせて制限があるかもしれないし。
0400399
02/06/01 10:20ID:???×落ちかも
○落ちるかも
まぁ自分がその機種のユーザーなら、そんな「仕様」は認めたくない、文句も言いたいだろうけどね。
それならそう言って欲しいよ。0.2秒毎にタイマーを作りなおすのが正しいって言われても困る。
>>397
＞だから、ドコモの仕様書48ページ一番上に書いてある通りのプログラムでしょ?
あ、本当だ。DoJa-1.0プロファイル（503の事？）では「タイマーのインスタンスを破棄した上で再作成する必要があります。」って書いてあるね。
けど、「アプリケーションの実行が中断された場合」って書いてあるよ。0.2秒毎にイベントを発生させるのに、いちいち再作成する必要がありますとは書いてないよね。
0401372
02/06/01 10:59ID:???504iのバグ(不具合)情報もっときぼんぬ
0402名前は開発中のものです。
02/06/01 11:17ID:???0403エアリエル
02/06/01 11:56ID:???ようするにそういう問題があって、他にもまだありそうでまだ完璧とはいえないのに、
出そうという上の方針に疑念を抱く人の告発でしょう？
たしかに現実問題、意図して100回もタイマーを生成することはないでしょうけど、
長期間遊ぶ場合、着信復帰などで100回を越える事も無いとはいえないわけですからね～。
、、という事にしておこうっと。
0404名前は開発中のものです。
02/06/01 12:38ID:???本当に372本人？
「クレイマーってのは言い過ぎだった」って書き込むつもりで来たんだけど、ほんとうにクレイマーじみてきだぞ・・・・・
バグるっていうか、「例外が発生してる」んだよね、納得し難い。その根本原因はバグかもしれない訳だけど。
メーカーでは認識していなかったんだろうか？認識していれば簡単に修正出来そうな気はする。けど、エミュにまで「制限」を埋め込んであるのは・・・・・
これも「バグ」なのだろうか？かもしれないけど、エミュ版制限の100って数字は、意図的なものの様にも思える。
N社の端末の「バグ」取りが間に合わなくて、次善の策として？エミュ側により強い制限を組み込んだ？
372は自分の主張（の変化？）を改めて見なおして欲しい。
「以前の機種では（N504i以外では？）正常に動作していたアプリケーションが動かなくなる可能性がある」
「この新たな制限はドキュメントに記述されていないし、著しく不便だし、改善されるべきだ」
って主張に関しては、その通りだと思う。
「バグの為にオレの作りたいアプリケーションが作れない」
という主張なのであれば、そりゃ違うんじゃないかと思う。
回避は可能だし、行儀の良いコーディングをすれば、実用上は問題なく動作させられるだろう。
もちろん、だからと言ってこの制限が正当化される訳じゃないよ。
372のコードは問題提起用のサンプルとしてはスマートさに欠け過ぎというか・・・・・
0405名前は開発中のものです。
02/06/01 13:27ID:PI6zGk6Aこのアプリでしか発覚せん可能性、十分にあり。
こんなことで文句つけるやつはWindowsなど使えん。
.NET Frameworkなんかなぁ…。ため息がでるよ。
0406y2kbest@k9.dion.ne.jp
02/06/01 13:51ID:???「 RX-2001 」がパワーアップした、
「 RX-2000Ⅲ 」↓
http://user.auctions.yahoo.co.jp/jp/user/NEO_UURONNTYA
店頭販売価格は、13900 円なんですが、
今回だけ、破格の 7100 円に設定して
おります。
購入希望の方は、名前の所にも書いて
ある、y2kbest@k9.dion.ne.jp 迄、
メールを下さい。
不安な方は、落札をして頂いても
構いません。
0407名前は開発中のものです。
02/06/01 13:53ID:???いやおそらく、単純に繰り返しShortTimer.getShortTimer()を呼び出すだけで再現できるよ。
長時間連続可動させつつShortTimerを用いるアプリでは避けられない問題、って事になるんだと思う。
また、372の様に作られたアプリが従来は動作していたものが、特定機種で動作しなくなってしまうのも、おそらく事実であり。
修正すれば実質的に回避できるとしても、修正する手間を取らせる理由が不明確。何故そんな制限が新設されたのか。
それと、MSに比べたら・・・・ってのは、本当に最後の言い訳というか。それ言ったら終わりというか。
0408名前は開発中のものです。
02/06/01 14:23ID:XGrag9Kc通常の使用で100回もタイマを取得するようなことになってしまうような
コードは、俺は絶対に書かないが、世の中にはそんなプログラマが多いのか？
不思議になってくる。
0409名前は開発中のものです。
02/06/01 14:24ID:???0410407
02/06/01 14:47ID:???いや、一つ間違えました。
DoJa2.0からはstart()にて復帰できる事が仕様として保証されたみたいですが、
DoJa1.0では「タイマーのインスタンスを破棄した上で再作成する必要があります。」だそうなので。
実行環境を認識し、DoJa2.0だったらShortTimerを作りなおさずに再利用する、様に作れば良いんですね。
＞通常の使用で100回もタイマを取得するようなことになってしまうような
コードは、俺は絶対に書かないが
との事ですが、DoJa1.0時代にはそれが常識だったらしいです。
まあ、「アプリケーションの実行が中断された場合」に限って取得すれば良いはずではありますが。
それでも理屈上は、何十回か（タイマー動作中に？）中断を繰り返せば、DoJa1.0時代の常識で書かれたコードはN504iでは落ちる、って事になるでしょう。
ところで>>404に
＞バグるっていうか、「例外が発生してる」んだよね
って書いたけど、実機でも例外がThrowされてる、とは明言されて無さそうですね。要確認でした。
0411名前は開発中のものです。
02/06/01 16:44ID:???0412名前は開発中のものです。
02/06/01 17:28ID:???"Write Once, Run Anywhere" の幻想はハードに余裕が無いほど霞むって事だろうか。
ってゆうか、実力以上の仕事を強いられているんだろうね、製品開発を担当している人々は。バグが生じても当たり前のスケジュール、みたいな。
0413372
02/06/01 21:05ID:wk3mO9w.>>390
登山家に何故の山に登ると?と聞くと「そこに山があるから」と答えるのになぞらえて洒落のつもりで言ったんですが、
まじめな議論に水を差すような発言だったようで申し訳無いです。今後は冗談を控えるんでもう少し議論に付き合ってください。
>>398
あなたの主観で間違ってるといわれても困ります。具体的に説明してください。
少なくとも、俺のプログラムが何故あんなプログラムになったかは説明しています。
言いっぱなしは止めましょう。議論になりません。
俺はプログラムについていろいろ勉強したいのです。
>>400 0.2秒毎にイベントを発生させるのに、いちいち再作成する必要がありますとは書いてないよね。
将来的に0.2秒を可変にするつもりだったって説明してるでしょ?だから、必要なのです。
>>402
あなたがこの関数の設計者ですか?それともこの関数の作成意図がどこかに書かれていますか?
根拠を示してください。
>>404
>エミュ版制限の100って数字は、意図的なものの様にも思える。
その意図を公式に説明して無いから文句を言っているのです。
>「バグの為にオレの作りたいアプリケーションが作れない」
俺の主張は「俺の作った503アプリが504で動かない」です。
503用のアプリと互換性を謳っているのに504で動かないのは問題でしょ?
>>405
>確かにバグくさいが、こんなださいソース書いてる方が笑われるぞ。
バグなのと笑われるのは別々に論議しましょう。
>このアプリでしか発覚せん可能性、十分にあり。
DOCOMOが503用エミュのサンプルとして提供しているスペースインベーダーがShortTimer.dispose()で落ちます。
DOCOMOのサンプルを参考にして作ると今回の件に引っかかる可能性、十分にあり。
0414372
02/06/01 21:09ID:wk3mO9w.ShortTimerとThread.sleepで同じ動きをするサンプルを書いてみました。
http://mightguy.tripod.co.jp/cupmen/ShortTimerVSThread.lzh
カップ麺タイマーから余計なものを省いた仕様にしたつもりです。
・503, 504両対応
・レジュームの処理をする
・キー入力を受けつける
・ShortTimerおよびThread.sleepの間隔は2000から毎回-1する
・ShortTimerおよびThread.sleepと平行して画面出力を行う
DOCOMO503エミュでコンパイル後、jarファイルのサイズを比較
俺のプログラム能力では
ShortTimer:1234byte
Thread:1513byte
となり、2パケット強の差が出ました。
これは、Thread使うよりShortTimer使う利点になると思うのですが、どうでしょうか?
もし、Threadの方がShortTimerよりも小さくなるならば
今後はThread派に転向するので、プログラムの添削お願いします。
(ようやくスレッド名に沿った内容に近づいたかな?)
paint(), repaint()についての記述をみつけました。
http://www.nttdocomo.co.jp/p_s/imode/java/pdf/jguide504_020517.pdf
68ページ。paint(), repaint()は用途が違うようです。
意図した画面を確実に出したい場合はrepaint()ではなくpaint()を使えと書いてあるように読めます。iアプリは一般的なJAVAと違うようですね。
0415エアリエル
02/06/01 22:06ID:???情報ソースはこちらでふ。
http://vs.g-appli.net/tips03.html
PだけRESET_VM_EVENTが通知されなかったりとか、、
まぁ色々機種があれば色々あるわな～～、、、統一せい！（怒
0416372
02/06/02 00:02ID:FWelNZ.Eいろいろ制限あるんですね。商売でiアプリかいてる人は大変だなぁ。
誰も答えてくれないからShortTimerを頻繁にdisposeするのは下品だって解説してるサイト
探してるんだけど、見つからないです。
実はここのみんなに担がれてるんじゃないかって気になってきたよ。
0417名前は開発中のものです。
02/06/02 00:30ID:???じゃ最初から他で聞けよ
0418エアリエル
02/06/02 00:33ID:???>
ご要望とあらば作りますが…(笑）
0419372
02/06/02 00:49ID:FWelNZ.Eあなたは、ろくに理由も説明されずに人を殺せってアドバイスされたら殺しちゃうタイプですか?
ShortTimerに関しては「普通はそんなプログラム書かない」と言うだけで
何故それが普通なのか誰も解説してないでしょ？
ShortTimerバグの回避方法とか、Threadの使い道とかいろいろ参考になってるので感謝してますよ。
文句だけ言うなら他で言えよ
0420名前は開発中のものです。
02/06/02 01:08ID:???おそらく見つからないわけで。
0421名前は開発中のものです。
02/06/02 01:44ID:FWelNZ.Ehttp://www.himeji-iec.or.jp/life/c_03/
これじゃ駄目？
0422エアリエル
02/06/02 01:49ID:???>
ご要望とあらば作りますが…(笑）
、、と、冗談は置いといて、
3分クッキングでこんなに盛り上がってて楽しかったけど飽きた。
それに、夜更かしはお肌の大敵だからみんな寝ようね。
これ以上盛り上がってもつまらないので、とりあえず眠って、
頭冷やすなり、凍らせるなり、滝に打たれるなり幽体離脱してきてちょうだい。
0423名前は開発中のものです。
02/06/02 10:03ID:???＞将来的に0.2秒を可変にするつもりだったって説明してるでしょ?だから、必要なのです。
だからよぁ、必要無いって指摘があるでしょーが。>>393に。意味が解らない？
それとも無数のバリエーションに可変する必要があると主張するか？
最悪、最高のレゾリューション（最小の間隔、例えば100ms）のタイマー1個で済ます、って手もあるよ？
0424名前は開発中のものです。
02/06/02 10:39ID:???＞68ページ。paint(), repaint()は用途が違うようです。
全く同じだと思っている人は少ないでしょう。その違いは認識した上でrepaint()を用いているのが普通だと思いますよ。repaint()は、システムが負荷に応じてpaint()呼出しのタイミングを調節できるようにする為に用意されている、と認識してます。
＞意図した画面を確実に出したい場合はrepaint()ではなくpaint()を使えと書いてあるように読めます。
確実に......まあ、より確実にpaint()が実行されるのは事実でしょうね。
画面の書き換え頻度が0.2秒毎程度でpaint()以外に重たい処理を行わないiAppliならrepaint()で十分なんじゃないかとも思えるんですが、なんぜ機種毎に何が起こるか解らない端末ですから、確実性を求めたくなるのも、もっともかもしれませんね。
開発ガイドを熱心に読まれているようですね。73ページ下の注意事項も重要だと思いますよ。processEvent()呼出しからpaint()を呼び出すのは、推奨されていないんじゃないでしょうか？paint()が十分に軽いと確信されているのなら、これ以上は言いませんが。
0425424
02/06/02 10:47ID:???0426372
02/06/02 12:41ID:FWelNZ.E＞無数のバリエーションに可変する必要があると主張するか
414で主張していますが。
最小の間隔のShortTimerを使いまわすとプログラムが増えて
jarファイルのサイズが大きくなるので却下です。
パケット代も考慮しましょうよ。
>>424
素人なんで参考に出来るのがDOCOMOのサンプルとWEBの情報だけなんですが、
503エミュのサンプル
\J2MEWSDK4DOJA\apps\uidemo\src\uidemo\CanvasDemo.java
でprocessEvent内からrepaint()しているのが確認できます。
0427エアリエル
02/06/02 13:07ID:8G3ggT66聞いた事があるんですが、本当ですか～？それとも意図的に中央にするメソッドか
何かがあるんでしょうか？そんなのがあるんなら教えて欲しいです～～～。
0428名前は開発中のものです。
02/06/02 14:02ID:???＞でprocessEvent内からrepaint()しているのが確認できます。
あなたはその例を参考にしてrepaint()を用いるようにしている、という事ですか？
>>427
>>271-275では解決しなかったという事ですか？
0429名前は開発中のものです。
02/06/02 14:11ID:g8uN2UCAhttp://freehost.kakiko.com/freen/kesaku.html
0430372
02/06/02 14:35ID:WLew8kMw話がややこしくなってきているのでここで一度整理したいと思います。
1:N504iと504エミュのShortTimer.dispose()問題
dispose()を呼ぶこと自体が問題なので、
ShortTimerを使うならここで紹介された回避策を使う
Threadでタイミングを取る
という意見に俺自身納得しました。今後この件に関してはの俺のスタンスは、
プログラムのここを変更すると効率が良くなる
ほかの方法でもタイミングが取れる、といった前向きな議論以外には参加しないということにしたいと思います。
2:ShortTimer.dispose()が正常に動く端末でのdispose()の是非
>>414にて、特定条件下でのThreadに対するdispose()の利点(jarサイズ)を挙げてみました。
これに対して、プログラムの書き方次第では立場が逆転する
disposeしないでShortTimerをうまく使いまわすと効率が良い、といった議論は大歓迎です。
「俺はこんなださいプログラムを書かない」「普通はこんなことしない」といった
実例をあげない反論は無視させていただきます。
あと、「dispose()は極力避けましょう」と多くの人が言っている根拠(雑誌の記事、ネットのTips集など)を知りたいので情報をお持ちの方はお教えください。
3:その他
俺がサンプルとして書いたプログラムに関する根拠のある突っ込み(最近だと>>424)はいろいろ勉強になるので大歓迎です。
0431372
02/06/02 14:54ID:WLew8kMw極力短時間というのはどう解釈すれば良いんですかね?
解釈の一例として426で挙げたプログラムは参考にしています。
いろいろ指摘を受けた結果、カップ麺タイマーに関しては極力短時間の
範疇を超えてるなと現在では思っています。
0432名前は開発中のものです。
02/06/02 15:11ID:???>>414のサンプルを見てみましたが、repaint()について理解していない様に思えます。
それと、あなたはたしか、ある時間が経過した事を知らせるアプリケーションを作ろうとしてたんだと思います。
最低限、その機能を持たせたサンプルにしていただけますか。
現状だと、両コードが同等の挙動を示すとは思えませんし。（interval値の変化など。）
（同等の動作をしている事を画面等で確認できる様にした方が良いのでは。）
その上で、出来れば実機でのタイマーとしての精度なども合わせて評価してみて欲しいですね。
そう精密な精度を要求するアプリケーションでは無いでしょうけれど、レゾリューションが荒いと評判のiアプリ環境で、Timer（恐らくsleep()も？）を細めに無数に繋ぎ合せての経過時間算出というのは、あまり普通の方法では無い様に思えます。
0434名前は開発中のものです。
02/06/02 15:21ID:???＞いろいろ指摘を受けた結果、カップ麺タイマーに関しては極力短時間の範疇を超えてるなと現在では思っています。
これまであなたは、自分は間違っていないと主張する事に一生懸命だったように思えます。気のせいでしょうか？
0435エアリエル
02/06/02 15:45ID:???揚げ足とりは”大好き”だけど、今回の揚げ物は面白味が無い。
ということで、とりあえず終わりにしませうや。
さもないと実況しちゃうよ？
0436名前は開発中のものです。
02/06/02 15:48ID:???>>428に答えよ。
揚げ足とりで無く、反省を促しているつもりなんだけど。今後の為に。
実況？すれば？
0437エアリエル
02/06/02 16:08ID:???あ～～～っと！さっそくレスが来た！！！！！（笑
まぁ～ええからええから、、人の考え方は違って当然、
その人にはその人のやりかたってものがあるんだから
ちょっと自分の気に食わん意見があってもしゃ～ないねん。
まっ気にせんとこうや～～。というわけで、我が問いに答えよ（爆
反省しろいうても、言ってる方の言う事が本当に正しいの？
言われてる方の言う事が正しいの？私はどっちでもいいし
どうでもいい。というわけで、我が問いに答えよ（しつこい(笑
0438名前は開発中のものです。
02/06/02 16:24ID:???はぁ。>>428に答えよ。
0439名前は開発中のものです。
02/06/02 16:36ID:???0440名前は開発中のものです。
02/06/02 16:56ID:???0441エアリエル
02/06/02 18:15ID:???一般的なアプリは120*130ですから、SO504iの128*128だと仕様でダウン出来ない
そうですし…(前提条件のサイズは必ずその機種の描画サイズ以下でなければいけない)
なんかこう～都合良く503.504全機種で使えるようなものはないですかね～。
0443名前は開発中のものです。
02/06/02 18:58ID:???＞なんかこう～都合良く
ではまず、あんたの都合を教えてください
0444名前は開発中のものです。
02/06/02 19:30ID:???＞忘れてました。
>>427
＞あの～ところで、、503用アプリは504で中央に寄せられた形で表示されると聞いた事があるんですが、本当ですか～？
「中央に寄せられた形で表示されると聞いた事がある」ってのは結局、DrawAreaの事だったの？別の方法を聞いた事があるの？
0445372
02/06/02 20:19ID:WLew8kMwhttp://members.tripod.co.jp/mightguy/cupmen/ShortTimerVSThread2.lzh
・503, 504両対応
・レジュームの処理をする
・キー入力を受けつける
・ShortTimerおよびThread.sleepの間隔は5000から毎回-1000し、1000になった段階で終了表示を行う。
・ShortTimerおよびThread.sleepと平行して画面出力を行う
「5回ならタイマー5個用意すればすむ」という人は5000という値を増やしてください。
DOCOMO503エミュでコンパイル後、jarファイルのサイズを比較
ShortTimer:1304byte
Thread:1682byte
となりました。
>>434 気のせいでしょうか？
気のせいです。複数の主張を一まとめにして語られても困ります。
実際、N504iと504エミュに問題があるって主張は変えてないし、
皆さんの協力のおかげで原因とその対処方法が確立されたわけですよ。
ただ、カップ麺タイマーの件を指摘した>>393にはどこまで削れば極力短時間に収まるのか、解説願いたいですね。
0446名前は開発中のものです。
02/06/02 20:50ID:???0447エアリエル
02/06/02 21:18ID:???え～っとねぇ～、まず頭で考えたのが自動的にコードになってくれてねぇ～…
>>444
504で503アプリは勝手に中央揃えになってくれると聞いた事があります。
つまり、、別の方法という事になります。
しかし、まぁたぶんDrawAreaの事でしょうね。
人づてに歪んだ形で伝わってきたんでしょう。
0448名前は開発中のものです。
02/06/02 21:31ID:???そんなに間隔を広くしちゃ、当初の目的？のAAアニメが出来ないじゃん。アニメ止めちゃうの？
細かいインターバルの単発タイマを大量につなげた際の誤差を計測するのが嫌だから止めたの？
タイマーを大量に（百個～数百個？）取得する際にトラブるのが問題だったんだよね？その線で続けないの？
上手い省略が難しいなら、元々小さなアプリだし、フル実装しちゃえば確実じゃない？
動作確認してみた？通話の割り込みなどで中断した際の復帰は正常に動作してる？
repaint()の動作、まだ解ってないみたいだね。paint()はrepaint()が呼ばれた回数だけ呼ばれるとは限らない事は解ってるんだよね？
なんか、想像以上だよ、あんた。
0449372
02/06/02 21:45ID:WLew8kMwあなたが423という家庭で話すね。
>>430の2読め
ShortTimer使わないでThread使ったらという人がいるからShortTimerを使う利点の話してるの。
話を勝手な方向に持っていかない。
＞なんか、想像以上だよ、あんた。
あんた、俺以上だよ
0450エアリエル
02/06/02 21:47ID:???(という表現が正しいかはわからないが)みたいなので、強烈にズレません？
着信時はアプリが止まってる訳だから、この時間分の誤差はどうしようも
出来ないけど、せめて着信があったその直前の値から数えないとマズイと思う。
0451名前は開発中のものです。
02/06/02 22:01ID:???ずれるって事は、復帰はするの？うちのエミュでは例外が出て復帰出来ないんだけど。
0452名前は開発中のものです。
02/06/02 22:09ID:???コードのサイズを比較したいんだよね？ShortTimerを使った場合とThreadで実装した場合で。
ならさ、それに関連する部分の必要なコードは一通り正しく実装しないとね。例えば中断からの復帰とか。現状、正しく動作しないみたいなんだけど。
インターバルが小さいままでも大きくしてもコードサイズに影響ないと思うんだけど、どうして初めの仕様から大幅に変えたんだろう？0.2秒間隔近辺の可変でも良いんじゃないの？
で、経過時間を表示する様にしとけば良いじゃん。
0453名前は開発中のものです。
02/06/02 22:18ID:???あまりに元のアプリの仕様とかけ離れてると、「こうやればコードサイズを小さくできるよ」って指摘のしようが無いんだけど。
現状のコードに対して指摘しても、「その方法は私のアプリでは使えません」って事になる可能性が高いでしょ？
0455372
02/06/02 22:46ID:WLew8kMwレジューム処理の確認をしないままUPして申し訳無い。
http://members.tripod.co.jp/mightguy/cupmen/ShortTimerVSThread3.lzh
・503, 504両対応
・レジュームの処理をする
・キー入力を受けつける
・経過時間の表示
・ShortTimerおよびThread.sleepの間隔は1000から毎回-100し、100になった段階で終了表示を行う。
・ShortTimerおよびThread.sleepと平行して画面出力を行う
DOCOMO503エミュでコンパイル後、jarファイルのサイズを比較
ShortTimer:1427byte
Thread:1695byte
となりました。
>>453
元の仕様に近づくように変更しましたが、まだかけ離れていると思う点があれば指摘してください。
0456名前は開発中のものです。
02/06/02 23:52ID:???Threadの方、修正したら1253byteになったよ。
ShortTimerの方は、さわる気にならかったよ。
■ このスレッドは過去ログ倉庫に格納されています