Monthly Archives: August 2015

Swift: Core Data についての概要

アプリの設定等の保持するデータが単純で数が限られている場合、Swift: Core Data を使用しないデータの永続化について で説明した NSUserDefaults 等を使用すれば実現可能です。 一方、扱うデータの構造が複雑で、アプリからユーザーの入力した情報を保存したり、任意の条件で入力した情報の検索結果を返したい場合、メモリ等のパフォーマンスを考慮し Core Data を使用することになるかと思います。 今回はこの Core Data についての概要を自分に向けて説明したいと思います。 目次 Core Data とは RDB(リレーショナルデータベース)とは O/R マッピングフレームワークとは Core Data の概要 Core Data とは Core Data とは MVC デザインパターンの Model を担当する Mac OS X や iOS のデータを永続化するための フレームワーク です。 わかりやすく言えば、Core Data とは SQLite へデータの入出力を行う命令や処理がまとめられたもので、iOS (Mac OS X) と SQLite の橋渡しをおこなってくれるものです。 SQL コマンドがわからなくても、Objecive-C や Swift でオブジェクトを扱うようにデータを渡せば、SQLite にデータが保存され、SQLite のデータをオブジェクトとして処理することができるようになります。 他にも iOS (Mac OS X) から SQLite にデータの受け渡しをおこなう方法としては、 Objective-C の Wrapper ライブラリ FMDB を使用する方法があります。 また最近では SQLite 以外に、iOS や Android 等のモバイル環境に特化したデータベース Realm が注目されてますが、今回は Core data の説明なので、Realm については別の機会に記事にしたいと思います。 RDB(リレーショナルデータベース)とは SQLite 等のデータベースのデータの中身は Excel のセルような構造になっていて、テーブルと呼びます。これは Swift でいうところのクラスに該当します。また、テーブルで構成されたデータの実体はレコードと呼ばれます。 Swift や Objecive-C であつかうクラスやオブジェクトの概念は、オブジェクト技術(オブジェクト指向)と呼ばれていますが、データベースの定義やテーブルやレコードでデータ構造を定義し、データの保存・抽出をおこなう技術を リレーショナル技術 と呼び、リレーショナル技術により構築されたデータベースを RDB(リレーショナル・データベース) と言います。 O/R マッピングフレームワークとは オブジェクト技術 と リレーショナル技術 はどちらも データを扱うための技術 です。なぜこのように2つの技術が分かれているのかは、それぞれが扱うデータがどこに存在するかで理解することができます。 アプリで実行されるオブジェクトはメモリ上のデータであるのに対し、RDB のテーブルやレコードはストレージ上のデータそのものを指します。 アプリでデータを永続化するには、HDD や SDD といったストレージへデータを保存する必要があります。そこで Swift や Objecive-C から RDB へデータを受け渡しをする Core Data が必要となってくるのです。 Core Data はオブジェクト(Object)とリレーショナル(Relational)のデータを置き換える役割を果たすため、O/R マッピングフレームワーク(O/R マッパー) と呼ばれます。 Core Data の概要 ここから具体的に Core Data の中身を見て行きたいと思います。 Core Data のクラスで代表的なものは以下のとおりとなります。 エンティティ データベースのテーブルに相当するものです。 エンティティの実体は XML で Xcode のモデルエディタで定義します。 NSManagedObject データベースのレコードに相当するものです。 エンティティクラス、モデルクラス、テーブルのレコードといったモデルデータ全体の設定を行います。 NSManagedObjectModel エンティティ同士の関連を管理するクラスです。データベースの構造(スキーマ)に相当するもので、属性(フィールド)や関係(表)の関連といったモデルの定義をおこないます。 アプリそのものの根幹となる部分です。 NSManagedObjectContext データベースのクエリに相当するものです。 Core Data では、このオブジェクトを使用しデータの検索・挿入・変更・削除・Undo / Redo といったデータの操作を行います。 NSFetchRequest データの取得を行うときに使用します。1件だけのデータ取得であれば NSFetchRequest を使用すればいいかと思います。 NSFetchedResultsController NSManagedObject オブジェクトを監視するコントローラクラスで、NSFetchRequest からデータの取得を行うときに使用します。 NSManagedObject オブジェクトが挿入・変更・削除された時に NSFetchedResultsControllerDelegate オブジェクトに通知します。 UITableView の indexPath に対応しているため、section や row などのデータにアクセスしやすくなります。 NSPersistentStore データベースの抽象化クラスでデータベースの情報を管理します。 NSPersistentStoreCoodinator NSPersistentStore を管理するクラス。データベースを複数管理する際にも使用します。 NSPersistentStore と NSManagedObjectContext を仲介するクラスで、NSPersistentStore クラスを使い、ファイルの読み書きを行ないます。 Core Data で使用するクラスやオブジェクトを図でまとめると以下のようになります。 まとめ 今回は Core Data の概要とデータベースについてざっくりと説明しました。次回は具体例として Core… 続きを読む

Xcode: UIImageView 表示モード一覧(Xcode 6 Swift 対応)

UIImageView の UIViewContentMode (Scale to Fill や Aspect Fit等) の意味をよく忘れるので、メモしておきます。 UIImageView 表示モード一覧 Scale to Fill 縦横の比率を変え全体表示 Aspect Fit 縦横の比率をそのままに長い辺を基準に全体表示(※空白が発生する可能性あり) Aspect Fill 縦横の比率をそのままに短い辺を基準に全体表示(※空白は発生しない) Redraw Aspect Fillと同じだが、UIImageViewのサイズ変更に追随してリサイズ Center 画像サイズを変えず中央配置 Top 画像サイズを変えず上辺を揃える Bottom 画像サイズを変えず下辺を揃える Left 画像サイズを変えず左辺を揃える Right 画像サイズを変えず右辺を揃える Top Left 画像サイズを変えず上辺・左辺を揃える Top Right 画像サイズを変えず上辺・右辺を揃える Bottom Left 画像サイズを変えず下辺・左辺を揃える Bottom Right 画像サイズを変えず下辺・右辺を揃える まとめ Aspect Fit か Aspect Fill で迷う方が多いと思いますが、これらは Fit(ぴったり合う)、 Fill(満たす)と、素直に英語で判断すればよいと思われます。日本人開発者は損ですよね。。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。

Swift: Core Data を使用しないデータの永続化について

iOS アプリでデータを永続化させる方法はいくつかあり、Core Data や SQLite 等のデータベースを使用するかどうかで、選択肢は大きく2つに分かれます。 今回は データベースを使用しないデータの永続化 について説明したいと思います。 目次 Core Data 以外でデータの永続化する方法 NSUserDefaults について NSKeyedArchiver について プロパティリストについて Core Data 以外でデータの永続化する方法 主に次の3つが iOS アプリでのデータの永続化に使用されています。 NSUserDefaults NSKeyedArchiver プロパティリスト これらの使い方を個別に説明していきたいと思います。 ファイルパス データは次の何れかの階層へ保存することになります。 永続化を行うのであれば /Documents へファイルの保存を行います。 /Documents アプリがファイルを作成し保存する領域 /Library/Caches アプリが一時的に使用する領域(キャッシュファイル) /tmp 一時ファイルの保存に使用する領域(テンポラリーファイル) 各ファイルパスのコードは以下のようになります。 データを datastore.dat ファイルに保存をおこなうサンプルコードは以下のようになります。 NSKeyedArchiver と プロパティリスト でのデータの保存には、このサンプルコードの path を使用し、ファイルへデータの読み書きを行っていきます。 サンプルコード NSUserDefaults について NSUserDefaults については以前に Objective-C で説明した記事 がありますが、ここでは読み書きを行う部分のコードだけをピックアップして説明します。 書き込み 読み込み NSKeyedArchiver について NSKeyedArchiver はその名の通り、オブジェクトをアーカイブ(シリアライズ)しデータの保存を行います。 アーカイブとはオブジェクトのデータをバイナリ(0と1)に変換し保存されます。 保存されるデータはバイナリファイルなので、高速に読み書きが可能ですが、オブジェクトを常に一つのバイナリとして扱うため、データが大きくなるに連れメモリ使用量やデータ検索の効率が悪くなります。 このことから、NSKeyedArchiver はデータが10件、20件程度の 少量データの保存に適した方法 だと言えます。 書き込み 定義済みの path(datastore.dat) へ保存を行います。 読み込み プロパティリストについて プロパティリストとは プロパティリストは拡張子 .plist というファイルで、その実体は xml です。 xml や json でよく目にする < > や { } などで括られた文字列で構成されており、Max OS X や iOS ではその名の通りプロパティリストとして、アプリの設定が保存されています。 注意点 基本的にプロパティリストに保存を行うデータは NSDictionary 型で行います。 このようにプロパティリストは NSDictionary 型で保存されているため、データを読み込む際は NSDictionary 型の変数を用意する必要があります。 書き込み 読み込み NSDictionary を宣言し、読み込みを行います。 まとめ アプリで使用するデータが設定やスコアのみのアプリであれば、今回説明した方法で十分事足りるかと思います。 ユーザーがアプリからデータを保存したり、保存されたデータを使用しなければならない場合は Core Data を利用する必要があります。 次回からは Core Data でのデータの永続化の方法を説明したいと思います。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。

Terminal: iCloud の Mobile Document へのシンボリックリンクを作成する

iCloud のドキュメントへ Terminal コマンドからシンボリックリンクを作成する際に、初歩的な問題で数十分ほどつまづきました。 今回はシンボリックリンクのおさらいを兼ねて、iCloud Document へシンボリックリンクを作成してみたいと思います。 目次 シンボリックリンクとは シンボリックリンクの使い道 iCloud の Mobile Document へのシンボリックリンクを作成する シンボリックリンクとは 特定のファイルやディレクトリを指し示す別のファイルを作成し、それを通じて本体を参照できるようにする仕組みで、Mac でいうところのエイリアスのようなものです。 エイリアスとシンボリックリンクの違いは、エイリアスがただのリンクであるのに対して、シンボリックリンクは、元のファイルやフォルダと同等に扱うことができると言う点です。 シンボリックリンクの使い道 複数台のマシンでアプリや開発環境を共有したい場合、マシンごとに設定を行うのは面倒です。 そういった場合、iCloud や Dropbox へ設定ファイルを作成しておき、各マシンのシンボリックリンクから クラウドに保存された設定ファイルを参照することで、マシンが違っても同じ環境で作業を行うことができます。 マシンを乗り換えた場合やリストアを行った場合には、最初からアプリや開発環境の設定を行うことなく、シンボリックリンクを作成するだけでこれまでどおりの環境で作業が行えるといった使い方ができます。 iCloud の Mobile Document へのシンボリックリンクを作成する シンボリックリンクを作成するコマンドは以下の通りです。 このコマンドで pathB から pathA(実体)へのシンボリックリンクが作成されます。 Windows のコマンドプロンプトだとこの pathA と pathB の定義が反対であるため、いつもどっちがどっちだったかを忘れてしまいます。 問題点 基本的にこの ln -s コマンドでシンボリックリンクが作成されるはずなのですが、iCloud を参照する場合問題が発生します。 ユーザーのホームディレクトリに abc.txt というシンボリックリンクを作成し、iCloud のモバイルドキュメント直下の abc.txt を参照したい場合は以下の様なコマンドになると思います。 うまくいく場合はこのまま問題なくシンボリックリンクが作成されますが、ドットから始まる不可視ファイル等に対してシンボリックリンクを作成した場合 No such file or directory のエラーが返されてしまうケースがあります。 解決法 よく入力したコマンドを見れば分かることなのですが、Mobile Document のフォルダ名にスペースが入っているため、これが悪さをしていたようです。スペースをエスケープすると無事シンボリックリンクが作成されました。 まとめ 今回のケースは Dropbox から iCloud へ一部の環境や設定ファイルを移行している最中の出来事でした。 両者とも便利なサービスなので、これからうまく使い分けていきたいと思います。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。