2013年11月札幌iPhone開発懇談会勉強会プレゼンテーション資料。 iOS CoreData徹底入門 販売記念。CoreData のバッドプラクティスを紹介します。Read less

2013年11月札幌iPhone開発懇談会勉強会プレゼンテーション資料。 iOS CoreData徹底入門 販売記念。CoreData のバッドプラクティスを紹介します。Read less
このアプリでは、ユーザに世界の様々な場所のバーチャルバケーション先をコレクションしてもらう。ユーザは、行きたい場所の写真を選ぶためにこのアプリのFast Map Placesという写真選択機能を使う。このアプリには2つの主要課題がある:(1)ユーザに行きたい場所を選んでもらい、(2)ユーザにそのバーチャルバケーションのスポットでバケーションしてもらうことである。前者は写真が表示されているFast Map Placesの中に"Vist/Unvist"ボタンを追加することで達成される。後者は、タブバーコントローラに新しいタブを追加して、そのタブでユーザに場所または滞在希望地の写真のFlickr dictionary内にある検索タグでバーチャルバケーションをじっくり見てもらうことで達成される。
SQLite を見てみよう。 sqlite> .tables ZBLOGENTRY ZTAG Z_1TAGS Z_METADATA Z_PRIMARYKEY 新しく Z_1TAGS テーブルが追加されているのが分かる。 sqlite> .schema z_1tags CREATE TABLE Z_1TAGS ( Z_1ENTRIES, Z_2TAGS ); CREATE INDEX Z_1TAGS_Z_1ENTRIES_INDEX ON Z_1TAGS (Z_1ENTRIES); CREATE INDEX Z_1TAGS_Z_2TAGS_INDEX ON Z_1TAGS (Z_2TAGS); 中身を見ると、いわゆる中間テーブルで ZBLOGENTRY と ZTAG へのリレーションを持っている。 データはこんな感じ。 sqlite> select * from z_1tags; 2|1 2
HOME » Natsu note » 古い投稿 » Core Data 勉強日記 (11):More iPhone 3 Development / chapter 7 (関連/Relationship) Core Data 勉強日記 (11):More iPhone 3 Development / chapter 7 (関連/Relationship) 2010/02/24/|古い投稿|Core Data More iPhone 3 Development: Tackling iPhone SDK 3 (Beginning) Chapter 7 のまとめ。 最終章は、関連(Relationship)、取得済みプロパティ(Fetched property)について。さらに、流用がしやすいように汎用的なViewControllerの設計について考える。内容が多いので、まずはRelations
ものすごく便利な機能がたくさんあってもなかなか使いこなすのは大変なCore Data。基本の登場人物をまとめてみた。全体像が見えているとリファレンスガイドも楽に読めるようになるし、何より、「やりたいこと」があったとき、何を調べればよいかの見当がつくようになる。 ということで、まずは根っこからCore Dataの「仕組み」を把握しよう。 ここで紹介する主な登場人物は以下。 NSPersistentStoreCoordinator NSManagedObjectContext NSManagedObjectModel NSManagedObject NSEntityDescription NSFetchRequest ここまではMac OS, iOS共通。iOSでは上記以外にNSFetchedResultsControllerという素晴らしきコントローラがあるが、これはあくまでも取得したデータ
前回の記事 で、「 Core Data によって、プログラムの骨格を作るのはかなり楽になるけれど、それだけでちゃんとしたプログラムができるわけではないし、もしそれができなければ、いま作っている Kaku の画像挿入機能は搭載しない」 ということを書いたと思います。 昨日はまさに、そういう「これじゃあ公開できない」という事態に直面していました。前回の記事を書く前に、うすうす気付いてはいたのですが、やはり大量の画像を登録したとき、画像挿入機能のパフォーマンスがかなり悪くなる のです。 結局原因は、Core Data に頼りすぎた、とかではなく、設計そのものがおかしかったというか、単純に、もっと勉強してから臨むべきだった、ということでしたが…(汗) …というわけで今日は、その問題を解決していった過程を書いていきたいと思います。タイトルは「Core Data で画像を扱う」となっていますが、それに
CoreDataに大量のデータを追加するとき、メモリに気をつけてあげないとすぐメモリ不足になってしまいます。 しかし、CoreDataのManagedObjectは解放したいと思ったタイミングではなかなか解放してくれません。 メモリ解放するにはちょっとした手順が必要となります。 新しくManagedObjectContextを作る ManagedObjectをひとつ追加→保存する ManagedObjectContextのresetを呼ぶ(メモリ強制開放) 2〜3を必要なだけ繰り返す 他のManagedObjectContextで作ったManagedObjectに保存結果をマージする ちなみに、大量のデータを変更・処理する時なども手順は同じです。 新しくManagedObjectContextを作る まず、新しくManagedObjectContextが必要になります。 なぜ新しいのが必要
現在の多くのデスクトップアプリケーションのためのフレームワークは、その多くが、デザイン原理としてモデル・ビュー・コントローラ(MVC)アーキテクチャを取り入れている。これは、アプリケーションに必要とされるモジュールを、データを表すモデル、ユーザへの表示を行うビュー、これらをコントロールするコントローラ、の3層に分割して設計しよう、というものだ。 今回紹介するのは、Apple ComputerのMac OS Xにおけるアプリケーションフレームワークである「Cocoa」のMVCアーキテクチャだ。Mac OS Xのバージョンアップに伴い、Cocoaにも2度、重要なアップデートがあった。まずはこの変遷を追いかけてみたい。 Cocoa BindingとCore Dataの導入 Cocoaは、その由来となるNEXTSTEPのころから、MVCをベースに設計されていた。MVCの3つのレイヤのうち、ビューに
Core Data のパフォーマンスを良くするためのテクニックはいくつか存在するが、その中でも重要だと思われるバイナリデータの扱いについて記載されている書籍を見つけたので参考までにまとめておく。 Core Data: Apple’s API for Persisting Data on Mac OS X (リンク Amazon) の6章に分かりやすい解説があった。ただし、この本は主にOSX用に書かれたものなので、目安となるバイト数はiPhoneOSでは少し変わってくるかもしれない。それでも三通りの方法を使い分けるべきだという基本概念は十分iPhoneOSにも流用できるし、各方法がどのようにパフォーマンスに効いてくるかという理論的な部分は是非理解しておきたいところ。 バイナリデータの管理方法 例えば、レシピアプリの各レシピに画像を保存し、レシピ一覧でその画像を表示することを考える。もし、画像
Hi, I’m new here. You may know me as @atomicbird on Twitter. Just a few days ago my book Core Data for iOS: Developing Data-Driven Applications for the iPad, iPhone, and iPod touch (co-written with the excellent Tim Isted) was published, and Matt invited me to contribute some Core Data tips to CIMGF. I’m going to start off discussing taking JSON data from a web service and converting it to Core Da
iOS 12に向けた準備 iOSは、世界で最も先進的なモバイルオペレーティングシステムです。Core ML 2とCreate MLによる機械学習の力を利用すれば、さらにインテリジェントなAppを作成することができます。ARKitによって、マルチプレイヤーの拡張現実(AR)体験を構築し、現実世界のオブジェクトに組み込むことができます。また、Siriショートカット、新しいカメラAPIなどのエキサイティングなテクノロジーを利用することで、一層インテリジェントで臨場感のあるユーザー体験を提供できます。 Siriショートカット Siriでは、ユーザーの日々の行動とAppをスマートに組み合わせ、必要な時に便利なショートカットが提案されるようになりました。Shortcuts APIを使用すれば、ロック画面、検索、Siriの文字盤から直接、Appに関連したタスクをすばやく実行することができます。 機械学習
CoreDataややっこしいよ、後で理解するからとりあえず使ってみたい>< というときにとりあえず使えるようにする手順メモ。 プロジェクトを作成する際に「Use Core Data for storage」にチェックを入れれば、とりあえず使えるようになりますが、既存のプロジェクトに導入する際の手順にもなります。 プロジェクトの作成 プロジェクトは「Window-based-Application」を選択。 「Use Core Data for storage」にはチェックを入れません。 CoreData.frameworkの取り込みとxcdatamodelの作成 「CoreData.framework」を取り込みは、 「グループとファイル」の「Frameworks」で右クリック 「追加」-> 「既存のフレームワーク」を選択 「CoreData.framework」を選択して「追加」ボタンを
iphoneアプリでデータの永続化にCoreDataの使用について、ちょっと整理していきましょ。 (これまで使ってきたDB接続のインターフェイスとは考え方が違うのでちょっとわかりにくかったこともあるので。) 使用している開発環境は、「XCode 3.2.1」です。 アプリケーションの作成 プロジェクトのタイプとして「navigation-based Application」を選択、「Use Core Data for storage」をチェックしてプロジェクトを作成するとCore Dataを使うためのテンプレートソースなどを作成してくれます。 今回をそれを利用します。 基本的なオブジェクト 「Core Data」を使用するさいの基本となるオブジェクトを生成するコードが、アプリケーションのデレゲートクラスに作られます。 このクラスのヘッダーファイルは以下のようなものになりますが。 @inte
先日の続き。 iphoneアプリでデータの永続化にCoreDataの使用について、XCodeで自動生成されるコードをいじってみての整理2回目。 モデルの編集 「Use Core Data for storage」をチェックしてプロジェクトを作成していると 「xcdatamodel」という拡張子で モデルファイル(ディレクトリ)が作られているので、これを編集します。。(XCodeでファイルを選択するとエディタが起動される。) 今回は、 Category(記事カテゴリー)とTopic(記事)という2つのEntityを定義。 CategoryとTopicは1対多となるようリレーションを設定。Category側からTopicへの関連、 TopicからCategoryの関連の両方を定義します。 それぞれのEntityは以下のように。 Category name String createdAt Da
先日の続き。 iphoneアプリでデータの永続化にCoreDataの使用について、整理3回目。 今回は、リレーションをつけた場合の下位のエンティティの扱い。 今回の具体例では、Categoryに属する、Topic(記事)の表示、追加。 追加、削除のためのManagedObjectクラスを定義 リレーションの上位のEntityに対する、ManagedObjectクラス(NSManagedObjectから派生)を追加、追加と削除のメソッドを作成。上位から下位のEntityの関連を登録することができるようになります。ですが、この追加、削除のメソッドは実装を行わなくても、CoreDataGeneratedAccessorsというカテゴリーでインターフェイスだけを宣言しておければ、実装は不要です(動的に生成されます。) カテゴリーなしのインターフェイスは、Entityの属性値にアクセスするためのPr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く