【iOS/Mac開発】Core Data を使いはじめるのに最低限知っておけばいいこと

こんにちは。Objective-C は Emacs で書く金内です。

ウェブブラウザ Sleipnir for Mac や Sleipnir Mobile for iPhone / iPad は、ブックマークや履歴・タブのデータを Core Data を使って管理しています。 Core Data は iOS / OS X 開発の主要フレームワークのひとつですが、どうにもとっつきにくいためか、尻込みしてしまう方も多いという印象があります。

この記事の目的は、とっつきにくい Core Data を最低限の内容にしぼって解説して、「なるほどそーいうものなのね。ボク／ワタシのアプリでも使ってみよっかなー」と思っていただくことです。

どんな時に使うの？

ひとことで言えば、Core Data は Apple 純正の高機能・高性能データ管理フレームワークです。

iOS / Mac 向けのアプリである程度の件数（数百件とか）を超えるデータを保存・利用する場合は、Core Data の利用を検討するのがおすすめです。 Sleipnir のブックマークや履歴も、10件くらいしかないケースもあれば、数百、数千件になるケースがあってもおかしくありません。そのようなデータを扱う場合、Core Data は有力な選択肢になります。

他の選択肢には、プロパティリスト（plist）や SQLite データベースなどがあります。それらの中で Core Data のメリットは次のような点にあります。

プロパティや相互参照、カスタムロジックを持ったオブジェクトをそのまま保存できる学習コストの低さ
Objective-C ベースの標準フレームワークとして、KVO などのテクニックがそのまま使える導入のしやすさ
データが10件でも数千〜数万件でもちゃんと動くスケーラビリティ
パフォーマンスやメモリ使用効率について Apple がチューニングしている安心感

他にもいろいろメリットがあります。使わないなんてもったいない!

Core Data のとっつきにくさ

Core Data のとっつきにくさは、登場人物（クラス）がたくさん出てくるところにあります。しかも、名前が長いうえにお互い似ていたり、理解するためにはあまり重要じゃないのに重要そうな顔をしていたりして、必要以上に複雑に感じられてしまうところがあります。

どれも理由があってのことなのですが、説明のしかたによっては軽減できる部分でもあります。この記事では、使いはじめるために必要な最低限の内容にしぼって、Core Data のとっつきにくさを解消したいと思います。

Core Data の最低限の登場人物

では、Core Data を理解するのに最低限必要な登場人物を紹介していきましょう。実際の役割がわかりやすいように「ウェブブラウザのブックマーク管理モジュール」を作る観点で解説します。

マネージド・オブジェクト: ブックマーク

Core Data に保存するひとつひとつのブックマークは、「マネージド・オブジェクト（NSManagedObject）」となります。このマネージド・オブジェクトこそが、Core Data を使う上でもっとも重要な概念になります。

「マネージド」とあるのは、「Core Data が管理する」という意味です。生成、破棄などメモリ関連も Core Data が管理するので、アプリ側が管理する通常のオブジェクトとは若干違った振舞いをします。具体的な違いについてここでは省略しますが、「Core Data の管理下にあるちょっと変わったオブジェクト」とイメージしておいてください。

コンテキスト: ブックマークの集まり

アプリが Core Data にブックマークを追加したり、取り出したりする機能は「コンテキスト（NSManagedObjectContext）」というオブジェクトにあります。コンテキストの中にブックマークがあるイメージです。

save メソッドを呼べばコンテキストがデータを保存します。実際にどこにどのように保存するかは、後述する永続化ストアで決まります。

リクエスト: ブックマークの取得

コンテキストからブックマークを取得するにはリクエスト（NSFetchRequest）を使います。リクエストには取得するオブジェクトの種類や、条件（たとえばタイトルに “Sleipnir” を含むなど）、取得結果のソート順などを指定できます。

モデル: ブックマークのデータ構造定義

ブックマークには、URL やタイトルを保存しておきたいですよね。他にも最終アクセス日時や、フォルダ管理のための親子関係情報なんかも保存しておきたいかもしれません。

そのようなブックマークのデータ構造定義を保持するのがモデル（NSManagedObjectModel）です。 Xcode の専用エディタで編集して、アプリ実行時にデータファイルとして Core Data に読み込みます。

永続化ストア: データベース

コンテキストの内容をどこにどうやって保存するかは、コンテキストに設定された永続化ストア（NSPersistentStore）オブジェクトによって決まります。永続化ストアには SQLite データベースを使うのが一般的ですが、XML ファイルやメモリ（永続化しない）を使うストアなどもあります。

下図は、アプリと、ここまでで登場した人々の関係をあらわしたものです。

Core Data Diagram

実際のアプリにおける Core Data とのやりとり

イメージしやすいように、実際のアプリで Core Data とのやりとりの例を紹介しましょう。たとえばあるブックマークのタイトルを変更したい場合は次のような流れになります。

コンテキストを取得する（どうやって取得するかはアプリの設計次第）
条件を設定したリクエストを使ってコンテキストからブックマークオブジェクトを取得する
ブックマークオブジェクトのタイトルプロパティを変更する
コンテキストを保存する

アプリの実装において大切なのは、何といってもマネージド・オブジェクトとコンテキスト、そしてその2つをつなぐリクエストです。

アプリに適用するには

みなさんのアプリに適用するには、まず、どんなマネージド・オブジェクトが必要かを考えてみてください。Sleipnir のようなウェブブラウザなら、ブックマーク、履歴、タブなどがマネージド・オブジェクトの候補になります。

次に、各マネージド・オブジェクトのデータ構造を、Xcode の Core Data のモデルエディタを使って作ってみてください。データ構造は「エンティティ」という単位で作成します。たとえば、ブックマークエンティティ、履歴エンティティなどを作ります。エンティティどうしには「関連」を持たせることもできます。