kikita for Palm webOS コンセプトバージョンをv.0.0.2へ更新しました
「超！A&G | AM1134kHz 文化放送 JOQR」のサイトのレイアウトがガラッとかわって、番組表を受信できなくなっていたので対応しました。その他、いくつかの不具合の修正なども行っています。
あと、今回の変更とあまり関係ないですが、ドキュメントの最初にあったPalmEmulatorでしか試していません的な文章がちょっとくどいかなと思ったので削除しました（とは言っても相変わらずPalmEmulatorでしか試していませんが…）。
くわしくは以下のリンクのからどうぞ。
□ kikitai for Palm webOS コンセプトバージョン
あと、今回の変更とあまり関係ないですが、ドキュメントの最初にあったPalmEmulatorでしか試していません的な文章がちょっとくどいかなと思ったので削除しました（とは言っても相変わらずPalmEmulatorでしか試していませんが…）。
くわしくは以下のリンクのからどうぞ。
□ kikitai for Palm webOS コンセプトバージョン
tag : PalmwebOS yahoopipes
PalmMojoSDKでpushSceneされたときのアニメーション効果をアプリ側の処理に同期させる方法（あるいは、画面切り替え時の0.5秒って意外と長く感じるのね、という話しなのかも）
画面(scene)を複数持つアプリでは、画面を(pushSceneなどで)切り替えるときにアニメーション効果(scene transitionと言うらしい)が表示されるのですが、描画用のデータをSQLなどで非同期に取ってくる場合などでは、描画が途中の状態でアニメーションが始まってしまい、画面の構成によってはなんとも「むむむむ」な状態になることがあったりなかったり。で、この辺の処理を同期させる方法がないかと調べてみたところ、APIs - Mojo.Function.Synchronize - Palm Developer Centerを経由しつつLaunch Cycle – Palm Developer CenterとAPIs - Mojo.Event - Palm Developer Centerからそれっぽい方法が２つわかったのでメモ。
そして、テスト用アプリを作っての検証など。
今回は、以下のメニュー画面からpushされるscene上で、Assistantの開始から初期化完了までの経過時間を画面に表示するアプリです。
(初期化処理の内容ですが、とくに何もせず一定秒後に完了するになっています)
なお、このテストアプリのソースはこちらからダウンロードできます。
と、こんな感じです。
画面のレイアウトや処理の内容によっては、同期させない方が動きがスムーズに見えたりもするので(実は上記のテストアプリも同期しない方がスムーズに感じるかも…)、今回の方法を全部のSceneで使うことはないかなと言ったところですが、それでも途中で画面が切り替わると妙なケースもあるので、そういった場合に使える選択肢が増えたのは良かったかなと。
- SceneのAssistantにaboutToActivate関数を定義する
たとえば、SecondAssistantの場合ならSecondAssistant.prototype.aboutToActivate = function(callback){みたいにすると、Sceneがactivateされる前にaboutToActivateが実行されて、callbackにはtransition処理と同期するMojoフレームワークのsynchronizeオブジェクトに何もしない関数がwrapされた値がセットされてくる（ややこしいですね、何を書いてるんだが自分でもわけわからなくなりました）。なんだかややこしいですが、ようはaboutToActivateを定義してcallbackを受け取れば、「アプリ側がcallback関数を実行するまではtransition処理に待ったをかけることが出来る」と言うことらしいです。
}
具体的にはSecondAssistant.prototype.aboutToActivate = function(callback){とやると、transition処理の開始を0.3秒遅らせることができます。よって、時間のかかりそうな初期化処理をする場合は、アプリ側でcallbackの実行タイミングを制御することで、画面の描画処理完了とアニメーション開始を同期させることができるようになります。
callback.delay(.3);
}
ただし、ここで使われているSyncronizerにはタイムアウトが設定されていて、遅らせることができるのは最大で0.5秒です。よって、「callback.delay(10);」とやっても実際には10秒待つことにはなりません。おそらく、初期化処理に0.5秒以上かかる場合は「そろそろ時間かかりすぎだし、途中経過が見えても不自然にならないように表示してね」ってことなのかなと(試しにアニメーション開始を0.5秒近く遅らせてみると結構と長く感じる)。
あと、aboutToActivateはactivateと同様に、他の画面から戻ってきて画面がアクティブになるときにも実行されるので、scene開始時に1回だけしか実行したくない処理を行う場合は注意が必要です。 - SceneControllerのsceneElementでMojo.Event.aboutToActivateイベントを受け取るようにする
たとえば、ThirdAssistantのsetupなどでMojo.Event.listen(this.controller.sceneElement, Mojo.Event.aboutToActivate, this.handleAboutToActivate);
とやると、ThirdAssistant.prototype.handleAboutToActivate = function(event) {のように定義したハンドラのeventを経由して、transition処理と同期するSynchronizeオブジェクト(event.synchronizer)を受け取れるようになります。
}
構造的には1の方法と似たような感じですが、こちらの場合は受け取れるのがSynchronizeオブジェクトなので、自分で関数をwrapすることでtransitionの開始を制御することになります。
具体的にはSecondAssistant.prototype.handleAboutToActivate = function(event) {とやると、0.3秒後にログへ"my func2 called","my func1 called"と書き出した後、transition処理の開始させることができます。このようにアプリ側でトリガーを複数作ることが出来るので、完了時間がバラバラな非同期処理が複数ある場合などには、こちらの方が便利かもしれません。
f1=event.synchronizer.wrap(function(){Mojo.Log.info("my func1 called")});
f2=event.synchronizer.wrap(function(){Mojo.Log.info("my func2 called")});
f1();
f2.delay(.3);
}
なお、タイムアウトや画面がアクティブになる毎にイベントを受け取ることになる状況については、1の方法のときと同じです(こっちはやろうと思えばタイムアウトを解除できなくもない感じです)。
そして、テスト用アプリを作っての検証など。
今回は、以下のメニュー画面からpushされるscene上で、Assistantの開始から初期化完了までの経過時間を画面に表示するアプリです。
(初期化処理の内容ですが、とくに何もせず一定秒後に完了するになっています)
- 初期化完了を待たずにtransitionが開始されるsceneの場合
メニューから「普通に表示」をタップすると、「初期化中」ラベルセットされた状態でアニメーションが開始される
最後に値がセットされる。
- 初期化を待ってからtransitionが開始されるsceneの場合、その１
メニューから「aboutToActivate関数を定義」をタップすると、初期化が完了するまで元の画面で止まっている
初期化が完了すると値がセットされた状態でアニメーションが開始される
- 初期化を待ってからtransitionが開始されるsceneの場合、その２
※この画面では初期化処理を２つ行い、どちらの完了も待つようになっています
メニューから「aboutToActivateイベントを使う」をタップすると、今回も初期化が完了するまで元の画面で止まっている
初期化が完了すると２つの値がセットされた状態でアニメーションが開始される
なお、このテストアプリのソースはこちらからダウンロードできます。
と、こんな感じです。
画面のレイアウトや処理の内容によっては、同期させない方が動きがスムーズに見えたりもするので(実は上記のテストアプリも同期しない方がスムーズに感じるかも…)、今回の方法を全部のSceneで使うことはないかなと言ったところですが、それでも途中で画面が切り替わると妙なケースもあるので、そういった場合に使える選択肢が増えたのは良かったかなと。
tag : PalmwebOS
けいおん２期、４月。
□ けいおん２期、４月。 [アニプレックス]
□ けいおん２期、４月。 [アニプレックス]
□ けいおん２期、４月。その�� [バンダイビジュアル]
Googleリーダーを見てたら↑の記事が並んでいて、本日２度目のゲシュタルト崩壊。いい感じで「お」とかの形がわけわからなくなってきた。そして、なんだかわからないけれど、宣伝マンのみなさんの熱意は伝わってきた。
ちなみに、真のけいおん２期は↓だと思う。たぶん
□ TVアニメ「けいおん！」第２期、春番です！！ [ポニーキャニオン]
□ けいおん２期、４月。 [アニプレックス]
□ けいおん２期、４月。その�� [バンダイビジュアル]
Googleリーダーを見てたら↑の記事が並んでいて、本日２度目のゲシュタルト崩壊。いい感じで「お」とかの形がわけわからなくなってきた。そして、なんだかわからないけれど、宣伝マンのみなさんの熱意は伝わってきた。
ちなみに、真のけいおん２期は↓だと思う。たぶん
□ TVアニメ「けいおん！」第２期、春番です！！ [ポニーキャニオン]
わらし様っぽい
わがままDIYでUSBメモリーを連結して大容量化してたけど、似たようなこと考えて（こっちは充電用なので実際はかなり違うけど）さらに製品にしてしまうとは。これに80個のギガっちさんを挿してみたら壮観なんだろうなと思ってみたり。仰天! 80ポートを備えたUSBチャージャーがサンコーから -MSNデジタルライフ
サンコーは29日、「80ポートUSBチャージャーボード」の発売を開始。直販価格は14,800円。
その名のとおり、80ポートを設けたUSBチャージャーボード。まるで基板のような本体にポートがずらりと並ぶ。1列10基、横は8基の構成で、各列とブロックにあるジャンパーピンを付け足しすることで、各列、ブロックの通電のON/OFF切り替えが可能となる。
と、ここまで書いて思ったけど、あのネタってふおんの方だったような気もしてきたような。なんか急に自信がなくなってきた。こういう１つの文章見ていて急にわけわからなくなる現象って、なんとか崩壊って言うんだっけ…。
つーこって、わがままDIYも早く単行本にまとまって欲しいなと。出来ればネタ製品一覧図解付きで。
tag : ふおんコネクト!
PalmMojoSDKのFilePickerから受け取ったiconPathの使い方（あるいはサムネイルを表示させるファイルの名前には、コロンは使わない方よさそうという話しかも)
Mojo.FilePickerを使って、メディア系のファイル(画像、オーディオ、ビデオ)を選択すると、コールバック関数にfullPathとiconPathが渡されるが、このiconPathをimgタグのsrcにセットしてもそのままでは使えないっぽい。なにか方法はないのかなと、フレームワークのソースを調べてみたところ、なんとなく表示できるようになったのでメモなど。
まず、画像ファイルを選択したときのiconPathに含まれている"/var/luna/data/extractfs"でフレームワークのソースを検索してみると、widget_imageview.js(ImageViewWidgetのソースファイル)がひっかかる。そこで、ソースをざっと眺めてみたところ、どうやら"/var/luna/data/extractfs"にローカルの画像ファイル名とかを連結したものをurlとして組み立てて、そのurlをimgタグのsrcにセットすると、iconPathとか関係なしにリサイズされた画像が表示できそうな予感。で、google先生に"extractfs"のことをたずねてみると、やはりできそう。
□ Resize image captured with camera - PreCentral Forums
ということなので、ImageViewWidgetのパラメータなども参考に「iconPath + "幅:高さ:3"」とurlを組み立ててimgタグのsrcにセットしてみたところ、画像が表示されることが確認できるのだが、ちょっと問題が…。
画像全体が指定サイズに収まるようにリサイズされてしまうので、複数の画像ファイルのアイコンを並べるとサイズがバラバラになる可能性もある。そこでパラメータをてきとうに弄ってみたところ、"幅:高さ:4"を連結するとFilePicker上に表示されるサムネイル画像のようにリサイズされるので、アイコンとして表示させるならば、末尾は":4"を指定したほうがよさそう(*1)。
また、オーディオファイルではiconPathに"/var/luna/data/extractfs"が含まれず、ビデオファイルは逆にそのままsrcにセットできそうな値になっているっぽい。そのため、画像ファイル以外も同一ロジックでアイコンを表示させるならば、iconPathをそのまま使うよりも、widget_imageview.js内の_getExtractFSUrlを参考にオリジナルのファイル名(fullPath)からiconPathを組み立て直すほうがよさそう。
あと、これはiconPathよりも"/var/luna/data/extractfs"側の問題っぽいけれど、ファイル名に":"が含まれているとリサイズされた画像が表示できないような気がする(画像ファイルだとFilePickerから選択すること自体ができない)。
で、その辺を考慮してiconPathの使い方をまとめてみると
FilePickerから受け取ったiconPathは、「"/var/luna/data/extractfs" + encodeURIComponent(fullPath) + "nnn:mmm:幅:高さ:4"」(nnnとmmmはiconPath末尾の":"で区切られた数値の最初の２つ)のようにurlを組み立てなおした後、そのurlをimgタグのsrcなどにセットするとアイコン画像を表示できるようになる。ただし、選択したファイルのパスに":"が含まれていると、アイコン画像を表示できない可能性が高いと思われる。
といった感じになるのかなと。
以下、テストアプリを作成して検証など。
アプリ起動後FilePickerを表示させてファイルを選択すと、右側の図のようにファイル名やパラメータがセットされる。
ファイル選択後「表示」ボタンをタップすると、アイコンなどが表示される。
パラメータは手動で変更できるので、試しに末尾を"4"から"3"へ変更してから再度「表示」ボタンをタップすると、画像のリサイズ方法が変わったことが確認できる。
オーディオファイルを選択して表示したところ。
オーディオとビデオファイルの場合は、2番目の値は数字であればいいらしい(何故なのかは不明、なので普通は弄らないほうがいいのかなと)。
ファイル名に":"が含まれている場合は表示できない(":"を含めた後はFilePickerやMusicPlayer上でもサムネイルが表示できていない状態です)。
(このテストアプリのソースはこちらからダウンロードできます)
あと、いちおう念のため補足ですが、FilePickerから渡されるiconPathや"/var/luna/data/extractfs"はアプリ側から直接使っていいのかよくわらないので、今回の方法が今後のwebOSのバージョンアップ後にも使えるかはわかりません。また検証もそれほど多くのファイルで行っていないので、テストアプリのコードではうまくいかないパターンもあるかもしれません(画像ファイルについては大丈夫そうだけれど、オーディオとビデオは実機での挙動が不明なのとサンプル数が少ないので、あまり自信はないといった感じです)。
(*1)
念のため、Photosアプリで表示されるサムネイル画像のurl確認したところ、末尾が":4"になっていたので、サムネイルっぽくリサイズするならばとりあえずは末尾が":4"でいいのかなと。たぶん。
まず、画像ファイルを選択したときのiconPathに含まれている"/var/luna/data/extractfs"でフレームワークのソースを検索してみると、widget_imageview.js(ImageViewWidgetのソースファイル)がひっかかる。そこで、ソースをざっと眺めてみたところ、どうやら"/var/luna/data/extractfs"にローカルの画像ファイル名とかを連結したものをurlとして組み立てて、そのurlをimgタグのsrcにセットすると、iconPathとか関係なしにリサイズされた画像が表示できそうな予感。で、google先生に"extractfs"のことをたずねてみると、やはりできそう。
□ Resize image captured with camera - PreCentral Forums
ということなので、ImageViewWidgetのパラメータなども参考に「iconPath + "幅:高さ:3"」とurlを組み立ててimgタグのsrcにセットしてみたところ、画像が表示されることが確認できるのだが、ちょっと問題が…。
画像全体が指定サイズに収まるようにリサイズされてしまうので、複数の画像ファイルのアイコンを並べるとサイズがバラバラになる可能性もある。そこでパラメータをてきとうに弄ってみたところ、"幅:高さ:4"を連結するとFilePicker上に表示されるサムネイル画像のようにリサイズされるので、アイコンとして表示させるならば、末尾は":4"を指定したほうがよさそう(*1)。
また、オーディオファイルではiconPathに"/var/luna/data/extractfs"が含まれず、ビデオファイルは逆にそのままsrcにセットできそうな値になっているっぽい。そのため、画像ファイル以外も同一ロジックでアイコンを表示させるならば、iconPathをそのまま使うよりも、widget_imageview.js内の_getExtractFSUrlを参考にオリジナルのファイル名(fullPath)からiconPathを組み立て直すほうがよさそう。
あと、これはiconPathよりも"/var/luna/data/extractfs"側の問題っぽいけれど、ファイル名に":"が含まれているとリサイズされた画像が表示できないような気がする(画像ファイルだとFilePickerから選択すること自体ができない)。
で、その辺を考慮してiconPathの使い方をまとめてみると
FilePickerから受け取ったiconPathは、「"/var/luna/data/extractfs" + encodeURIComponent(fullPath) + "nnn:mmm:幅:高さ:4"」(nnnとmmmはiconPath末尾の":"で区切られた数値の最初の２つ)のようにurlを組み立てなおした後、そのurlをimgタグのsrcなどにセットするとアイコン画像を表示できるようになる。ただし、選択したファイルのパスに":"が含まれていると、アイコン画像を表示できない可能性が高いと思われる。
といった感じになるのかなと。
以下、テストアプリを作成して検証など。
アプリ起動後FilePickerを表示させてファイルを選択すと、右側の図のようにファイル名やパラメータがセットされる。
ファイル選択後「表示」ボタンをタップすると、アイコンなどが表示される。
パラメータは手動で変更できるので、試しに末尾を"4"から"3"へ変更してから再度「表示」ボタンをタップすると、画像のリサイズ方法が変わったことが確認できる。
オーディオファイルを選択して表示したところ。
オーディオとビデオファイルの場合は、2番目の値は数字であればいいらしい(何故なのかは不明、なので普通は弄らないほうがいいのかなと)。
ファイル名に":"が含まれている場合は表示できない(":"を含めた後はFilePickerやMusicPlayer上でもサムネイルが表示できていない状態です)。
(このテストアプリのソースはこちらからダウンロードできます)
あと、いちおう念のため補足ですが、FilePickerから渡されるiconPathや"/var/luna/data/extractfs"はアプリ側から直接使っていいのかよくわらないので、今回の方法が今後のwebOSのバージョンアップ後にも使えるかはわかりません。また検証もそれほど多くのファイルで行っていないので、テストアプリのコードではうまくいかないパターンもあるかもしれません(画像ファイルについては大丈夫そうだけれど、オーディオとビデオは実機での挙動が不明なのとサンプル数が少ないので、あまり自信はないといった感じです)。
(*1)
念のため、Photosアプリで表示されるサムネイル画像のurl確認したところ、末尾が":4"になっていたので、サムネイルっぽくリサイズするならばとりあえずは末尾が":4"でいいのかなと。たぶん。
tag : PalmwebOS
Web SQL Databaseで日本語の文字列をキーとして行をソートする
いま作っているアプリでSQLを使おうかなと思ってる理由に、group byや order byを使いたいというのがあるのですが、Web SQL DatabaseのexecuteSqlで「select * from table order by key;」みたいな指定をしても、何故か思ったようにソートされないという問題が…。google先生で検索してみると、どうやらWeb SQL Databaseのベースとなっているsqliteでorder byを使う場合、「SQLiteの日本語ソート問題 - Fioの素敵な日々」を参考にした感じではデータベースに指定されているencodeに関係ありそうなのだけれども(エミュレータ内に出来てたデータベースを「PRAGMA encoding;」で調べたらUTF-16leだった)、Web SQL Databaseではデータベースのencodingを変更する方法がよくわからないので、リンク先にある解決方法と同じような方法は使うことができなさそう…。
で、どうしたものかなと悩んでいると、なぜか「select * from table order by lower(key);」のようにlower関数を使うと(大文字小文字の区別はなくなるが)なんとなくそれっぽい並びになる。
以下、「あ」「ん」「ア」「ン」「こじま」「ごとう」「こばやし」「漢字」「亜」「意」「卯」「絵」「尾」「！」「＃」「＄」「｛」「｝」「!」「#」「$」「{」「}」「a」「z」「A」「Z」「ａ」「ｚ」「Ａ」「Ｚ」「0」「9」「０」「９」をinsertした後、ソートして表示するページを作成して検証した結果など。
※今回はwebOS上のWeb SQL Database固有の問題か確認してみようかとも思って、Palm webOS(SDK 1.3.5に付属のエミュレータ)のWebブラウザの他に、WindowsXP上のSafari4.0.4で試してみましたが、結果は同じでした。
この結果からなんとなく思うのは、TEXT型を単純にorder byにかけると生データで比較するけれど、lowerのように文字列を操作する関数を通すと、関数の結果をUTF-8あたりの文字列として比較するのかなと。この辺の挙動はどうなるのが正解なのかよくわからないけれど、どちらにしても大文字小文字の区別はなくしたかったので、とりあえずorder byではlowerを使う対応で行くことにしようかなと。
ただ、ちょっと残念なのは、lowerで回避した場合でもいわゆる半角と全角の英数記号が離れたならびになったり、仮名などが辞書順のならびにできないことなんですよねぇ…。
と、いうことで、以下ちょっと脱線。
Contactsアプリで「こじま」「ごとう」「こばやし」「0」「０」「9」「９」を名前にした項目を登録するとこの通りにならぶので、なにか辞書順にソートする方法がないか、こちらもちょっと調べてみることに。その結果、ContactsはService側で項目のリストを作成しているようなので、他のアプリでは参考にできなさそうだけれど、Javascript上でソート処理を行う場合は、比較関数内でlocaleCompareを使えば行けそうな感じが。
で、これを試してみたところ…、safariではそれっぽい並びが得られるものの、webOSのWebブラウザでは残念ながら普通に文字列を比較したのと同じ結果となってしまう（もしやと思って、ミニー氏のlocaleを追加する方法でja_jpへ切り替えて試してみたけれど、こちらでも結果はかわらず）。どうやらwebOSのlocaleComapreは日本語対応していないようで…。
以下、order byの検証のときに使ったデータを、Array.sort+localeCompareでソートした結果など。
ここまできたら上手くいかないのもモヤっとした感じではあるけれど、まぁ今回はorder byを使う方針にしたので、とりあえずはあまり深く考えない方向でってことにしておこうかなと。
なお、今回テストに使ったページはこちらで表示できます。
※Palm webOS(SDK 1.3.5に付属のエミュレータ)のWebブラウザとWindowsXP上のSafari4.0.4で動作確認してあります。IEやFirefoxなどでは動作しません。エラーや環境チェックをしていないでの、未対応のブラウザを使っている場合や、あまり変な動作をするページに近づきたくない場合は、開かないほうがいいかと思います。また、Palm webOSのブラウザでは、メニューなどからデータベースを消す方法がよくわからないので、テスト用に作成したデータベースが残ったままになるのを避けたい場合も、Palm webOSのブラウザでは開かないほうがいいと思います(エミュレータへloginして/var/home/root/html5-databases/http_zawakei.web.fc2.com_0フォルダを消せばいいようですが、よくわかりません)。
以下、Safariで上記ページを表示したときの画像。
で、どうしたものかなと悩んでいると、なぜか「select * from table order by lower(key);」のようにlower関数を使うと(大文字小文字の区別はなくなるが)なんとなくそれっぽい並びになる。
以下、「あ」「ん」「ア」「ン」「こじま」「ごとう」「こばやし」「漢字」「亜」「意」「卯」「絵」「尾」「！」「＃」「＄」「｛」「｝」「!」「#」「$」「{」「}」「a」「z」「A」「Z」「ａ」「ｚ」「Ａ」「Ｚ」「0」「9」「０」「９」をinsertした後、ソートして表示するページを作成して検証した結果など。
| order byのみ | order by+lower |
| ！ ＃ ＄ 意 ０ ９ ! Ａ 漢字 # $ 0 9 Ｚ 尾 A ａ あ こじま こばやし ごとう Z ｚ ｛ ｝ a 卯 絵 z { } ん 亜 ア ン | ! # $ 0 9 a A z Z { } あ こじま こばやし ごとう ん ア ン 亜 卯 尾 意 漢字 絵 ！ ＃ ＄ ０ ９ Ａ Ｚ ａ ｚ ｛ ｝ |
この結果からなんとなく思うのは、TEXT型を単純にorder byにかけると生データで比較するけれど、lowerのように文字列を操作する関数を通すと、関数の結果をUTF-8あたりの文字列として比較するのかなと。この辺の挙動はどうなるのが正解なのかよくわからないけれど、どちらにしても大文字小文字の区別はなくしたかったので、とりあえずorder byではlowerを使う対応で行くことにしようかなと。
ただ、ちょっと残念なのは、lowerで回避した場合でもいわゆる半角と全角の英数記号が離れたならびになったり、仮名などが辞書順のならびにできないことなんですよねぇ…。
と、いうことで、以下ちょっと脱線。
Contactsアプリで「こじま」「ごとう」「こばやし」「0」「０」「9」「９」を名前にした項目を登録するとこの通りにならぶので、なにか辞書順にソートする方法がないか、こちらもちょっと調べてみることに。その結果、ContactsはService側で項目のリストを作成しているようなので、他のアプリでは参考にできなさそうだけれど、Javascript上でソート処理を行う場合は、比較関数内でlocaleCompareを使えば行けそうな感じが。
で、これを試してみたところ…、safariではそれっぽい並びが得られるものの、webOSのWebブラウザでは残念ながら普通に文字列を比較したのと同じ結果となってしまう（もしやと思って、ミニー氏のlocaleを追加する方法でja_jpへ切り替えて試してみたけれど、こちらでも結果はかわらず）。どうやらwebOSのlocaleComapreは日本語対応していないようで…。
以下、order byの検証のときに使ったデータを、Array.sort+localeCompareでソートした結果など。
| webOS | safari |
| ! # $ 0 9 A Z a z { } あ こじま こばやし ごとう ん ア ン 亜 卯 尾 意 漢字 絵 ！ ＃ ＄ ０ ９ Ａ Ｚ ａ ｚ ｛ ｝ | ！ ! ｛ { ｝ } ＃ # ＄ $ 0 ０ 9 ９ A Ａ a ａ Z Ｚ z ｚ あ ア こじま ごとう こばやし ん ン 亜 意 卯 絵 漢字 尾 |
なお、今回テストに使ったページはこちらで表示できます。
※Palm webOS(SDK 1.3.5に付属のエミュレータ)のWebブラウザとWindowsXP上のSafari4.0.4で動作確認してあります。IEやFirefoxなどでは動作しません。エラーや環境チェックをしていないでの、未対応のブラウザを使っている場合や、あまり変な動作をするページに近づきたくない場合は、開かないほうがいいかと思います。また、Palm webOSのブラウザでは、メニューなどからデータベースを消す方法がよくわからないので、テスト用に作成したデータベースが残ったままになるのを避けたい場合も、Palm webOSのブラウザでは開かないほうがいいと思います(エミュレータへloginして/var/home/root/html5-databases/http_zawakei.web.fc2.com_0フォルダを消せばいいようですが、よくわかりません)。
以下、Safariで上記ページを表示したときの画像。
tag : PalmwebOS
マルドゥック・スクランブル劇場アニメ化
なんと、アニメ化の企画が復活ですか。この機会に単行本未収録の短編をまとめてもらえると嬉しいなと思ってみたり。マルドゥック・スクランブル
冲方丁が放つSF最高傑作「マルドゥック・スクランブル」の劇場アニメ化が決定した。
【関連リンク】
□ 人気SF小説「マルドゥック・スクランブル」の劇場アニメ化が決定！ : 映画ニュース - 映画のことならeiga.com
PalmMojoSDKでローカルのストレージにデータを格納するにはどの方法を使うのがいいのか？
PalmMojoSDKでローカルのストレージにデータを格納する方法については、「Storage – Palm Developer Center」を見ると
これからはIndexed Database APIと言うのがかわりになっていくのかな、と言った感じなようですが、現状のwebOSでは、Indexed Database APIを使うことができない＆その他のローカルストレージ用APIのWeb Storageも使うことができないっぽいので、大きめのデータを格納しようとしたら、現時点ではとりあえずWeb Storageに似てるDepotを使っておくのが無難な選択なのかなと。
とは言ってみたものの、いま作っているアプリはSQL前提で作り始めてしまったから、ちょっと悩んでしまうけれど、やっぱり今回はWeb SQL Databaseを使っていくことになりそうかなぁ。
- Mojo.Cookie-CookieをMojoアプリから使いやすいようにしたAPI
- Mojo.Depot-HTML 5 database objectをラップしてkey/value型の形式で扱えるようにしたAPI(将来は異なる実装になるかもしれない)
- HTML 5 database object-Web SQL Databaseのこと
Mojo.CookieやMojo.DepotのようにMojo側のAPIでラップされていなかったから、将来的にはwebOS(が使うWebKit)のバージョンによる実装の違いに悩むことになったりするのかな？とはちょっとだけ思っていたけれど、このようなことになっていたとは…。2009年12月のW3C | Web標準Blog | ミツエーリンクス
このうち、Web SQL Databaseは今後の策定が実質的に停止する旨が仕様書に書かれました。
これからはIndexed Database APIと言うのがかわりになっていくのかな、と言った感じなようですが、現状のwebOSでは、Indexed Database APIを使うことができない＆その他のローカルストレージ用APIのWeb Storageも使うことができないっぽいので、大きめのデータを格納しようとしたら、現時点ではとりあえずWeb Storageに似てるDepotを使っておくのが無難な選択なのかなと。
とは言ってみたものの、いま作っているアプリはSQL前提で作り始めてしまったから、ちょっと悩んでしまうけれど、やっぱり今回はWeb SQL Databaseを使っていくことになりそうかなぁ。
tag : PalmwebOS
PalmMojoSDKではファイルの絶対パス指定に"file://"が使えないときがある？
「もじもか」でSDK v1.3.5対応したときに、ファイルの絶対パス指定でちょっとハマったのでメモなど。
Palm webOS 1.3.5からはアプリが格納されるフォルダが変わって、自アプリフォルダ内のファイルをフルパスで扱うような場合は、Mojo.appPathを使うほうがいいよ的な記述があるのですが、Mojo.View.renderのtemplate用に「Mojo.appPath + "app/views/main/template"」みたいな感じでファイルのパスを組み立てると、Mojo.View.render実行時に"template load failed:〜"が返ってきたります。
これは何が原因かと言うと、Mojo.appPathから取り出せるアプリフォルダのパスはスキームとかくっついてくるようなのですが(先頭に"file://"が付いてくる)、Mojo.View.renderではこれを上手く処理できないようです。試しに"file://"を取り除いたパスを指定すると、それだけで正しくテンプレートを読み込めるようになります。
では、ファイルを扱う他のAPIでも同じようになるのかというと、Mojo.Locale.readStringTableではpathToResourcesDirの指定に"file://"があってもなくても正しく動いたりします…。
以下、Mojo.appPathを使って組み立てた絶対パスなどから、Mojo.Locale.readStringTableとMojo.View.renderを実行するテストアプリ(appPathChk)を作って検証など。
（今回のテストアプリは、アプリフォルダ内のresources/table.jsonを読み込んで内容をベタで表示、同じくアプリフォルダ内のapp/views/main/template.htmlをテンプレートとして今日の日付を表示します。）
"file://"を取り除かない場合、Mojo.Locale.readStringTableは正常に動作するが、Mojo.View.renderはエラーとなる。
"file://"を取り除いた場合は、どちらも正常に動作する。
（このテストアプリのソースはこちらからダウンロードできます）
自アプリフォルダ内のファイルを指定する場合、殆どの場合は相対パスで間に合うので、Mojo.View.renderのtemplateへ絶対パスを指定したときのことはあまり気にしなくてもいいのかなとは思いますが、どのようなことをやると"file://"がエラーになるのかよくわからないので(*1)、「相対パスで指定していたときは調子良かったのに、Mojo.〜の値を使って絶対パスを指定したら何故か動かない」といったようなケースに遭遇したときには、この辺を疑ってみるのもありなのかなと(*2)。
あと、いちおう補足ですが、今回はとりあえず"file://"を取り除くことで対応してますが、これが正しい対応なのかはよくわかりません（将来Palm webOSでまたなんらかの仕様変更があった場合、これが原因でアプリが動かなくなるかもしれません）。また、Mojo.View.renderではtemplateを絶対パスで指定するとローカライズリソースを使うのが難しくなります。よって、templateなどの指定は、何か理由があって相対パスが使えない場合以外では、できるだけ不確定な要素が入らない相対パスを使ったほうがよいのでないかと思います（「もじもか」で思いっきり絶対パス指定を使っているおまえが言うなって感じだとは思いますが…）。
(*1)
今回は試してないですが、ListWidgetのitemTemplateあたりもダメなような気がしないでもないです。
(*2)
逆にローカルファイルの指定で、"file://"が無いとエラーになるケースとかもあったりしちゃうのかなとか、ちょといやーんなことも思ってみたり。ちなみに、Mojo.FilePicker.pickFileでファイル一覧からファイルを選択した場合、コールバック関数へ返されるfullPathには"file://"が無かったりします…。
Palm webOS 1.3.5からはアプリが格納されるフォルダが変わって、自アプリフォルダ内のファイルをフルパスで扱うような場合は、Mojo.appPathを使うほうがいいよ的な記述があるのですが、Mojo.View.renderのtemplate用に「Mojo.appPath + "app/views/main/template"」みたいな感じでファイルのパスを組み立てると、Mojo.View.render実行時に"template load failed:〜"が返ってきたります。
これは何が原因かと言うと、Mojo.appPathから取り出せるアプリフォルダのパスはスキームとかくっついてくるようなのですが(先頭に"file://"が付いてくる)、Mojo.View.renderではこれを上手く処理できないようです。試しに"file://"を取り除いたパスを指定すると、それだけで正しくテンプレートを読み込めるようになります。
では、ファイルを扱う他のAPIでも同じようになるのかというと、Mojo.Locale.readStringTableではpathToResourcesDirの指定に"file://"があってもなくても正しく動いたりします…。
以下、Mojo.appPathを使って組み立てた絶対パスなどから、Mojo.Locale.readStringTableとMojo.View.renderを実行するテストアプリ(appPathChk)を作って検証など。
（今回のテストアプリは、アプリフォルダ内のresources/table.jsonを読み込んで内容をベタで表示、同じくアプリフォルダ内のapp/views/main/template.htmlをテンプレートとして今日の日付を表示します。）
"file://"を取り除かない場合、Mojo.Locale.readStringTableは正常に動作するが、Mojo.View.renderはエラーとなる。
"file://"を取り除いた場合は、どちらも正常に動作する。
（このテストアプリのソースはこちらからダウンロードできます）
自アプリフォルダ内のファイルを指定する場合、殆どの場合は相対パスで間に合うので、Mojo.View.renderのtemplateへ絶対パスを指定したときのことはあまり気にしなくてもいいのかなとは思いますが、どのようなことをやると"file://"がエラーになるのかよくわからないので(*1)、「相対パスで指定していたときは調子良かったのに、Mojo.〜の値を使って絶対パスを指定したら何故か動かない」といったようなケースに遭遇したときには、この辺を疑ってみるのもありなのかなと(*2)。
あと、いちおう補足ですが、今回はとりあえず"file://"を取り除くことで対応してますが、これが正しい対応なのかはよくわかりません（将来Palm webOSでまたなんらかの仕様変更があった場合、これが原因でアプリが動かなくなるかもしれません）。また、Mojo.View.renderではtemplateを絶対パスで指定するとローカライズリソースを使うのが難しくなります。よって、templateなどの指定は、何か理由があって相対パスが使えない場合以外では、できるだけ不確定な要素が入らない相対パスを使ったほうがよいのでないかと思います（「もじもか」で思いっきり絶対パス指定を使っているおまえが言うなって感じだとは思いますが…）。
(*1)
今回は試してないですが、ListWidgetのitemTemplateあたりもダメなような気がしないでもないです。
(*2)
逆にローカルファイルの指定で、"file://"が無いとエラーになるケースとかもあったりしちゃうのかなとか、ちょといやーんなことも思ってみたり。ちなみに、Mojo.FilePicker.pickFileでファイル一覧からファイルを選択した場合、コールバック関数へ返されるfullPathには"file://"が無かったりします…。
tag : PalmwebOS
2010年シチューの旅
初詣のおみくじを引いた後、「今ここで1年の運を使い切ったのでは」とちょっと心配になってみたりした、そんな正月2010。
今年も適当にいってみようかなと思ってみたりみなかったりなので、ゆるーく読んでいただければ幸いです。
今年も適当にいってみようかなと思ってみたりみなかったりなので、ゆるーく読んでいただければ幸いです。
