JEvaHz Messages 1062-1080

about contact links home tools todo search

Panel-Canvas Switching


[JavaHz:1062] Panel-Canvasの切り替え
Panel-Canvas Switching

おはようございます。

Good Morning.

スレッドの扱いで、ちょっとわかりそうにないのでご質問させていただきます。

I'm not sure I fully understand thread-handling, so if you'll
allow me to ask a question....

今作成中のプログラムは、パネル、キャンバスの2画面あって、
始めにパネルでユーザー情報などを入力して、SoftKeyで
キャンバス画面に移り、画像の点滅、キーによる画像の移動をします。

In a program I'm putting together now, there are two images,
one a panel and one a canvas.  Initially, in the panel,
user information is entered; moving to the canvas image is
by soft key; image switching is done with an image
toggling/switching key.

画像を点滅させるためにThread(Runnable)を入れたのですが、パネル画面に戻る時に、
パネルとキャンバスがうまく切り替わってくれません。半分の時間ずつ両画面が表示され
ます。

In order to make the image switch, "Thread(Runnable)" is called.
However upon returning to the panel image, the Panel and Canvas won't
switch -- every other time, both images show up.

これは、threadを殺していないために当然だと思いますが、Thread.stop()
が見つからないので対処できないでいます。

This is done, I think, in order that the thread not be
killed, but it can't be handled because Thread.stop()
can't find it. [Can't find the thread?]

Threadを止めるにはどうすればいいのでしょうか?

So I wonder: what's a good way to stop a thread?
 
(shorttimerを使うという方法も考えられますが)

 (Maybe some way using shorttimer is possible?)
 
宜しくお願いいたします。

Best Regards,

Tsutomu Okumura





Re: [JavaHz:1062] Panel-Canvasの切り替え
Panel-Canvas Switching

Ken Morishita 

森下です。おはようございます。
Mori here.  Good morning.

方法はいろいろあると思いますが、例えば、 run() の中で、

There are several ways, I think; for example, during run():

while (flag) {
画像の点滅 [switch between images]
}

という風に書いておき、
Threadを止めたいときは flag = false にする
という感じではどうでしょうか。

How about setting flag = false when you want to stop the
thread?


>  (Maybe some way using shorttimer is possible?)

どちらかというと、
画像の点滅だけならばこちらの方が簡単にできるように思います。

I think if it's only for alternating images,
this is the simplest way to do it.

Ken "Come Through" Morishita 



From: Saga
Sent: Monday, May 21, 2001 7:34 PM
Subject: Re: [JavaHz:1062] Panel-Canvasの

sagaです。

Hi, Saga here.

この場合、スレッドである必然性は全くなく
、というよりスレッドを使用すべきケースではありません。

This is a case where threads aren't absolutely necessary; i.e.,
you don't really have to use them. 

オリジナルメールにある通り、ここは(CLDCでは)
タイマーを使用すべき箇所です。

As mentioned in the original mail, this is one place
where (with CLDC) you should use a timer.

お勧めしませんが、どうしてもスレッドで実装したいというならば、
スーパークラスのObjectのメソッドを調べて下さい。

If you insist on using threads no matter what,
check into the superclass methods.

同期取りとしてモニタとフラグを使用すること
となりますが(勿論、synchronizedです)、画面切り替
えにユーザーイベントがトリガとなる場合、タイミングのずれは生じます。

It it's decided to use a flag and synchronous monitor
(naturally, it's "synchronized"), if a user event is triggered
in image-switching, a timing discrepancy will arise.
[Translator: had trouble here.]

もしくはThread.sleep()かThread,yeild()を使用できるでしょう。

Or I guess you could use Thread.sleep or Thread.yield.

ちなみに、Javaの場合、suspend, resume, stop系は推奨外メソッド
となっています(モニタロックの整合性の問題がある場合です)。

By the way, in Java, suspend, resume and stop have become
deprecated methods.  (There are some problems with monitor
lock integrity.)

使用できるのはinterruped()くらいでしょうか。

Among the ones you can use: "interrupted", or something like that?

とはいっても、この機構をうまく実装
しているスレッドライブラリ自体少ないのですが。

In any case, it's unusual to find this sort of
functionality well-packaged in thread libraries.

参考になりましたか?

Has this helped?



[JavaHz:1062] Panel-Canvasの
Tsutomu Okumura

森下さま、sagaさま、ありがとうございました。たいへん参考になりました。

[Code-god] Morishita, [Code-god] Saga, thank you - you've
really helped me.

Javaに対するスレッドのイメージがわかってきました。

I've really gotten a better picture of how Java threads work.

きっぱり言っていただけると、助かります。

Your clear explanation has saved me, here.

shorttimerを使う事にします。

I'm going to use shorttimer.

 奥村 勉

 Tsutomu Okumura


iAppli string-splitting



Kenichiro Ueda
[JavaHz:1066] Re: iアプリでsplit
Re: iAppli split

植田ですえ。

Ueda here.

> JavaではstringTokenizerクラスがあると思いますが、
> iアプリではありませんよね。
> なにかいい方法はありませんでしょうか?

> I think there's a stringTokenizer class in Java, but
> not for iAppli.
> What's a good way to do this, I wonder?

> ・・・やはり自分でクラスを作るべきなんでしょうかね。

> ...I wonder if I'll have write my own class?

セパレータ文字が決まっているのなら、String#indexOfを使って
切り出すクラスを作るしかないと思います。

If you decide on a separator character, and use String#indexOf,
I don't think you need to make a separate class.

ただ、クラスを作るとjarサイズが増えるので、
メインクラスの内部にメソッドを作って実装するほうがいいと思います。

Also, if you make a class, the Jar file size increases;
so I think this is better packaged as a main class method.



[JavaHz:1065] iアプリでsplit
iAppli split

こんにちは。

Hello.

(まだ発言できるスキルではありませんが。)

 (I'm still kind of a klutz about expressing myself here, but....)

自分の場合はjdkのStreamTokenizer.javaを参考にして、
StreamTokenizerもどきを作成しました。機能は制限してますが、
これがないと結構不便ですね。だいたい150行位になりました。

In my case, by looking at the JDK's Java implementation of it, I've
put together a kind of "toy" StreamTokenizer.  The functionality
is limited, but doing without it is rather inconvenient.  It
ended up being about 150 lines.

 奥村 勉

 Tsutomu Okumura



RE: [JavaHz:1065] iアプリでsplit
iAppli split

[From Shouichi Ichinose]

結局、クラス内に簡単なメソッドで実装する道を選びました。
ありがとうございました。

I chose implementing this with a simple class-internal method,
after all.

ところで、iアプリでVectorオブジェクトは利用できるのでしょうか?

By the way, can I use Vector objects in iAppli?






[JavaHz:1074] Re: iアプリでsplit
iAppli split

Kamei-san says:

>ところで、iアプリでVectorオブジェクトは利用できるのでしょうか?

> By the way, can I use Vector objects in iAppli? 

java.util.Vector
で使えます。

Yes.  Use java.util.Vector.



This week's off-line meeting




[JavaHz:1069] 今週のオフ会
This week's "Off" meeting.

陸@JavaHz管理人です。

This is Riku, from JavaHz management.

今週も、小オフ会をやりたいと思っています。

This week, we were thinking we'd like to have a small off-line meeting.

特に幹事がいるわけではなく、誰もが都合のいい時間に来て、都合のいい時間に帰る
というゆる〜い会です。

It's not like I'm especially a manager or anything, so this is going
to be a pretty relaxed event, with people just coming and going whenever.

前回は「こすり系iアプリ」のいわきさんを始め、何人かの方がいらっしゃって、
ディープに盛り上がりました。

Last time, when Iwaki-san ("polishing iAppli") started, we 
had a lot of people showing up.

今週も、すでに何人かの方から「行きます」とのご連絡を頂いています。

This week, we have already received quite a few RSVPs.

「ギガアプリ袋」「ギガ払い」について直接聞いてみたいという方や、僕の新作
ジョークアプリを見たいという方も(いないと思いますが)、ぜひいらしてくだ
さい。

People who want to hear straight from the horse's mouth about
the "GigaAppli bag" and about "GigaPay" -- AND anyone who wants
to see my latest JokeAppli (probably nobody, but anyway...) --
by all means, please come.

時間  5月24日(木曜日) 21:00頃から適宜集合、適宜解散

When: May 24th (Thu), from about 9pm to whenever we have to break up.

場所  SWEET JANE  
Where:  SWEET JANE

http://www.mapfan.com/map.cgi?MAP=E139.43.2.3N35.38.32.4
  恵比寿駅東口交差点(富士銀行のある五差路)の、
  Kinko'sと煙草屋に挟まれた細い道をまっすぐ100mほど
  進みます。右手に京内科というお医者さんがあり、その隣です。
  Cash on deliverでビールがハーフサイズで500円〜です。
  パブなので食べ物はあまりありません。

From Ebisu stn east exit crossing (5-way Xing at Fuji bank),
Go straight up the narrow road between Kinko's about 100 meters.
There's a clinic on the left hand side; it's right near there.
Half size beer is 500 yen ("Cash on delivery").   It's a pub,
so there really won't be much food.

お待ちしています。

We'll be waiting for you.


BASIC registration



[JavaHz:1070] BASIC認証について
About BASIC registration


加藤と申します。よろしくお願いします。

My name is Kato.  Nice to meet you all.

業務で、iアプリとWEBサーバのBASIC認証が設定されているディレクトリへ
配置されたServletとのHTTP通信を実現したいと考えておりますが、
どのように実現するか悩んでいます。

As part of my work, I've been thinking of implementing
a directory of settings for iAppli and Web server basic registration
of servlet-to-HTTP communications.

その方法などをご教授いただけないでしょうか?

I wonder if people could tell me a good way to do this?

ドコモの開発ガイドなどを調べたのですが、
全く、情報がない状態です。

I've checked the DoCoMo developer's guide but it seems
there really is no information.

また、HttpConnectionのsetRequestPropertyメソッドを調査しましたが、
「Content-Type」と「If-Modified-Since」しか設定できないと記述されています。

Also, I've looked into the HttpConnection setRequestProperty method,
but it's described as not allowing settings except for "Content-Type"
and "If-Modified-Since".

#iモード対応Javaコンテンツ開発ガイド P120より

# According to "i-mode-compatible Java content developers guide," p.120

以上です。

That's all for now.



[JavaHz:1070] BASIC認証について
About BASIC registration

亀井といいます。
> また、HttpConnectionのsetRequestPropertyメソッドを調査しましたが、
> 「Content-Type」と「If-Modified-Since」しか設定できないと記述されています。

Kamei writes:
> Also, I've looked into the HttpConnection setRequestProperty method,
> but it's described as not allowing settings except for "Content-Type"
> and "If-Modified-Since", .

試してはいませんが、ガイドによると無理そうですね。

I haven't tried this, but according to the guide, it's impossible.

もし、どうしてもBASIC認証をやりたいというので有ればHttpCennectionの実装
クラスを継承するクラスを作り、setRequestProperty()をオーバーライドして
Authorizationヘッダを設定できるように実装するしかないのではないでしょう
か。

If you want to make a BASIC registration regardless, make a
subclass of HttpConnection, override its setRequestProperty so
that you can set the Authorization header - I think this is about
all you can do.

ただし、setRequestProperty()の中でprivate宣言されたメソッドを
呼んでいる場合はアウトです。private宣言されているメソッドは継承出来ませ
んから。

However, declaring a method "private" in setRequestProperty() is
definitely out; methods declared "private" can't be inherited.

その場合は、setAuthorization(String s, String s1)と言う専用メソッドを作
るとか・・・実装しようがないですね。

In this case, making a special "setAuthorization (String s, String s1)"
method ... you'll have to implement this yourself, right?

あとはopenOutputStream()でヘッダ情報、ボディ情報をまとめて送るとか、
と言いたいところですが調べてみるとこのメソッドではヘッダ情報は送れないみ
たいですね。

After that, use openOutputStream, collect and send header and body
information - or so I'd like to suggest, but this method would seem to
be incapable of sending send header information.

違う方式を考えるしかないのではないでしょうか。

I really don't know if there's any other way...



[JavaHz:1078] Re: BASIC認証について
About BASIC registration

はじめまして。うえのと申します。

How do you do.  My name is Ueno.

> また、HttpConnectionのsetRequestPropertyメソッドを調査しましたが、
> 「Content-Type」と「If-Modified-Since」しか設定できないと記述されています。
> #iモード対応Javaコンテンツ開発ガイド P120より

> Also, I've looked into the HttpConnection setRequestProperty method,
> but it's described as not allowing settings except for "Content-Type"
> and "If-Modified-Since", .


 現在ドコモの公式サイトに掲載されている「iモード対応Javaコンテンツ開発ガイ
ド(詳細編)1.0版」の P.79 に、

Currently, According to the "i-mode-compatible Java content developers guide
(detailed edition)" version 1.0, p. 79:

---- 引用開始 -----
アプリケーションがアクセスするURL には、サーバー側で基本認証(BASIC 認証)
の設定が行われている場合があります。このようなURL にアクセスした場合、携
帯電話は自動的にユーザーID とパスワードの入力を促すダイアログを表示します。
アプリケーションが独自の処理で基本認証の情報(Authorization リクエストヘッ
ダなど)をサーバーに送信することはできません。
---- ここまで -----

----- start quote -----
With a URL accessing an application, "BASIC" registration
settings are done on the server side.
With this kind of URL access, there is an automatic user ID
and password dialog with the mobile phone.  An application
cannot send to the server its own, independently-arranged
basic registration information (e.g., "Authorization request
header," etc.) 
------ end quote ------

 となっているため、プログラムの中では意識することなくユーザ認証を行うこと
ができると思います。

...and in order to have this, the program has to be able to
run without knowing about registration.

ただし起動毎にユーザがユーザ名とパスワードを入力する必要
があると思います。(手元に実機がないため確認できていませんが。)

However, prior to starting, I think it's necessary for the
user to enter user name and password.  (Without some authentication
mechanism at hand, it can't really verify anything.)

 ただし iアプリの中でユーザ名とパスワードをセットし、Basic 認証に使用すると
いう目的でしたら、文章の後半部分から考えて不可能だと思います。

On the other hand, setting username and password in an iAppli,
with the goal of BASIC registration, is (because of the second
part of the above quote) impossible, I believe.







[JavaHz:1079] Re: BASIC認証について
About BASIC registration

加藤です。

Kato here.

亀井様、うえの様、本当にありがとうございます。

Kamei-san, Ueno-san, I'm really grateful.

「iモード対応Javaコンテンツ開発ガイド(詳細編)1.0版」の内容
を実機でテストしてみます。

I'm going to try testing the authentication described in
"i-mode-compatible Java content developers guide (detailed
edition) version 1.0"


テスト後、結果報告します。
(機種依存などあれば、それも含めて)

After testing, I'll report on the result.
(Including any device-dependencies I find.)







[JavaHz:1080] Re: Re: BASIC認証について
Re: about BASIC registration

亀井です

Kamei here.

以下、うえのさんの発言から引用
> 現在ドコモの公式サイトに掲載されている「iモード対応Javaコンテンツ開発
>ガイド(詳細編)1.0版」の P.79 に、
昨日、自宅に帰ってからぱらぱら見ていたら偶然私も発見してしまいました。
対処法あったのね・・・

Ueno-san wrote, in part:
> Currently, According to the "i-mode-compatible Java content
> developers guide (detailed edition)" version 1.0, p. 79:
Yesterday, after getting home and really groveling over this one,
I ended up running across the same thing.  Looks like there
really is a way.....

でもレスポンスヘッダは何でも読み込むことが出来るのに
リクエストヘッダは2つに制限されていると言うのはちぐはぐな感じがしますね。

But, even though you can read the response header, it seems
there are two ways in which the request header has been
restricted.

プログラミング的にはリクエストヘッダを無制限にするという方が簡単で
むしろ2つに限定するというのはわざわざ条件文を入れてあげないといけない
はずで、そこまですると言うことは(Docomoに)何か考えがあっての
ことなのでしょう。

From a programming point of view, you'd think it would have been
easier to leave it unrestricted, rather than having to write
two conditional statements; DoCoMo must have had something in
mind to put us through all this....

Having said that, I wonder if this is one of those i-mode
server restrictions?  Just a thought....

> テスト後、結果報告します。
> (機種依存などあれば、それも含めて)

> After testing, I'll report on the result.
> (Including any device-dependencies I find.)

私も知りたいので宜しくお願いします。

I'd also really appreciate hearing back about this.



Audio data?



[JavaHz:1073] 音声データとは?
Audio data?

Takashi Suzuki

初めまして。
鈴木と申します。

My name is Suzuki, pleased to meet you all.

今、DOCOMOから公開されている、「iモード対応Javaコンテンツ開発ガイド〜詳細編〜」を
見ているのですが、その中の69P「マルチメディアデータの使用」の項目内で、

Recently, I'm looking at DoCoMo's recently released "i-mode-compatible Java
content developer guide - detailed edition"; in the section "Using Multimedia
Data" (p. 69), it says

「iモードJavaアプリケーション環境では、アニメーションを含む画像の表示や
 音声ファイルの再生を行う機能が提供されます。」
 (iモード対応Javaコンテンツ開発ガイド〜詳細編〜より引用)

 "The i-mode Java application environment offers functionality
 for replay of audio files and displaying animations."

とあるのですが、「音声ファイルを使用したサンプル」を見てみますと、MLD形式の
ファイルを再生しているのです。

However, when I went to look at "Using Audio Files", it's MLD format files
that are being replayed.

私は、このMLD拡張子のファイルは、iモードの着メロで使用されているMIDI形式の亜種かな…と
考えているのですが、この形式で「音声」は再生できるのでしょうか。

To me, this MLD extension/subset file....I'm wondering if it's a MIDI-oid
variant of the chakumeru format being used in i-mode - maybe it can replay
files in that format?

以上、よろしくお願いいたします。

That's all.  Best regards.

それでは失礼いたします。

I'll be out of your way now.




Re: [JavaHz:1073] 音声データとは?
Audio data?

----- Original Message -----
From: "Takashi Suzuki" 
To: 
Sent: Wednesday, May 23, 2001 1:35 PM
Subject: 音声データとは?

> 私は、このMLD拡張子のファイルは、iモードの着メロで使用されているMIDI形式
の亜種かな…と
> 考えているのですが、この形式で「音声」は再生できるのでしょうか。

> To me, this MLD extension/subset file....I'm wondering if it's a MIDI-oid
> variant of the chakumeru format being used in i-mode - maybe it can replay
> files in that format?

緑川です。

Midorikawa [?] here.

たしか「16bit,8000Hzモノラルで約2.4秒」のような制限?はあると思いますが、音
声ファイル?というかwaveファイルなどから変換することは出来ますよ。ただし同じ
503系でも機種によりFM音源系とADPCM系の2種類あるから1つのMLDで全機種OKとは行
かないんだろうな〜

If I remember right, I believe there's a restriction like "16-bit, 8Khs
monaural/2.4 seconds"; but this varies between audio files
and wave files.  Even within the 503 series, there are two types
(depending on the unit, FM sound source or ADPCM), so I wonder if
you're OK using just MLD format?






[JavaHz:1076] Re: 音声データとは?
E.Ayabe


綾部です。

Ayabe here.

> とあるのですが、「音声ファイルを使用したサンプル」を見てみますと、MLD形式の
> ファイルを再生しているのです。

> However, when I went to look at "Using Audio Files", it's MLD format files
> that are being replayed.

503でADPCM再生できる機種に限られますが、サンプリングした音をMLDとして再生
する事が出来ます。NとFですか。

The functionality allowing replay of ADPCM on the 503 is limited, depending
on the device, but sampled sound replayed as MLD is possible.  I think on
"N" and "F" 503 phones?

ここが参考になると思います。

I think the following site might help:

「着声を作ろう♪」

"Let's make Chakumero!"

http://kamen.dyndns.org/voice/







Takashi Suzuki
[JavaHz:1077] Re: 音声データとは?
Audio data?

鈴木です。

Suzuki here.

緑川様、綾部様、ありがとうございます。

Midori-san, Ayabe-san, thank you!

E.Ayabe さんは書きました:
>綾部です。
>ここが参考になると思います。
>
>「着声を作ろう♪」
>http://kamen.dyndns.org/voice/

Ayabe-san wrote:
>Ayabe here.
>
> I think the following site might help:
>
> "Let's make Chakumero!"
>
> http://kamen.dyndns.org/voice/

このサイトを参考にさせていただき、なんとかN503iで聴くことのできる
音声データを作成できたのですが…ファイルサイズ自体が大きくなってしまい、
とても多くの種類を頻繁に使用できるものではありませんでした。

I got a lot out of this site, and at last, I can make audio data
that can be heard on the N503i....the file size ends up increasing
and a lot [of file types???] aren't often used.

また、機種も限定されてしまう(らしい)とのことで…
上記サイトなどの情報によりますと、NとFでは可能ということでした。
緑川様のおっしゃる「ADPCM音源」を使用している機種は…ということだと思います。

Also, with respect to (what seems to be) limits on the types of devices....
According to information on the above site and elsewhere, with
N and F [503] phones, one can, in fact, do this.
The devices use what Midorikawa-san called "ADPCM sound source",
I believe.

ともあれ、「音声データを再生する」ことはできました。
どうもありがとうございました。

Anyway, it is possible to replay sound.
Thanks very much.

それでは失礼いたします。

Be seeing you.



top