Ray's diary

ちょっと更新．

• TreeNote

編集中ファイルのショートカットをホーム画面に作る機能を追加．「ファイル」メニュー内．

• Howmm

編集画面の日時入力ダイアログを機能強化．ちょっとごちゃごちゃしてうっとおしいかなあ．

さらに編集画面はショートカットとしてホーム画面とかに置けるようにした．こっちは，ホーム長押しからのショートカット追加メニューで追加できる．クイック起動とかサブランチャーの類でも，ショートカットをリストから選択できるものならいけるはず．これで，従来のアプリ一覧にある「新規」とか「固定ファイル」とかは不要なはずなので削除した．前のバージョンで使ってた人がもしいたら，ショートカットにおきかえてください．

あと設定をメニューからリセットできるようにした．どうも，たまに設定が壊れることがあるらしくて，もしそうなると強制終了が発生するようになると思うので，そういう時に．

TreeNoteは意外に反応があるのでびっくりしている．まだハードキー派もそれなりにいるんだろうか．タッチ操作で使うならほかにもありそうだしなあ．もしかしてNexus7みたいのとBluetoothキーボードを組みあわせても使えるのか？

今回の改良点は三つ．

・テキストボックスでカット・コピー・ペーストをした場合はテキストに対して操作できる
なお，サブツリーに対する操作とは全く別扱いで，選択テキストをツリーノードとしてペーストしたりするようなことはできない．
・最後に使っていたファイルで再開するとき，開閉状態や選択位置も復帰する
・タスク切り替え中にメモリ不足で落とされても，編集中の内容が保存される
……はず．たぶん．テストしにくいなこの機能．

正月はヒマなので，Howmmを更新してみた．というかわりといつもヒマだな．

今回は，文字コードとか設定項目を増やして設定画面を整理したこと，メモを読むモードの画面をすっきりしたことが主な変更点だ．あとはバグ修正とかソースの整理とか．昔書いたプログラムを読みやすく整理しなおすのも，パズルっぽくてけっこう楽しいと思う．

ところで，絞りこみ検索とかソート順変更とかの機能をメニューに追い出して思ったのは，そもそもあまりこの機能って使ってないなということである．自分で作っといてなんだが．というかそれを言うならリンク機能はもっと使ってない．作るのにはけっこう苦労したんだけど．逆にリマインダー機能，ウィジェット，エディタ直接起動，固定ファイル起動なんかはよく使っている．

何が言いたいかというと，事前にユースケース的なアレを完璧に想定するのって難しいよねということだ．

TreeNoteのテキストボックスサイズを可変にする機能だが，なんとか動いているようなのでとりあえず公開してみた．正直Layoutの自作とかよくわからないので，ほかの人が作ったものを使ってるわけだが．要するに，Layoutを作るときはonMeasure()とonLayout()が重要なのかな．

さんざんあちこちで「画面サイズに合わせてコンポーネントを組みあわせられるフレキシブルなUIが作れますよ」的な宣伝をしているので，Fragmentについても調べてみたのだが，別にあまり役に立ちそうでもなかったので大層がっかりだ．あれは「全画面を占有するとは限らないActivity的なもの」にすぎないので，それをどうやって画面に配置したり生成消滅を管理したりするかは全然別の話で，Layoutとか組みあわせて勝手にやれってことらしい．そこの管理を簡単にする仕組みは作ってないのかよ．

それから，ファイルマネージャとかでテキストファイルを開こうとしたときに出てくる，「どのアプリで開きますか」リストにもTreeNoteが登場するようにしてみた．しかし世の中でファイルを開こうとするときどういうIntentを出すのが普通かよく知らないので，ちゃんとできてるのか不安が残る今日このごろ．とりあえずGhostCommanderからは開けたけど．

あとフォントサイズの選択肢を増やしてみた．でも，開く/閉じるのアイコン（丸に矢印のやつ）のサイズは可変じゃないので，あんまりフォントを小さくしたところで行間が広くなるだけだな．まあ，テキストボックスでは意味がなくもない．

というわけでSKK for androidをひさしぶりにバージョンアップした．前のエントリで書いた候補ウインドウをひかえめにする件のほかに，なんとなく思いついて辞書ファイルを内部ストレージに置くように変えてみた．IS01で使ってると時々あった，妙にひっかかる瞬間が減ったような気がする．このバージョンだと，いちおう，android用日本語IMEとしてはトップクラスで軽いほうだと言ってもいいんではなかろうか．ていうかIS01のSDスロットがヘボいのが問題なんだけど．

サイズ的にアレかなあと思わないでもなかったが，他のIMEでも辞書を内部に持ってるのがあるようだし，まあいいかと．というか全部で12MB程度だし，そんな非常識に巨大というほどのこともないよね？

それと，別アプリになってる必要がないことに気づいたので，ユーザー辞書ツールを統合した．1.6を入れた場合，前のバージョンのSKKDicToolは消しちゃって大丈夫．

ところで辞書はassetsに入れたのだが，その場合数メガ超のファイルは圧縮しないと駄目で，つまり最初に一回解凍する必要がある．そのためにわざわざ専用のactivityを用意するのが微妙にめんどくさい．あとBroadcastReceiverを用意してアップデート後に勝手に辞書展開を始めさせようかとも思ったが，なんかウザい気がするのでやめた．

TreeNoteのUIをちょっといじってみた．

・ファイル選択画面にインクリメンタルサーチを追加
・ツリー項目の一行表示モード
・ツリー表示の行間設定
・ファイルメニューの「最近使用したファイル」
・全画面編集でも「ツールバーを表示」が影響するようにした（コピペとかはメニューからも可）
・バグ修正いくつか

インクリメンタルサーチはghost commanderにあった機能のパクリだが，俺的にはすげえ便利になった．やっぱハードウェアキーボードっていいよね．

あと，ショートカット用の修飾キーに，「L-04Cのマナーキー」「LifeTouch NoteのCtrlキー」「005SHのFnキー」をこっそり設定できるようにしてみたのだが，なにしろ実物がないので本当に効くかは不明．

しかしアレだ，設計者が傲慢だったのか手抜きしたのか知らんが，やはりandroidフレームワークにもモーダルダイアログの仕組みは入れておいてほしかった．ネットのQ&Aサイトとかでも「モーダルダイアログでyes/no確認とかできないの？」的質問はかなり見る気がする．なんか関数オブジェクトとかクラス変数を使ったまわりくどいやりかたでしか実現できないよね．

またTreeNote修正．なんか最近これ関連のエントリばっかりだな．

まずファイルを開くときに下位項目を閉じておく設定を追加．これはちょっと気になってたし．直すのも簡単．

あと今のところ全画面編集モード限定でアンドゥ機能があるけど，実はショートカットもこっそり入れていた（Mod+z）．しかしこれがミスでちゃんと働いてなかったので修正．javaとかcとかのswitch文のフォールスルー形式って，どうもやっぱ好きになれないな．break忘れを何度やったことかわからん．

というわけで，TreeNoteのファイル保存時に，レベル記号と項目の間にスペースをあけないようにしてみた．読みこむときはスペースがあろうがなかろうが大丈夫なので，今までの版で文書作っちゃったよという人がもしいても，特に問題はないと思う．

万一，スペースがないと困るという意見があったらコメントしてください．

TreeNote更新．

やっと置換機能をつけてみた．けっこう悩んだのだが，「カーソル位置」という概念がないしListViewの中の文字を直接選択もできないので，普通のエディタみたいな検索置換ダイアログがうまく考え出せなかった．最終的にわりとザツな機能になってしまったがまあ使えなくもなかろう．

あと今までは深さ5段を限界にしてたのだが，ためしに10段にしてみた．メモリをやたら喰うとかすげえ遅くなるとかがないようなら，このままいってみようと思う．ツリー構造を編集するときに，途中経過として6段7段になることって意外とあるんだよな．使ってみて思ったけど．まあ，getViewTypeCount()が10とか返しても，覚えておくViewのキャッシュ自体が増えるわけじゃないし，なんとかなってくれんだろうか．

あとほしい機能っていうとアンドゥだが，これはなかなか面倒そうだ．どうやって実現するかなあ．

TreeNoteをちょっと修正．

前の版だとちょっとショートカットキーの扱いの扱いに問題があるようだ．具体的には，修飾キーに設定したものがショートカット以外の用途に全く使えなくなってしまう．たとえば，IS01だとAlt+Pで@が入力できる．ここで，修飾キーをAltにしておいて，Pに何かのショートカットを設定した場合は，@が入力できなくなるのは当然である．しかし，Altを修飾キーにした時点で，Pを空けておいても問答無用で@が入力できなくなってしまうのだ．

これは不便に思ったので，内部的なショートカットの扱いを変えてみた．これで，上記のような問題は解決するはず．ただ，この方式で，修飾キーに何でも設定できるようにするのは難しそうだったので，選択肢から選ぶ方式にした．もし，XXX端末のYYYキーも修飾キーにできないか，とかいうのがあったら，個別に教えてもらえれば対応できるかも．あと，バージョンアップすると修飾キーの設定がリセットされ，もう一度設定が必要なので注意．

あとついでに，ファイル選択画面でEnterを押したら，OKボタンとかにフォーカスが移動するようにもした．地味に便利．

TreeNoteをまた更新．今回は，

・ショートカットキーの改善（menuキー＋？でも大丈夫，IMEより先に発動させてみた，設定できる機能を増やした，など）
・ファイル選択画面のタッチ操作の改善
・本文を全画面で表示できる機能

の三本でーす．しかし，このアプリは多少はアウトラインプロセッサーとして使いものになると言えるんだろうか．こんなの使うような知り合いはいないからよくわからない．

キー選択Preferenceはずいぶん仕様が迷走してるが，なんとか安定してきたかな．「『設定なし』にできなかった」という事実に最近やっと気付いたというていたらくだが．

そういえば，あまりいないと思うけど，俺のアプリとかそういうのの更新情報を見に来たという人は，上のほうにある「リリース情報」というリンクを押すと，これ関連のエントリだけ出せるのでいいと思うよ．このブログはそれ以外にも旅行記とかどうでもいい愚痴とか関係ないことも書いてあるので．たしか「特定カテゴリだけの更新情報をrssで取得」というのまでは残念ながらできなかったと思うけど．

2chの人達にもらった意見を参考に，TreeNoteを直してみた． 以前から，アプリの利用中に縦横変更するのって意味ねえだろと思ってたけど，アウトラインプロセッサーだと確かにちょっと意味があるような気がしなくもない．つまり，編集に便利な方向と閲覧に便利な方向が異なる場合があるんだろう．

しかたがないので，androidではどうやって回転に対応するのか真面目に調べた．なんかonSavedなんとかいうやつで一時的にBundleに状態を保存する機能を使えばいいのかと思っていたのだが，どうも回転に対応する場合はActivity#onRetainNonConfigurationInstance()というのを使ったらいいらしい．これはどうやら「何かconfigurationが変わり，activityが破棄されてすぐ作りなおす」という状況専用で，でもどんなobjectでも扱えるのでParcelableとか考えなくても超簡単に使える．わかってしまえばたいして面倒でもなかった．

あとだんだんPreferencesが増えてきて地味にめんどい．正直，androidのPreferenceは数が増えると管理が大変である．設定値をsummaryに表示させるとかも個別にやんないといけないし，なによりpreference keyの管理を簡単確実にする方法がなさそうだ．なんかそれ用のクラス作ってほしいなあ．xmlの記述に対応するとかはこっちではどうしようもないし．xmlでの記述を気にしないで全部コードで作るんなら，もうEnumとか使ってもいいんだけど．

android機のキーボード廃止傾向に伴ってタッチ操作専用のアプリばかりになっているので，IS01を快適に使おうとするなら自分で作るしかないのだ．LifeTouch Note民やDynabook AZ民ももっとオレオレアプリ作ろうぜ．

というわけで今回はアウトラインプロセッサーを作ってみた．こういうのは英語圏でもメジャーだから既存のものもそれなりにあるんだけど，実際こんなのタッチ操作なんかでやってらんねえだろと思うのは俺が古い人間だからなんだろうか．

今回のプログラムでちょっとおもしろかったのは，キー設定用のDialogPreferenceをまじめに作りなおしてみたことである．SKKのときに作ったのだが，よくわからないままあちこちからコピーして作ってたのでいろいろ要らないところがあったり，EnterやBackをちゃんと扱ってなかったり，キーコードからちゃんとキーの名前を表示してくれなかったり，けっこうしょぼかったので．

あと画像じゃなくてxmlでDrawableを作る方法も調べてみた．グラデーション背景や枠線ごときでいちいち各解像度の9-patch画像を用意する手間がはぶけて，なかなかいい．できれば下位ノード開け閉めボタンとかもこれでやりたかったが，どうも複雑なのは思ったようにいかず，今回は普通に画像である．

android用howmもどきを更新した．今回のメインはホーム画面用ウィジェットの追加である．これでまあ一応予定管理アプリとしても使えないこともない感じになった．

ウィジェットの作り方は今回初めて調べたので，やっぱり理解するまで苦労した．要するにAppWidgetProviderクラスというのは特定のブロードキャストに対応したルーチンを並べておくだけのもので，Activityみたいな実体のある感じではないのか．実際の表示はホームアプリのほうでやってるわけだし，RemoteViewsとかいうのも表示内容をまとめた依頼書みたいなもんなんだな．

あとたいていの説明では「複雑な処理がいるときはServiceを使いましょう」とか書いてあるが，なんか大仰な気がする．そんなにずっと何かしてるわけでもない（けどonUpdate()に全部書いちゃうほど簡単でもない）場合，AsyncTaskでやったほうが単純なように思う．実際ちゃんと動いてるようだけど，なにか問題があるんだろうか．

ところで，元々のhowmの「指定日にアクティブ化する」という考え方がどうも理解しにくいと思うのは俺だけなんだろうか．たとえば締切りとか，別に七日前とか言わず最初からふつうに表示しといたらいいような気がするんだけど．まだ遠い先ならどうせリストの下のほうに表示されるんだし．

あ，あと浮沈todoはそのうちhowmmにも入れようかなあ．

授業の新ネタを考えなきゃいけないのだがどうにもやる気が起きないので，howmもどきのバージョンアップをした．

変更したかどうかのチェックのためだけにTextWatcherを使ってるのがもったいない気がしたので，編集画面にundoをつけてみた．要するに変更を全部覚えておくだけの安易なもので，IMEの入力中の状態とかも全部そのままだ．というかIMEごとに表示が違うから直す方法は思いつかない．TextWatcherにComposingTextを無視させる方法とか無いよな．

あと，なんとなくlintでチェックしてみたらレイアウトに関する警告が山のように出てびびる．いいかげん，よくわからないままレイアウトファイルを書くのも問題だと思ったので調べてみたところ，ようやっとweightというのが何なのか理解できた（こことか）．「余白が負の値」とかアホかと思うが，まあ理解してみれば意外と単純な話だ．それより，howmもどきみたいに「heightとwidthにそれぞれ別々にweightが必要」という状況の場合に，NestedWeightsの警告がどうも避けようがない気がするのが不満である．最近のandroid的には，複雑な画面構成だったらFragmentを使えということなんだろうか．めんどくせえなあ．

それから，正規表現を使わない場合はPatternやMatcherを使わずString.indexOfで検索するようにしてみたのだが，実際のところ速くなっているのだろうか．俺の環境でプロファイルを取ってみるとあんまり違わないので，無駄だったかも．まあ，それに合わせて内部的に整理しなおして，俺的にはわかりやすくなったのでいいことにした．

というかJavaの正規表現って意外に速いのな．

android用howmもどきは，自分で作っといてなんだがいくつか難点がある．検索ヒットした語にジャンプしない件とか，さすがに気になってきたので直してみた．

そもそもScrollViewが行単位の操作にも最初から対応してくれてたらいいのに．一画面におさまらないテキストを表示したい場面とかふつうにあると思うんだけどなあ．とりあえず，好きな位置まで自動でスクロールするには，（1）String中の特定の位置がそのTextView中では何行目にあたるか調べる→（2）ScrollViewを所定の行までスクロール，という方法をとればいいようだ．（1）に必要なLayoutなるクラスの存在を初めて知った．

ところでこの解はstackoverflow.comでみつけたのだが，プログラミング関係で調べてるとここがひっかかることの多いこと多いこと．確かに役には立っている．まったく最近は，英語の国で育った奴らっていうのは，それだけでずいぶん楽してるんだろうなあ．

FetchWebを使うと，ときどき画像をちゃんと読まないことがあるし，稀に無限ループになることもあるのだが，放置されて久しい（主語を省略し責任を回避する表現）．

授業がもうすぐ始まるから大変不愉快なので，現実逃避としてこいつを調べてみた．どうも使っている画像ファイルを抽出する正規表現が不十分なのが原因っぽい．一気に読みこんだりしてる手抜きな構造のせいでデータが化けるのかとも思ってたが，別にそういうことではないようだった．

スペースがいくつ入るかは基本的に自由，とかはまあしょうがないような気もするが，画像のURIを書くのに引用符があってもなくてもいい，とか勘弁してほしい．シングルクオートでもダブルでもいいとか．あとbackground属性って非推奨らしいが，でもいまだにテーブルレイアウト＋background属性ってけっこう見るし対応すべきかな．

先日作成したかんたんランチャーだが，2chで教えてもらったところによると，どうもBufferedReaderのバッファのサイズが大きいと，化けたりとかのトラブルが起こる可能性があるらしい．大きいって言っても2kぐらいだし，そんなアホなと思ったが，実際小さくしてみたらトラブルが起きなくなったようである．うちの環境では実機・エミュレーター共に一切再現しないのでよくわからんのだが，そういうこともあるのかなあ．さすが環境がまちまちと評判のandroidだけあるな．

あと最近webページを更新してて思うのだが，今後のことを考えるとEUCで書いてるページはUTF-8に移行していったほうがいいんだろうか．

どうもどうも，全日本反タッチパネル団の海月です．

androidのアプリランチャーの類は，だいたいアイコンを並べてその中からスワイプやタッチ操作で選択するようになっている．それは別にいいが，キーボードで操作できるようになっていない場合がけっこうあるのが腹の立つ点だ．あと見た目をかっこよくするためか，起動が妙に遅かったりメモリを食ったり動作が重かったりするのも大変こまる．我らがIS01は基本性能がへぼいのである．

というわけで，アプリ名を文字だけで一覧表示して，そこから選択して起動するだけの簡単ランチャーを作った．さらに，名前の一部を入力すると絞りこみできるようにもしてみた．しょうもないアプリだが，IS01ではけっこう便利だ．

IS01を購入したとき，「まあandroidだから，この機種が市場的に見捨てられても，自分で便利ツールとか作って使えばいいかな」などと思ったような記憶があるが，まさにそんな感じになってきた今日このごろ．

最近はあまりemacsを使わなくなっているのだが，howmは気にいってるのでメモのためだけにemacsを起動したりしていた．というわけで，このところandroid用に似たようなアプリを作っていて，ずいぶん時間がかかったがなんとかそれらしいのが完成したよ．やったね．まあ実をいうと最近のPCは速いので，emacsをたびたび起動したり終了したりしててもたいして気にならないのだが．

今回もClickableSpanとかArrayAdapterとか知らないトピックがいろいろ出てきて大変だったな．あと今回は，意外とパフォーマンス的なことも厄介だった．適当につくったらGCが発生しまくって，メモの一覧を見るのにいちいち数秒待つような代物になったし．おかげでプロファイラの使いかたまで調べるはめになった．

ていうかいい加減まともなJavaの本でも読んだほうがいいかもしれん．世の中にはちゃんと事前に設計して効率よくプログラム書く方法とかあるって聞いたよ？

まあ見てみたい人はいつもどおりこっちにどうぞ．いつもどおりソースも置いてあります．

CM4IS01にしてから，自作のアプリが妙に小さく表示されるようになった．Spare Partsとかで直せるおなじみの症状だ．どうも気になるので調べたところ，これはサポート解像度の問題らしい．俺が作ったものは全部1.5以上用にしてあるのだが，なんでも複数の解像度がサポートされたのが1.6以降で，1.5以前対応のものはデフォルトだと中ぐらいの解像度しかサポートしてない扱いになるらしい．

そこでAndroidManifest.xmlにsupports-screensを書いて，android:largeScreens="true"とかそういうのを明示的に入れてやれば，高解像度のときはそれなりに広く表示してくれるようになる．もちろん本当に対応してなければうまくいかないが，俺の作ったアプリは単純な画面ばっかりだから別に問題はない．これでCM4IS01でもちゃんと表示されるようになった．

さて，ここで気付いたのだが，もしかすると「SKKをLifeTouch Noteで使ったり，lcd_densityを小さくして使ったりすると候補表示が変な位置に出る」という問題も，実はこのせいなのではないだろうか．ということで試してみたら，確かにlcd_densityが小さくてもちゃんと出るようになった．LifeTouch Noteを使ってる人に試してもらったところ，そっちでもちゃんと出たらしい．なんと，こんなツマランことに半年以上気付かなかったとは．一人でやってるとこういうことってあるよな．

ところで1.6のIS01でlcd_densityを小さくしてた場合，一旦SKKをkillしてやると表示が直ってたのはなんでだろうね．

Android用SKKのシフトキーの扱いが変だ，ということをあるブログで指摘されて初めて気付いた．確かに，シフト押しっぱなしで入力しようとすると最初の一文字しかシフト扱いにならない．IS01ではそんなことしないので全然思いもしなかったな．とりあえずこの件の修正と，ついでにzhなどで記号を入力する機能を入れて更新．中黒とかが入力しにくいのは自分でも気にはなってたし．

しかしCandidatesViewの表示位置がおかしくなる問題はどうしようもないな．いろいろ調べてみたがさっぱり解決法がわからない．本家の解説を読んでも「ソフトキーボードが画面最下部に，その上にCandidatesViewが出る」としか書いてないし，どうもAndroidのInputMethodフレームワーク自体が画面サイズを取りそこねてるような気がする．シフトキーの扱いもそうだが，結局はこのフレームワーク自体が発展途上だからどうしようもないのだろうか．公開されてるOpenWnnのソースを見てみたら，CandidatesViewをわざわざ自前で描画している始末．シフト状態の管理も当然自前だし．

Android用の画面メモなるソフトがあって，ブラウザで表示中のページをhtmlとして保存したり画像として保存したりできる．なるべくネット接続を少なくするという方針で使う貧乏人としては，なかなか便利なものだ．ただ，IS01が悪いのか何が悪いのか知らんが，どうもちゃんと保存できないページがあるようだ．

しかたがないので，httpでページをダウンロードして保存する簡単なソフトを作ってみた．プログラミング的には「インテントでブラウザのページ共有から起動する」「設定画面に設定以外のボタンも付ける」「AsyncTaskで非同期処理」「多言語対応」あたりが新しく試してみた内容かな．

AsyncTaskは微妙に使いにくいような気がする．処理中に呼び出し元のActivityに何か通知したい場合，Handlerの中でActivityのメソッドを呼び出すぐらいしか方法がないらしい．なんかメモリーリークが起きそうで不安な感じだが，Activityが破棄されたらAsyncTaskも破棄されるだろうから大丈夫なのかな．縦横切りかえたら最初からダウンロードしなおすようだし．

例によってソースと一緒にここに置いたので，興味のある人はどうぞ．

SKKをちょびっと修正．必要なとき以外は候補ウインドウを消すようにしたら，単語登録の表示が変になっていた．setCandidatesViewShown(false)とやると，どうもウインドウを消すと同時にComposingTextを吐き出すようになっているらしい．しょうがないのでモード変更の際に一旦ComposingTextをクリアし，単語登録中だけモード変更が終わったあとに改めて復活させることにした．

ていうかComposingTextを流用してないでポップアップウインドウとか出したほうがAndroid的にはいいんだろうけど．めんどくさいしなあ．

そうそう，今回のバグはunaju氏の連絡で気付いた．氏に感謝します．