|誰かがもう本に書いてしまっていそうな内容ですが、気にしない。cocos2dのprojectをSenTestingKitを使った自動テストに掛けた場合、テスト以前の想定外のエラー等が発生するケースがあります。それらのケース全てに対応できるかどうかは不明ですが、ある程度のカバーは可能になるであろうと思われる手順を以下に。bundle」を指定するわけですが、これだけでは正常にテストできません。Sources」にcocos2dのライブラリ(.mと.c)を一通りと、開発しているアプリのソース(.m)を一通り追加します。Flags」に「-lz」と入れます。Libraries」に以下を追加します。(開発しているアプリの同じ構成+SenTestingKit)AudioToolBox.frameworkAVFoundation.frameworkQuartzCore.frameworkOpenAL.frameworkOpenGLES.frameworkCoreGraphics.frameworkSenTestingKit.frameworkUIKit.frameworkFoundation.framework基本は、開発しているTargetと同じ構成にします。Test時にGL_VENDOR等がnullにならないようにするtest時にwindowを生成していないことが原因です。tearDown];}@endテスト用に上記のような内容のベースクラスをはさんでしまうのも手です。これで、テスト自体はコケることなく実行されるようになります。Targetでも問題なく動くように修正するCCSpriteなどを使ったファイルにて、CCTextureCacheにイメージを追加しようとして失敗するケースがあります。BundleのパスがアプリとUnitTestで異なることをcocos2d側では考慮されていない為です。inDirectory:imageDirectory];}これでCCTextureCacheで問題が発生することはなくなります。|サンプルのCoreDataBooksを弄くり通して移植とか試みた結果、どこがどうなってるのかようやく把握できた感じなのでメモ。そもそも何故分かりづらいのかCoreDataはSQliteをObjective-Cのみで操作できることにメリットがあるわけですが、その操作を行うためのクラス名、取り扱い方に問題があります。イメージしずらいネーミング各クラスの解説を読むと判明しますが、実際には他の言語で使われているDBとの接続を行うための各種クラスと、CoreData関連クラスがやってることには、あまり違いはありません。それらのクラスと余りに剥離したネーミングというのが一つ。複数のDBの接続を同時に取り扱っているもう一つは、あくまでCoreDataは「複数のDBとそれらDBとの接続情報」をひとまとめにした代物であるため、他の言語でのDBと同じ感覚で取り扱うとズレが生じるということ。TableView専用というわけではないNSFetchedResultsControllerさらにもう一つ、NSFetchedResultsController自体はCoreDataから取得したデータの配列をキャッシュしているコントローラであり、別にUITableViewController専用のオブジェクトではない、ということ。CoreDataのコンテキスト構成コンテキスト以下の構成図を貼ってみます。NSManagedObjectModel他の言語での、DBのColumnとRelationShip指定に相当。NSPersisitentStore実DBとの接続を担当。ColumnもといEntityを追加したい場合にはNSManagedObjectModelへの操作、接続するDBを増やしたい場合にはNSPersistentStoreを追加するといった形です。NSPersistantStore追加の際の実DBファイル接続するDBを増やす場合にはNSPersistentStoreを追加するわけですが、実体のファイルもその際に自動で生成されています。データ追加NSEntityDescriptionで追加先のEntityを指定すると生成されるオブジェクト(レコード相当)に値を入れて保存、という流れです。DBへのレコード追加をSQLを直接触れずに行う形です。データの読み込みNSFetchedResultsControllerを生成した時点で、データの取得ができ上がるため、あとは取得したデータの配列からインデックスを指定して取得という流れ。まとめNSManagedObjectContextを構成する際の煩雑さも原因だと思うので、NSManagedObjectContextまでの生成過程を一つのクラスにして分離したほうが、なにかと分かりやすいかと思います。CoreDataManagerあと、これらを一つ一つ確かめていくとどこかで同じ構成をみたような感覚があったのですが、PerlにおけるDBIx::Classがそれでした。今日のCPANモジュールを読むと分かりやすいと思います。|perlのMVCフレームワークCatalyst用モジュールとして、Catalyst::View::APNSを書いてみました。githubに上げてます。作成完了したらCPANに申請の予定。Catalyst::View::APNS掲示板とかでメールによる通知とかもありますが、Pushで通知とかもあってもよさそうなものです。Catalystに触れる事が多くなったので、せめてCatalystだけでもそれをお手軽にしたいと思いました。CPAN申請が完了したら改めて書く事にします。|現行の最新Xcodeは、ソースコードの静的解析を行うClangがメニューから実行できるようになっています。設定実行する手間が省けて助かる事間違い無しなんですが、毎回clangのために余計な操作をするのは本当面倒です。知られていませんが、このClangも自動で実行できるようになっています。デフォルトで実行がONになっていれば良いとは思うんですが、多分それだと初学者の壁が只管高くなるとかそんな具合だと思います。設定方法Xcodeのメニューから、「プロジェクト->プロジェクト設定を編集」の順に選択します。ビルドオプションの「静的アナライザを実行」にチェックをいれます。|Macでのデータベース取り扱いが楽になるというCoreDataですが、確かにMac用アプリでは開発が楽になるようです。いうのも、iPhoneでは色々とコーディングが要求されてしまうから。結果、はまってしまうところがでて、それが解消されにくい場合は、思い切ってFMDBで行うほうが幸せかもしれません。試行錯誤しつつ組み込みに挑戦していますが、エラーが完全には解消されず詰まっている状態です。現状に至るまでに分かったいくつかのはまりポイントについてまとめてみます。entity...xcdatamodel内でEntityの名称が間違っている場合や、NSEntityDescriptionを生成する以前にNSPersistentStoreCoordinatorなどを適切に生成していない、など。Z_PKなどの、頭にZが付くコラムが足りないと表示されるsqliteファイルを手動作成した場合、CoreDataに用いるsqliteのテーブルおよびコラム名は、イニシャルがZで始まる必要があります。(NameならZNameになる、など)また、CoreDataが用いる専用のテーブルを作成する必要もあります。BLOB);Entityを収めたテーブルにも、システムが管理に用いるためのコラムの追加が必要です。Leopard...。