ケータイJavaの最近のブログ記事

せっかく下の内容を書いたのに、発掘してきた昔のアカウントを試すとすんなりアプリゲットにログインできてそのまま新アカ移行できて、しかもアプリのダウンロード履歴がごく最近まであって特に停止していた気配もないみたいで、どういうことなのかよくわからないけどとりあえずそのまま残しておきます。

================================================================
掲示板に報告受けて知りましたが、2010年8月に、私の名義で アプリ☆ゲットに登録していたソフト(と場合によっては私のアカウントも)が止まっています。まぁ、私がアカウント登録するときに使ったメールアドレスがもうとっくに廃止されてて、んで私もその後まったく更新してなかったんで、リニューアル時にアカウントごと整理されたあたりだと思います。

今更アカウント更新するなんていうのもアレなので、このままとします。数多くの・・・というほどでもないと思いますが、利用してくれた方、バグ報告くれた方、デバッグにつきあってくれた方、アイコン描いてくれた方、その他の方々、どうもありがとうございました。

オリジナルの作者に協力いただいた「みす☆ばるJ」を除いて、ソフトウェアの部屋あたりからソースコードにたどれるようにしているハズので、興味があるという変わった方がもしいればそちらへどうぞ。ソースコードは基本、四条項BSDライセンス(もしくは同封されてる文章通りのそれっぽいもの)です。

3年半くらい前に某匿名掲示板に書いた内容(http://hobby10.2ch.net/test/read.cgi/chakumelo/1107690864/733)がdat落ちしてるんで、以下に載せときます。

================================================================
733 携帯電話情報通知しません [sage] 投稿日:2008/02/14(木) 02:50:23 ID:DzKWMGVY0
>723
stviewer/stVewer3gc作者のらるるです。

VGA対応が叫ばれる今日この頃ですが、
ソースは公開しているので、
需要があれば誰かが勝手に対応する、
誰も対応しないなら需要がない、
と判断してます。

アプリゲットなどで「オレ専用」で使う場合、
ソースをDLして *.jad の MIDlet-Application-Range: を消し
MIDxlet-ScreenSize: を書き換え
(VGAなら480,520、WVGAなら480,640に書き換え)
くらいでいけるはずです。

再配布する場合は、アプリ名・作者・バージョンを書き直して、
BSDライセンスを遵守してください。
(再コンパイルも必要ないはず)

私自身が対応をしないのは、
たんまつもってなくて動作確認できないのが 90%、
ソース公開してんだからやりたい人は勝手にやってくれよ、が 10% です。

よろしくお願いします。
================================================================

ユーザからいただいたメールで知ったんですが、某電卓にてバグが見つかりました。しかも、計算がらみのバグ。

バグ自体は大昔に作ったMathライブラリに起因するもので、某Liteの方にも同じバグがございました。。とっととバグ直して修正したバージョンをappgetへ申請して、とりあえずの作業は終わり。

電卓を最初に作ったのが2002年の5月。かれこれ4年もの間ちょこまかとしたバグが出続けていて、報告され次第直し続けてきました。でも、それでも未だに報告されるとは。。

もともとは、doubleやfloatが使えないシステムの上で小数点を含む計算を実装しなきゃいけないので、内部に計算用ライブラリを作る必要があり、そのライブラリがなかなか完全なものにできあがらずに・・・という経緯で来ています。「0.0001 * 10000 = 0.9997」などなど、有効数字がらみで苦しめられ続けてきてます。

某FOMA機種の電卓のバグ(2003年)なんて話もありました。普通の人なら「電卓ごときでバグ出しやがって」てなところでしょう。でも私の場合は、上記のような理由で、当時は人のことを笑えるような立場じゃなかったです。もちろん今も。

「電卓ごときを作れないでどうする」と自信を持っていえるプログラマってどのくらいいるんだろう。電卓の仕様書を、論理回路の加算機レベルまで含めてさくっと書けるレベルじゃなきゃ、プログラマとはいえないだろうなぁ。

stViewer3gcがまともに動かないだとかいう話が掲示板にいくつか寄せられてますが、これの回答をする上で大切なことを忘れてしまっていました。

Vodafoneの3G(3GC)端末では、VアプリのライブラリであるJSCLはオプション扱いになってたんでした。

Vodafone(J-PHONE)の2G時代の遺産であるVアプリ(Javaアプリ)のJSCLのライブラリは、3G時代では過去のものとして捨てられることはすでにご存じかと思われます。(参考) んで、いわゆるP5型〜P7型までを作ったことのあるメーカであるSH(シャープ)とT(東芝)とN(NEC)は、3GでもJSCLライブラリに対応した機種を作ってます。で、それ以外のメーカは、JSCLなんていう過去のライブラリにこだわるはずもなく、JSCL未対応となっているはずです。

というわけで、JSCLを使ってるstViewer3gcはSHとTとNでしか動かなくて、ほかの端末ではちゃんと動かないのはごく当たり前ということになります。いやいや、肝心なとこを忘れてしまっていた。

で、利用者の関心は、JSCLに未対応の端末ではstViewerが使えるのかどうかというとこかと思われます。

JSCLに未対応の代わりとして、MIDP2.0のJSR 75の「FileConnection Optional Package」が使えます。これを使ったstViewerのバージョンとして、WILLCOM向けに遊びで作ったやつがあります。これをベースにすればよいってことになります。というかWILLCOM向けのやつそのままで動く可能性もアリ。

てなわけで、あとはやる気とデバッグをどうするのかというあたりですな。

2G向け(P5型以降)でStorageConnection使ってて動いていたようなやつを、3GC向けへ移植する時のチェック項目みたいなもの。*.jad/manifestがちゃんとかかれていないと「不正なアプリ」「不正なデータ」などの表示でダウンロードすら完了しない。

MIDlet-OCL: JSCL-1.2.0
MIDxlet-API: JSCL-1.2.0
MIDlet-Application-Range: 0,0
MIDxlet-ScreenSize: 0,0
MIDlet-Application-Security: Y
MIDxlet-Application-Security: Y
MIDlet-Permissions:
　com.j_phone.io.Connector.StorageConnection.read,
　com.j_phone.io.Connector.StorageConnection.write

以上を書いてみたものの、まだどこかおかしいらしい。何か書き足りないのだろうか。CFLFをLFだけにしてみたり、MIDlet-Nameの中にあった半角空白を消してみたりするものの効果なし。

参考
http://memories.cocolog-nifty.com/diary/2006/02/vodafone_3gc_2dbd.html
http://pc8.2ch.net/test/read.cgi/tech/1132493827/

らるるです。
遊んでたら待ち受けくーまんバグにはまり端末がフリーズしたとです。
らるるです...

はまった場合の脱出: 「閉じる・開く・Fメニューを開く」をFメニューが出るまで繰り返しましょう。

[ケータイウォッチ] スパイシーソフト、通信可能な3G向けVアプリを配信可能に
一般の人向けには、まずはこのニュースは何を意味するのかから話さないといけなさそうですが・・・

Vodafone端末向けJava「Vアプリ」の場合、通信やら端末内ストレージへのアクセスやら、今話題の「個人情報」に関わるような機能が利用できるAPIを「セキュリティ対象クラス・メソッド」と呼び、利用に制限を課すことにしています。具体的なAPIリスト(appgetより、該当ページは認証が必要なため勝手に転載)

で、具体的な利用制限は、アプリ開発者に「オフィシャル登録」をさせるというものです。まぁいってみれば、身元確認などを伴う書類審査です。審査をするとこは、Vodafone自信ではなく、アプリ配信を行う主体である「コンテンツアグリゲータ」です。一般人向けのコンテンツアグリゲータは、アプリ☆ゲット(スパイシーソフト)とモバイルゲームチャンネルがあります。

っと、ここまでが2G端末までの話。話がややこしくなるのが、3G端末投入に当たってまた別の制限を課してきたとこです。ここでいう3G端末とは「V」が取れた3G対応端末以降を表していて、それ以前のは対象となりません。技術文章上では「3GC端末」ということになります。

3GC端末では、上記の「セキュリティ対象クラス・メソッド」とはまた違ったAPI群を定義し、それを利用する際に「オフィシャル登録」とはまた違った制限を課すことになっています。このAPI群は、大まかには上記の「セキュリティ対象クラス・メソッド」とほぼ一緒と思っていいです。一部MIDP 2.0の新機能やらが追加されているという感じです。

制限のかけ方はMIDP 2.0で定義された「Trusted/Untrusted MIDlet Suite」を使っていて、早い話が、PKIによる署名が有効であればTrusted MIDlet扱いで動き、そうでないならUntrusted MIDlet扱いで動く、てなもんです。で、Trusted MIDletでないと、この制限されたAPIを使うときに端末が拒否動作をするわけです。

んで話はここから。オフィシャル登録している作者ならばこのTrusted MIDletとするための署名を自由につけられるならば話はわかりやすいんですが、この署名が全くできなかったというのがこれまででした、少なくとも一般作者では。3GCな端末が発売されて1年たつのに署名付きアプリを配信できないとは何事だ、という感じでVodafoneを見限った人も少なからずいることでしょう。

んで今回、その署名付きアプリに対応したというのが上記のニュースになるわけです。えぇ、長かった。理解していただけましたでしょうか。。・・・ここまでは本題じゃないんですがね。

で、ここからが本題です。

今回のニュースに関し、スパイシーソフトからな〜んにもリリースがないです。「署名つきに対応した」というふつーのリリースはもちろんのこと、「どうすれば署名付きになるのか」「オフィシャル登録とのかねあい」などなどの情報がいっさい告知されていません。私は２ちゃんねるのスレ(ここやここ)やニュースサイト(インプレスやITmedia)に張り付いている変人だからこそ署名対応の話を知り得たわけで、そうじゃない人にはどうするんの？と思うわけです。ケータイウォッチが、このニュースのソースをどこから仕入れてきたのかというのも謎です。

また、おそらく署名対応にするためのシステム変更が原因と思うんですが、トラブルが起こってます。上記のように署名付きに関しては3GC端末だけのもののはずなんですが、3GC以前の2G端末(P5端末以降)を対象としたアプリでトラブル起こってます。もう少し具体的に書くと、JSCL-1.2.0のStorageConnectionを使うアプリで3GC以前のP5端末向け(P6/P7端末にも上位互換で対応)のものをアップロードするとチェックでエラー扱いされちゃいます。(エラーの内容 このエラーは「オフィシャル登録」しか使っちゃいけない機能、「オフィシャル登録者」でも使っちゃいけない組み合わせ、を自動で検出してチェックするシステムでエラーが出ているものです。

上記のように、署名付きに対応したことすらふつうは知り得ない情報で、署名付きはあくまで3GC端末向けの話でそれ以前の端末向けとは関係ないはずで、ひょんなとこで変なトラブルに巻き込まれてしまったなぁというのが今回の感想です。

今回の件で思うのは、一般クリエータ向けのVアプリ配信専門ポータルってのがいかに商売として成り立っていないかということです。たぶんまともな対応を取れるほどのサポート体制になっていないんでしょうね、スパイシーソフトさん。コンテンツアグリゲータを通してしか一般作者がアプリを公開できないというVodafoneの仕様上、コンテンツアグリゲータに認定してもらえること自体がある程度権利になります。ビジネス向けはおいとくとして、上記のように一般向けのポータルはたった2つしかないので、その権利をうまく使えば、Vectorのケータイ向け版を作れるというビジネスモデルでのベンチャーだったんでしょうけど。

データフォルダアクセスや通信に制限があるものの自由に配布できるiアプリ、Javaを捨てBREWに向かい法人向けのみにシフトしたau、つっこんだ機能が使えるものの配布がコンテンツアグリゲータのみに制限されたVアプリ。根底には、今のPCのようなウィルスだらけなプラットフォームにはしたくなかったという思いがあっての制限だったんでしょうけど。

MIDP 2.0準拠でキャリアがいっさい口出ししていないっぽいWILLCOM・・・というかサンヨーが出てきて、この辺の考えも変わってくるんでしょうか。

今回Java対応してる端末はWX310J (日本無線)とWX310SA(三洋)とW-ZERO3(シャープ)。てか、Windows MobileなのにJavaですか、へぇ。JBlendだから、別にMS vs Sunはどうでもいいか。

MIDP2.0メモ(ん・ぱか工房)
willcom Javaアプリスレッド vol.1
WILLCOM Javaアプリ(PukiWiki)
画面サイズ、フォントサイズ、ヒープサイズ、データフォルダへのアクセスあたりを整理しなきゃダメかな。

JSR 75の「FileConnection Optional Package」が使えるらしい。「file://localhost/」でデータフォルダにアクセスできるらしい。「file:///」じゃないのか？"/"が1本足りないような。JSCLのStorageConnection(com.j_phone.io.StorageConnection)に似すぎ、Vodafoneがcommitしたのか知らん。FileSystemRegistry#listRoots()(javax.microedition.io.file.FileSystemRegistry)でルートディレクトリ集合を得られる仕様なので、「file:///localhost/」を直接指定するのはよくない気がする。「Possible Root Value」が/から始まってないとこでミスりそう。。*.jadに「MIDlet-Permission: javax.microedition.io.Connector.file.read」を忘れないように。

エミュで実行中、ちょっとでもRecordStore(javax.microedition.rms.RecordStore)にアクセスするたびにPCのHDDがガリガリとお忙しく動く。仕様なのか私の環境が悪いのかがわからん。実端末で問題になるのかもわからん。とりあえず終了時(MIDlet#destroyApp)にだけ書き込むようにしてみた。そしたら終了時にエミュがエラーはきやがる。destroyAppメソッド処理がが5秒以内に終わらないと強制終了させられる「5秒ルール」があったような気がしないでもない。Vodafoneには、アプリ終了時にdestroyAppが呼ばれる保証がないとかいう意味不明な仕様もあったし、困ったもんだ。C:\WTK22\appdb\DefaultColorPhone\run_by_class_storage_conf.dbがRecordStoreの保存先、エミュのRecordStoreを消すにはこのファイルを消せばよい。

Gauge(javax.microedition.lcdui.Gauge)はエミュでは視覚的なメータしか表示してくれない。おかげで、今現在の値がわからない。不便だ。横に数値も添えてくれればいいのに。CustomItem(javax.microedition.lcdui.CustomItem)使えばそういうのを自作できるようになったが、Form(javax.microedition.lcdui.Form)の上で行儀よく振る舞わなければならないItem(javax.microedition.lcdui.Item)の仕様上、CustomItemの実装に課される制約が重く感じる。こんなの使うくらいなら、Form使うのをあきらめてCanvas(javax.microedition.lcdui.Canvas)使うだろうな、ふつう。(わかりやすくいえば、ボタンやコンボボックスやチェックボックスなどのコントロールがItemにあたり、そんなコントロールを自作できるようになってるのがCustomItemってことです。コントロールとしての共通の振る舞いがCustomItemにも求められるため、実装上注意しなきゃいけない仕様がCustomItemにはたくさんある。)

JSCLのFEPControl(com.j_phone.ui.FEPControl)にあたるものがMIDP2.0にはなくてちょっと困る。FEPControlは、処理の流れをブロックしてユーザにテキストを入力してもらうと、ブロックした制御が動くと同時に入力してもらったテキストが返ってくる、というように使える。この流れはTextField(javax.microedition.lcdui.TextField)では代用できない。TextFieldでは、入力してもらったテキストが引数となるようなコールバック関数をListenerとして提供するのが限界か。

JSCLのcom.j_phone.util.GraphicsUtil#drawRegionがほぼそっくりそのままjavax.microedition.lcdui.Graphics#drawRegionとなってる。

あと、エミュでプロポーショナルフォントになっててビビった。まぁプロポーショナルだったのはさすがに英数だけだったけど。Font.FACE_SYSTEM(javax.microedition.lcdui.Font)じゃなくてFont.FACE_MONOSPACE使いなさいってことか。

まだメモりたいことがあった気がするけど思い出せないのでここまで。