このシリーズは今回で最終回の予定です。
ChromeOS向けの「IME API」を使ってSKKを作りました、という話のシリーズなのですが、こういうものを作るときに何が一番厄介かといって、やっぱりデバッグだろうと思うわけです。
IMEはデバッグをするのが非常に厄介なたぐいのソフトウェアです。うっかり変なことをすると完全に壊れて何もできなくなることすらあります。ChromeOSのIME APIでは、IMEは単なるChrome extensionなために完全にsandbox化された環境で動作しますし、developer toolsもあるのでデバッグは相当楽なほうですが、それでもなかなか面倒な面もあります。
面倒さの一つには、実機での動作確認が面倒だということが挙げられると思います。ChromeOSでは、まだセルフホスティングの開発環境が整っていません。普通にたとえばWindowsやMacでChrome extensionを開発するなら、適当にJSファイルを書いてunpacked extensionとしてロードして手元で動かして見ることができます。ですが、ChromeOSではローカルファイルを編集するためのテキストエディタがありませんし(と思ったら、そういう拡張機能もあるようですが)、なんだかんだでまだまだ大変な面が強いわけです。
そういうわけで、今回はMacで開発をしたのですが、じゃあどうすればいいのでしょうか。Macのほうで拡張機能のパッケージ化を行い、適当なサーバにアップロードして、ChromeOSのほうでダウンロードして……などとやれば出来ますが、毎度それをやるのはあまり実際的でもありません。
といった状況を踏まえ、まず開発をするための実行環境を作ってみました。それがソースコード中のtestpageというディレクトリです。
こいつのやることは簡単です。まずmock.jsというJSを読み込みます。こいつはchrome.input.imeというオブジェクトをグローバルに追加して、setCompositionとかclearCompositionとかのメソッドを登録します。この関数の実行結果は、適当にHTMLで画面に表示させます。一方でキー入力も適当なeditableな要素のほうで受け付けておき、onkeydown/onkeyupを使って適当なイベントリスナにキーイベントを横流しできるようにしておきます。
そうしておいて、のこりの拡張機能で使うJSファイルをロードすると、ある程度は動作するようになるという仕組みです。実際に、前回の記事で書いたAppEngineのホストにくっつけて公開もしています→こちら
前々回の記事で、AJAX-IMEのようにページ内に寄生するIMEっぽいJSの話に軽く触れました。今回はこれと似たアプローチで、ただし、変換エンジンの処理を直接書き下すのではなく、IME API互換のレイヤを間に挟んでいる、という解釈ができるかと思います。
この手法はなかなかうまく行きました。ちょっとコードを書いたら、すぐ実際にキー入力してみてどう表示されるのか確認できる環境がある、というのはいいものです。すぐ確認できることによる全体的な開発の高速化もありますし、実際に動いているのを目にすることができるというのは、とくに開発初期においてモチベーションを高めるという意味もあると思います。わりとすぐにそこそこのものが開発できたのも、この方式のおかげというのがあるかなあと個人的には考えています。
まあ、実際には、APIのドキュメントをちゃんと読まずに実装したので、いざ実機にロードしてみたらちゃんと動かなかった、みたいなよくある失敗もあるし、JSやイベント処理まわりの無理解のために動かなかった、みたいなしょぼい問題もたくさん踏んでいるので、あんまり自慢するようなポイントではないような気もします。また、現状ではonKeyEventの返り値を見ていないので、一部の機能は全然動いていないように見えます。それに、動かして確認するといった単純な手法よりは、細かいコーナーケースではユニットテストをちゃんと書くほうが大事だったりします……このコードではテストを書いてませんが、IMEはコーナーケースばっかりなので本当はテストが大事です。
なのですが、個人的には、テスト環境を実装してみたら割と簡単に実装できて、これが思いの外便利だった、というハックがちょっと面白かったので、紹介してみた次第です。
photo: http://www.flickr.com/photos/mjmyap/147909798/in/photostream/ by mjmyap
IMEはデバッグをするのが非常に厄介なたぐいのソフトウェアです。うっかり変なことをすると完全に壊れて何もできなくなることすらあります。ChromeOSのIME APIでは、IMEは単なるChrome extensionなために完全にsandbox化された環境で動作しますし、developer toolsもあるのでデバッグは相当楽なほうですが、それでもなかなか面倒な面もあります。
面倒さの一つには、実機での動作確認が面倒だということが挙げられると思います。ChromeOSでは、まだセルフホスティングの開発環境が整っていません。普通にたとえばWindowsやMacでChrome extensionを開発するなら、適当にJSファイルを書いてunpacked extensionとしてロードして手元で動かして見ることができます。ですが、ChromeOSではローカルファイルを編集するためのテキストエディタがありませんし(と思ったら、そういう拡張機能もあるようですが)、なんだかんだでまだまだ大変な面が強いわけです。
そういうわけで、今回はMacで開発をしたのですが、じゃあどうすればいいのでしょうか。Macのほうで拡張機能のパッケージ化を行い、適当なサーバにアップロードして、ChromeOSのほうでダウンロードして……などとやれば出来ますが、毎度それをやるのはあまり実際的でもありません。
といった状況を踏まえ、まず開発をするための実行環境を作ってみました。それがソースコード中のtestpageというディレクトリです。
こいつのやることは簡単です。まずmock.jsというJSを読み込みます。こいつはchrome.input.imeというオブジェクトをグローバルに追加して、setCompositionとかclearCompositionとかのメソッドを登録します。この関数の実行結果は、適当にHTMLで画面に表示させます。一方でキー入力も適当なeditableな要素のほうで受け付けておき、onkeydown/onkeyupを使って適当なイベントリスナにキーイベントを横流しできるようにしておきます。
そうしておいて、のこりの拡張機能で使うJSファイルをロードすると、ある程度は動作するようになるという仕組みです。実際に、前回の記事で書いたAppEngineのホストにくっつけて公開もしています→こちら
前々回の記事で、AJAX-IMEのようにページ内に寄生するIMEっぽいJSの話に軽く触れました。今回はこれと似たアプローチで、ただし、変換エンジンの処理を直接書き下すのではなく、IME API互換のレイヤを間に挟んでいる、という解釈ができるかと思います。
この手法はなかなかうまく行きました。ちょっとコードを書いたら、すぐ実際にキー入力してみてどう表示されるのか確認できる環境がある、というのはいいものです。すぐ確認できることによる全体的な開発の高速化もありますし、実際に動いているのを目にすることができるというのは、とくに開発初期においてモチベーションを高めるという意味もあると思います。わりとすぐにそこそこのものが開発できたのも、この方式のおかげというのがあるかなあと個人的には考えています。
まあ、実際には、APIのドキュメントをちゃんと読まずに実装したので、いざ実機にロードしてみたらちゃんと動かなかった、みたいなよくある失敗もあるし、JSやイベント処理まわりの無理解のために動かなかった、みたいなしょぼい問題もたくさん踏んでいるので、あんまり自慢するようなポイントではないような気もします。また、現状ではonKeyEventの返り値を見ていないので、一部の機能は全然動いていないように見えます。それに、動かして確認するといった単純な手法よりは、細かいコーナーケースではユニットテストをちゃんと書くほうが大事だったりします……このコードではテストを書いてませんが、IMEはコーナーケースばっかりなので本当はテストが大事です。
なのですが、個人的には、テスト環境を実装してみたら割と簡単に実装できて、これが思いの外便利だった、というハックがちょっと面白かったので、紹介してみた次第です。
photo: http://www.flickr.com/photos/mjmyap/147909798/in/photostream/ by mjmyap
