ｉアプリでゲーム

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

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

**名前は開発中のものです。** · 02/05/26 00:39

>>322
＞損はないんじゃないのかな

時間の損

>>321、例えばどのメソッド？

**haruka** · 02/05/26 01:26

>>319
Sunが提供しているすべての機能を覚えてからでないと
DoJaを勉強できないってなったら、
いつまでたってもDoJaを勉強できないよ。

AppletとDoJaは無関係なものなので、
別にApplet→DoJaの順に勉強する必要はないよ。

**エアリエル** · 02/05/26 02:06

タマゴが先か鶏が先か…　　ブツブツ…。

**名前は開発中のものです。** · 02/05/26 02:07

うむ。Sunの組み込み機器向けJavaプラットホームJ2MEと、
同じくSunが決めた小型端末を想定したコンフィギュレーションCLDCの上に、
NTTドコモ独自のプロファイルを載せてるのがiアプリの環境でし。

アプレットを含む標準のJ2SEとは、根っこから別階層でし。

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

アプレットくらいJavaを扱うものとして
出来て当たり前だと思われ。

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

>>327
本気で言ってるの？単なる厨房？

**326** · 02/05/26 02:30

>>327
あー、その妙な信念はどっから来るかなー。
Javaの仕組みと現状の理解に激しく勘違いがありそうな予感。

**名前は開発中のものです。** · 02/05/26 03:09

だってアプレットなんて超簡単じゃん。
そこらへんのネット講座を見ればすぐ理解できるんだから
普通の人は出来るはず。

**エアリエル** · 02/05/26 08:44

>>330
>だってアプレットなんて超簡単じゃん。
そうなの？ふ～ん、、ヒマがあれば一度やってみたいもんだな～。
参考までに、ココはわかりやすいぞ～ってHPがあればご紹介を。

いつかそのうち３Ｄのゲームかなにかをつくるんだぃ！＜願望
まっその時の基礎知識の一つとして学んでおいて損はない。

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

>>330
やっぱりそうきたか・・・・
簡単に出来るからってやっとかなきゃダメな訳じゃないだろーに
ハァ・・・

**名前は開発中のものです。** · 02/05/26 09:44

>>330＝引っ込みがつかなくなった>>310と見た。

まあ、なんだ。ﾏﾀｰﾘと卓球でもしようぜ。
( ´ー)ρ┳┻┳°σ（ー｀ )

**名前は開発中のものです。** · 02/05/26 18:47

>>315
体験版公開の反響はありましたか？販売数が伸びた、とか....
私は、端末持っていないんで。

**エアリエル** · 02/05/26 21:01

>>334
ＨＰ来客数が倍になったくらいかな…？
今回は504狂想曲の真っ只中なもんで
思ったほど足を運んでくれる人が居ないのよね～
しかたない…もうちょい宣伝してくるか…。

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

>>323
drawImageで画像内の任意の位置からコピーしたり拡大縮小したりとか。
あとImageを新たに作成できないのにはかなり焦った。
504で少しはまともになってるみたいだけど
圧倒的に多い503ユーザーを考えると難しいな。
っていうか便利なメソッドたくさん作れとは言わないから
グラフィックメモリにダイレクトアクセスできるようにしてくれてたらよかったのに。

>>315
私も実機がないのでえみゅで動かしてみたんですが
速すぎてゲームになりませんでした(^^;;
forでウエイトとるよりもスレッドでやった方がいいかも。
それとも最適化のためにわざとこうしているんでしょうか？それならすみません。

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

Z3Dあたりに挑戦する予定は？
新製品買ったユーザーはとりあえず売りとなる機能を試したがっている、自己満足したがってる、やや金銭感覚が麻痺しているだろうから、特定機種向けであってもそれなりの需要が期待できると思うんだけど。
今から準備するのではお祭り需要を捕まえるのは難しいか・・・

**名前は開発中のものです。** · 02/05/26 21:40

>>336
＞あとImageを新たに作成できないのにはかなり焦った。

その辺りはAppletと比べてどうこう、って話しじゃないと思えるんだけど。

ウェイトはTimer使えば良いんじゃないのかな

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

>>338
dojaはcreateImage(int,int)ができないことを言いたかったんだけど
もしかして見当違いなこと言ってるかな。javaはほとんど知らないのですまそ。
503実機のTimerは分解能がやばいらしい。100msの機種とかあるしみたいだし。
Thread.sleepも全機種でちゃんと指定した時間sleepしてるかはわからないけど。

**エアリエル** · 02/05/27 00:26

>>336
>それとも最適化のためにわざとこうしているんでしょうか？それならすみません。
それよりどうして私のウェイトのとりかたを知ってるんだよ！
とツッコミを入れたいんですが…。
いかんよ～リバースなんたらーは。

**haruka** · 02/05/27 00:48

TimerでもThreadでもどっちでもいいよ。

私は、
long a, b;
while (true) {
　a = System.currentTimeMillis() + 50;
　　　　　/*ゲームの処理 */
　b = System.currentTimeMillis();
　if (b < a) {
　　try { Thread.sleep(b - a) } catch (Exception e) {}
　}
}
ってやってるけど、
currentTimeMillisの精度も機種によって違うんだよねえ…

>>339は正しいよ。

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

a-bでは

**haruka** · 02/05/27 03:28

>>342
あああ本当ですね。ごめん…

**名前は開発中のものです。** · 02/05/27 11:04

ShortTimerで100ms間隔とかにしたとき、100ms以上の負荷かかると
イベント溜め込んでいって操作不能になるのって解決策あります？

今はメインループ中にThread.sleep(100);でやってます。悲しい。

**名前は開発中のものです。** · 02/05/27 12:50

>>344
>>341の様な方法で良いんじゃないの？

遅い機種向けには、出来ればTimerの使用は避けた方が良いっぽいみたいですね。（十分に軽い処理内容でない限り？）

ところで、100ms以上かかる処理を100ms毎に発生するイベント全てについて行い、イベントが並列に発生しないなら、溜まって行くのは当然のような、そうでなければ溜まらないような気がするのですが、そういう事では無いんでしょうか。

**名前は開発中のものです。** · 02/05/27 17:08

waitつきのメインループを別スレッドで回して
ShortTimerのイベントからnotify呼んでやれば処理落ち対策もオッケー！とか思ったけど
やっぱり駄目なのな（N503i）。一体どないなってんねん。

**エアリエル** · 02/05/27 22:20

>>346
notifyって何？

ShortTimer使ってタイマーイベントでaを0からカウントアップさせるようにする。
メインの処理をaが0の間は処理しない（処理待ち状態）ようにする。
タイマーイベントが呼び出されaがカウントアップされ1になる。
メインの処理を行う。処理が終わったらaを0にする。
そうすれば、if(a>=1)を使って一定間隔（か、それ以上）で処理する事が可能なはず。

負荷が高くてイベントが発生しない場合、、これはもうどうしようもない。
そのまま処理続行！。
逆に負荷が高くても一定間隔でイベントが発生するなら、例えばaが2とか3とか
になってたら、次の処理をスキップさせるとか、、。

**名前は開発中のものです。** · 02/05/28 05:40

Synchronizedブロック内でフラグチェックした上でwait/notifyすれば良さそうに思えるけど、スレッドスケジューリングの実装次第（VM次第）では上手く動かない、のかな？
とりあえず、>>341の様な処理が無難っぽいけど。

**名前は開発中のものです。** · 02/05/28 09:56

>notifyって何？
Javaに標準で乗ってるスレッドの同期取りの手段でございまする。
CLDCのAPIドキュメントのObjectクラスをご覧下さいまし。

ってなるへそ、カウンタ作ってポーリングする手もあるですな。
下手にネイティブな機能に頼らないぶんいいかもしんない。試してみよっと。

**エアリエル** · 02/05/28 11:32

>>349
ほうほう、にゃるほど。
そんなのがあったんですね。

***
おのれアプリゲット！さらし物にしてくれるとはどういう了見だ！？
いやねぇ、、この世界、本名さらされたからといって、どうってものでもないかも
知れないけど、さらすのは私本人がやるべきことであって、関係の無い第三者が
許可もなくさらすのは犯罪だぞ。くそっ！

**名前は開発中のものです。** · 02/05/28 11:54

ポーリングはどうやってやるの？
ループの中でsleepでもするの？

**名前は開発中のものです。** · 02/05/28 12:02

while (a == 0) {}
と見た。aはvolatile宣言しとかにゃ駄目かな。

**エアリエル** · 02/05/28 14:13

volatile宣言もわからん…（苦笑
ダメだこりゃ。

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

たしかにダメかも。「ダメだこりゃ。」って書き込んでいる間にも調べられる事だもんね。

**エアリエル** · 02/05/28 17:43

>>354
見捨てちゃイヤ～ン♪(笑
今すぐ使用する必要があるなら調べるけど、そうじゃないのなら時間をかけてまで
調べる必要はない…という損なスタンスなもんで、、、失礼しました。

***
アプリゲットから謝罪の電話があったなり～
私の名前が漏れてるだけといったクダラナイことでも6時間も放置すな！
と言いたい、、言ったけど(笑

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

しかし、どこここで本名が漏れてます、とここで自ら晒すってのは、是非本名を知って欲しいって事だと思うんだけど。
興味無いから調べなかったけど。

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

>>355
Google ToolBarでもインストールして、知らないキーワードは即検索するクセを
付けるといいよ。一見、必要のないように見える知識こそ、あとで重要になったり
することが多いから。

スレと関係ないのでsageときます。

**エアリエル** · 02/05/28 19:53

>>356
ぐさっ！そんなするどいツッコミをいれなくとも、、パタッ。
ぽくぽくぽくちぃ～ん♪あいはてもうした。
、、と、冗談はおいといて、調べるということはHP見てくれると
いうことなわけで、、見てくれたらひょっとしたら買ってくれるかな～と。

さて、、それにしても、ただ「申しわけございません。」かな～？それとも
「何アクセスありました～申し訳ございません。」かな～？
きちんと誠意ある対応をしてくれるかで今後の行動が決まるんだけどな～♪

**エアリエル** · 02/05/28 21:00

>>357
Sleipnirブラウザ使ってるから検索しようと思えばいつでも出来るんですけど、
こういうのは御堅い仕様書みるより、人から優しく教えてもらった方が、
多少間違ってても覚えやすくていいんですよ～。

ところで、、504公式エミュレータで音鳴らせるの？
某有名メーリングリストで音が二つ同時に出ません何が原因でしょうか？！
って質問があったんですけど…、、ウチはそれ以前の問題で音出ないんですけど…。

**haruka** · 02/05/29 01:18

>>355
もう見捨ててますよ。

>>352
ポーリングは電池消費するよ。
だから普通はそこで wait/notify を使うんだよ。

**名前は開発中のものです。** · 02/05/29 01:25

ていうか、wait/notifyで駄目だったからって話でしょ？
電池の消費量についてはハードウェアとOSとVMの設計によると思われ。

**haruka** · 02/05/29 01:50

wait/notify が駄目だったのか、
>>346の書いたコードがバグってたのか
それともN503iでは他のところにヘンな部分があってうまく動かないのか
全然切り分けできてないじゃん。

wait/notifyみたいにVM仕様の基本的な部分がバグっているってことは
さすがにないんじゃないかって思うんだけど。

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

>N504i(4) 544 200 300 100 800 175 2350 350
　
KVMMarkからだけど、System.currentTimeMillis()の精度は
相変わらず100msくさいですな。とほほ。

**名前は開発中のものです。** · 02/05/29 12:11

>>346は「どういう風にダメ」だったんだろうか。他の機種やエミュレータでは動いたんだろうか。周期を十分に遅くすると動くんだろうか。

**346** · 02/05/29 13:41

不安になってきたのでｻｸｯと再実験してみた。こんなんでどう？
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();
}

**346** · 02/05/29 13:42

public synchronized void run() {
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);
}

**346** · 02/05/29 13:42

public synchronized void processEvent(int type, int param) {
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();
}
}

**346** · 02/05/29 13:50

んでもって、wait・notify使わないポーリング方式も試したけど同じ結果ですわ。

**346** · 02/05/29 20:41

ってこれ、よく見たら思いっきりsynchronizedの区間がまずいわ。
鋭意修正中。

**名前は開発中のものです。** · 02/05/29 23:11

>>232
米Nazomi社，英ARM社を特許侵害で提訴
http://ne.nikkeibp.co.jp/DSP/2002/05/1000012875.html

＞Nazomi社は明言していないものの，ARM社が自社のCPUコア向けに開発したJavaバイト・コードのアクセラレータ回路「Jazelle」を対象しているとみられる。

Jazelleが訴えられたっぽい。
既にJazelleの採用された携帯は存在するのだろうか。
ところでNazomiって、謎だね・・・・寒・・・・いや、NAOMIの・・・・あぁ・・・

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

拡張API、とりあえず3D部分は全機種で使えるみたいね。
見たとこ癖のないごく普通の3DAPIだし、割と面白そう。

さて何を作ろう。

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

携帯・PHS板とマルチポストになってしまいますが、お尋ねしたいことがあります。
俺の作ったiアプリ、503シリーズ、F504i、D504iでは動くんだが、
N504iは途中で止まってしまいます。
http://mightguy.tripod.co.jp/cupmen/
リンク先にソースも置いてあります。
何か気がついたところがあればアドバイスお願いします。

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

＞が出て止まってしまいます(噂のフリーズバグなんだろうかねぇ？)。
＞もしバグだったら、NECは謝罪と補償(ホームラン軒味噌味)をしる(藁

だってさ・・・・・ﾊｧ

**haruka** · 02/05/31 09:54

>>372
せめてどういう操作したら止まるのか書いてよ。

とりあえず
　stimer.stop();
　stimer.dispose();
　stimer = null;
のあたりとか、
　stimer = ShortTimer.getShortTimer(this, 0, timerSpan, false);
　stimer.start();
が強烈に怪しいので、
メソッドprocessEventとfuncを synchronized にしてみたら
直ると思うんだけど、どうかな?

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

バグの噂とか立ってるんですか？噂のソースを教えてください。

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

>>372

Doja2.0ドキュメントによると

＞getGraphics
＞public Graphics getGraphics()キャンバスに描画するためのグラフィクスオブジェクトを取得します。取得されたグラフィックスオブジェクトは初期状態になっています。
＞[DoJa-1.0]
＞getGraphicsメソッドを呼び出すたびに新しいオブジェクトを生成するのか、予め確保したオブジェクトを再使用するのかは機種依存です。
＞[DoJa-2.0]
＞getGraphicsメソッドを呼び出すたびに新しいオブジェクトを生成して返します。

って事なんだけど。
タイマー（とキー）イベントのたびにGraphicsオブジェクト作ってるみたいだけど、そーいうもんなの？
あと、repaintで無くpaintを呼び出すのはiAppli的には普通なの？

いちいちAA[]を作りなおしてるのはどうなんだろ。っていうか全体的に...

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

stimer.dispose();
stimer = null;
ここだと思う…。
disposeして存在を消し去ったのに、それに対しnullを入れようとしている…。
っていうか、null必要無いような気もするし、順番逆の気もするし…。
あり？paintメソッドを意図的に何回も呼び出す（生成）していいんだっけ？

それにしても、一般的なiアプリの作り方はこうなのか…
私はcのなかでg = this.getGraphics();としてpaintメソッドは空にするやり方だな～

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

**名前は開発中のものです。** · 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分クッキングでこんなに盛り上がってて楽しかったけど飽きた。
それに、夜更かしはお肌の大敵だからみんな寝ようね。
これ以上盛り上がってもつまらないので、とりあえず眠って、
頭冷やすなり、凍らせるなり、滝に打たれるなり幽体離脱してきてちょうだい。