ｉアプリでゲーム

**利用者側** · 01/11/06 19:30

単純ではまるってなゲームつくってほしいー。

**名前は開発中のものです。** · 02/05/31 13:53

＞ヘボヘボプログラマからの信用出来ない一言でした。

本当にヘボへボだね・・・・

**378** · 02/05/31 14:01

ごめん、言い過ぎた

**エアリエル** · 02/05/31 15:01

>>378
　　　　_＿　っっ
　　　　 Gﾆ･　ヽ.、　／￣￣￣￣￣￣
　´￣＼ Gﾆ･　ノ`′＜　いぢめる？
（　へ　ヽ/　三;´￣ヽ　＼＿＿＿＿＿＿
　＼__人__.（＿＿ヽ＿

**名前は開発中のものです。** · 02/05/31 16:57

何のAAですか？ところで

＞元関係者（正確には下請け）としては、担当者しっかりチェックせい！
＞ですな。私らが関係してた時はこれでもか！というくらい厳しかったんですが…。

iAppli関連の調べものしてたらこういう書き込みを見つけたんですが、いったい何を担当してたんですか

**エアリエル** · 02/05/31 19:46

>>381
守秘義務って知ってますよね？まだ有効期間のはずなので、
とあるサービスに使うツール開発としか答えられません。

**名前は開発中のものです。** · 02/05/31 20:13

いや、そんな厳密な話しは期待してないけど。
この人ってプログラマなのだろうか？と疑問を持ったもんで。

**372** · 02/05/31 22:45

>>374
アプリを起動して３～５の何れかを押してカウントダウン開始
↓
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
俺はサンデープログラマで、なおかつ
自己流でプログラム覚えちゃったので恐らく一般的な書き方ではないです。

**372** · 02/05/31 22:45

問題を切り分けるために以下のように書きなおしました
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

何が原因なのかもう少し追いかけて見ますわ。

**エアリエル** · 02/05/31 23:34

>>383
元はデザイナー兼エセプログラマーだよん。

**エアリエル** · 02/05/31 23:50

>>381
AA…アスキーアートね…今わかった。
「ぼのぼの」のシマリスくんです。
どっかの誰かが何年か前に作ったのを使ってます。

**名前は開発中のものです。** · 02/06/01 00:18

>>372
すぐに端末のバグだとかエミュのバグだとか騒ぐのはみっともないぞ
ちょっと調べればどこでどう落ちてるのかわかるだろ

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を繰り返せばいいんじゃないのか？

**372** · 02/06/01 00:27

あのー
stimer.dispose()
した後に
getShortTimer()
してるんですけど?
dispose()が利いてないのはバグなんじゃないですか?

**名前は開発中のものです。** · 02/06/01 00:30

>>385
あのー、そこまで絞れたら、わかりそうな気がするんだけど・・・・。
何回目のgetShortTimerで落ちてるかカウントしてみた？
>>388も言ってるけど（同一のID云々は誤りだと思うけど。disposeしてる訳だから。）、毎回getShortTimerを生成し直す必然性は何ですか？ソースがあったら教えてください。
repeatをtrueにして回しとくんじゃ問題が生じるの？
エミュだと問題無い/私はエミュでしか確認出来ないんで。

それと、paint()呼出し駆動というか、この場合だとpaint()からfunc()を呼んでるけど、そういうのって良くない気がするなぁ。paint()はあくまでも描画処理関連のみ、って風には作れないもんかね。

**372** · 02/06/01 00:56

>>390
>毎回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()しなくちゃいけないですよね?

**388** · 02/06/01 01:07

エミュでしか確認してないけど、必ず100回目のgetShortTimerで落ちてる。
stimer.dispose()でメモリは解放されてるが、
内部のタイマIDは解放されないんじゃないかな。

そもそもShortTimerは何度も生成するものじゃないと思う
タイマの間隔を調整するならThread.sleep()とかでやったほうがいいんじゃないか？

**390** · 02/06/01 01:19

あ、372が先に書き込んでたね。
で、dispose()が利いてないってのはどーかなー。
エミュでもわざわざ???回目のgetShortTimerで例外発生するように作ってある？ところを見ると・・・・まあ、バグというか、そういう「仕様」なんじゃないですかね・・・・・。
本当に何十回もタイマーを作りなおす必要あるの？っていうか実機では何回目に落ちるか教えて欲しい。

あ、またレスが付いてた。

＞timerの間隔を変更するにはdispose()しなくちゃいけないですよね?

２種類の間隔が必要なら、タイマー２個（もちろん別々のIDで、複数を使い分ける/使いまわす）で済みそうだけど・・・・・ダメ？
（10種類なら10個）

73ページ見てみたけど、うーん。確かにこのゲームを何十回か繰り返して遊んでいるうちに落ちる可能性はありますね。
あるいは、Canvas１個あたりのタイマー数制限があるのかも。だとしたらCanvasごといちいち作りなおすってのはどう？（必要なら。）

ちなみに、同ページにprocessEvent()内の処理は極力短時間で終わらせろ、って書いてありますね。守った方が良いね。

**372** · 02/06/01 01:50

用意してある関数でアプリが停止するのが仕様ならマニュアルに書いておいてほしいなぁ。
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アプリは全滅しませんか?

**372** · 02/06/01 02:07

>>390 実機では何回目に落ちるか教えて欲しい。
0.2秒単位で計ってて50秒くらいで落ちるので250回くらいだと思います。

**390** · 02/06/01 02:24

「全然」関係者じゃないよ。iアプリ端末どころか、携帯電話すら持ってないぜ。（それ自慢かよ）

エミュでCanvasいちいち作りなおしを試してみたけど駄目だった。

>>395
うーん、実際にカウント表示するプログラムを動かしてくれればはっきりするんだけど・・・・250回くらいってのは、良い数字ではあるよね。255とか？

394にあるサイト行ってみたけど、推奨してる？「結果オーライ」としか読めないんだけど。
いちいち作りなおさなくちゃ正常に動きません、って風にも読めないし。
resume された時にstopしてるかどうか解らない？そうなの？startしたかどうかはフラグで判定すれば良いし、stopされたかどうか本当に解らないなら（rsume時にもstopしていない可能性があるなら）、とにかくstartを試みて例外はキャッチすれば良いんじゃ？

バグか仕様かは私の知ったことじゃないんで、メーカーに問い合わせるなりしてください。
私は、迂回策はあるだろうと意見してるだけで。
にしても、タイマー生成数限定が本当なら、正常に動かなくなるiアプリがけっこうあるかもね。

**372** · 02/06/01 02:45

眠いんで今日のまとめをして寝ます。
・ShortTimerの確保と開放を連続して行うとN504iは250回程度、504エミュで100回で例外が出て終了する。
・503シリーズ、503エミュ、F504i、D504iではこの現象を確認できず。
・マニュアルにはこの件についての記述が無い。
・372自身はバグだと思うが、ドコモの仕様説もある。

>>390
>394にあるサイト行ってみたけど、推奨してる？「結果オーライ」としか読めないんだけど。
だから、ドコモの仕様書48ページ一番上に書いてある通りのプログラムでしょ?
「タイマーのインスタンスを破棄した上で再作成する必要があります。」
timer.dispose() -> timer.getShortTimer()

>バグか仕様かは私の知ったことじゃないんで、メーカーに問い合わせるなりしてください。
朝目が覚めたら、このスレのURL付けてメールしてみます。
DOCOMOの許可が下りればここで返事を公開するつもりなので、期待していてください。

最後に...
>>390 本当に何十回もタイマーを作りなおす必要あるの？
そこにdispose()があるからです。(藁

**名前は開発中のものです。** · 02/06/01 03:04

Javaやiアプリはあまり詳しくないのだが、タイマーを何百回も
生成・破棄を繰り返さなければいけないという、プログラムの設計
自体が根本から激しく間違っている気がする。

**名前は開発中のものです。** · 02/06/01 09:43

とうとう0.2秒ごとにタイマーを作りなおす必然性が「そこにdispose()があるから」だけになっちゃったね。他にやりかたがあるって指摘しても「無視」だし。あーあ。

いわゆる「クレイマー」だったと考えるべきなのかな。
それならそうと初めから言ってくれれば、時間を無駄にせずに済んだのに。

ただ、1分に1回の割合でタイマーを再生成するプログラムだとしても約250分使いつづければ落ちかもしれない訳で、問題だろうけどね。
或いはタイマーに限らず、他のネイティブリソースと合わせて制限があるかもしれないし。

**399** · 02/06/01 10:20

>>399
×落ちかも
○落ちるかも

まぁ自分がその機種のユーザーなら、そんな「仕様」は認めたくない、文句も言いたいだろうけどね。
それならそう言って欲しいよ。0.2秒毎にタイマーを作りなおすのが正しいって言われても困る。

>>397
＞だから、ドコモの仕様書48ページ一番上に書いてある通りのプログラムでしょ?

あ、本当だ。DoJa-1.0プロファイル（503の事？）では「タイマーのインスタンスを破棄した上で再作成する必要があります。」って書いてあるね。
けど、「アプリケーションの実行が中断された場合」って書いてあるよ。0.2秒毎にイベントを発生させるのに、いちいち再作成する必要がありますとは書いてないよね。

**372** · 02/06/01 10:59

こんな簡単なことでバグるならほかの関数も怪しいよな。
504iのバグ(不具合)情報もっときぼんぬ

**名前は開発中のものです。** · 02/06/01 11:17

関数の設計を無視した使いかたして、バグるとか得意げに語られてもなぁ

**エアリエル** · 02/06/01 11:56

この話題を振った人は内部告発者と見た！
ようするにそういう問題があって、他にもまだありそうでまだ完璧とはいえないのに、
出そうという上の方針に疑念を抱く人の告発でしょう？
たしかに現実問題、意図して100回もタイマーを生成することはないでしょうけど、
長期間遊ぶ場合、着信復帰などで100回を越える事も無いとはいえないわけですからね～。
、、という事にしておこうっと。

**名前は開発中のものです。** · 02/06/01 12:38

>>401
本当に372本人？
「クレイマーってのは言い過ぎだった」って書き込むつもりで来たんだけど、ほんとうにクレイマーじみてきだぞ・・・・・

バグるっていうか、「例外が発生してる」んだよね、納得し難い。その根本原因はバグかもしれない訳だけど。
メーカーでは認識していなかったんだろうか？認識していれば簡単に修正出来そうな気はする。けど、エミュにまで「制限」を埋め込んであるのは・・・・・
これも「バグ」なのだろうか？かもしれないけど、エミュ版制限の100って数字は、意図的なものの様にも思える。
N社の端末の「バグ」取りが間に合わなくて、次善の策として？エミュ側により強い制限を組み込んだ？

372は自分の主張（の変化？）を改めて見なおして欲しい。

「以前の機種では（N504i以外では？）正常に動作していたアプリケーションが動かなくなる可能性がある」
「この新たな制限はドキュメントに記述されていないし、著しく不便だし、改善されるべきだ」
って主張に関しては、その通りだと思う。

「バグの為にオレの作りたいアプリケーションが作れない」
という主張なのであれば、そりゃ違うんじゃないかと思う。
回避は可能だし、行儀の良いコーディングをすれば、実用上は問題なく動作させられるだろう。
もちろん、だからと言ってこの制限が正当化される訳じゃないよ。
372のコードは問題提起用のサンプルとしてはスマートさに欠け過ぎというか・・・・・

**名前は開発中のものです。** · 02/06/01 13:27

確かにバグくさいが、こんなださいソース書いてる方が笑われるぞ。
このアプリでしか発覚せん可能性、十分にあり。
こんなことで文句つけるやつはWindowsなど使えん。
.NET Frameworkなんかなぁ…。ため息がでるよ。

**y2kbest@k9.dion.ne.jp** · 02/06/01 13:51

「 RX-2001 」がパワーアップした、
「 RX-2000Ⅲ 」↓
http://user.auctions.yahoo.co.jp/jp/user/NEO_UURONNTYA

店頭販売価格は、13900 円なんですが、
今回だけ、破格の 7100 円に設定して
おります。

購入希望の方は、名前の所にも書いて
ある、y2kbest@k9.dion.ne.jp 迄、
メールを下さい。

不安な方は、落札をして頂いても
構いません。

**名前は開発中のものです。** · 02/06/01 13:53

>>405
いやおそらく、単純に繰り返しShortTimer.getShortTimer()を呼び出すだけで再現できるよ。
長時間連続可動させつつShortTimerを用いるアプリでは避けられない問題、って事になるんだと思う。
また、372の様に作られたアプリが従来は動作していたものが、特定機種で動作しなくなってしまうのも、おそらく事実であり。
修正すれば実質的に回避できるとしても、修正する手間を取らせる理由が不明確。何故そんな制限が新設されたのか。

それと、MSに比べたら・・・・ってのは、本当に最後の言い訳というか。それ言ったら終わりというか。

**名前は開発中のものです。** · 02/06/01 14:23

>>407
通常の使用で100回もタイマを取得するようなことになってしまうような
コードは、俺は絶対に書かないが、世の中にはそんなプログラマが多いのか？
不思議になってくる。

**名前は開発中のものです。** · 02/06/01 14:24

っつうか、パケ代がたけーんだよ。なんとかしろ！＞NTTコドモ！！！

**407** · 02/06/01 14:47

>>408
いや、一つ間違えました。
DoJa2.0からはstart()にて復帰できる事が仕様として保証されたみたいですが、
DoJa1.0では「タイマーのインスタンスを破棄した上で再作成する必要があります。」だそうなので。
実行環境を認識し、DoJa2.0だったらShortTimerを作りなおさずに再利用する、様に作れば良いんですね。

＞通常の使用で100回もタイマを取得するようなことになってしまうような
コードは、俺は絶対に書かないが

との事ですが、DoJa1.0時代にはそれが常識だったらしいです。
まあ、「アプリケーションの実行が中断された場合」に限って取得すれば良いはずではありますが。
それでも理屈上は、何十回か（タイマー動作中に？）中断を繰り返せば、DoJa1.0時代の常識で書かれたコードはN504iでは落ちる、って事になるでしょう。

ところで>>404に
＞バグるっていうか、「例外が発生してる」んだよね
って書いたけど、実機でも例外がThrowされてる、とは明言されて無さそうですね。要確認でした。

**名前は開発中のものです。** · 02/06/01 16:44

10機種あればこの手の小バグの数が10倍になるというJavaの罠

**名前は開発中のものです。** · 02/06/01 17:28

Javaが原因ってより、
"Write Once, Run Anywhere" の幻想はハードに余裕が無いほど霞むって事だろうか。
ってゆうか、実力以上の仕事を強いられているんだろうね、製品開発を担当している人々は。バグが生じても当たり前のスケジュール、みたいな。

**372** · 02/06/01 21:05

えらい言われようの372です。
>>390
登山家に何故の山に登ると?と聞くと「そこに山があるから」と答えるのになぞらえて洒落のつもりで言ったんですが、
まじめな議論に水を差すような発言だったようで申し訳無いです。今後は冗談を控えるんでもう少し議論に付き合ってください。
>>398
あなたの主観で間違ってるといわれても困ります。具体的に説明してください。
少なくとも、俺のプログラムが何故あんなプログラムになったかは説明しています。
言いっぱなしは止めましょう。議論になりません。
俺はプログラムについていろいろ勉強したいのです。
>>400 0.2秒毎にイベントを発生させるのに、いちいち再作成する必要がありますとは書いてないよね。
将来的に0.2秒を可変にするつもりだったって説明してるでしょ?だから、必要なのです。
>>402
あなたがこの関数の設計者ですか?それともこの関数の作成意図がどこかに書かれていますか?
根拠を示してください。
>>404
>エミュ版制限の100って数字は、意図的なものの様にも思える。
その意図を公式に説明して無いから文句を言っているのです。
>「バグの為にオレの作りたいアプリケーションが作れない」
俺の主張は「俺の作った503アプリが504で動かない」です。
503用のアプリと互換性を謳っているのに504で動かないのは問題でしょ?
>>405
>確かにバグくさいが、こんなださいソース書いてる方が笑われるぞ。
バグなのと笑われるのは別々に論議しましょう。
>このアプリでしか発覚せん可能性、十分にあり。
DOCOMOが503用エミュのサンプルとして提供しているスペースインベーダーがShortTimer.dispose()で落ちます。
DOCOMOのサンプルを参考にして作ると今回の件に引っかかる可能性、十分にあり。

**372** · 02/06/01 21:09

>>408 & Thread使えばと指摘した皆さん
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と違うようですね。

**エアリエル** · 02/06/01 22:06

そういえばN503だけショートタイマーが正確ではないそうですよ。
情報ソースはこちらでふ。
http://vs.g-appli.net/tips03.html

PだけRESET_VM_EVENTが通知されなかったりとか、、
まぁ色々機種があれば色々あるわな～～、、、統一せい！（怒

**372** · 02/06/02 00:02

>>415
いろいろ制限あるんですね。商売でiアプリかいてる人は大変だなぁ。

誰も答えてくれないからShortTimerを頻繁にdisposeするのは下品だって解説してるサイト
探してるんだけど、見つからないです。
実はここのみんなに担がれてるんじゃないかって気になってきたよ。

**名前は開発中のものです。** · 02/06/02 00:30

ここでアドバイスしてくれたひとは信用ならんって訳か？
じゃ最初から他で聞けよ

**エアリエル** · 02/06/02 00:33

>誰も答えてくれないからShortTimerを頻繁にdisposeするのは下品だって解説してるサイト
>
ご要望とあらば作りますが…(笑）

**372** · 02/06/02 00:49

>>417
あなたは、ろくに理由も説明されずに人を殺せってアドバイスされたら殺しちゃうタイプですか?
ShortTimerに関しては「普通はそんなプログラム書かない」と言うだけで
何故それが普通なのか誰も解説してないでしょ？
ShortTimerバグの回避方法とか、Threadの使い道とかいろいろ参考になってるので感謝してますよ。
文句だけ言うなら他で言えよ

**名前は開発中のものです。** · 02/06/02 01:08

例えば「自動改札機の正しい通り方」なんかを解説してるサイトなんてのを探しても
おそらく見つからないわけで。

**名前は開発中のものです。** · 02/06/02 01:44

>>420
http://www.himeji-iec.or.jp/life/c_03/
これじゃ駄目？

**エアリエル** · 02/06/02 01:49

>「自動改札機の正しい通り方」なんかを解説してるサイトなんてのを探しても
>
ご要望とあらば作りますが…(笑）

、、と、冗談は置いといて、
3分クッキングでこんなに盛り上がってて楽しかったけど飽きた。
それに、夜更かしはお肌の大敵だからみんな寝ようね。
これ以上盛り上がってもつまらないので、とりあえず眠って、
頭冷やすなり、凍らせるなり、滝に打たれるなり幽体離脱してきてちょうだい。

**名前は開発中のものです。** · 02/06/02 10:03

>>413
＞将来的に0.2秒を可変にするつもりだったって説明してるでしょ?だから、必要なのです。

だからよぁ、必要無いって指摘があるでしょーが。>>393に。意味が解らない？
それとも無数のバリエーションに可変する必要があると主張するか？
最悪、最高のレゾリューション（最小の間隔、例えば100ms）のタイマー1個で済ます、って手もあるよ？

**名前は開発中のものです。** · 02/06/02 10:39

>>414
＞68ページ。paint(), repaint()は用途が違うようです。

全く同じだと思っている人は少ないでしょう。その違いは認識した上でrepaint()を用いているのが普通だと思いますよ。repaint()は、システムが負荷に応じてpaint()呼出しのタイミングを調節できるようにする為に用意されている、と認識してます。

＞意図した画面を確実に出したい場合はrepaint()ではなくpaint()を使えと書いてあるように読めます。

確実に......まあ、より確実にpaint()が実行されるのは事実でしょうね。
画面の書き換え頻度が0.2秒毎程度でpaint()以外に重たい処理を行わないiAppliならrepaint()で十分なんじゃないかとも思えるんですが、なんぜ機種毎に何が起こるか解らない端末ですから、確実性を求めたくなるのも、もっともかもしれませんね。
開発ガイドを熱心に読まれているようですね。73ページ下の注意事項も重要だと思いますよ。processEvent()呼出しからpaint()を呼び出すのは、推奨されていないんじゃないでしょうか？paint()が十分に軽いと確信されているのなら、これ以上は言いませんが。

**424** · 02/06/02 10:47

....まあ、どうせ限られたイベントしか発生しないのだろうし、タイマーでアスキーアートを書きかえる程度のアプリケーションであれば、processEvent()からpaint()を呼び出しても実害は発生しないでしょうね。余計なアドバイスでした。

**372** · 02/06/02 12:41

>>423
＞無数のバリエーションに可変する必要があると主張するか
414で主張していますが。
最小の間隔のShortTimerを使いまわすとプログラムが増えて
jarファイルのサイズが大きくなるので却下です。
パケット代も考慮しましょうよ。

>>424
素人なんで参考に出来るのがDOCOMOのサンプルとWEBの情報だけなんですが、
503エミュのサンプル
\J2MEWSDK4DOJA\apps\uidemo\src\uidemo\CanvasDemo.java
でprocessEvent内からrepaint()しているのが確認できます。

**エアリエル** · 02/06/02 13:07

あの～ところで、、503用アプリは504で中央に寄せられた形で表示されると
聞いた事があるんですが、本当ですか～？それとも意図的に中央にするメソッドか
何かがあるんでしょうか？そんなのがあるんなら教えて欲しいです～～～。

**名前は開発中のものです。** · 02/06/02 14:02

>>426
＞でprocessEvent内からrepaint()しているのが確認できます。

あなたはその例を参考にしてrepaint()を用いるようにしている、という事ですか？

>>427
>>271-275では解決しなかったという事ですか？

**名前は開発中のものです。** · 02/06/02 14:11

>>897これとかねｗ
http://freehost.kakiko.com/freen/kesaku.html

**372** · 02/06/02 14:35

>>議論に参加している皆さんへ
話がややこしくなってきているのでここで一度整理したいと思います。
1:N504iと504エミュのShortTimer.dispose()問題
dispose()を呼ぶこと自体が問題なので、
ShortTimerを使うならここで紹介された回避策を使う
Threadでタイミングを取る
という意見に俺自身納得しました。今後この件に関してはの俺のスタンスは、
プログラムのここを変更すると効率が良くなる
ほかの方法でもタイミングが取れる、といった前向きな議論以外には参加しないということにしたいと思います。

2:ShortTimer.dispose()が正常に動く端末でのdispose()の是非
>>414にて、特定条件下でのThreadに対するdispose()の利点(jarサイズ)を挙げてみました。
これに対して、プログラムの書き方次第では立場が逆転する
disposeしないでShortTimerをうまく使いまわすと効率が良い、といった議論は大歓迎です。
「俺はこんなださいプログラムを書かない」「普通はこんなことしない」といった
実例をあげない反論は無視させていただきます。
あと、「dispose()は極力避けましょう」と多くの人が言っている根拠(雑誌の記事、ネットのTips集など)を知りたいので情報をお持ちの方はお教えください。

3:その他
俺がサンプルとして書いたプログラムに関する根拠のある突っ込み(最近だと>>424)はいろいろ勉強になるので大歓迎です。

**372** · 02/06/02 14:54

>>424,428
極力短時間というのはどう解釈すれば良いんですかね?
解釈の一例として426で挙げたプログラムは参考にしています。
いろいろ指摘を受けた結果、カップ麺タイマーに関しては極力短時間の
範疇を超えてるなと現在では思っています。

**名前は開発中のものです。** · 02/06/02 15:11

>>430
>>414のサンプルを見てみましたが、repaint()について理解していない様に思えます。
それと、あなたはたしか、ある時間が経過した事を知らせるアプリケーションを作ろうとしてたんだと思います。
最低限、その機能を持たせたサンプルにしていただけますか。
現状だと、両コードが同等の挙動を示すとは思えませんし。（interval値の変化など。）
（同等の動作をしている事を画面等で確認できる様にした方が良いのでは。）
その上で、出来れば実機でのタイマーとしての精度なども合わせて評価してみて欲しいですね。
そう精密な精度を要求するアプリケーションでは無いでしょうけれど、レゾリューションが荒いと評判のiアプリ環境で、Timer（恐らくsleep()も？）を細めに無数に繋ぎ合せての経過時間算出というのは、あまり普通の方法では無い様に思えます。

**432** · 02/06/02 15:16

>>432
＞レゾリューションが荒い

タイマーの事です。

**名前は開発中のものです。** · 02/06/02 15:21

>>431
＞いろいろ指摘を受けた結果、カップ麺タイマーに関しては極力短時間の範疇を超えてるなと現在では思っています。

これまであなたは、自分は間違っていないと主張する事に一生懸命だったように思えます。気のせいでしょうか？

**エアリエル** · 02/06/02 15:45

そんな事はどうでも良い。我が問いに答えよ（笑）
揚げ足とりは”大好き”だけど、今回の揚げ物は面白味が無い。
ということで、とりあえず終わりにしませうや。
さもないと実況しちゃうよ？

**名前は開発中のものです。** · 02/06/02 15:48

>>435
>>428に答えよ。
揚げ足とりで無く、反省を促しているつもりなんだけど。今後の為に。
実況？すれば？

**エアリエル** · 02/06/02 16:08

>>436
あ～～～っと！さっそくレスが来た！！！！！（笑

まぁ～ええからええから、、人の考え方は違って当然、
その人にはその人のやりかたってものがあるんだから
ちょっと自分の気に食わん意見があってもしゃ～ないねん。
まっ気にせんとこうや～～。というわけで、我が問いに答えよ（爆
反省しろいうても、言ってる方の言う事が本当に正しいの？
言われてる方の言う事が正しいの？私はどっちでもいいし
どうでもいい。というわけで、我が問いに答えよ（しつこい(笑

**名前は開発中のものです。** · 02/06/02 16:24

>>437
はぁ。>>428に答えよ。

**名前は開発中のものです。** · 02/06/02 16:36

サンプルコードとか、落ちてないの？

**名前は開発中のものです。** · 02/06/02 16:56

エミュレーション環境ではその方法でセンタリングされたけど、実機ではダメなの？

**エアリエル** · 02/06/02 18:15

DrawAreaもいいんですが、これはJAMに情報を書きこまないといけないし、
一般的なアプリは120*130ですから、SO504iの128*128だと仕様でダウン出来ない
そうですし…(前提条件のサイズは必ずその機種の描画サイズ以下でなければいけない)
なんかこう～都合良く503.504全機種で使えるようなものはないですかね～。

**エアリエル** · 02/06/02 18:19

>>271-275では解決しなかったという事ですか？

↑この記述見落としてました。
それと該当の271～275、、忘れてました。

**名前は開発中のものです。** · 02/06/02 18:58

>>441
＞なんかこう～都合良く

ではまず、あんたの都合を教えてください

**名前は開発中のものです。** · 02/06/02 19:30

>>442
＞忘れてました。
>>427
＞あの～ところで、、503用アプリは504で中央に寄せられた形で表示されると聞いた事があるんですが、本当ですか～？

「中央に寄せられた形で表示されると聞いた事がある」ってのは結局、DrawAreaの事だったの？別の方法を聞いた事があるの？

**372** · 02/06/02 20:19

>>432 最低限、その機能を持たせたサンプルにしていただけますか。
http://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にはどこまで削れば極力短時間に収まるのか、解説願いたいですね。

**名前は開発中のものです。** · 02/06/02 20:50

なんだかなあ・・・

**エアリエル** · 02/06/02 21:18

>>443
え～っとねぇ～、まず頭で考えたのが自動的にコードになってくれてねぇ～…

>>444
504で503アプリは勝手に中央揃えになってくれると聞いた事があります。
つまり、、別の方法という事になります。
しかし、まぁたぶんDrawAreaの事でしょうね。
人づてに歪んだ形で伝わってきたんでしょう。

**名前は開発中のものです。** · 02/06/02 21:31

>>445
そんなに間隔を広くしちゃ、当初の目的？のAAアニメが出来ないじゃん。アニメ止めちゃうの？
細かいインターバルの単発タイマを大量につなげた際の誤差を計測するのが嫌だから止めたの？
タイマーを大量に（百個～数百個？）取得する際にトラブるのが問題だったんだよね？その線で続けないの？
上手い省略が難しいなら、元々小さなアプリだし、フル実装しちゃえば確実じゃない？
動作確認してみた？通話の割り込みなどで中断した際の復帰は正常に動作してる？
repaint()の動作、まだ解ってないみたいだね。paint()はrepaint()が呼ばれた回数だけ呼ばれるとは限らない事は解ってるんだよね？

なんか、想像以上だよ、あんた。

**372** · 02/06/02 21:45

>>448
あなたが423という家庭で話すね。
>>430の2読め
ShortTimer使わないでThread使ったらという人がいるからShortTimerを使う利点の話してるの。
話を勝手な方向に持っていかない。

＞なんか、想像以上だよ、あんた。
あんた、俺以上だよ

**エアリエル** · 02/06/02 21:47

現在のソースでは着信復帰時にintervalのカウントをやり直す
(という表現が正しいかはわからないが)みたいなので、強烈にズレません？
着信時はアプリが止まってる訳だから、この時間分の誤差はどうしようも
出来ないけど、せめて着信があったその直前の値から数えないとマズイと思う。

**名前は開発中のものです。** · 02/06/02 22:01

>>450
ずれるって事は、復帰はするの？うちのエミュでは例外が出て復帰出来ないんだけど。

**名前は開発中のものです。** · 02/06/02 22:09

>>449
コードのサイズを比較したいんだよね？ShortTimerを使った場合とThreadで実装した場合で。
ならさ、それに関連する部分の必要なコードは一通り正しく実装しないとね。例えば中断からの復帰とか。現状、正しく動作しないみたいなんだけど。
インターバルが小さいままでも大きくしてもコードサイズに影響ないと思うんだけど、どうして初めの仕様から大幅に変えたんだろう？0.2秒間隔近辺の可変でも良いんじゃないの？
で、経過時間を表示する様にしとけば良いじゃん。

**名前は開発中のものです。** · 02/06/02 22:18

>>449
あまりに元のアプリの仕様とかけ離れてると、「こうやればコードサイズを小さくできるよ」って指摘のしようが無いんだけど。
現状のコードに対して指摘しても、「その方法は私のアプリでは使えません」って事になる可能性が高いでしょ？

**エアリエル** · 02/06/02 22:32

>>451
実際には動作させてませんので、あしからず。
見ての通り、残りあと少しといった所で着信があったら、また最初から数え直しでしょ？

**372** · 02/06/02 22:46

>>448, 451
レジューム処理の確認をしないまま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
元の仕様に近づくように変更しましたが、まだかけ離れていると思う点があれば指摘してください。

**名前は開発中のものです。** · 02/06/02 23:52

>>455
Threadの方、修正したら1253byteになったよ。
ShortTimerの方は、さわる気にならかったよ。

**haruka** · 02/06/03 04:12

>>455
リソースの限られている機械向けのソフトウェアで、
オブジェクトの生成→破棄を必要以上に頻繁に行うっていうのが、
私にはとても奇妙に感じるのです。

Thread版見たけど、一回タイミング測る毎に
Threadを生成→破棄を繰り返してるってのは、
ちょっと普通じゃないと思うな。

**名前は開発中のものです。** · 02/06/03 08:08

>>456-457
ソースコードがみたいにゃー

**458** · 02/06/03 09:03

>>456
気になって仕事に行けねぇ(藁
せめてrun()だけでもここにはってくだちい
予想ではこんな感じか?
public void run() {
while (true){
repaint();
try {
if (interval > 100) interval -=100;
Thread.sleep(interval);
} catch (InterruptedException e){}
}
}
で、class Wを取っちゃうの。

**名前は開発中のものです。** · 02/06/03 14:28

ソースの注釈を見たところ、製作者としては時間計測の精度に気を使っているようです。
時間を正確に計りたいならもっと良い方法はあるでしょうけれど、
現在の方法でどの程度の精度が得られるのか、実機（何機種か）で評価してみていただきたいです。
カップラーメンタイマーとの事ですから、３分か５分の計測が良いでしょう。
（通話などの割り込みがあるケースは無視して良いでしょう。）
ストップウォッチを用いて、各機種ごとに10回程度計測し、....んな事、だれもやらないですね。

**名前は開発中のものです。** · 02/06/03 22:19

ル・マン24時間レースのアプリとかどうですか？

ちゃんとセーブ機能をつけないと大変なことになりますが・・・。

**名前は開発中のものです。** · 02/06/03 22:30

>>461
サーバー側で勝手に周回してるようなゲームだと良いかも。
時々アクセスして状況を見る。気が向いたらドライバー交代して運転も可能？

**372** · 02/06/03 23:27

>>457
＞私にはとても奇妙に感じるのです。
普通のプログラマが奇妙に感じるプログラムで、jarファイルのサイズ(==パケット代)が減るかも
という仮説に基づいてのプログラムしたものです。
＞ちょっと普通じゃないと思うな。
俺にはrepaint()とThread.sleep()を並列化させる方法があれしか思い浮かびませんでした。
今回の件でいろいろ勉強になりましたが、まだまだ未熟だと実感しています。
ですので、もっと良い方法があったらご教授ください。

>>459さんのプログラムに２、３行追加して、repaint()とThread.sleep()を並列化させるという方向で
>>456さん言うの方法を小一時間考えてみたのですが、俺の乏しい知識では思いつきませんでした。
降参です、>>456さんにはぜひともプログラムを公開していただきたい。お願いします。

>>460
意図を汲み取って頂けてなんとなくうれしいです。
それに、精度のこともあるけど、比較するなら同じ条件じゃないと不公平じゃないですか。
repaint()とThread.sleep()のを並列にしないなら、ShrotTimer側のresume処理を端折っても良いとか言えちゃうわけでして。

**通りすがり** · 02/06/04 00:25

>>455 さんの物を元にいじってみた。
Thread 1237byte
ShortTimer 1271byte
容量重視でいったので必要な分しか書いてません。
場違いだったら大変申し訳ない。
http://www.xoasis.com/~fnmvei/apps.zip

**名前は開発中のものです。** · 02/06/04 00:31

Thread版のclass c に対して、
変数
　volatile int n = 0;
を追加し、run() の
　repaint();
を
　n = 2;
　repaint();
　n *= 2;
に修正、paint()の先頭に
　n +=3;
を追加、func()のどこかに
　g.drawString("n:" + n, 50, 15);
を追加してみてください。
nはいくらになるでしょうか？

或いは
repaint()を呼び出しているThreadとpaint()が呼ばれているThreadは同一でしょうか？
例えばThread.currentThread().toString()などとすればThreadを識別する為の文字列が得られると思います。

実行環境によって結果が異なる可能性は、ありますね。私はiアプリ端末を持っていませんから実機での確認は出来ませんが・・・・

**465** · 02/06/04 02:25

そういう問題でも無さそうですね・・・・
じゃあ、Threadを生成するのとrepaint()、どっちが重たいか・・・・
いや、そんな事考えるより、単純に計測スタート時のSystem.currentTimeMillis()を基準にタイミング調整するように作っとけば累積誤差とか気にせずに済むんだよね。
（機種によっては、補正が必要らしいけど・・・・。）

**haruka** · 02/06/04 05:50

>>463
片方のスレッド(a)で、
Thread.sleep(...); count++; b.notify(); をぐるぐるまわして、
もう片方のスレッド(b)で、
repaint(); wait(); をぐるぐるまわせばいいんじゃないの?

wait()の方がnotifyより後に実行されちゃうとハマるから、
本当にやるならフラグ管理してwait()を飛ばす等の処理が必要になるけど。

**名前は開発中のものです。** · 02/06/04 21:54

あまりどういう事か把握できなくて何だけど
repaint() paint() で描画やら無くてもいいと思うけどこれは的外れかな・・。
paint() は repaint()によって呼ばれるとは限らなかったはずだから。

**名前は開発中のものです。** · 02/06/04 22:46

>>468
プログラムから意図的にrepaint()しなくても、例えば通話の割り込みからのアプリへの復帰などの際にシステムからpaint()が呼ばれたりする訳ですよね。
だからこそ、paint()が呼ばれた際に描画を行う事が望ましいと思うのですが。
そして、システムの都合に合わせ、無駄な再描画による電力消費を抑制する為にもrepaint()呼出しによる控えめな描画要求を行うのだと思います。
リアルタイムなアクションゲームなど、再描画がムチャクチャ激しいアプリケーションの場合は、そういう気遣いの優先順位は低いでしょうけどね。
ゆるいアプリなら、わざわざrepaint()やpaint()を無視する必要は無いと思うんですが。
もちろん、paint()では表示バッファの更新を行うのであって、オフスクリーン描画他の処理はpaint()で行う必要はないと思います。

**名前は開発中のものです。** · 02/06/05 22:58

>>372は消えましたか？

**372** · 02/06/06 02:34

>>464
この時間はサイトが重いのか、ファイルを拾うことが出来ませんでした。申し訳無い。
昼間の軽い時間に再チャレンジしてみます。

>>470
仕事で残業(泊まり)あったりするんで、皆勤賞は狙えないかもです。

>>一連のThread議論
前にも一度引用したんですが、
http://www.atmarkit.co.jp/fmobile/rensai/doja06/doja06.html#2
の●Canvas#repaint()のタイミングってところ。
この記事を信じると、repaint()で描画スレッドが作成され他の処理と並列に描画する端末と
repaint()内部でpaint()を呼ぶ端末があるように読めます。
俺の解釈では後者はThreadを使わないで描画処理していると思うんですが、
N503i,P503iを借りてきて実験してみるという環境にいません。
そこで、>>465さんの提案を誰か実際の端末(P503i, N503i)でやってみてもらえませんか?

**haruka** · 02/06/06 09:00

>>469
それはあってると思うよ。
でも同じ理由で、、
paintで描画以外の処理をやるのは、
あんまりオススメできないと思う。

意図しないときに呼ばれたり、呼ばれなかったりするわけだから。

**名前は開発中のものです。** · 02/06/06 11:32

>>472
＞でも同じ理由で、、paintで描画以外の処理をやるのは、あんまりオススメできないと思う。

オススメしてるように読める？？？
私としては、このスレでもその種のコーディング（かならず呼ばれる事を前提にした）は止めたほうがいいと何度か注意してるんですけど。名無しだから識別出来ないけど。

**名前は開発中のものです。** · 02/06/06 11:47

372って社会人なのか。てっきり学生だと思ってた。実社会には適応出来てるんだろうか。会社でもああいう調子だとしたら、同僚はストレス溜まってるだろうと思う。

**エアリエル** · 02/06/06 13:33

まるでちょっと前までの私みたい…(爆

**haruka** · 02/06/06 23:00

>>473
そういうわけじゃなくて、372がそういうコーディングしててヤバいよってのを
指摘したかっただけ。誤解するよーな書き方してごめん。

**エアリエル** · 02/06/08 12:58

ちょっと！ヤバイだとかウソツキとかいう表現
どうしてそういうことが言えるんですか？
とか言ってた人がいたな～～。。。