update.<この記事は自社のブログにも転載しました>少し歩くと汗ばんで、春の陽気を感じます。こんにちはyimajoです。クックパッドさんが月イチで行っている第6回potatotips(ポテトチップス)という開発Tips共有会が開かれたので参加させてもらい、『やはりお前らのCoreDataの使い方も間違っている』というタイトルで発表させてもらいました。今回が3回目の発表&参加だったので、過去自分が発表したものもリンクしておきます。お前らのiOS7対応は間違っている今回の開催場所はUIEvolution株式会社さんということで、あまりメディアで公開されてない社内を少しだけ体験することも出来ました。(写真は海外の出会い系iOSアプリに使われたライブラリの説明を聴いてるところ)ちなみに写真右側がバーのテーブルのようになっていて、そこで発表をしている雰囲気が伝わるでしょうか。左側が執務室となっており、残業の雰囲気をわずかに感じながらの発表となりました。本題、お前らがCoreDataを使う上で何を間違っているか自分が発表した内容はCoreDataに関する次の3つのものです。AppDelegateでNSManagedObjectContextを生成しているCoreDataでのデータの取得は全てNSFetchedResultsControllerを必要があるわけではないNSManagedObjectのサブクラスを自動生成しているのに、データのアクセスにsetValue:forKeyを使ってしまっている順に説明していきますAppDelegateでNSManagedObjectContext生成して保持しないことAppleのXcodeテンプレートから生成されるCoreDataのコードでは、AppDelegateからNSManagedObjectContextを生成して保持してしまっていますが、AppDelegateの役割はiOSから受け取る処理を行うものであって、データの永続化のためにNSManagedObjectContextを生成したりするのは役割として間違っています。Data」にチェックボックスを入れた場合に生成されるテンプレートは次のようなコードです。_persistentStoreCoordinator;}これをAppDelegateがやるべきことなの?ってことです。CoreDataでのデータの取得は全てNSFetchedResultsControllerを必要があるわけではないUITableViewを使い、保存されている1つのデータをそのまま1つのcellに表示するような使い方ならNSFetchedResultsControllerはとても適していると思いますし、グルーピングを行うのであればsection毎にデータを分けられるのでindexPathでそのままデータにアクセスも出来ます。section用の属性は動的に作成もできるので便利です。参考:NSFetchedResultsControllerで日付毎にセクションをまとめる方法http://qiita.com/takayama/items/aa3a7acd2f40ffb93dfbただ、全てのデータ取得にNSFetchedResultsControllerを使う必要はなくて、例えば取得したいデータが特定のひとつなどであればNSFetchRequestで充分だったりします。NSManagedObjectのサブクラスを自動生成しているのに、データのアクセスにsetValue:forKeyを使ってしまっているNSManagedObjectのサブクラスを自動生成しているのであれば、そのサブクラスのプロパティを使えばデータのセットはドット構文でアクセスするだけなのに、わざわざNSMangedObject#setValue:<#オブジェクト#>forKey:<#キー名#>を使ってKeyValue形式でデータにアクセスしてしまっている例もよく見かけます。これもXcodeが生成するテンプレートが正しいと思ってしまうせいではないかと思います。@"hoge";Xcodeが生成しているテンプレートのコードではNSManagedObjectのサブクラスを自動生成していないので、前者のようにせざるを得ないのであって、自動生成していればこんな抽象化はほとんど意味をなさないですしリファクタリングする際にも効率が落ちます。まとめXcodeのコードテンプレートはそれ自体がベストプラクティスなわけではないし、たいていの場合によってはとても余分なやり方になりますのでテンプレートからプロジェクトを作っていくのは辞めたほうがいいです。私が発表させてもらった内容もプロダクトの性質やプロジェクトメンバーの経験に依存したり、期間に依存する話だったりとケースバイケースであり、決められた開発期間内でまずは動くプロダクトを作ることというものが絶対的に優先順位が高いということは言うまでもありません。いい方法があるとか、いや実はテンプレート通りに作ることのメリットが大きいんだよという事があればコメントを書いてもらうのも良いですが、yimajoが変なことを言ってるのを止めるためにpotatotipsに参加してみるかというきっかけになるのかもしれません。おわりに(写真は順番待ちしてるときにクックパッド社のgfxさんを撮ったもの)写真で伝えることは出来ませんが、UIEvolution社は組み込み機器での開発も行っているようで、執務室の中には所かしこにカーナビなどの機器があり、ソフトウェア専業の会社にはない雰囲気がありました。私が新卒で入った会社は半導体メーカーだったので、そういうのがとても懐かしく思えました。次のpotatotips#6はDeNA社が開催場所になるそうです。このような勉強家に参加していて気づいた事としては、こういう会を開催場所としてもらえる会社がエンジニア募集をする場合は業務内容だけではなく現在の課題を話してくれると参加者もツッコめるのではないかなと思います。表面上の業務内容にもし興味がなくても課題を解決できなくないかな、という面からもっと話を聞きたくなりますし、自分が働くときのイメージもできるのではないかと思います。発表会後、iOSアプリエンジニアだったら誰でも知っている「iPhoneプログラミングUIKit詳解リファレンス」という本を書かれた@tokoromさんにサインを頂きました。UIKitについて書かれたかなり詳しい本で、iPhoneアプリ開発の現場では机の上に最もよく見かけた本です。リファレンスとしてあの部品の使い方ってどうやるんだろうという時に役に立ちました。requestStockLike123@yimajo株式会社キュリオシティソフトウェアの代表です。iOSアプリを作っています。最近はRxSwift研究読本書いてます。upLoginユーザーは見つかりませんでした。