Posts Tagged ‘Objecive-C’
NSFetchedResultsControllerとUISearchDisplayControllerを使ったUITableView検索機能の実装
NSFetchedResultsControllerとUISearchDisplayControllerを使ったUITableViewの検索機能を実現するというトピックはネット上でも幾つか見つかるのだが、複数のクラスが組み合わさって動作するためになかなか思うような動きをするコードを書くことができなかった。
UITableView(ここではMaster-Detail Appとする)にUISearchDisplayControllerを組み合わせ、UISearchBarに検索文字列を入力するとすぐに絞り込まれる(ようにコードを書く)のだが、その時表示される絞り込まれた表はUITableViewではなくUISearchResultTableViewのインスタンスである。だから、現在見えている表がどのクラスのインスタンスなのかを意識しなければ思うようなコードを書けないということを痛感した。
表のデータソースにCore Dataを使用している場合、NSFetchedResultsControllerとUISearchDisplayControllerの両クラスの連携が鍵になる。
よく見かけるサンプルコードは次のようなものである。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | - (void)controllerWillChangeContent:(NSFetchedResultsController *)controller { [self.tableView beginUpdates]; } - (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath { UITableView *tableView = self.tableView; // (省略) } - (void)controllerDidChangeContent:(NSFetchedResultsController *)controller { [self.tableView endUpdates]; } |
だが、検索して絞り込んだ表から選択して更に編集画面でDBを更新した場合、このcontrollerDidChangeContentメソッドでアベンドしてしまう。
1 2 | Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid update: invalid number of rows in section 0. (以下省略) |
こんなメッセージだ。言いたいことは分かるがどう対応して良いか分からない。
1 | [self.tableView endUpdates]; |
の代わりに
1 | [self.tableView reloadData]; |
とやれば、更新時にアベンドはしなくなるが、検索をキャンセルした場合に表示されるオリジナルの表のレンダリングがおかしくなってしまう。(あと、削除できなくなったり詳細画面に遷移できなくなったり。)散々悩んだ挙句、冒頭の書いたことに思い当たった。そう、分かってしまえば何てことはない。NSFetchedResultsControllerの操作も、どのTableViewに対して行うかを判断すれば良かったのだ。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | - (void)controllerWillChangeContent:(NSFetchedResultsController *)controller { if (self.searchDisplayController.isActive) { [self.searchDisplayController.searchResultsTableView beginUpdates]; } else { [self.tableView beginUpdates]; } } - (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath { UITableView *tableView = self.searchDisplayController.isActive ? self.searchDisplayController.searchResultsTableView : self.tableView; // (省略) } - (void)controllerDidChangeContent:(NSFetchedResultsController *)controller { if (self.searchDisplayController.isActive) { [self.searchDisplayController.searchResultsTableView endUpdates]; } else { [self.tableView endUpdates]; } } |
UITableViewCellの再利用について
iOS 5.x までは
– (UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath
メソッド内で
1 2 3 4 | UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:TABLE_CELL_NAME]; if (cell == nil) { cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:TABLE_CELL_NAME]; } |
のようなコードを書く必要があったが、iOS 6.0 からは – (void)viewDidLoad メソッドに
1 | [self.tableView registerClass:[UITableViewCell class] forCellReuseIdentifier:TABLE_CELL_NAME]; |
というセットアップをすれば
1 | UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:TABLE_CELL_NAME forIndexPath:indexPath]; |
と書くだけで良いというのがネットで得られる情報なのだが、UISearchDisplayController を使って検索機能を実装しようとすると検索文字列を入力した途端に落ちてしまう。検索結果は UITableView が使われるのではなく、UISearchResultTableView のインスタンスが(しかも都度)生成されるので、適切な場所でセットアップをしてあげる必要がある。ここではupdateFilteredContentForNameメソッドで検索をした直後に記述したら(5行目)うまくいった。
1 2 3 4 5 6 7 | - (BOOL)searchDisplayController:(UISearchDisplayController *)controller shouldReloadTableForSearchString:(NSString *)searchString { [self updateFilteredContentForName:searchString]; [self.searchDisplayController.searchResultsTableView registerClass:[UITableViewCell class] forCellReuseIdentifier:TABLE_CELL_NAME]; return YES; } |
NSDateComponentsからNSDateを取得するとnilが返ってくる
日付値に対して加減演算を行い、その結果を日付値として取得したくてNSDateComponentsクラスを使用した。以下のようなコードを書いたら、 result
は常に nil
が入って来る。
1 2 3 4 5 | NSDate* dt = [NSDate date]; NSCalendar* cal = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar]; NSDateComponents* dc = [cal components:NSYearCalendarUnit fromDate:dt]; // dcに対する操作 NSDate* result = [dc date]; |
そこでNSCalendarオブジェクトを使って以下のように変更したら期待通りの値が取得できた。
1 2 3 4 5 | NSDate* dt = [NSDate date]; NSCalendar* cal = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar]; NSDateComponents* dc = [cal components:NSYearCalendarUnit fromDate:dt]; // dcに対する操作 NSDate* result = [cal dateFromComponents:dc]; |
Master-Detail Appで新規追加画面から戻るとUITableViewに空のセルが追加されてしまう
Xcodeでプロジェクトを作成する時に選べるテンプレートの中に「Master-Detail Application」というのがある。これはいわゆる一覧画面と詳細画面を行き来する割と代表的なアプリケーションの形であり、頻繁に利用されるパターンでもある。一覧と詳細と言えば、その多くがデータベースのようなものと組み合わせて使うのが一般的だ。ローカルのデータベースの場合、特にこだわりがなければCoreDataを使う事になると思うが、その際にちょっとハマったケースがあるのでメモしておく。
それは詳細画面というより編集画面を新規追加の局面で開いた場合だ。ところで「Master-Detail Application」ではUITableViewControllerの他にUINavigationControllerが使われているので、編集画面にて保存の操作を行うにはUINavigationBarに保存ボタンを追加し、NSManagedObjectContextオブジェクトのsaveメソッドを呼ぶ事で保存を行うことができる。ただ、編集画面を新規追加で開いた瞬間にNSManagedObjectクラスのインスタンスが生成されるようで、保存せずに戻るボタンが押された場合には一覧画面に空のセルが追加されてしまう。これを防ぐには戻るタイミングで未保存の変更がある場合には、以下のようにロールバックするコードを書けば良い。
1 2 3 4 5 | - (void)viewWillDisappear:(BOOL)animated { if ([self.managedObjectContext hasChanges]) { [self.managedObjectContext rollback]; } } |
これで空のセルが追加されるのを防ぐ事ができる。
—
UITextFieldがキーボードに隠れないようにオフセットする
iPhoneでアプリの画面にたくさんTextFieldを配置した時、画面下の方のTextFieldを選択するとキーボードが下からニョキッと出てきてTextFieldを隠してしまう。もちろんそのままでも入力は可能だが、キーボードを仕舞うまでどう入力されているか分からないので不便である。
そこで、TextFieldを選択したときに隠れてしまう場合は表示をずらして隠れないようにしたい。ネットでサンプルを探したのだが、これというものが見当たらなかったので作ってみた。
InterfaceBuilderでまず全体にUIScrollViewを敷き詰めて、そこにUITextFieldを並べていく。
まず、(隠れてしまう)全てのTextFieldについて「Editing Did Begin」と「Editing Did End」の2つのイベントハンドラを定義しておく。この際、どのTextFieldに対しても同じメソッドを適用する。例えばそれぞれ – (void)textEditingDidBegin および - (void)textEditingDidEnd とする。
この時、InterfaceBuilderを使って普通にイベントハンドラを定義しようとすると両方とも「Editing Did End」イベントに結合してしまうので、ConnectionsInspectorで「Editing Did Begin」イベントから – (void)textEditingDidBegin メソッドに結合した方が良い。
また次のフィールドを宣言しておく。
1 2 3 4 5 6 7 | @interface ViewController () { float _keyboardOffset; // 表示のオフセット(どれだけずらすか) float _offsetMargin; // 実際にオフセットを適用し始めるマージン } : : @end |
そしてそれぞれ次のように初期化する。
1 2 3 4 5 6 7 8 | - (void)viewDidLoad { [super viewDidLoad]; : : _keyboardOffset = 0.0f; _offsetMargin = 120.0f; // 4インチディスプレイの場合は 210.0f 程度 } |
_offsetMargin というのは、例えば画面の上の方にあるTextFieldを選択したときは表示をずらす必要がないので、じゃあY座標がどこまでの範囲内ならオフセットしないかというのを決めておく必要がある。3.5インチの場合はだいたい120ピクセルぐらいまではずらさなくても大丈夫。4インチの場合は3.5インチの場合と90ピクセルくらい差があるのでマージンもそれだけ増やして大丈夫だ。
次に最初に定義したイベントハンドラを実装する。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | - (IBAction)textEditingDidBegin:(UITextField *)sender { // オフセットすべきサイズを計算する CGRect textFieldRect = [sender frame]; _keyboardOffset = MAX(0, textFieldRect.origin.y - _offsetMargin); // アクティブなTextFieldが表示されるようにオフセットする CGRect viewFrame = [self.scrollView frame]; viewFrame.origin.y -= _keyboardOffset; self.scrollView.frame = viewFrame; } - (IBAction)textEditingDidEnd:(UITextField *)sender { // ScrollViewのオフセットを元の値に戻す CGRect viewFrame = [self.scrollView frame]; viewFrame.origin.y += _keyboardOffset; self.scrollView.frame = viewFrame; _keyboardOffset = 0.0f; } |
尚、UITextFieldDelegateとかオフセット時のアニメーションとかは本題から外れるので適宜実装してください。
—
UITableViewの一覧にCora Dataで取得した内容を反映する
Core Dataのサンプルとか、UITableViewのサンプルとかはネット上でも書籍でもかなり豊富にあるのだが、それらの組み合わせの例は意外と少ない。先日見つけた書籍はかなり詳しく書いてあって「これはいけるか!?」と思われたが、実は肝心なコードが抜けていた。それはMaster-Detail型で言うところのMaster画面でCore Dataから取得したデータの一覧をUITableViewに表示する際、一覧の見出しにデータの内容が反映されないのだ。おそらくその書籍の著者にとってはあまりに自明の事なので記載するのを忘れてしまったのだろう。あるいはそれくらいは自分で考えろという事なのかもしれない。
まあここで毒づいても仕方が無いので対処方法をメモしておく。
一覧に内容を反映させるには MasterViewController.m の
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
メソッドにコードを記述する。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { UITableViewCell *cell; // iOSのバージョンによりセルの取得方法が変わる if (6.0 <= [[[UIDevice currentDevice] systemVersion] floatValue]) { cell = [tableView dequeueReusableCellWithIdentifier:@"AnyId" forIndexPath:indexPath]; [self configureCell:cell atIndexPath:indexPath]; } else { cell = [tableView dequeueReusableCellWithIdentifier:@"AnyId"]; if (!cell) { cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"AnyId"]; } } // ここでセルの表示を変更 NSManagedObject* managedObject = [self.fetchedResultsController objectAtIndexPath:indexPath]; cell.textLabel.text = managedObject.anyProperty; return cell; } |
—
尚、iOSのOSバージョンを判別する方法は以下のサイトを参考にした。
http://syszr.com/s14.html
UIButtonに任意の画像を使ってタップ時にハイライトさせる
今更ではあるがメモしておく。
画面上にボタンを用意するにはUIButtonを使うが、標準の外観では物足りない場合はボタンに見える画像を用意することが多い。ところがHTMLのつもりでImageプロパティに画像を指定してTitleプロパティにラベルを指定…とやってしまうと画像だけ表示されてラベルが表示されない。
その場合はラベルも含んだボタン画像を用意するというのも一つの方法だが、ボタンの種類が多い場合は用意すべき画像が多くなってしまう。背景画像(BackgroundImageプロパティ)に画像を設定する。
ただ、単純に背景画像を設定してもいいが、より細かく表現するにはボタンの状態別に画像を用意する。非活性状態、有効状態、選択状態、押下状態の4種類あればよいだろう。それぞれ次のようなコードになる。
1 2 3 4 | [button setBackgroundImage:[UIImage ...] forState:UIControlStateDisabled]; [button setBackgroundImage:[UIImage ...] forState:UIControlStateNormal]; [button setBackgroundImage:[UIImage ...] forState:UIControlStateSelected]; [button setBackgroundImage:[UIImage ...] forState:UIControlStateHighlighted]; |
これを利用してトグルボタンのような機能を持たせることもできる。タッチイベントを捕捉してOFF状態であればONにし、ON状態であればOFFにするという具合だ。しかし、これがうまく動作してくれない。いや、トグルは動作するのだが、OFF状態のボタン押下中のハイライト画像が表示されないのだ。
まず、adjustsImageWhenHighlightedプロパティはfalseにしておこう。これがtrueだとOFF状態のボタンを押下した時にハイライト画像ではなく、ボタン全体が暗転してしまう。だがそれでもまだ不充分。
どうやらUIControlState~はビット和を指定することが可能らしい。つまりON状態とOFF状態だけでなく、OFF状態のボタンを押下中やON状態のボタンを押下中という表現ができる。それを改良したのが次のコード。
1 2 3 4 5 | [button setBackgroundImage:[UIImage ...] forState:UIControlStateDisabled]; [button setBackgroundImage:[UIImage ...] forState:UIControlStateNormal]; [button setBackgroundImage:[UIImage ...] forState:UIControlStateSelected]; [button setBackgroundImage:[UIImage ...] forState:(UIControlStateHighlighted|UIControlStateNormal)]; [button setBackgroundImage:[UIImage ...] forState:(UIControlStateHighlighted|UIControlStateSelected)]; |
これでボタンの状態に関係なく、ボタン押下中はハイライト画像を表示させることができた。
“Unknown class ‘class name’ in Interface Builder file” に対処する
久しぶりにiOSアプリの開発環境をいじったら久しぶりにハマったのでメモしておく。
現象としてはXcodeからプロジェクトをビルドしてシミュレータで起動しようとすると、起動できずにアプリは終了し、以下のエラーメッセージを吐くというもの。実際には「class name」には作成したクラス名が入る。
Unknown class ‘class name’ in Interface Builder file
対処方法は次の通り。
- XcodeのProject Navigatorでプロジェクトのルートを選択して設定画面を開く。
- Standard editorの左ペインで TARGETS 以下の項目を選択する。
- Standard editorの右ペインの Build Phases タブを選択する。
- Compile Sources のグループを開き、不足しているクラスのソース本体(.m)を追加する。
- ビルド及び実行する。
これはInterface Builderから特定のクラスが見えないという状況なのだが、例えば新規にプロジェクトを作成した時に、他のプロジェクトで作成したクラスをファイルのコピーによって追加したような場合に発生する。(クラスを新規作成で追加した場合は自動でBuild Phaseに追加されるようだ。)
絵文字を含むNSStringの正確な文字数をカウントする(2)
ちょっと前に絵文字の混在した文字列のカウント方法について書いたら、ちゃんとカウントできない文字があると指摘された。
なるほど、確かにカウントできない文字がある。いったいどんな規則性があるのかと思っていたら、絵文字の文字コードをまとめていたサイトを教えてもらった。
それがこれ↓
iOS Emoji
う~ん、まるで規則性が見当たらないと思っていたらピンときた。前は UTF8String
とかやってたけど、内部の文字コードはもしかしてUTF-16ではなかろうか?と思って調べたらやっぱりUTF-16だった。それならわざわざUTF-8に変換しないでUTF-16のまま処理した方が良い。
UTF-16といえば主要なトピックはサロゲートペアだ。0xD800-0xDBFFが上位サロゲート、0xDC00-0xDFFFが下位サロゲート。( Wikipedia#Unicode 参考)なので上位サロゲートを検出したら1文字スキップする。(1)
さらに、国旗の絵文字には Regional Indicator という専用のシンボルが2つの組み合わせで使われている。( Unicode.orgのこのページ の最下段に記載されている。)なのでRegional Indicatorを検出して次のサロゲートペアもRegional Indicatorだったら3文字スキップする。(2)
あと、ガラケーではお馴染みの四角で囲まれた数字には通常の数字の後に COMBINING ENCLOSING KEYCAP という専用の文字が配置されている。だがこれは単純に無視すればいいだろう。(3)
そうすると、こんな感じで書けばいいかな?ちゃんと実装するには文字のインデックスが out of bounds にならんようにした方がいいかも。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | - (NSUInteger) actualNSStringSize:(NSString *) txt { int len = [txt length]; NSUInteger count = 0; for (NSUInteger i = 0; i < len; i++) { unichar c = [txt characterAtIndex:i]; if (0xD83C == c) { unichar c1 = [txt characterAtIndex:i+1]; if ((0xDDE6 <= c1) && (c1 <= 0xDDFF)) { unichar c2 = [txt characterAtIndex:i+2]; if (0xD83C == c2) { unichar c3 = [txt characterAtIndex:i+3]; if ((0xDDE6 <= c3) && (c3 <= 0xDDFF)) { // 国旗なのでスキップ・・・(2) i += 3; ++count; continue; } } } i++; ++count; } else if (0xD800 <= c && c <= 0xDBFF) { // 上位サロゲート・・・(1) i++; ++count; } else if (0xDC00 <= c && c <= 0xDFFF) { // 下位サロゲートなので念のため無視 } else if (0x20E3 == c) { // 囲みなので無視・・・(3) } else { ++count; } } return count; } |
ちなみに、これらの絵文字はiOS独自の実装かと思っていたらそうではなく、Unicode6.0 というれっきとした国際規格なのだそうだ。ガラケーに端を発した日本発の絵文字が知らない間に国際規格に…っていうか Unicode のバージョンって知らない間にこんなに上がっていたんだ。
絵文字を含むNSStringの正確な文字数をカウントする
iPhone/iPad のキーボード設定で「絵文字」というキーボードを追加すると、ガラケーよろしく絵文字を入力できるようになる。なので、何も考えないとUITextFieldなどに絵文字を入力されてしまう可能性がある。ここでアプリの仕様上、絵文字を許容するかしないかという議論は当然起こるが、許容したくないというケースはひとまず置いといて、許容する場合のトピックを取り上げる。
絵文字も他の文字と同様UTF-8であるようだが、絵文字の中には4バイトで表現されるものもあるようで、その4バイトの絵文字を含んだ文字列は [str length]
で得られる文字数が狂ってしまうのだ。そうなるとバリデーションとして文字数制限を設ける場合にうまくない。
この現象はどうやらNSStringクラスのUTF-8の取り扱いに原因があるようだが、不具合だと認識されていれば将来的にSDKの方で対応される可能性がある。それまでは次のような関数で凌ぎたいと思う。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | - (NSUInteger) actualUtf8StringSize:NSString str { const char* cstr = [str UTF8String]; int len = strlen(cstr); NSUInteger count = 0; unsigned char c; for (int i = 0; i < len; i++) { c = (unsigned char)cstr[i]; if (0x00 <= c && c <= 0x7F) { ; } else if (0xC2 <= c && c <= 0xDF) { i += 1; } else if (0xE0 <= c && c <= 0xEF) { i += 2; } else if (0xF0 <= c && c <= 0xF7) { i += 3; } else { continue; } ++count; } return count; } |
これはUTF-8の性質を利用して文字数をカウントしている。UTF-8は文字の1バイト目でその文字が何バイトかを示している。なので、バイト列を先頭から調べて行き、文字のバイト数分スキップしながらカウンタを増加している。ひとつ留意したいのは、バイト列から1バイト取得する時に char
型ではなく unsigned char
型の変数に代入することだ。C言語では常識の範疇だが、慣れていないと見落としやすい。