Swiftの動向とアツさを追う try! Swift参加レポート

try! Swift 2日目 参加レポート

この記事を読むのに必要な時間:およそ 5 分

Daniel Eggertさん「モダンCoraData」

objc.ioの共同設立者の一人でもあるDaniel Eggertさん@danielboedewadtは,Core DataのAPIをベースにSwiftに置き換えていく方法を紹介しました。DanielさんはAppleでPhotos.appとCamera.appをCore Dataに関する仕事をしていたこともあるそうです。また,objc · Core Dataも執筆しています。

画像

以下の方法で置き換えていきました。

1. Insert New Object

従来だとエンティティ名をStringで指定していたので型安全ではありませんでした。まずProtocol Extensionでエンティティ名を切り出しました。インサート処理の際に切り出したメソッド名を呼ぶようにすることでコンパイルでチェックできるようになります。

2. Key Value Coding

従来の方法だとキーの値をタイプミスしやすく型安全ではありませんでした。型制約付きのProtocol Extensionを利用し,キーの値にEnumを用いることで,型安全に指定できるように改善できました。

3. Fetch Request

Fetch RequestはSortDescriptorをProtocolに切り出し,Protocol ExtensionでSortDescriptor処理を実装することでシンプルに改善できました。Predicateを使用する場合も同様です。

4. ValueTransformer

Protocol ExtensionにA→Bの変換,B→Aの逆変換をそれぞれ実装し,typealiasで宣言しておくことで様々な型に適用できるようにしました。

5. NSNotification

ClosureでDelete,Updateなどを処理できるように修正しました。NSManagedObjectContextにProtocol Extensionで通知を確認し,Closureで返すヘルパーを実装し,DidChangeNotificationをラップすることでシンプルな書き方に改善していました。

画像

既存APIのスピリットを尊重する

上記のようにProtocolとProtocol Extensionを駆使して既存APIをベースにSwiftコードに置き換えていました。これにより,既存APIのスピリットを尊重しつつ,Swiftの書き方で活かすことができると話していました。

画像

Novall Khanさん「SwiftコンパイラとLLDBの連携」

SplitwiseでiOSエンジニアをされているNovall Khanさん@novallkhanさんは,デバッグコンソールを使ったテクニックを紹介しました。

画像

LLDBについて

LLDBのデバッグコマンドを知ることで,エラーをより早く見つけられるようになるそうです。

LLDBはObjective-Cの場合はClang,Swiftの場合はSwift compilerの2つのコンパイラを持っています。コンパイラが内蔵されているため,デバッグコンソールに打ち込んだコードは実行中のアプリケーションで呼び出すこともできます。また,モジュール(UIApplication)にもアクセスできます。

Swiftのエラーハンドリング

LLDBはSwiftのエラーハンドリングに対応しており,該当箇所でブレークした後,LLDBのコマンドで「expression」を使用すればthrowされるエラーの結果を見ることができます。

また,エラーを起こしたコードを見る際に「breakpoint set -E swift」とすればエラー発生時にブレークされるようになります。特定のエラーの場合は「-O EnumError」と指定すればよいそうです。

画像

CustomStringConvertible

また,ネストされたデータ構造をデバッグ出力するときに,出力結果を見やすくする方法を説明しました。CustomStringConvertibleを実装することで,出力されるデータ構造を見やすくなるとのことです。

Jeff Huiさん「ライブラリの開発」

RSpecライクなSwiftのテストライブラリのQuick/NimbleのコアチームメンバーであるJeff Huiさん@jeffhuiは,Swiftのライブラリの開発についてセッションを行いました。

画像

テスト(CI)について

一定のレベルを保証したいのでテストは必ず組み込むようにしているそうです。テスト(CI)についてはオープンソースであればTravis CIが有効な選択肢で,.travis.ymlファイルだけで設定が完了するのでオススメとのことです。テストスクリプトもプラットフォームごとに同じことを書けば良いとのことでした。

画像

実際にライブラリを例に作業手順を説明しました。

パッケージマネージャへの対応

その際,以下の3つへの導入を考慮すべきとことでした。

CocoaPods
  • 依存性のあるライブラリを含めて自動でライブラリ化してくれる
  • PodSpecファイルの作成が必要
Carthage
  • プロジェクトに直接インクルードする場合
  • Cartファイルの設定が必要
Swift Package Manager
  • 唯一Linuxでの配布サポート
  • 対応作業が他の2つのパッケージマネージャより多い

画像

Swift Package Managerの注意点として,SwiftLinux自体が安定していないことを挙げていました。新しいバージョンが毎週出るほど問題があるそうです。そのため,SwiftEnvという環境ツールを使って指定のスナップショットからインストールしなければならないと話していました。

リリースの際のバージョニング

セマンティックバージョンの付け方についても言及がありました。詳しくはsemver.orgを参考にしてくださいとのことです。

著者プロフィール

田中孝明(たなかたかあき)

岡山県岡山市出身。愛知県>福岡県と様々な地で開発業務に従事。電子制御機器のプログラミングでC言語に触れてから,C++,Java,PHP等を経験。iPhoneアプリ開発に触れてからはObjective-Cを学び,2015年にクラスメソッドにジョインしてからはSwiftでのiPhoneアプリ開発に従事。

Twitter:@kongmingtrap

コメント

コメントの記入