CoreDataと再度向き合うことを決定。その前に前回の反省。

昨年からやってるランブリンのデータ部分、当初CoreDataを使っていたんだけど、どうにも使い勝手も悪く感じて、とどめはマイグレーションではまってバージョンアップでトラブル。これでもう、次のバージョンは自分で作ったCoreDataぐらいの互換レイヤーに切り替えよう、というのが今年の２月。

ある程度の時間をかけてMoreDataと言うモノを作り上げて、ランブリン 2.0のコアに使ってみたんだけど、結論から言うとあまり芳しくない状況。特にメモリ効率が極端に悪くなってしまったのが大きな誤算。SQLの使い方にはある程度自身があったんだけど、スレッド・セイフティの確保やフォルトの仕組みなんかを入れていくと速度も芳しくなく、使い勝手やマイグレーションの仕組みは直接的でよかったんだけど、全体的にいわゆる失敗と判断せざるを得なくなってしまった。

メモリ周りはやっぱり難しくて、要はキャッシュの話。何をいつ忘れるのか、これを正しく実装するのが至難の業。iOS4にはNSCacheというクラスが導入されているのも、キャッシュの難しさを表している一端と言えよう。

と言う状況で挑んだ今年のWWDC。事前に去年のビデオでCoreDataを勉強し、ドキュメントももう一度読みこんで、果たして自分はCoreDataの何を間違えていたのか、そういう視点でいろいろと検証していった。結論として

• CoreDataをいわゆるデータベースととらえていてはダメ。単なるデータを保存する場所ではなく、データが生き続ける環境を提供してくれる環境であって、データをそこから取り出してしまっては、メリットの大半を消すことになる。
• 同じ理由で、CoreDataを簡単なDBMに見えるようなラッパークラス経由で使ってはダメ。ちゃんとコンテクストを意識して、正しく使わないと意味がない。中途半端なSQLの知識が邪魔をしたのは否めない。
• マイグレーションは後々絶対はまる場所なので、最初から経験を積んでおくべき。ライトウェイトだろうとなんだろうと、アプリを出した後は実際にデータがたまってしまった状況でテストも出来ないので、かならず各バージョンのデータファイルを保存しておくべき。後から手に入れるのはとても大変。
• スレッドは最小限に。でも一つは使う。なのでNSManagedObjectIDは登場する。

こんな感じだと思う。もう一度CoreDataに手を出す前にまとめておきたかった。数ヶ月後に何を思うか。