Cocoaの日々: CoreData - マイグレーションを考慮した CoreDataManager パターン
CoreData を使うアプリであればこの程度の件数はすぐに行くので、起動時にマイグレーションが走ると確実に落ちてしまう。これを防ぐためには起動時に CoreData へアクセスさせないのが最低限の対策になるが、その場合でもユーザが CoreData へアクセスする操作を行った瞬間にマイグレーション処理に時間がかかって画面が固まったようになるのでユーザビリティは良くない。 マイグレーションを考慮したパターン よって CoreDataを使うアプリではマイグレーション用の画面を用意するのがベスト。処理フローはこんな感じ。 起動 ↓ (1)マイグレーションチェック もし必要なら、マイグレーション用の画面へ遷移し、(2)マイグレーション実行 ↓ 通常画面マイグレーションチェックは NSPersistentCoordinator を使えばわかる。 Cocoaの日々: [iOS][Mac] CoreD
CoreDataのためのNSFetchRequestをArelみたいに作るためのライブラリを公開しました - soutaroブログ
https://github.com/soutaro/Arelish CoreDataを使わずにObjective Cのプログラムを書いていると、馬鹿みたいなことを馬鹿みたいに繰り返しやるはめになって馬鹿みたいである。しかしCoreDataを使ったとしても、NSFetchRequestを作るために馬鹿みたいなプログラムを馬鹿みたいに何行も書かなくちゃいけなくて、やっぱり馬鹿みたいである。 こういう状況を改善するために、Arelみたいに条件が書けたり書けなかったりするライブラリを作りました。 Arelish* arel = [Arelish arelishWithEntity:NSStringFromClass([YourCoreDataModel class]) context:managedObjectContext]; arel = [[arel where:@"parent" is:
Cocoaの日々: CoreData - 大量データを扱う場合のメモリ利用量を減らす
データ件数は、Customerが 500件、Karteが6,000件（Customer１件につきKarte 12件）となっていて、それぞれを１つの CSVファイルへ書き出す。 処理は次のような感じになる。 NSMangedObjectContext* moc = [取得]; NSArray* customers = [moc Customer全件取得]; for (NSManagedObject* customer in customers) { NSArray* kartes = [moc Karte取得・条件：customer]; for (NSManagedObject* karte in kartes) { [CSV１行書き出し]; } }メモリのフットプリント（利用状況）はこんな感じ。 Customer, Karte を１件づつ読み込む度にメモリが消費され、フットプリントが増大し
NSFetchedResultsController を使って CoreData を表示する
iPhone Dev Center から CoreDataBooks というサンプルコードを入手してソースを読む。なるほど NSFetchedResultsController を使うと UITableView で CoreData を使うのが楽になりそうだ。 CoreDataBooks の動作はこんな感じ。 リストに詳細表示、それと項目の編集を行う３つのビューから構成される。データの格納に CoreData を採用していて UITableView との連携に NSFetchedResultsController を使っている。 NSFetchedResultsController の使い方を理解するためにこのコードを参考にしつつ、（テーブルが一つで）構造が単純な OneLiner を NSFetcedResultsController を使うバージョンに書き換えてみる。 MainView
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.spice-of-life.net/wiki/index.cgi?CoreDataCooking
