猫好きモバイルアプリケーション開発者記録
モバイルアプリケーション開発プログラマの開発ナレッジ記録です
MySQL 5.5.xのソースからのビルド失敗例
ネットでも同様の例はありつつも、解決策を記述しているところはなかったので紹介しておきます。
LinuxでソースからMySQL 5.5.xをビルドしたときに、
環境変数の設定によってはビルドに失敗してしまいます。
具体的には、「C_INCLUDE_PATH」を設定していると、以下のようなエラーになります。
エラー内容としてはMySQL内で利用されている共通関数定義が見つからず、エラーになっている感じです。なので、無理矢理インクルードファイルの相対パスを指定するように修正するとコンパイルまでは通るのですが、結局リンクに失敗します。
このエラー、正確には「C_INCLUDE_PATH」に「コロン(:)」が含まれていると失敗するようで、例えば以下のように「C_INCLUDE_PATH」が定義されていると失敗しません。
とはいえ、普段から環境変数に「C_INCLUDE_PATH」や「LD_LIBRARY_PATH」などを設定しておくのはよくない習慣とされていますので、最初から設定しておかないに限ります。
MySQL 5.5.xに限らず、同じような例はいくつかあるようなので、もし同じようなエラーが発生した場合は「C_INCLUDE_PATH」を疑ってみるといいかも知れません。
LinuxでソースからMySQL 5.5.xをビルドしたときに、
環境変数の設定によってはビルドに失敗してしまいます。
具体的には、「C_INCLUDE_PATH」を設定していると、以下のようなエラーになります。
[ 0%] Built target INFO_BIN
[ 0%] Built target INFO_SRC
[ 0%] Built target abi_check
[ 2%] Built target zlib
[ 7%] Built target readline
[ 8%] Built target mysqlservices
[ 15%] Built target strings
[ 31%] Built target mysys
[ 31%] Built target dbug
[ 31%] Built target comp_err
[ 31%] Built target GenError
[ 31%] Built target blackhole
[ 31%] Built target example
[ 32%] Built target csv
[ 46%] Built target innobase
[ 46%] Built target archive
[ 47%] Built target federated
[ 51%] Built target heap
[ 51%] Built target hp_test1
[ 51%] Built target hp_test2
[ 59%] Built target myisam
[ 60%] Built target myisam_ftdump
[ 60%] Built target myisamchk
[ 60%] Built target myisamlog
[ 61%] Built target myisampack
[ 65%] Built target perfschema
[ 65%] Built target mytap
[ 65%] Built target pfs-t
[ 65%] Built target pfs_instr-oom-t
[ 65%] Built target pfs_instr-t
[ 65%] Built target pfs_instr_class-oom-t
[ 66%] Built target pfs_instr_class-t
[ 69%] Built target myisammrg
[ 69%] Built target auth
[ 69%] Built target auth_socket
[ 69%] Built target auth_test_plugin
[ 69%] Built target qa_auth_client
[ 69%] Built target qa_auth_interface
[ 69%] Built target qa_auth_server
[ 70%] Built target semisync_master
[ 70%] Built target semisync_slave
[ 71%] Built target audit_null
[ 71%] Built target daemon_example
[ 71%] Built target ftexample
[ 72%] Built target vio
[ 73%] Built target regex
[ 73%] Built target thr_lock
[ 73%] Building C object libmysql/CMakeFiles/clientlib.dir/__/sql-common/client.c.o
/usr/local/src/mysql-5.5.22/sql-common/client.c:1936: error: ‘cli_list_fields’ undeclared here (not in a function)
/usr/local/src/mysql-5.5.22/sql-common/client.c:1937: error: ‘cli_read_prepare_result’ undeclared here (not in a function)
/usr/local/src/mysql-5.5.22/sql-common/client.c:1938: error: ‘cli_stmt_execute’ undeclared here (not in a function)
/usr/local/src/mysql-5.5.22/sql-common/client.c:1939: error: ‘cli_read_binary_rows’ undeclared here (not in a function)
/usr/local/src/mysql-5.5.22/sql-common/client.c:1940: error: ‘cli_unbuffered_fetch’ undeclared here (not in a function)
/usr/local/src/mysql-5.5.22/sql-common/client.c:1942: error: ‘cli_read_statistics’ undeclared here (not in a function)
/usr/local/src/mysql-5.5.22/sql-common/client.c: In function ‘cli_read_query_result’:
/usr/local/src/mysql-5.5.22/sql-common/client.c:3807: 警告: implicit declaration of function ‘handle_local_infile’
make[2]: *** [libmysql/CMakeFiles/clientlib.dir/__/sql-common/client.c.o] エラー 1
make[1]: *** [libmysql/CMakeFiles/clientlib.dir/all] エラー 2
make: *** [all] エラー 2
エラー内容としてはMySQL内で利用されている共通関数定義が見つからず、エラーになっている感じです。なので、無理矢理インクルードファイルの相対パスを指定するように修正するとコンパイルまでは通るのですが、結局リンクに失敗します。
このエラー、正確には「C_INCLUDE_PATH」に「コロン(:)」が含まれていると失敗するようで、例えば以下のように「C_INCLUDE_PATH」が定義されていると失敗しません。
export C_INCLUDE_PATH=/usr/local/include
export C_INCLUDE_PATH=$C_INCLUDE_PATH:/usr/local/include
とはいえ、普段から環境変数に「C_INCLUDE_PATH」や「LD_LIBRARY_PATH」などを設定しておくのはよくない習慣とされていますので、最初から設定しておかないに限ります。
MySQL 5.5.xに限らず、同じような例はいくつかあるようなので、もし同じようなエラーが発生した場合は「C_INCLUDE_PATH」を疑ってみるといいかも知れません。
Xcode 4.3における xcodebuild コマンドのディレクトリパス設定
多忙なためなかなか更新できずにすみません。
メモ書き程度の内容ですが、Xcode 4.3から/Developer ディレクトリではなく
/Applications ディレクトリへインストールされるようになりました。
その関係から、 xcodebuild コマンドを実行する際にXcodeのディレクトリがないと言われてエラーになる場合があります。
なのでその場合はXcodeのディレクトリパスを再度指定しなおす必要があります。
これで xcodebuild が使えるようになります。
メモ書き程度の内容ですが、Xcode 4.3から/Developer ディレクトリではなく
/Applications ディレクトリへインストールされるようになりました。
その関係から、 xcodebuild コマンドを実行する際にXcodeのディレクトリがないと言われてエラーになる場合があります。
なのでその場合はXcodeのディレクトリパスを再度指定しなおす必要があります。
sudo xcode-select -switch /Applications/Xcode.app
これで xcodebuild が使えるようになります。
git-daemon (gitプロトコル)におけるcloneエラー
git-daemonをVPSサーバへ構築する際に少しハマったので
こちらへ紹介しておきます。
通常、Linuxでよくつかわれるアプリやライブラリのインストール先は /usr/local だと思うのですが、ソースファイルからインストールしたときなどに別の場所へインストールしたいという場合もあるかと思います。
この場合に注意しなければならないのが、
gitをコンパイルするときのzlibのバージョンです。
CentOS 5.7だとデフォルトのzlibのバージョンが1.2.3なのですが、このバージョンのzlibをコンパイル時にリンクすると、git-daemonコマンドを実行した際に「/lib/libz.so.1: no version information available」といった警告が発生します。
gitコマンドそのものはこの警告が発生しても動くのですが、git-daemonを動かしている際に、コンソールに余計な文字列が出力されるとgitプロトコルによるcloneに失敗するようで、クライアント側で「fatal: protocol error: bad line length character: git-」といったエラーメッセージが出力されてcloneに失敗します。
これを解決するには、サーバ側のgitをコンパイルする際にリンクするzlibのバージョンを1.2.5以降にする必要があります。具体的には、gitのコンパイル時のオプション指定で
このように1.2.5のzlibの場所を明示してあげれば、git-daemon実行時に警告が発生しなくなりますので、gitプロトコルによるcloneも問題なく成功するようになります。
サーバ側の.bashrcなどに余計なechoがあるとgit-daemonに失敗するというの話は聞いたことがありましたが、まさか警告が出ているだなんてなかなか気づきませんでした。(というのも、rootユーザでgit-daemonを実行した際は何も警告が発生せず、git-daemon用に作成したユーザで実行すると警告が発生していましたので、rootでインストール作業をすることが多いと中々気付けないですね)
サーバで試しにgit-daemonを動かす際も、
といったように、ユーザを明示してから実行してみた方がいいですね。(って、これが当たり前なのですが…)
こちらへ紹介しておきます。
通常、Linuxでよくつかわれるアプリやライブラリのインストール先は /usr/local だと思うのですが、ソースファイルからインストールしたときなどに別の場所へインストールしたいという場合もあるかと思います。
この場合に注意しなければならないのが、
gitをコンパイルするときのzlibのバージョンです。
CentOS 5.7だとデフォルトのzlibのバージョンが1.2.3なのですが、このバージョンのzlibをコンパイル時にリンクすると、git-daemonコマンドを実行した際に「/lib/libz.so.1: no version information available」といった警告が発生します。
gitコマンドそのものはこの警告が発生しても動くのですが、git-daemonを動かしている際に、コンソールに余計な文字列が出力されるとgitプロトコルによるcloneに失敗するようで、クライアント側で「fatal: protocol error: bad line length character: git-」といったエラーメッセージが出力されてcloneに失敗します。
これを解決するには、サーバ側のgitをコンパイルする際にリンクするzlibのバージョンを1.2.5以降にする必要があります。具体的には、gitのコンパイル時のオプション指定で
./configure --prefix=/opt/git/git-1.7.7 --with-zlib=/opt/zlib/zlib-1.2.5
このように1.2.5のzlibの場所を明示してあげれば、git-daemon実行時に警告が発生しなくなりますので、gitプロトコルによるcloneも問題なく成功するようになります。
サーバ側の.bashrcなどに余計なechoがあるとgit-daemonに失敗するというの話は聞いたことがありましたが、まさか警告が出ているだなんてなかなか気づきませんでした。(というのも、rootユーザでgit-daemonを実行した際は何も警告が発生せず、git-daemon用に作成したユーザで実行すると警告が発生していましたので、rootでインストール作業をすることが多いと中々気付けないですね)
サーバで試しにgit-daemonを動かす際も、
sudo -u gituser git daemon --export-all
といったように、ユーザを明示してから実行してみた方がいいですね。(って、これが当たり前なのですが…)
CoreDataをRDBのように利用する Vol.1
CocoaでiPhoneアプリやMacアプリ開発をしている方なら一度は耳にする単語であるCoreData。これは主にSQLiteをラップし、データとビューのつなぎ合わせを簡潔にすることを目的としたフレームワークライブラリです。(MVCでいうところのModelに当たる)。加えて、Xcodeにおいて標準でCoreDataのエンティティ(テーブル)の作成やリレーションシップの作成をGUI上で行えるようになっているため、一見すると使いやすい印象を受けます。
ところが、現実的にこのライブラリをiPhoneアプリ開発で利用する方はあまり多くないようです。何故利用されないのかといえば、CoreDataにRDBと同じ機能を求めて利用しようとする方が多いからだと考えられます。CoreDataは前述のとおり、MVCでいうところのModelに当たる機能を担うため、ビューやコントローラとも密接に関係するように作られています。そのため、WebでいうところのHibernateやiBATIS(MyBATIS)、S2DAOといったO/Rマッピングツールとは異なり、データ単体での操作を目的としたライブラリとは少々違うものなのです。
そうなってしまうために「CoreDataなんか使えない！」となり、普通のSQLiteに走る方が多くなりがちなのです。とはいえ、Objective-Cで作られたSQLiteのO/Rマッピングツールで優れたものはまだ世に出ていないのとも事実です。FMDBという簡易的なSQLiteのラッパーライブラリは存在しますが、こちらは結局JavaでいうところのJDBCっぽい組み方が要求されるため、インピーダンスミスマッチが起こりうる可能性を抱えていますし、何よりソースコードにSQL文を記述するという時点で、普段からO/Rマッピングツールを利用している方から見れば扱いにくさを感じることも多いでしょう。
そうなると、Objective-CベースのO/Rマッピングツールをつくるしかないのか？という話になるのですが、少し待ってください。CoreDataは本当に使えないのでしょうか？そもそも、何故CoreDataは使えないという話になっているのでしょうか。その問題点さえ解決できれば、CoreDataも使えるようになる可能性があるかも知れません。
以下にCoreDataが使えない・使いにくいと言われる理由と考えられるものを挙げてみました。
01. Xcode上から初期レコードをデータベースに挿入することができない
SQLiteのよいところの１つとして、DBがファイル１つで表されているところにあります。そのため、予めレコードを追加しておき、そのファイルをコピーして利用すれば初期レコードをわざわざプログラム内で追加する必要がなくなります。SQLiteを利用している以上、CoreDataもそれが出来ないのかとおもいきや、そのように初期レコードを入れておくような仕組みはサポートされていません。ですので、結局プログラム内で初期レコードは追加する必要があります
02. 主キーや外部キーの概念がない
前述のとおり、CoreDataが目的としていることは、MVCでいうところのModelに当たります。そして、01でも記述したとおり予めレコードを追加しておくことを想定しておらず、そのアプリ上に限定してデータのCRUDが行われていることを想定しています。そのため、空っぽのDBに対してアプリ上でデータのCRUDを行う分に関しては扱いやすいのです。リレーションシップをXcode上で作成したとおりに勝手に行ってくれるばかりか、その関連先のエンティティ(NSManagedObjectクラスのインスタンスで、通常は管理オブジェクトと呼ぶ)のインスタンスも勝手に作成してくれるため、その点では非常に便利と言えます。では逆に、初期レコードを予め追加しておきたい場合はどうなのか？というと、ここで大きな問題が発生します。何故なら、主キーと外部キーの概念がないため、データの対応付けを自分で行うことが非常に難解になるからです。RDBでいうところのテーブル同士のリレーションシップには主キーと外部キーが必要です。その概念がないCoreDataに対して、どのように予めリレーションシップの存在する初期レコードを挿入することが出来るのでしょうか。まさかソースコードに１つ１つ記述していくわけには行きませんので、これは大きな課題となります
03. 追加した順番にデータを取得することが非常に面倒
主キーと外部キーがないということは、データのソートが追加順にできないことも示しています。CoreDataはソート条件を指定しないで取得した場合、追加した順番通りには取得できません。追加した順番にデータを取得したい場面は多いですよね。CoreDataでこれを行う場合、エンティティの属性に予め priority のような値属性を設けておき、順番に番号を振っておき、これを元にソートする・・・といった手段が考えられますが、CoreDataには主キーと外部キーの概念がないのと同時に、自動採番の仕組みもありません。自動採番をプログラム上で行っても、アプリを再起動したらメモリ上の自動採番用のIDはまた 0 から開始になりますので、その点からも重複を考慮し出すとどうすればいいんだ！という感じになってしまいます。(日付を利用するという手段も考えられますが、日付というのはいくらでも変更が出来るため、順番を保証する要素としては些か弱いです)
04. SQLでは1行で書ける集約関数がCoreDataだと20行くらい書かないといけない
これはもう大きな解説をするまでもない事実として紹介しておきます。SQLでいう集約関数(SUMやCOUNTといったもの)をCoreDataで扱うには、なんとソース上で20行くらい書かないといけません。データ処理を簡潔にしてソース量を減らせるのがCoreDataの売りじゃなかったのか・・・と少々疑問に感じる部分です。CoreDataは何もSQLiteだけがデータ保存先となるわけではないので、それを考えればそんなものかと考えられる節もありますが、それにしてもこの差は大きいです。
他にもまだまだあるかも知れませんが、
大きな理由としては上記の 4 つが挙げられるかと思います。
上記の問題を解決できれば確かにRDBのような使い方は出来るかと思います。とはいえ、本当に解決するだけの価値があるのかどうかが問題になりますね。結局SQLiteを直接使ったほうがいいんじゃないの？っていう疑問も当然あるかと思います。では次に、CoreDataの良い点を挙げてみます。
01. 空っぽのデータベースに対してデータをCRUDするときにリレーションも考慮してインスタンスを作成してくれる
これは前述でも紹介しましたが、CoreDataの良い点の１つです。主キー外部キーの概念がないため、その部分は勝手につなぎあわせてくれるというところです。
02. マイグレーションが簡単
アプリの機能拡張によって、データベースのスキーマが変更されることは多々あります。これをSQLiteで行う場合、非常に大変です。CoreDataでは予めバージョンごとのモデルデータを用意しておくことで、これを自動化してくれます。しかもXcode上でマイグレーションの設定が行えるので、非常に簡単です。これはSQLiteにはない優れた点ですね。
03. Key-value形式でデータを更新することが可能であり、またデータの変更に応じてコールバックを通知することが出来る
CoreDataではデータをKey-value形式で管理しているため、カラムのインデックスからデータを取得する生のSQLiteに比べるとデータが扱いやすいです。また、予めデリゲート先を指定しておくことで、データの追加や変更をコールバックとして通知することも可能です。この点もCoreDataの利点であると言えます。
04. エンティティに親子関係を作れる
これは簡単にいえば、クラスにおけるスーパークラスとサブクラスの関係と同じです。スーパークラスにあたるエンティティを親とすることで、同じ親を持ったエンティティはその親の属性を保持することが出来ます。例えば全てのエンティティに日付を持たせたい場合、各々のエンティティに日付属性を作成しなくても、親となる日付属性をもったエンティティを１つ作成し、これを継承することで全てのエンティティに日付属性を持たすことが可能になります。
以上代表的と思われる良い点を 4 つ挙げてみました。他にも、Xcodeがエンティティのクラスを自動生成してくれるところなどもあるかと思います。
この悪い点と良い点、2つを合わせて考えてみると、CoreDataにも他にはあまりない魅力的な機能が多いことがわかります。特にマイグレーションが簡単な点は大きいですし、Cocoa標準でサポートされている機能だけあって、同じくCocoa標準であるコントローラへの連携がし易い特徴もあります。
そこで、この悪い点を解決することを考えてみると、その殆どが主キーと外部キーがないことに起因するものであることがわかります。これを解決できれば、RDBのような扱い方をしつつもCoreDataを使うことも可能になると考えられます。
というわけで、次回は実際にどのようにコーディングすることで今回紹介した悪い点を解決することが出来るのか、という点についてご紹介していきます。
ところが、現実的にこのライブラリをiPhoneアプリ開発で利用する方はあまり多くないようです。何故利用されないのかといえば、CoreDataにRDBと同じ機能を求めて利用しようとする方が多いからだと考えられます。CoreDataは前述のとおり、MVCでいうところのModelに当たる機能を担うため、ビューやコントローラとも密接に関係するように作られています。そのため、WebでいうところのHibernateやiBATIS(MyBATIS)、S2DAOといったO/Rマッピングツールとは異なり、データ単体での操作を目的としたライブラリとは少々違うものなのです。
そうなってしまうために「CoreDataなんか使えない！」となり、普通のSQLiteに走る方が多くなりがちなのです。とはいえ、Objective-Cで作られたSQLiteのO/Rマッピングツールで優れたものはまだ世に出ていないのとも事実です。FMDBという簡易的なSQLiteのラッパーライブラリは存在しますが、こちらは結局JavaでいうところのJDBCっぽい組み方が要求されるため、インピーダンスミスマッチが起こりうる可能性を抱えていますし、何よりソースコードにSQL文を記述するという時点で、普段からO/Rマッピングツールを利用している方から見れば扱いにくさを感じることも多いでしょう。
そうなると、Objective-CベースのO/Rマッピングツールをつくるしかないのか？という話になるのですが、少し待ってください。CoreDataは本当に使えないのでしょうか？そもそも、何故CoreDataは使えないという話になっているのでしょうか。その問題点さえ解決できれば、CoreDataも使えるようになる可能性があるかも知れません。
以下にCoreDataが使えない・使いにくいと言われる理由と考えられるものを挙げてみました。
01. Xcode上から初期レコードをデータベースに挿入することができない
SQLiteのよいところの１つとして、DBがファイル１つで表されているところにあります。そのため、予めレコードを追加しておき、そのファイルをコピーして利用すれば初期レコードをわざわざプログラム内で追加する必要がなくなります。SQLiteを利用している以上、CoreDataもそれが出来ないのかとおもいきや、そのように初期レコードを入れておくような仕組みはサポートされていません。ですので、結局プログラム内で初期レコードは追加する必要があります
02. 主キーや外部キーの概念がない
前述のとおり、CoreDataが目的としていることは、MVCでいうところのModelに当たります。そして、01でも記述したとおり予めレコードを追加しておくことを想定しておらず、そのアプリ上に限定してデータのCRUDが行われていることを想定しています。そのため、空っぽのDBに対してアプリ上でデータのCRUDを行う分に関しては扱いやすいのです。リレーションシップをXcode上で作成したとおりに勝手に行ってくれるばかりか、その関連先のエンティティ(NSManagedObjectクラスのインスタンスで、通常は管理オブジェクトと呼ぶ)のインスタンスも勝手に作成してくれるため、その点では非常に便利と言えます。では逆に、初期レコードを予め追加しておきたい場合はどうなのか？というと、ここで大きな問題が発生します。何故なら、主キーと外部キーの概念がないため、データの対応付けを自分で行うことが非常に難解になるからです。RDBでいうところのテーブル同士のリレーションシップには主キーと外部キーが必要です。その概念がないCoreDataに対して、どのように予めリレーションシップの存在する初期レコードを挿入することが出来るのでしょうか。まさかソースコードに１つ１つ記述していくわけには行きませんので、これは大きな課題となります
03. 追加した順番にデータを取得することが非常に面倒
主キーと外部キーがないということは、データのソートが追加順にできないことも示しています。CoreDataはソート条件を指定しないで取得した場合、追加した順番通りには取得できません。追加した順番にデータを取得したい場面は多いですよね。CoreDataでこれを行う場合、エンティティの属性に予め priority のような値属性を設けておき、順番に番号を振っておき、これを元にソートする・・・といった手段が考えられますが、CoreDataには主キーと外部キーの概念がないのと同時に、自動採番の仕組みもありません。自動採番をプログラム上で行っても、アプリを再起動したらメモリ上の自動採番用のIDはまた 0 から開始になりますので、その点からも重複を考慮し出すとどうすればいいんだ！という感じになってしまいます。(日付を利用するという手段も考えられますが、日付というのはいくらでも変更が出来るため、順番を保証する要素としては些か弱いです)
04. SQLでは1行で書ける集約関数がCoreDataだと20行くらい書かないといけない
これはもう大きな解説をするまでもない事実として紹介しておきます。SQLでいう集約関数(SUMやCOUNTといったもの)をCoreDataで扱うには、なんとソース上で20行くらい書かないといけません。データ処理を簡潔にしてソース量を減らせるのがCoreDataの売りじゃなかったのか・・・と少々疑問に感じる部分です。CoreDataは何もSQLiteだけがデータ保存先となるわけではないので、それを考えればそんなものかと考えられる節もありますが、それにしてもこの差は大きいです。
他にもまだまだあるかも知れませんが、
大きな理由としては上記の 4 つが挙げられるかと思います。
上記の問題を解決できれば確かにRDBのような使い方は出来るかと思います。とはいえ、本当に解決するだけの価値があるのかどうかが問題になりますね。結局SQLiteを直接使ったほうがいいんじゃないの？っていう疑問も当然あるかと思います。では次に、CoreDataの良い点を挙げてみます。
01. 空っぽのデータベースに対してデータをCRUDするときにリレーションも考慮してインスタンスを作成してくれる
これは前述でも紹介しましたが、CoreDataの良い点の１つです。主キー外部キーの概念がないため、その部分は勝手につなぎあわせてくれるというところです。
02. マイグレーションが簡単
アプリの機能拡張によって、データベースのスキーマが変更されることは多々あります。これをSQLiteで行う場合、非常に大変です。CoreDataでは予めバージョンごとのモデルデータを用意しておくことで、これを自動化してくれます。しかもXcode上でマイグレーションの設定が行えるので、非常に簡単です。これはSQLiteにはない優れた点ですね。
03. Key-value形式でデータを更新することが可能であり、またデータの変更に応じてコールバックを通知することが出来る
CoreDataではデータをKey-value形式で管理しているため、カラムのインデックスからデータを取得する生のSQLiteに比べるとデータが扱いやすいです。また、予めデリゲート先を指定しておくことで、データの追加や変更をコールバックとして通知することも可能です。この点もCoreDataの利点であると言えます。
04. エンティティに親子関係を作れる
これは簡単にいえば、クラスにおけるスーパークラスとサブクラスの関係と同じです。スーパークラスにあたるエンティティを親とすることで、同じ親を持ったエンティティはその親の属性を保持することが出来ます。例えば全てのエンティティに日付を持たせたい場合、各々のエンティティに日付属性を作成しなくても、親となる日付属性をもったエンティティを１つ作成し、これを継承することで全てのエンティティに日付属性を持たすことが可能になります。
以上代表的と思われる良い点を 4 つ挙げてみました。他にも、Xcodeがエンティティのクラスを自動生成してくれるところなどもあるかと思います。
この悪い点と良い点、2つを合わせて考えてみると、CoreDataにも他にはあまりない魅力的な機能が多いことがわかります。特にマイグレーションが簡単な点は大きいですし、Cocoa標準でサポートされている機能だけあって、同じくCocoa標準であるコントローラへの連携がし易い特徴もあります。
そこで、この悪い点を解決することを考えてみると、その殆どが主キーと外部キーがないことに起因するものであることがわかります。これを解決できれば、RDBのような扱い方をしつつもCoreDataを使うことも可能になると考えられます。
というわけで、次回は実際にどのようにコーディングすることで今回紹介した悪い点を解決することが出来るのか、という点についてご紹介していきます。
iOS用メールライブラリを公開しました
iPhoneアプリにおけるメーラアプリは、実はあまり多くありません。(標準メーラと連携するアプリが殆どです)
これには多少なりとも理由がありまして、その１つにメール機能をサポートするiOS用ライブラリが殆ど世の中に出ていないという理由があります。有名なところでは「MailCore」というライブラリがありますが、こちらは2009年で開発がストップしているのと、日本語には全く対応していないため日本人には利用できません。
→GitHubで現在も開発が続いているようです。こちらは日本語も可能なようですが、独特の使いにくさは残ったままのようです
その他の理由としては、そもそも標準メーラで満足な人が多いことや、海外ではデコメの文化もないため、あまりこのあたりを気合入れて作っている人がいないという理由もあります。
このような背景があるため、iOSでSMTPやIMAPなどを実装することは非常に難しくなっています。
とはいえ、日本においてフィーチャーフォンユーザがスマートフォンに流れてくることを考えると、デコメールの利用者も流れてくることは間違いありません。そうなると、今後標準にはないデコメ機能をサポートしたメーラの需要というのはそこそこ増えるのではと考えられます。
JavaにはJavaMailという便利なライブラリがあります。
これはメール送信・受信やMIMEパートの構築などのほとんどの機能をサポートしており、非常に高機能です。iOSでもこれが使えればな・・・と思って、今回作成したのが「FrontierMail」というライブラリです。
[FrontierMail]
https://github.com/k-kou/FrontierMail
ベースは libEtPan というライブラリを使っており、これをObjective-Cでラップして、更にJavaMailよりも簡単に利用できるように設計してあります。
まだSMTP機能とMIMEパート構築しかサポートしていないため、詳細な利用方法は上記githubにアップロードしてあるOCUnitのテストコードや、APIドキュメントを参考にしてみてください。
これには多少なりとも理由がありまして、その１つにメール機能をサポートするiOS用ライブラリが殆ど世の中に出ていないという理由があります。有名なところでは「MailCore」というライブラリがありますが、
→GitHubで現在も開発が続いているようです。こちらは日本語も可能なようですが、独特の使いにくさは残ったままのようです
その他の理由としては、そもそも標準メーラで満足な人が多いことや、海外ではデコメの文化もないため、あまりこのあたりを気合入れて作っている人がいないという理由もあります。
このような背景があるため、iOSでSMTPやIMAPなどを実装することは非常に難しくなっています。
とはいえ、日本においてフィーチャーフォンユーザがスマートフォンに流れてくることを考えると、デコメールの利用者も流れてくることは間違いありません。そうなると、今後標準にはないデコメ機能をサポートしたメーラの需要というのはそこそこ増えるのではと考えられます。
JavaにはJavaMailという便利なライブラリがあります。
これはメール送信・受信やMIMEパートの構築などのほとんどの機能をサポートしており、非常に高機能です。iOSでもこれが使えればな・・・と思って、今回作成したのが「FrontierMail」というライブラリです。
[FrontierMail]
https://github.com/k-kou/FrontierMail
ベースは libEtPan というライブラリを使っており、これをObjective-Cでラップして、更にJavaMailよりも簡単に利用できるように設計してあります。
まだSMTP機能とMIMEパート構築しかサポートしていないため、詳細な利用方法は上記githubにアップロードしてあるOCUnitのテストコードや、APIドキュメントを参考にしてみてください。
- Powered By FC2ブログ
- ＱＲコード
