会社でいくつかスマフォアプリ作ってるけど、8月にリリースしたiPhoneアプリは個人的に出来が良い（自称）ので宣伝も含め紹介

アプリ名：ふりっく（無料） 公式ページ

ちなみに、新機能を追加した有料版も近日リリース予定です。

■開発のきっかけ 会社でランチ中に「フリック入力遅いんだよねえ」って話になって、じゃぁ練習アプリ作ろうかと、会社に戻って

プロトタイプが3時間でできました

が、、デザイン・辞書や他ごとでちょっと時間かかってしまいましたが。

辞書

一番時間を費やしたのが「辞書」 APIとか無料で使えそうな辞書ファイルとか、会社泊まってまでさんざん探しました。。。

で翌日、閃いてあるファイルを解析してPHPパースしてJSON辞書を作りました。

プログラム

キーボードの選択

iOS5からキーボードの候補表示位置が変わって話題となりましたが、実はキーボード入力の仕様も若干変わってるんですよね。 単直に言うと、

濁点の解析が面倒

キーボーはアプリの性格も含めていくつかあると思いますが大きく分けて、

(1) iOS純正のキーボード(UITextField)を使う (3) オリジナルキーボードを作る

今回のアプリでは純正を採用しましたが、MikuFlickみたいなアプリはオリジナルキーボードを作る必要がありますね。 デザインやアニメーション、入力ロジック等自由が広いですが、やっぱり面倒です。 （逆にカスタムクラス＆コンポーネントを作れば良いと言う話ですが）

iOSの濁点・半濁点・小文字判断は厄介

純正のフリック入力では、例えば「ば」なら「は + 濁点」の NSString にわけて処理されます。 つまり

(1) UITextField に「ば」が確定されるのを待つ (2) 「は」と「濁点」を別々に判別する

の２通りですが、本当に作り込むなら(2)を選択するでしょう。 ただ、辞書ファイルデータと比較する際に「ば」と「は + 濁点」を比較するロジック必要になります。

その点(1)なら単に確定文字を比較するだけなのです。 しかしその反面、入力確定するまで入力候補が表示されてしまいます。

できるだけ入力候補を出さない

「ふりっく」では、濁点／半濁点を除いてできるだけ入力候補を出さないように、１文字ずつチェックしています。 その際、Editing Changed イベントを使うのではなく、

- (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string;

を利用します。

shouldChangeCharactersInRange は、Editing Changed イベントより先に呼ばれる為、「NO」を返すことで、Editing Changed イベントが呼ばずに完結し、入力候補を常に非表示できます。

ただ、濁点・半濁点・小文字のように複数キータップが必要な場合は「YES」を返して入力確定を待つことになり、入力候補対策の点で不十分です。

常に入力候補を表示しないようにするには、

辞書ロジックレベルで濁点・半濁点・小文字など複数タップに対応する

必要があります。 恐らくは。。。

しかし、他のアプリよりは出来がいいと思うんだけど、ランキングがいまいち伸びないなぁ(^^;)