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

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

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

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

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

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

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

AppStoreのバージョン番号ではまる

ランブリンのバージョンアップ版をリリースしようと昨夜から奮闘した記録。

最初のバージョンが1.0でだして、次のマイナーアップデート版を1.01でだしました。ここまでは問題なかったのですが、昨日出すものが機能的にも増えたこともあり、1.02ではなく1.1にしましょうと決定しました。

で、いざリリースの段階になって、サブミットしてみると

The binary you uploaded was invalid. The key CFBundleVersion in the Info.plist file must contain a higher version than that of the previously uploaded version.

 これは困った。でGoogle様に聞いてみたところ、iPhone Dev SDKに記述を見つけました

DBinSyd Registered Member Join Date: Jul 2009 Posts: 8

Just went through this process with fairly simple version numbers and here's what I found; Original version '1.0'. Next upgrade version '1.01' - worked fine. Tried to submit an upgrade to version '1.1' and got the "CFBundleVersion in the Info.plist file must contain a higher version than that of the previously uploaded version" error. After much messing around with the package including check the version in the package contents of the built program submitted as version '1.10' and it worked. Seems like there is a problem with the string to float conversion that Apple is doing.

なるほど、1.01 の次は 1.10ならオッケーなのか。ではそれで．．．って1.10ってなんだよ！「十」ってなんだ。マイナーバージョン10はないだろう。SuperClock 3.9.10 ぐらいしか聞いたことないぞ。これはそのまま採用しづらいな。


じゃあ、1.1.0 ならどうだ。これならまだ意味は通じるので再度チャレンジ。さて．．．失敗。


orz




やっぱり1.10しかないか。とバイナリーは作り直して、ふと思う。表記上はあくまで1.1.0としたいのでiTunes Connectでの表記と変えてみてはどうなるか。前に一致してないからダメだよ、といわれたんだけど物は試し。エイヤっとアップしたら、なんと問題なく通った！おぉ、じゃあAppStoreにでるバージョン表記とBundleVersionは関係ないのか？関係がないならいっそ違う番号体系になっているほうが間違いは少ない。ということで、最終的には


iTunesConnect Version = 1.1.0
Info.plist CF Bundle Version = 2


という状態でアップしました。問題はなし。


混乱を極めたバージョン問題ですが、結局見た目のバージョンと内部バージョンを分けるというのがベスト。AppStoreにバイナリーをサブミットしたときに言われエラーは、結局内部バージョンを上げなさいということ。そのバージョンと表記上のバージョン（テキストフィールドにいれるもの＝ユーザーの目に触れるもの）は別と考えたほうが混乱はない。だいたい戦略上の理由で見た目のバージョンは決められることも多いし。


ただし、アプリ内のバージョン表記も必要で、これは今までCFBundleVersionKeyを参照していたので、新たにDisplayBundleVersion という項目を追加しました。今後箱の二本立てで管理することにします。