普通的生活

Adobeからソースコード用のフォントSource Code Proが公開されています。Iやl, Oと0などが視認しやすくなっています。

Mac OS Xでは/Library/Fontsにファイルファイルを入れておけば良いようです。

CotEditorで早速使用してみました。すっきりとして読みやすく、かなり良い感じです。

前のエントリーと関連した話題です。Perlにもいつの間にかデバッガーが搭載されていました。ほぼpythonのものと同等の機能を持っていますが微妙にコマンドが違います。ということで、覚書エントリーです。

起動は、

perl -d hoge.pl

などとします。

コマンドは、

 b 100

 L

 B 100

 c

 s

 n

 p $hoge

今時のpythonにはデバッガーが内蔵されているためブレークポイントを設定したりステップ動作を行いつつ変数の中身を調べるなどということを簡単に行うことが出来ます。たまにしか使わないためすぐコマンドを忘れてしまう自分のために覚書としてエントリーしておきます。

起動方法は簡単で

python -m pdb hoge.py

などとしてコマンドラインで起動します。同時にhoge.pyを行番号表示の出来るエディターで開いておくと分かりやすいです。

コマンドを自分で使う最低限のものだけ紹介します。

 b 100 

 b 

 cl 1 

 c 

 s 

 p hoge 

この本にはデバッガーについての解説は無いと思いますが、私がpythonを始めるにあたって購入した唯一の書籍です。

SQLite3というサーバー要らずのDBエンジンはパーソナルにSQLを使用するのに手軽です。また、最近の多くのモバイル・デバイスの内部でも使用されています。

ということでMac OS X上でもiOSアプリ内(最近はCoreDataに移行中ですが)でも多用しています。単純な単語の場合は問題ありませんが特殊文字も含めてqueryする場合には文字のエスケープを行わなればなりません。iOSアプリの内部で多様な文字列のqueryを行う必要が出てきたために文字列のエスケープについてまとめてみました。

[ LIKE operatorの場合 ]
標準的なSQLで使用されるLIKEと同じです。ワイルドカードとして%(0個以上の任意の文字に一致)と_(任意の一文字に一致)が使用できます。そのため%と_自身をマッチさせるためにはエスケープ文字の指定が必要です。 エスケープ文字の指定にはESCAPE節を使用します。

SELECT * FROM hoge WHERE key LIKE '% test^_case %' ESCAPE '^';

という具合に使用します。ESCAPEで指定した文字自体もエスケープ対象になります。

引用符の扱いはperlと同様です。
– シングルクォート ‘ で囲まれた文字列の中ではダブルクォート ” は自由に使用できる。
– ダブルクォート ” で囲まれた文字列の中ではシングルクォート ‘ は自由に使用できる。
– シングルクォートとダブルクォートが混在する場合には囲み文字自体でエスケープ出来る。

SELECT * FROM hoge WHERE key LIKE 'I''m reading the "SNOW WHITE"';

[ GLOB operatorの場合 ]
GLOBはSQLiteに特有なオペレーターです。正規表現的な表現を使用しLIKEより柔軟なパターンマッチングが行えます。またLIKEは大文字小文字の区別がありませんがGLOBでは大文字小文字を区別します。

ここではエスケープについてだけ書きます。エスケープしなければならない文字は [ ] * ? です。エスケープの方法は、それぞれを[]で囲みます。

SELECT * FROM hoge WHERE key GLOB 'How are you[?] *';

といった具合になります。'[Y/n]’のように[]自体が含まれる文字列のマッチングも同様です。

SELECT * FROM hoge WHERE key GLOB '[[]Y/n[]]';

引用符の扱いはLIKEと同じです。

KKJConvでエラーが発生するということで調べてみたところ、どうもMIDP実行環境側の問題のようです。

エラーが発生するのは次のようなコードです。

TextBox tb;
tb.delete(0, tb.size());

このコードはTextBoxの文字列を削除するためのものですが、TextBoxが空の時に左の写真のようにString Index Out Of Boundsというエラーが発生します。

deleteメソッドの第一パラメータはオフセット、第二パラメータは削除する文字列の長さです。

tb.size() が 0 の時の問題なので tb.delete(0, 0); のようにしてテストすると文字列が存在する時にはエラーは発生しません。言い換えるとTextBoxに文字列が存在しない時にdeleteを呼ぶとエラーするということです。一応、ドキュメントを確認しましたが呼び方には問題が無いように思えます。ましてやKKJConvの初期から存在するコードなので実績もおおいにあります。

回避策は簡単なので以下のようなコードに変更してKKJConvのエラーは回避出来ました。

if (0 < tb.size()) {
  tb.delete(0, tb.size());
}

Nokiaにバグではないの?と投げかけようと思いましたが、以前Forum Nokiaにあったバグレポートのシステムが見つかりません。もう一般開発者からのバグレポートは受け付けてないのかな?

既にAyamadoriさんがブログ「書くことないです。」に最新のNokia Series 40 Touch and Type端末のMIDP開発環境について書かれています。

私はQWERTYキーボードを中心に分かったことを書いてみたいと思います。

キーボード素直です。ずっとS60 3rdからフルキーボードのキーコードには悩み続けてきました。E7に至っては訳がわからないというのが正直な感想でした。それから考えると物足りないくらいに素直な挙動です。

E90などと違うのはCtrl+Cなどでコントロール・コードでは無く”C”そのものが返ってくることです。ただしCtrlキーそのものがキーコードを発生してくれるのでMIDPのアプリケーション内で処理可能です。また、CtrlだけではなくSymや数字シフトなどもキーコードが出ています。CtrlもSymキーもMIDPのCanvasでは何も働きませんので、逆に自分の好きなように役割を与えられるとも言えます。

カーソル移動キーが無い。「書くことないです」でも触れられていますが、方向キー、所謂10字キーが無いデバイスです。その代わりに画面を上下左右にスワイプすることで対応するキーコードが得られます。また左右のメニュー・キーもありません。これも画面のタップで代用します。S60 5thのタッチデバイスで表示される、あまり使いたいとは思わないゲーム・キーなバーチャル・キーボードは無くなったようです。

QWERTYキーで文字入力中に編集のためにスワイプというのは今ひとつな気もします。KKJConvではやはりキーボード操作でカーソルを移動できるようにしたいと思います。

液晶にタッチすれば何とか今までと同様の動作が出来ると思いきやダメなケースも見つかりました。Google Mapsは未だMIDP版が配布されていますが、これが全く操作不能でした。Google Mapsは画面を大きく使うためにCanvasをフルスクリーンで動作させています。検証はしていませんが、どうもこれが災いして画面のタッチが全く効きません。10キーだけは反応するですが、起動時に表示されたダイアログを消すことが出来なかったので、全く使い物になりませんでした。

Dropbox APIが新しくなったというニュースを見かけて、とあるアプリケーションに使ってみようと重い腰を上げテストしてみました。

iOS v1.0にはドキュメントが用意されていません。SDKに添付されているサンプル・プロジェクトが動くことを確認した後はtutorialに従って基本的に動作確認です。ところがファイルをアップロードしようとしたらupLoadFileがdeprecatedであると言われてしまいました。

ChagelogやDBRestClient.hを読めば事情は把握できるので良しとしましょう。せっかくのtutorialなので最新のAPIに変更しておいて欲しいものです。

新しいupLoadFileは、

- (void)uploadFile:(NSString *)filename toPath:(NSString *)path withParentRev:(NSString *)parentRev
    fromPath:(NSString *)sourcePath;

という形式です。parentRevと言うパラメータが増えています。ここにnilを指定してアップロードすることも出来ます。その場合、同じファイル名がサーバー上に存在する場合上書きをせずファイル名の後に(1)などと付加されて新しいファイルとして保管されます。現行ファイルを上書きする場合はloadMetadataにて現在のファイルのrevを取得しなければなりません。

ものすごく単純なコード例を書いておきます。
前提としてdocDirはアプリのDocumentフォルダーを指し、そこにファイルtest.txtが存在するものとします。またTutorial通りの手順でrestClientは初期化されているものとします。

- (void)uploadFile1
{
    [[self restClient] loadMetadata:@"/test.txt"];
}

-(void)uploadFile2:(DBMetadata*)meta
{
    NSString *testfile = [docDir stringByAppendingPathComponent:@"test.txt"];
    [[self restClient] uploadFile:@"test.txt" toPath:@"/" withParentRev:meta.rev fromPath:testfile];
}

// DBRestCleintDelegte
- (void)restClient:(DBRestClient*)client loadedMetadata:(DBMetadata*)metadata
{
    [self uploadFile2:metadata];
}

- (void)restClient:(DBRestClient*)client loadMetadataFailedWithError:(NSError*)error
{
    [self uploadFile2:nil];
}

revは元々、古いバージョンのファイルをリストアしたりするためのものと思います。詳しくは考えていませんが(ぉぃ、とりあえず動いてはいるようです。

久しぶりにiOSアプリケーションを更新しサブミットしたらInvalid Binaryになってしまいました。Xcode 4.2のArchiveからValidationは問題なし。Xcode4.2上ではSubmitも問題なしですがiTunes Connectを見るとInvalid Binaryと表示されていました。以前ですと問題があると何かしらエラーの理由が記されたメールが送られてくるのですが、それもありません。

まったく、手がかりの無いところから原因を探らねばなりません。Googolで検索すると、同様の現象について沢山の事例が見つかりました。ひとつひとつ検証した結果Info.plistでのアイコン指定の問題でした。

前提としてはiOS Deployment Targetが3.0なUniversal Applicationです。

最初は、

CFBundleIconFile icon.png
CFBundleIconFiles
  Item 0 icon.png
  Item 1 icon@x2.png
  Item 2 icon-72.png

みたいな感じでした。これで以前は問題なかったと思います。

ここに下のアイテムを追加してInvalid Binaryが解消しました。

CFBundleIconFile~ipad icon-72.png

本来ならXcodeのValidationでエラーを見つけてくれるべきなんでしょうね。試しにCFBundleIconFileにファイル名を消してみるとValidationの際にかなり詳しいエラーメッセージが出ました。

Nokia E7-00のKKJConv対応で、どうやっても解決出来無い部分が残ってしまいました(これはN97miniやN97から同じかも知れないです)。E7-00に搭載されているQWERTYキーボードがMIDPアプリケーションからどのように見えるかという問題です。

[ 改行キーでキーコードが発生しない ]

改行キーが何も役割を与えられていない訳ではありません。通常のMIDPアプリケーションで改行キーを押すと左側ソフトキーに対応するメニューが開くようになっています。タッチデバイスということで何かしらの配慮から、こうなったのかも知れませんがQWERTYキーボードとして使用する上では、かなり不自然で不便です。メニューの存在しない(正確にはリスナーを登録しない)テストプログラムも試してみましたが、やはりkeyPressed(int)やkeyReleased(int)でキーコードを得ることは出来ませんでした。

CtrlキーがあるE7-00ではCtrl+jで改行キーを代用出来るのですが、ここにも落とし穴(後述します)あるので’@’キーを改行キーの代用として割り当てています。

[ シフトモードが分からない ]

通常のシフト、数字記号用のシフト、あるいはSymキーを押すと通常の画面ではシフトモードが画面上部に表示されます。ところがMIDPでは、非フルスクリーンな表示でもシフトモードが表示されません。シフトモードは通常と同じく、一回押すとシフト、２回押すとシフトロックという動作なので、それを自分で把握して入力しなければ行けません。

E90やE63もMIDPではシフト状態の表示はありません。しかしながらシフトを押しても次に入力される英字には影響されず常に小文字が入力されました。つまりアプリケーションにシフト状態の管理が任されていました。それ故、何の表示もないことが正しかった訳です。またE63では数字記号モードはMIDPに入る前に効いていますが、それだけを使用者が自己管理すれば良かったので然程混乱することはありません。

[ 数字記号シフト、Symキーもシフトキーと同じキーコードが発生する ]

どれもシフトの仲間だからということでシフトキーと同じキーコードを割り当てたのかも知れませんが、それが役に立つ場面が思いあたりません。E90やE63では数字記号シフトは何もキーコードを発生しませんでした。それ故にシフト状態をアプリケーション内部で管理するということが容易に出来ていました。

KKJConvとしては、いっそのことシフト表示を止めてしまうかと思いましたが、今のところはシフト表示に合わせて大文字、小文字の相互変換を行っています。ロジックの都合によりシフトを押したままで英字入力が二文字目からは小文字に成ってしまいます。これも、致し方なしです。

[ Ctrl + 英字が効かない事がある ]

英字を入力する際、本体のシフトモードに応じてMIDPアプリケーションに渡されるキーコードが小文字だったり大文字だったりするのは構いません。ところが、Ctrlキーと英字キーを同時に押して発生させるコントロール・コードがシフトモードによって左右されています。シフトモードが大文字に成っている時にCtrl+Jが押されると、キーコードは’J’が発生してしまいます。E90, E63では常に期待どおりのコントロール・コードが発生します。特にE63では数字記号シフトにロックされていてもCtrl+jなら改行キーとして機能します。

Ctrlキーはもともと押下状態かどうかがMIDPアプリケーションでは感知出来ないのでKKJConv側では対処の方法がありません。

ps. 一縷の望みを託してForum Nokiaにてバグレポートいたしました。直ると良いなぁ。

春節前から上海の南京東路にあるノキア旗艦店にてNOKIA E7-00が展示されていました。先日、華南の同志とおもいっきりいじり倒してきましたので、その時の印象です(写真は、同志の撮影たものを無断使用 🙂 )。

まだ販売予定は世界数カ国ですので、今の時点で実機に触れるのは限られ場所と思います。という恵まれた状況にありながら自分の興味の中心にあることだけひたすらテストしていましたのでレビューになってないです。予めお断りしておきます。

[ キーボードはイケテます ] キーボードの開閉は、見たとおりで片手でディスプレイをスライドすれば気持よく開きます。この辺りはノキア、問題なしです。キーの押し込んだ時の感触が適度で携帯端末としては十分に優秀です。

[ サクサクとは言えないか ] 普段iPod Touchを使っているせいか画面の反応は少し鈍くも感じましたが、許容範囲でしょう。アプリケーションによってサクサクだったり鈍かったりしていたような気がします。徐々に良くなっていくことでしょう。

[ カメラは残念 ] Eシリーズでありながら写真の編集アプリが内蔵されていました。顔だけ変形させたりスタンプを押したりするお遊び系アプリです。その反面、搭載されているカメラはフルフォーカスと称する自動焦点の無いものです。このため、紙の書類を撮影しても文字が読めるほどに焦点は合いませんし、細かない部品を撮ろうにもマクロは効きません。最近のノキアはNシリーズのみがCarl Zeissブランドのオートフォーカス・カメラが搭載されていて、他のシリーズは全て自動焦点が有りません。ビジネス・ユーザーだってCarl Zeissじゃなくて良いので自動焦点なカメラが欲しいと思うのですけどね。

[ MIDPはどうやろ? ] さて、ここからが私の本題であるMIDP (Javaアプリ)関連の話になります。