寄付窓口はこちら

try! Swift モダンCore Data #tryswiftconf Day2-6

Daniel Eggert

写真を愛し、ベルリンに住んでいます。objc.ioの共同設立者の一人です。10年以上、Cocoaに関係する全て(主に写真や画像処理)に関わって仕事をしています。5年間Appleで働き、Photos.appとCamera.appをCore Dataに移行する仕事をしました。

twitter.com

Swiftを使い、古いObjective-CAPIに新たな命を吹き込みます。

f:id:niwatako:20160303142655j:plain

コアデータそのものの話ではないです。既存APIを近代的Swiftコードで使う。

既存APISwiftの用に楽しくしていきたい

ローランのセッション、読めるコードを書こうというのを覚えていますか

読みやすいコード、エラーしにくいコードを作りたいと思います。

ProtocolとProtocol Extensionを使います

CoreDataは12年の歴史がありObjective-Cで作られダイナミックでタイプセーフでないので良い題材。

f:id:niwatako:20160303143147j:plain

昨年書きました f:id:niwatako:20160303143207j:plain

既存APIのスピリットを維持したい。 f:id:niwatako:20160303143232j:plain

簡単に使えるようにしたい。

エンてティとクラスがカップリングされています f:id:niwatako:20160303143253j:plain

エンティティとクラスは1対1でマッピングされます。ObjCの歴史もあってコードが変に見えます こうなりますよね

f:id:niwatako:20160303143331j:plain

  • 長い
  • Stringになっててコンパイラが働かない
  • !になってる(←??)

f:id:niwatako:20160303143407j:plain f:id:niwatako:20160303143414j:plain f:id:niwatako:20160303143427j:plain f:id:niwatako:20160303143438j:plain

CityエンティティとCityClassをひも付けました

f:id:niwatako:20160303143500j:plain f:id:niwatako:20160303143508j:plain タイプキャストも出来て一箇所にまとまった f:id:niwatako:20160303143523j:plain シンプルに

KVO

f:id:niwatako:20160303143534j:plain f:id:niwatako:20160303143547j:plain タイプミスをしやすい、タイプセーフでない、そこがよくない。

従来のやり方 f:id:niwatako:20160303143613j:plain ポイントとしては引数を渡すとストリングになってこう使う f:id:niwatako:20160303143630j:plain コンパイラが使えない。それがクラッシュになる。

こんなにKeyをつかう f:id:niwatako:20160303143651j:plain

改善しましょう

f:id:niwatako:20160303143721j:plain コンパイラチェック出来ます f:id:niwatako:20160303143738j:plain f:id:niwatako:20160303143747j:plain ネスト化されたタイプでKeyはCityに属している。

プロトコルを活用 f:id:niwatako:20160303143812j:plain StringではなくKeyをとっていて f:id:niwatako:20160303143839j:plain コンパイラがチェックしてくれる

Fetchリクエストを良くする f:id:niwatako:20160303143900j:plainf:id:niwatako:20160303143904j:plain

こうできたらよい f:id:niwatako:20160303143916j:plain

同じプロトコルf:id:niwatako:20160303143934j:plain ロジカルなオーダリングクラスをうまくつなげていける f:id:niwatako:20160303143959j:plain Fetchがよくなる f:id:niwatako:20160303144007j:plain 1行になった f:id:niwatako:20160303144020j:plain とてもクリーンで読みやすい

f:id:niwatako:20160303144036j:plain Predicateを使うが f:id:niwatako:20160303144054j:plain これも改善 f:id:niwatako:20160303144104j:plain

f:id:niwatako:20160303144123j:plain ValueTransformerについて

f:id:niwatako:20160303144139j:plain f:id:niwatako:20160303144148j:plain サブクラスも必要でSwiftらしくない

f:id:niwatako:20160303144206j:plain StringをUUIDに変えていきたい

そのままでもそんなに悪くないが f:id:niwatako:20160303144221j:plain まだ改善の余地はある f:id:niwatako:20160303144237j:plain どのタイプに変えるかは伝えていない、推論される。

2つのスライドで解説します f:id:niwatako:20160303144314j:plain f:id:niwatako:20160303144340j:plain f:id:niwatako:20160303144343j:plain

とてもSwifty!

f:id:niwatako:20160303144406j:plain f:id:niwatako:20160303144418j:plain

Blockはここ5,6年、使いやすくなったのはSwiftでてからですね Saveを見てみます f:id:niwatako:20160303144439j:plain

シンプルだがもっと改善 f:id:niwatako:20160303144459j:plain チェンジを一つのブロックにラッピング。変更書けたところが見える。読みやすい。

f:id:niwatako:20160303144524j:plain

UIApplicaitonAPIにはいろいろ簡素化してくれるものがあると思います、小さなラッパでも多くの機能を提供します。

f:id:niwatako:20160303144605j:plain

f:id:niwatako:20160303144613j:plain

DidChangeでリアクティブアプローチが可能になる。変更で、誰が何故変えたのか、通知が行われます。コードとUIのアップデートがタイアップされてる

こんな形でやっていましたね。実装する度出てきました。 f:id:niwatako:20160303144659j:plain

これも簡単に f:id:niwatako:20160303144720j:plain 読みやすいですよね。Cityが変更された時にNameラベルを変更します。

実装方法ですが、大枠の局面から見ていきます。このヘルパで通知を確認します。 f:id:niwatako:20160303144811j:plain

最後の行原っぱを使うということを示す。これでタイプセーフになっている。 f:id:niwatako:20160303144840j:plain

ラップをするというノーティフィケーションのみ。

コードが突然こういうものを使い始めてSwift的に使いやすくなっていく。

幾つか例を示しました。

まとめ

f:id:niwatako:20160303144939j:plain

小さなヘルパーになるが人生がもっと楽になる。あなただけではなくリーダーも皆さんが楽になる。

古いAPIは確認済みなので使うことは良いこと。バグがない。でも改善してより生きやすくなる。 f:id:niwatako:20160303145027j:plain

実装時の精神を大切にしたい。私たちが作ったものをコードとして読みやすいものにしていく。

f:id:niwatako:20160303145056j:plain

QA

CoreData、Swiftについて質問があったらQAルームへどうぞ。クリスの質問はもう受けない(・ω<)

クリスさん)実験的に私もやったがCoreDataについてあまり知らないから、SwiftライクだがCoreDataを失うことにならないか?

Swiftのスラックに入れるが、CoreDataは多くのキャッシングをします。パフォーマンスのメリットが有る。アプリが大きい時にはやらないほうがいい、パフォーマンスが悪くなる。

既存APIを魅せて頂いたところで、タイプミスではないですか?

f:id:niwatako:20160303145354j:plain

existing ですね、exittingはダメですね。既存APIがなくなることはないですね。CoreDataのコード自体は何千ものiOSのアプリ、Macアプリにも使われています。なのでこれに関してバグフィックスが累積していて安定している。Appleが何かしていまのCoreDataに到達するなら2028年ぐらいでは??

新たに作るなら他のソリューションもあるのでJobに適切なものを選ぶのが良いでしょう。

気に入った記事は はてなブックマーク

はてなブックマークアプリiOS開発チームから来ました! はてなブックマークにはSwift特集があります! 良い記事を見逃さないように、ご利用ください! http://b.hatena.ne.jp/hotentry/it/Swift

そして良いまとめ記事があったらはてなブックマークでブックマークしましょう! try! Swift の記事で盛り上がると嬉しいです!