CoreDataのモデルクラスはXcodeのモデルエディタから自動生成しますが、生成されたクラスにメソッドを追加したりしたいことがあると思います。 そのとき、自動生成されたファイルを直接変更してしまうと、モデルに変更がありモデルクラスを再生成したときにその変更が上書きされてしまいます。 そこで、カテゴリを使って追加部分は別のファイルに分けておくと、モデルクラスを再生成しても後から追加した部分は上書きされずに残るのでそのまま使えます。 例えば下記のようなクラス (Event.h) があるとして、条件でフェッチするメソッドや、日付をフォーマットして返すメソッドを Event+CoreData.h/m や Event+Formatter.h/m として別ファイルに定義します。 // Event.h #import <Foundation/Foundation.h> #import <CoreDa
I'm trying to use core data in a multi thread way. I simply want to show the application with the previously downloaded data while downloading new data in background. This should let the user access the application during update process. I have a NSURLConnection which download the file asyncronously using delegate (and showing the progress), then i use an XMLParser to parse the new data and create
Cocoaの日々: 2月 2011
CoreData を使うアプリであればこの程度の件数はすぐに行くので、起動時にマイグレーションが走ると確実に落ちてしまう。これを防ぐためには起動時に CoreData へアクセスさせないのが最低限の対策になるが、その場合でもユーザが CoreData へアクセスする操作を行った瞬間にマイグレーション処理に時間がかかって画面が固まったようになるのでユーザビリティは良くない。 マイグレーションを考慮したパターン よって CoreDataを使うアプリではマイグレーション用の画面を用意するのがベスト。処理フローはこんな感じ。 起動 ↓ (1)マイグレーションチェック もし必要なら、マイグレーション用の画面へ遷移し、(2)マイグレーション実行 ↓ 通常画面マイグレーションチェックは NSPersistentCoordinator を使えばわかる。 Cocoaの日々: [iOS][Mac] CoreD
Core Dataのデータをフェッチするとき、特定の条件を指定したければNSPredicateを使う。NSPredicateは、Core Dataに限らず、NSArrayなどにも利用可能。このNSPredicateを作成する際の小ワザ的な話として、テンプレートを使う方法が以下のドキュメントに載っていた。 Max Dev Center: Core Data Snippets: Fetching Managed Objects … NSPredicate’s predicateWithFormat: method is typically the easiest way to use a predicate (as shown in “Fetch with a Predicate”), but it’s not the most efficient way to create the pred
先日の続き。 iphoneアプリでデータの永続化にCoreDataの使用について、XCodeで自動生成されるコードをいじってみての整理2回目。 モデルの編集 「Use Core Data for storage」をチェックしてプロジェクトを作成していると 「xcdatamodel」という拡張子で モデルファイル（ディレクトリ）が作られているので、これを編集します。。（XCodeでファイルを選択するとエディタが起動される。） 今回は、 Category(記事カテゴリー)とTopic(記事)という２つのEntityを定義。 CategoryとTopicは１対多となるようリレーションを設定。Category側からTopicへの関連、 TopicからCategoryの関連の両方を定義します。 それぞれのEntityは以下のように。 Category name String createdAt Da
Update 4/17/12: Fully updated for iOS 5 (original post by Ray Wenderlich, update by Adam Burkepile). This is the third and final part of a series to help get you up to speed with the basics of Core Data quickly. In the first part of the Core Data tutorial series, we created a visual data model for our objects, ran a quick and dirty test to make sure it works, and hooked it up to a table view so we
I have a Core Data model in which a Task entity includes an optional to-many relationship excludedOccurrences. One of the properties of excludedOccurrences is start, which is an NSDate object. The ExcludedOccurrence entity has an inverse mandatory to-one relationship to the Task entity. In order to fetch tasks for a specified day, I need to make sure that the specified day does not appear as the s
Study CoreData 3 ~デルモに手を出すなら慎重に…~
大変な事に、この『Study CoreData』もすでに4エントリ目になりました。 しかも、まだ独自のデーターベース作成に一歩も入っていない始末…。 ですが、まず理解する事でこれからの作業が分かりやすくなる(はず？)です!! ってことで、引き続きデフォルトで作成されたプロジェクトを検証していきます。 前回までのエントリでコードとして書かれている核の部分はある程度理解できたと思うことにして^^; 今回は、 どのように<NSManagedObjectModel>(データの設計図)が作られるのか を見ていくことにします。 それでは、今まで見てきた『TodoCoreプロジェクト』を開きましょう。 注意：投稿者自身もCoraDataについて勉強中のため、このシリーズには誤りが含まれている可能性があります。もし、間違いに気付かれた方はコメント欄もしくはtwitterなどでご指摘いただけると幸いです<(
View-based Application で CoreData を使えるようしたい
新規プロジェクト作成のテンプレートでView-based Applicationを選択してプロジェクトを作成する。Core Dataを使いたいがどうすればいいのか。 Navigation-based Applicationテンプレートを選ぶ場合はCore Dataを使うかどうか選択できるようになってるけど、View-basedではチェックボックスが出てこない。 それならば自分で実装しようということになるのだけれど、うーんうーんって感じになる場合が多いと思うの。 なので手順を書いておく。 Xcode 3.2.4 and iOS SDK 4.1 で試してる。 古いバージョンとか新しいバージョンのこと考えてない。 新規プロジェクトをView-based Applicationを選択して名前をMyCDataとして作成してます。 僕がやったポイント。 CoreData.frameworkを追加 Da
練習で作っている時計アプリも、そろそろ形になってきました。 前回は NSUserDefaults を使い、アプリケーションの設定を保存しました。 しかし、この方法ではデータの検索をしたり、データの相互関係（リレーション）を実現するには、少し力不足… でも、そこは大丈夫。iPhoneはさすがスマートフォンと言うだけあって、標準でSQLiteを使う事ができちゃうんです！！（Androidもそうらしいですよ） しかも、普段SQLを使っていない人でもある程度扱えるよう、ORマッパー的な機能が用意されています。 Appleはこれらの、バックエンドのストレージ、それらを操作するコンテキスト、データ構造を扱うモデルを、CoreData(wikipedia)というフレームワークに纏めて提供しています。 今日はこれを扱っていこうと思います。 Core Dataコトハジメ Core Dataの手っ取り早いサン
Study CoreData 11 ~急がば回れ！~
性懲りもなく本日も更新していく『Study CoreData』。 第0回から数えると今回で10日を超えたわけですが、 実は実際にここまで辿り着くにはほぼ一ヶ月以上かかっていたりします^^; 一週間以上同じトコロでハマって抜け出せなくなりそ〜な事もありました。 そんな経緯もあり、ちょこちょこと ハマりやすいポイントなんかも含めて書いている感じです。 なので、正解だけが書かれた他の書籍などに比べると 随分と遠回りな旅かもしれませんが、じっくりCoreDataを身につけられたらなぁと思って今日も書いていきますので、どうぞよろしゅうに<(_ _)> 注意：投稿者自身もCoraDataについて勉強中のため、このシリーズには誤りが含まれている可能性があります。もし、間違いに気付かれた方はコメント欄もしくはtwitterなどでご指摘いただけると幸いです<(_ _)> また、開発環境はXcode3.2.3
10.02.25 Core Data 勉強日記 (12)：More iPhone 3 Development / chapter 7 (取得済みプロパティ/Fetched Property) More iPhone 3 Development: Tackling iPhone SDK 3 (Beginning) Chapter 7 のまとめ。 前回の Chapter 7 : 関連 (Relationship) に続き、ここでは取得済みプロパティ(Fetched property)について。 取得済みプロパティ/Fetched Properties Entity に追加できるプロパティの種類として取得済みプロパティ(Fetched Property)というものがある。これは、ある条件に一致するManagedObjectだと思えばよい。なお、Fetched Property は常に不変(imm
10.02.23 Core Data 勉強日記 (10)：More iPhone 3 Development / chapter 6 (Validation) More iPhone 3 Development: Tackling iPhone SDK 3 (Beginning) Chapter 6 のまとめ（後半）。 カスタムモデルの生成方法に関してはChapter 6（カスタムモデル）でまとめたが、ここでは、値の有効性チェック"Validation"についてまとめる。 Validationとは、値を変更する際にその正当性をチェックし不当ならエラーを返すというもの。簡単な有効範囲の指定（最大値や最小値など）であれば、データモデルエディタでできるが、細かいチェックや複数の変数をまたいだチェックを行いたければ、NSManagedObjectのサブクラスでチェック用のメソッドの実装する必要があ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
