スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

奇跡の音 2週間の結果

英語聴覚セラピー『奇跡の音』を今月頭から試した。

その結果報告。
結果は、というとよくわからない。
なんとなく、子音が響くなったような気もするのだが、リスニング力はそれだけじゃない。
やり方がよくなかったのかもしれない。1日流し聞きも含めて、1時間以上は聞いたと思う。しかし、同じ内容をずっと集中して聞き続けるのは難しい。どうしてもほかの事を始めてしまう。もしくは心は空想の世界に入って行くか、眠りに入るかのどちらか。
これがよくなかったか。時々は集中したのだが。結構ヒスノイズが耳に響くので、他の英語のコンテンツを聞くよりは、音に意識が向かうので、流し聞きでも全く効果がないということはないのではないかと思う。

通常は、流し聞きでは英語の勉強には全く役立たないと思う。自分が今までリスニング力が上がったと感じたのは、聞き取りにくい英語のテープをできるだけ集中して何度も聞いたときだ。

まあ、でもできれば4週間とあるのでまだまだ続けていこうと思う。あまり苦にならないし、なんとなく耳にいい刺激?をしているような気がする。
マジックリスニングだと一度12日間試したら半年間はやってはいけないとなっているが、これにはそういうことはないようだ。また価格も手ごろだし、効果が出ている人は出ているので、試してみる価値はあるのではないかと思う。

平易な英語だと思っていたが、音ばかりに集中して、また流し聞きしていると、きちんと聞き取っているかどうかのチェックがおろそかになる。今日始めて、スクリプトを見ながら聞いたが、聞き違えていたところが結構あった。

LAはアレイと聞こえていて、どこのことかと思っていた。全般的に自分は、a関係の音が弱い。特に、弱いアの音は、アに聞こえたり、イに聞こえたりする。andとinを聞き間違えたりする。こういう間違えはスクリプトがないと気づかないし、スクリプトをすぐに見ないで、繰り返せば繰り返すほど、自分の思い込みで音を解釈してしまう。

スクリプトをすぐに見るべきではないという説とすぐに見るべきという説があるが、私は後者が正しいと思う。聞けないものは、何十回、何百回と聞いても聞き取れるようにはならない。スクリプトがなければ永遠に正解はわからない。
あと、聞けないときはカタカナで書き取ってみるといいという説もあるが、これも?だ。日本語にしにくい音というのがある。例えば、ruralなどの音を、日本語の音に無理に当てはめて、うらぅとしたところで正しくはない。

やはり正確な英語の音を覚えて、それが文脈に応じてどう変化するのか、その音の範囲を押さえておく必要がある。これには大量の音を聞くしかない。

あと自分にとってのリスニングの課題は、連音を聞き分けることだ。日本人にとって難しいのは、一つ一つの単語がばらばらに発音されるのではなく、つながってしまうこと。逆に長い単語が二つの単語に聞こえたり、そうして単語の区切りを間違えてしまう。

なのでとりあえずの結論としては、こういう一発逆転の奇跡!もいいかもしれないが、こつこつ一つ一つの音を憶えていくしかない、というのが今の結論。

スポンサーサイト

資産形成フェア2007

今日は、資産形成フェア2007に行ってきた。
すごい盛況で、人気のあるセミナーでは、人が入りきらず、入口の人だかりの後ろからしか見ることができなかった。その一方、席の空いている広い会場もあり、この辺の調整って事前、あるいは直前にできないものかと思う。

特別講演を聴きたかったが、事前登録が必要で、行くかどうするか迷っているうちに満席になってしまった。こういうのは迷ったらとりあえず即登録しないといけない。

カリスマ主婦トレーダーの山本有花さんの話は参考になった。前に1冊本を読んだことがあっただけだったが話を聴いてみたかった。話はわかりやすかったし、毎年、目標・ポリシーを決め、一日のうち短時間でも時間をとってきちんと継続して儲けを出しているところがすごい。見習いたい。

去年は行動力なさが目立った。日経平均14000台のとき、買おうと思っていてチャンスを逃し、いつの間にか18000円にも届きそうなところまで来てしまった。為替も114円のときに買おうと言っていながら行動に移さず、これまたチャンスを逃した。
今年はそうならないようにしたい。

あと、『勝ち組投資家になるための ケンミレ式割安株投資』、これも参考になった。ただ、何分、講師の森田氏の発音がよくなく、ところどころよくわからないところがあった。
今英語の勉強をしていてリスニングで苦戦しているが、日本語のリスニングにも問題があるかも。hehehe

Finix英語学院フェスティバル

昔通っていたフィニックス英会話学校フェスティバルに行ってきた。
ここでは半年かけて生徒が準備する、ドラマとビジネスプレゼンテーションの発表がある。
やめた後、1,2回は知り合いのを見に行ったが、その後は行くことはなく、今回takewoodyに招待され、5年ぶりに行った。久しぶりだったにもかかわらず、相変わらずの雰囲気で、当時からずっと続けている生徒にも数人会い、驚いた。午後時間が過ぎるにつ入れて、大勢の人が来て熱気がすごかった。

このプレゼンテーションのクラスは、フィニックスの特長ともいえるし、すごく懐かしかった。この学校にいた期間いろいろ刺激になって、かなり英語の勉強をして、TOEICの点数も上がった。「いつ復活するの」とか聞かれたけど、まあ、ちょっと考えると、仕事以外のプライベートな時間でやることがなくなったら行くかな、って思う。それだけコアとなる人はかなり負担が大きい。それ以外の人はマイペースでやっていたりするけど。でも、大変だけにメンバーの結びつきは強くなるし、ちょっと同じ授業に出ただけですぐに知り合いになれるのもこの学校の特徴かな。

J2ME(S!アプリ)開発日記 総括

普段、ほとんどこのブログ書いていないのに、書くとなると一気に書いてしまう。毎日小出しがいいのだろうが、どうも性格的にそうもいかない。

日記と言いながら、まとめて書いている。


今回の開発でいえることは、そもそもの目的は、英語の学習をすることだったが、英語の勉強に時間を費やすのではなく、英語を勉強する手段に時間を投資した結果となった。という、本末転倒というもの。orz

今回のアプリだが、CLDC1.1 + MIDP2.0で、標準のAPI以外に使っているのは、
com.j_phone.io.StorageConnection
のみ。特に独自のものは使っていないので、MIDP2.0で、メモリカードが使える端末であれば、ソフトバンク端末であれば使えると思う。
とりあえず、904SH, 905SHでの動作は確認した。905SHは縦長なので画面の上端が使われていない。たぶんJadファイルのスクリーンサイズを変える必要はあると思うが。

ソフトバンクユーザで、このβ版を使ってみたい方、協力してくださる方、ぜひこちらにご連絡を。


J2ME(S!アプリ)開発日記 その7

エミュレータと実機の違いは、表示の面でもあり、なぜかイタリック指定が反映されないなどもあった。

あと備忘録としては、サンプルの梱包の仕方だが、jarファイルの中に入れておく。resディレクトリにアイコンやサンプルのcsvファイルを入れておくと、antを実行した際に、jarファイル内のルートディレクトリに置かれる。それをgetClass().getResourceAsStream()で読み込む。

起動時に、file:///mc/Other docuemnts/をチェックし、なければMiniSDカードを入れるように促す。あれば、サンプルをコピーする。そしてOther documents下にある.dicファイルをリスト表示し、プルダウンで選択できるようにする。
こんな感じでサンプルも同梱できた。

結局、いろいろ加えていった結果、見かけはシンプルだが、20クラスで、jarファイルは56kbyteになってしまった。アイコンやサンプルはあわせても3k。コンパイルオプションでもう少し圧縮するか。ダウンロードには通信料が若干かかる。デバッグの際には何度もダウンロードするので、パケット定額に入っていないと、すごい額になってしまう。

備忘録としてはこんな感じだが、あと重要なjadファイルの中身は以下のとおり。

MIDlet-Vendor: happie
MIDlet-Name: Eitan
MIDlet-Version: 0.8.0
MIDlet-1: Eitan,/eitan.png,happie.eitan.Eitan
MIDlet-Jar-URL: Eitan080.jar
MIDlet-Jar-Size: 56438
MIDlet-Icon: /eitan.png
MIDlet-API: MEXA
MIDxlet-API: JSCL-1.4.2
MIDlet-Application-Security: Y
MIDxlet-ScreenSize: 240,260
MIDlet-Permissions: com.j_phone.io.Connector.StorageConnection.read,com.j_phone.io.Connector.StorageConnection.write

またManifest.MFはこんな感じ。

MIDlet-Vendor: happie
MIDlet-Name: Eitan
MIDlet-Version: 0.8.0
MIDlet-1: Eitan,/eitan.png,happie.eitan.Eitan
MIDlet-Icon: /eitan.png
MicroEdition-Profile: MIDP-2.0
MicroEdition-Configuration: CLDC-1.1


J2ME(S!アプリ)開発日記 その6

エミュレータの開発が進み、そろそろ実機でテストする準備をしなければ、と思い、アプリゲットに作者登録した。

J2MEのアプリケーションは最終的には、JADファイルとJarファイルのセットで配布する。Jadファイルには、Midletの様々な属性を記述する。ここを間違えると、ダウンロードできなかったり、起動できなかったり、正しい動作ができなかったりするので重要だ。
特に、MIDxlet-API: JSCL-1.4.2
の記述は本当に重要だった。

で、そのJadとJarファイルだが、通常のWebサーバに置いてもダウンロードできない。JadもJarも正規の署名がされていなければ、あるいはキャリアの認めたURLでなければ、キャリアのネットワークがブロックするからだ。メモリカードに入れても同じ。端末が不正なアプリとして認識しない。また端末に保存されていても、SIMカードを入れ替えてしまうと認識できない。あくまでもダウンロードしたユーザにしか使えない。こういういろいろな制約がある。

なので、キャリアが認めたWebサーバ、アグリゲータに登録する必要がある。
アプリゲットに作者登録を申し込んだら、すぐに受理されて使えるようになった。しかし、外部との通信を行うアプリケーションは登録できない。セキュリティ上の問題でエラーになって、アップロードできない。なので、StorageConnectionを使う処理は実機では試すことができず、それを省いてUIの確認だけをまず実機でした。

外部との通信が可能なアプリを登録するには、オフィシャル作者登録が必要になる。これにはオンラインではなく、紙ベースで個人の証明書類とともに提出して審査してもらう。
送付後、メールでいろいろ質問が来た。公開の意志と何を作るのか。それに答えたらまた返ってきてなぜオフィシャルである必要があるのかと。
うーん、こんなの最初から聞いてくれよ。条件があるならそれをもっときちんと明記してくれよと思いながらも、丁寧に返答。ここで蹴られては、今までの実装が無駄になる。
まあ、自分ひとりで使う分には、アプリの中に辞書ファイルを含めてしまってダウンロードすればできてしまうことだが。
結局、審査に一週間かかりようやく受理。

早速実機での確認だと、エミュレータ上で完成したアプリをアップロード。エラーなくきちんとアップロードできる。
実機でダウンロードしようとすると、「不正データのためダウンロードできません」となって門前払い。アグリゲータのチェックを通っているのに何でと思った。Jadファイルで余計な項目があるからだろうと思い削ったが駄目。やっぱこれでもセキュリティ上の問題でStorageConnectionは駄目なのだろうかと思ったが、案外簡単なところにあった。
MIDxlet-ScreenSize: 480,588
としていたのが駄目で、
MIDxlet-ScreenSize: 240,260
としたらダウンロードできた。最初の奴は904SHの最大サイズなのだが。

OKかと思ったら、問題データが全く表示されない。サンプルは所定のディレクトリにコピーされているし、リスト表示もされている。ファイルのreadの仕方が悪いのかと思い、Resourceを読むのと同じようにavailable()を使うのをやめたが、それでも駄目。
Other docuemntsの下にeitanというディレクトリを作り、そこに入れていたのだが、それがまずかったのだ。Other documentsの直下しか読めないのだ。なのになぜ作成し、書き出せるのかがよくわからないが。他のドキュメントを置いている場合は競合してしまうが、eitan.iniと.dicの拡張子の付いたファイルを扱うようにする。

しかし、読み込みと書き込みで、
「ユーザーデータ読み込み
個人情報取得を行います。よろしいですか?」
「ユーザーデータ書き込み
個人情報書込みを行います。よろしいですか?」
と聞いてくるのはうざく、毎回聞いてくる。終了時には、辞書ファイルと設定ファイル二つ書き込むため、二度聞かれる。eitan.iniはRecordStoreを使うべきかと思ったが、これは、単純。携帯でアプリを選択して、セキュリティレベルの設定を「表示しない」にすればよかった。

読み込みだが、エミュレータ上では、InputStream#availableが使えたものの、実機上では0が返ってしまう。1バイトずつreadしていたが非常に遅い。byte配列のBufferを1kぐらいにとって読めばいいかと思ったが、どうやってその後Stringにすりゃよかったっけとしばし黙考。でもそんな必要はなく、StorageConnection#getLengthでファイルのバイト数を取得できたので、そのバイト数のバイト配列を用意して、読み込みをしたら一気に早くなった。

しかし、問題はここから先だった。
携帯ではいろいろな割り込みイベントがある。着信、フリップを閉じる、電源ボタンを押す、など。こうするとJavaは強制的に停止させられる。そのとき、MidletのpauseApp()やdestroyApp()が呼ばれるので、必要であればそこに終了処理を記述しておく。
私は、pauseApp()で、辞書ファイルと設定ファイルを出力する処理を呼び出すようにしたが、うまくいかない。
フリーズして、5秒後に「エラーが発生しました」となって強制終了になる。
ファイルがきちんと保存できていることもあるが、たいていは途中で更新された内容は保存されていない。厄介なことにファイルが消えてしまうこともあった。

通常に終了処理をするときは、ファイルの保存は一瞬で終わる。pauseApp()の仕様として、5秒以内に終わらないと強制終了されるとあるのだが、そんなにかかるはずがない。

通常の操作で終了してくれることをユーザに期待したいが、PCと違い、ユーザの意志だけではどうにもならないところがある。電話がかかってくれば、携帯「電話」なので、電話が優先される。Vアプリ設定で着信時優先動作を変更できるが、これを毎回このアプリのためだけに設定するというのは期待できない。

仕方ないので、定期的に保存することにした。問題が数問進んだら保存。最後の数問の結果が保存されないのは致し方ないだろう。しかし、これでも問題があった。大きなファイルの場合、若干時間がかかるので、その間に、携帯を閉じるとファイルが消えてしまうことがあった。

そこで保存は別ファイルにして、終了処理でリネームすることにした。リネームの方が軽い処理だろうと思い込み、pauseApp()に入れたのだが、結局これも前と同じ結果となった。

別スレッドにして動かしたらうまく行くかもしれないと思い、pauseApp()はすぐに抜けるようにして別スレッドを走らせた。こうすると、強制終了する問題は回避できたものの、やはり、リネーム処理が完了しないまま終わってしまっている。たぶんJavaVM上で動いているスレッドすべてに停止命令がかかるのだろう。

そもそも5秒も待っていない。確かにフリーズして、エラー表示されるまで5秒だが、その間、Javaは自由に動ける状態にあるとは思えない。
結局、ファイルを読み込んだときに、backupを取ることにした。そして正常終了時に削除する。異常終了時の再起動時には表示しない。もしファイルが消えていれば、その他のフォルダを見て、~付きのファイルをリネームして手動で復旧する。

J2ME(S!アプリ)開発日記 その5

当初、出題用の辞書データをどうするのかが問題だった。

PC版では、辞書作成機能を持たせて、アプリ上で問題-答えの組を作成できるようにした。単純なCSVファイルなので、テキストエディタで別に作ることもできる。

しかし携帯版では、携帯で辞書をごりごり自分で作るというのは酷だ。
PC版で作り、それを携帯に持ってくるというのがよい。

さて、それをどうやって移動するかだ。ご存知のように、携帯はPCのように自由ではない。端末からネットワークまですべてキャリアのコントロール下にある。自由にはさせてくれない。それはセキュリティ上の理由からだが、それによってキャリアが独占・寡占状態を作っている。キャリアの不利益になるような開放は行わない。これが日本の現状だ。
アプリケーションも無線でダウンロードしないといけない。しかもいろいろ制限がある。

ところで、データの移動の方法だが、サーバ上に置いてHTTPで取ってくるというのと、メモリカードを使って移動するのが考えられる。Bluetoothやメールというのもある。しかしメモリカードが一番シンプルだ。なので本アプリはメモリカード対応機種しか使えない。HTTPの場合、あっぷろーだサイトがあちこちにあるので、そういうところに置くことはできるが、逆に携帯の中に保存された辞書をPOSTすることは簡単には行かない。サーバ側の対応が必要になる。サーバとアプリをセットで考えないといけない。

また、携帯の中でのデータの保存場所だが、rmsを使うと簡単そうだが、外には持ち出せない。今のところ携帯上で辞書ファイルを編集することは考えていないが、それでも学習した結果はそこに記録されるので、PC版に戻したいときは、データを取り出す方法を考えないといけない。

なので結局SDカードを使い、SDカード上で、読み取り、書き込みを直接行う。
最初そんなことできるのかと思ったが、StorageConnectionクラスを指定し、file:///mc/と指定すると、メモリカードを指定できるのだ。
ふと、もしこれで他のアプリ用のディレクトリにアクセスしたらどうなるのだろうかと思ったが、そこはきちんとアクセスできないようにコントロールされている。ただファイルのリスト表示はできるようだ。
そして自由になる領域は決められている。mcの下のOther documentsディレクトリだ。この下なら自由に読み書きできる。ただし、サブディレクトリは扱えない。作成はできるが、その下のファイルを読み書きできない。

これはエミュレータではできたが、実機ではできなかった。
エミュレータと実機の差は他にもいろいろあった。

J2ME(S!アプリ)開発日記 その4

画面遷移を構成している中で困ったことがあった。
モーダルのダイアローグボックスを作ったつもりだったが、なぜか正常に動作しない。

問題出題画面で、確認ボタンを押したときに、確認画面に行き、そこから戻ってから次の問題に進むようにしたつもりだったが、確認画面に行ったときには、見えないがすでに次の問題に進んでいた。

なぜかよくわからなかったのだが、
Display#setCurrent()メソッドで別画面を指定したとき、別画面に遷移されるのだが、実際そこでブロックされるわけではなく、別画面の処理が進行している一方で、バックグラウンドで元の処理が進行してしまっているのだ。
「このメソッドは実際にディスプレイの表示が変更される前に直ちに呼び出し元へ戻ります。 」
とあった。
別スレッドで動いているのかと思い、別画面が表示されている間は、Thread.sleepを回して待機することにしたのだが、これをやると画面が真っ白になる。別スレッドで動いているわけではない。
仕方ないので、setCurrent()メソッドを読んだ後に処理を書かず、確認画面から処理を呼び出すようにした。

ここでロジックとViewを明確に分けるようにした。MVCモデルだ。
実際には、MVCと言っても、VとCは同じクラスにしている。論理的には分かれているが、結局のところController(Listener)はViewに密に結びついており、Viewクラスにリスナーをimplementしてしまうことが多い。リスナーを別クラスにすることも考えられるが、私は一緒にした方が可読性が高いと思う。

Modelだが結局ここはロジックとデータクラスで分離してしまった。データクラスにロジックを実装すると、複数のデータクラスをまとめて扱う場合、どっちのデータクラスに処理を実装すべきか悩む。むしろロジックは外出しにした方が汎用的だ。

簡素に作るはずが、だんだん凝ってきてしまう。
設定値も最初はハードコーディングしていたのだが、外の設定ファイル、JADに設定して、それを読み出すようにできないだろうかと思った。
Midlet#getAppProperty
でJADの属性を読み出せることがわかった。

また、辞書ファイルを読み出すとき、最初は単純なCSVファイルで、PC版との互換を完全に取らなくてもいいと思っていたが、結局、問題や答えや備考に改行を含めることができるフォーマットに対応するようにした。"\nでパースしたら思っていたほど難しくはなかった。
そう、StringTokenizerもないので、自分でパースのロジックを書く必要があった。

あとFormでStringItemを使っているときの問題は、改行の表示。
どうにもうまく行かない。改行を入れると2行分入ってしまったり、だからそれを取り除くと前の行につながってしまったりとどうもうまく行かない。

それから例外処理をどう扱うかというのも課題だった。
イベントドリブンのアプリの場合、どうしたらいいだろうか。Exceptionはどこにかえって行くのか。
自分が注目したのは、Controller(Listener)の部分。最初の画面の表示後は、すべてここから始まる。なので、すべてのFormのcommandAction()の実装をtry-catchで囲み、エラーがあった場合は、Alertクラスでエラー表示するようにした。catchではExceptionではなく、Throwableをcatchする。でないと、Uncaughted Errorとなってしまうことがある。何の例外がスローされるかわからない。

J2ME(S!アプリ)開発日記 その3

CLDC 1.1だと、1.0よりは充実している。しかし、J2SE, J2EEを使っているとどうしても不足している。ソートも自前で作らなくてはいけなくて、Comparatorなどはない。昔勉強していた頃のQuickSortのソースを持ってきて当てたりした。Vector#toArray()メソッドもない。

CLDCは1.0でもよかったが、MIDPでは、やはりリスト表示の際、ラジオボタンの羅列だと長くなってしまうので、プルダウン(POPUP)が使いたかったし、カスタムアイテムやボタンも使いたかったので、MIDP2.0にする必要があり、結局MEXAエミュレータを使うようにした。

また、最初の画面ぐらいは色をつけたいと思い、Canvasクラスを使っていたが、文章を載せたいときに、行の折り返しとか全部自分で指定しないといけない。
その点、Formクラスを使うと便利で、長い文章をappend()しても、勝手に折り返してくれるし、画面に収まりきらない場合、下ボタンを押せば、下にスクロールして見ることができる。
なので、結局、画面はすべてFormクラスで統一し、アプリの起動はMidletクラスで行うが、そのあとはほとんどFormクラスである。最初、Listクラスも使っていたが、メニュー表示するのであれば、Commandクラスを使った方が、数字キーでメニューの項目を選択するので、Listクラスは使わなくなった。

MIDP2.0でボタンオブジェクトが使えることがわかったので、PC版と同じ画面構成にしようかと思ったがやめにした。なぜかというと、携帯ではマウスが使えない。マウスが使えれば、ボタンへ直でアクセスできるが、携帯では上下左右キーで移動するしかなく、その間にボタンがたくさんあれば、キーを押下しなければならない回数は多い。だからあまりボタンの利点はない。
なので一部の確認画面でしか使わなかった。むしろ、ソフトキーを押してメニューを表示させ、そこで数字キーを押したほうが、押下数は少なくて済む。

こうしてUIを整え、ほぼ普通に動作するようになったものの、やはりキー押下数は少なくしたい。ショートカットはほしい。
しかし、CanvasではkeyPressedイベントがあって、数字キーにショートカットキーを割り当てることができるものの、Formでは拾うことができない。
いろいろ調べているうちに、CustomItemを使うと、keyPressedイベントを拾えることがわかった。しかし条件は、そのカスタムアイテムにフォーカスが当たっているときだけである。
最初この案を断念しかけたが、実は結構使える。
Form上のItemがそのカスタムアイテムしかないとき、フォーカスはそのカスタムアイテムに常に当たっている。
ポイントは、Form上にアイテムをappendしていくとき、フォーカスを当てられるアイテムがそのカスタムアイテムだけのときは、最後に、appendする。逆に、他にフォーカスの当たるボタンなどのItemがあるときは、最初にappendする。

今回作ったカスタムアイテムは全くのダミーでCustomItemを継承し、コンストラクタで" "(スペース)だけを指定した。目的がショートカットだけなので、必要なFormクラスのインナークラスとしてShortCutクラスを作り、implementする必要があるメソッドをダミーでインプリメントした。

こんなやり方で果たしてショートカットが使えるのか不安だったが、きちんと動作した。
ただ面倒なので全画面でするのはやめて、一部のよく使いそうな画面のみにした。

J2ME(S!アプリ)開発日記 その2

Canvasクラスを作ってどうやって描画するか、しっかり考えてからやろうと思ったが、その前に基礎的なことからと思い、今度はどこかのサイトにあったHelloWorldレベルのサンプルから取り掛かった。

特に画面に凝ろうと思わなければこういうテキストベースで作っても実用上いいんじゃないかと思った。ただし貧相な画面だと、どうしても安っぽく見る人が多いのが残念なことだが。

ということで、Canvasで描画せずに、Formクラスを使って、シンプルな構成でいこうと考えた。画面の遷移は、左右のソフトキーを使って行う。このソフトキーは、Commandオブジェクトに割り当てられていて、二つ以上割り当てると、右のソフトキーが「メニュー」に変わり、押すとメニュー画面で選択する形になる。
しかし、これ、ネイティブのアプリのように、元の画面はそのままで、メニューを押したときに、その上の部分だけに、ぴろーとメニューが出てくるようにはできないのだろうか。前Javaアプリでもそういうのを見たことがあるが、あれはどうやっていたのだろうか。ちょっと調べてみたが結局わからなかった。

最初、S! Appli Emulator for JSCL1.3.2を使っていたのだが、MIDP2.0の機能を使うには、MEXAを使う必要があることがわかった。
しかし、MEXAエミュレータを使おうとすると、StorageConnectionへのキャストのところで、なぜかNoClassDefFoundエラーが出てしまう。いろいろ試してもさっぱりわからない。
あとで原因がわかったのだが、とりあえず、S! Appli Emulator for JSCL1.3.2でも開発はできたので、そっちで進めた。

MIDP2.0もそうだが、CLDC1.1にも対応していない。J2MEの構成は、コアとなるConfigurationの上に、携帯独自のProfile(MIDP)からなっている。さらにその上にキャリア独自のAPIが追加されたりする。
Configurationはjava.lang, java.util, java.ioと基本的なネットワーク機能のAPIが定義されている。この基本的なパッケージもかなり限られていて、使いづらいことこの上ない。CLDC1.0では浮動小数点の計算に対応していなかったり、Mathクラスのメソッドも貧弱で、CLDC1.1の使えるMEXAにしなきゃと思いつつも、なんとか工夫したらできたので、そのまま、S! Appli Emulator を使い続けた。

それにしても、こんな貧弱なAPIでみんな開発しているのだろうか。たぶん追加でいろいろ入れるのだろうが、おそらくロジックはあまり複雑なものは組まず、描画やハードとの関連の部分を解決するのが、開発の重点とされているのかもしれない。実際、キャリアの拡張はハードがらみのところにある。携帯に載せているメールやオーディオプレーヤーの対応など。

MIDPで定義されている画面用のクラスとしては、最上位にDisplayableがあり、その下にScreenとCanvasクラスがある。Canvasクラスは自由に描画してグラフィカルな画面を作ることができる。たいていのアプリはこちらを使っている。
Screenクラスは、Alert, Form, List, TextBoxなどのサブクラスがあり、こちらが画面用コンポーネントだ。しかし、VBやawtなどのコンポーネントに比べて非常に貧弱だ。特に、MIDP1.0では、テキストを扱っているのと変わりない。テキストボックスやチェックボックス、ラジオボタンなどはある。MIDP2.0でボタンやリンクやプルダウンなどが追加されたので、そこそこできるが、扱えるフォントは限られているし、色もつけられない。

せめて字体の色、背景色、各コントロールの色を指定できたら、だいぶ見栄えがよくなるのだが。どうして色指定ができないのだろうか。

フォントのサイズも、端末依存だが、904SHだとネイティブだと5段階設定できるが、Javaだと3段階で、私としてはネイティブでの小で設定したいのだが、SMALLにすると最小になってしまう。これだと小さすぎるし、かといって標準だと大きすぎる。

最初、CLDC1.0, MIDP1.0でやっていて、それでもStorageConnectionで外部メモリにアクセスすることはできるので、この方が対応機種も増えていいのではと思っていた。

MEXAエミュレータが使えるようになってからも、S! Appli Emulatorの方が簡単なので、そちらを使い続けた。EclipseでAntを実行して、あとエミュレータでRUNボタンを押すだけ。一方、MEXAでは、Ant実行後、JADファイルを修正し、そしてエミュレータ上でインストール作業を行って、Launchボタンを押してと、非常に面倒くさい。

AntにはサポートサイトにあったZentekAntTasks.jarを使っていたが、JADファイルの頭に3行の変なヘッダを加える上、長い行を改行してしまうので、非常に迷惑だ。
MEXAエミュでは、セキュリティもエミュレートしていて、MIDlet-Permissionsを指定しないと、StorageConnectionが使えない。JADファイルの先頭に追加される属性は、エミュレータでは問題なかったが、アプリゲットにアップロードするとき、先頭がMidlet-属性のものが来ないとエラーになってしまう。

で、MEXAエミュレータで、NoClassDefFoundErrorが出ていた理由だが、2chのスレッドを見ていたら答えが見つかった。
MIDxlet-API: JSCL-1.4.2
が必要だったのだ。資料をきちんと読めばわかったかもしれないが、みようみまねで作っていてはこんなことは絶対わからない。この情報には非常に助かった。これがなかったらドキュメントを一から読み漁らないとわからなかったかもしれない。しかし、JADの指定で、NoClassDefとは。
てっきり、クラスパスに存在しないのだろうかと、そこばかり気になって、試行錯誤していた。

教訓:エラーメッセージを真に受けないこと。

まあ、この場合、JADで指定されたプロファイルでは、クラスが見つからないということで、正しいといえば正しいのだが。


J2ME(S!アプリ)開発日記 その1

PC版の、英単語学習ソフトeitanを携帯でも実現させたいと思い、ずっと前から移植しようと考えてた。携帯上でできれば、電車の中でも勉強できる。またユーザからそういう要望もあった。

ようやく腰を上げたのが、数ヶ月前。
ドキュメント、エミュレータ、開発キットをダウンロードし、サンプルを見ながら取り掛かった。ロジックの部分はできているし、J2MEはシンプルなので、そう難しいものではないと考えていた。

が、サンプルが単純ではない。入門サイトを探そうとしたが、これまた適切なのがない。通常のJavaに比べて、開発者の絶対数が少ないし、ノウハウはおそらく非公開で一部の開発会社に蓄えられているのではないかと思う。
なんとかEclipse上に開発環境を作り、エミュレータを動かすところまでいき、サンプルに少し手を加えて確認した。最初はサンプルをちょこちょこいじりながら、目的に近づけて行けばいいと思っていたがそうも行かなかった。基礎がわかっていない。みようみまねではうまく行かない。以前、J2MEのアプリケーションの開発プロジェクトに関わっていながら、あまりにも貧弱な知識で情けない。やはり実装に関わらないと駄目だろう。

それなりに開発環境が整っていて、VBライクに画面を作り、イベントドリブンで実装していけるような錯覚をしていたがそうは行かない。画面を描くには、Canvasクラスのpaint()メソッドを実装し、Graphicオブジェクトを使って描いて行く。描写位置のXYを指定し、という感じだ。
ボタンのようなコンポーネントがあるわけではなく、下ボタンを押したら、円形の図のふちを変えて、そこが選択されているように見せる、といった感じで非常に原始的だ。

とてもやってられない。で、結局のところ、これは本腰を入れないと駄目だと、一旦退散した。ひょっとしたらVBライクにできるものもあるのかもしれないが、結局使ったのはSoftbankから出ているエミュレータ、ツール、あとSunから出ているToolKitなのでわからない。数少ない入門サイトにもそのレベルの説明しかない。


今年に入って、英語の勉強をしなきゃと思い、通勤時間を有効活用して携帯を使って勉強するべきだと思い出し、再度制作に取り掛かった。
(つづく)




CDROM再生、奇跡の音

英語の勉強で、あるCDを使っているのだが、高周波を強調した音が含まれているので、できればPCを通さずに直接聞きたいので、内蔵CDドライブ自体に付いているヘッドフォンにつなげて聞こうとした。
が、音がでない。

PCのマニュアルを見て、何となくこれかなと思い、デバイスドライバで、「このCD-ROMデバイスでデジタル音楽CDを使用可能にする」のチェックを外した。再起動が必要で、しばし待った後、聞いてみるが、やはり聞こえない。
どこかに設定があるのだろうと思い、Dellのサポートに電話をかけた。混んでる、混んでる、で1時間ぐらい待たされた。

頼りなさそうなおばさん?が対応した。スピーカーや通常のヘッドフォンでは聞こえる旨を伝えると、故障しているので交換する必要があり、サポート期限が切れているので有償修理になるとのこと。「よろしいでしょうか」と言うので、「よろしくない」と応えた。「設定の問題だと思う」と言うと、調べますと言ってしばし保留に。

その間、自分でいじっていて、Media Playerの「ツール」-「オプション」-「デバイス」-「プロパティ」で、「オーディオ」タブの再生のところをデジタルからアナログに変えたら、聞こえるようになった。

FAQにあってもよさそうなものだが、多分あまり使われていないのだろう。
ところでこのCD、『奇跡の音』という本に付いているものだが、1日30分×2を2週間聞き続けることで、英語に含まれる高周波の音へ耳をチューニングするように訓練して、英語耳を作るというもの。

まさに、これだと思ったが、過去にも似たようなもの、(一時期さんざん宣伝がうざかった)マジックリスニングを試したことがあったが、全く効果なかったので、今回もどうか。
結果をレポートしたい。

聞くと、4000-8000Hzを強調したものは、耳にキンキン来る。単にヒスノイズが入っているとも言えなくもないが、これが訓練になるのかな。

通勤中にも聞けるようにオーディオプレーヤーにコピーした。MP3だと16kHz以上が削られてしまうので、なるべくCDそのままの方がいいと思い、wmaでの可逆圧縮でやったがオーディオプレーヤーが対応していない。wmaの可変ビットレートで高音質で変換すると、なぜか、通常音と2000-4000Hz強調音は再生できるのに、4000-8000Hzは再生するとキーキー音がして正常に再生できない。やはり高周波の部分が強調されているせいか。なので通常のwmaで高音質で変換。これで正常に再生できた。たぶんMP3とあまり変わらないし、16kHzまでではないのでMP3でよかったかもしれない。


プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。