こんにちは。 ベガコーポレーションの主計（カズエ）です。
9月15日（金）から9月17日（日）に早稲田大学理工学部西早稲田キャンパスで開催された iOSDC JAPAN 2017 に参加してきましたので、見てきたセッション等の中から特に印象に残ったものについてレポートを書いていきたいと思います。
スポンサー紹介
オープニングでスポンサー紹介があったのですが、何処かで聞いたことのある声が、、、
そっくりさんかと思ったらミサトさんだった #iosdc pic.twitter.com/0Seb0FzAEf
— ぎぎにゃん (@giginet) 2017年9月16日
スポンサー紹介聞き流すことが多いかと思いますが、
今回はみなさん、食い入るようにみていて、twitterのタイムラインがすごい勢いで流れました。
スポンサー企業にとっても嬉しいはずなのですごい良い取り組みだと感じました。
Swaggerで始めるAPI定義管理とコードジェネレート
speakerdeck.com
Swagger Codegen を使うことでクライアントを自動生成してくれるのは便利そうでした。
CocoaPodsのライブラリとして出力したりRxSwiftとの連携も可能だったりと結構実用的そうです。
設計とコードの乖離防止はクライアントとサーバー双方のエンジニアの不要なコミュニケーションを発生させたりするのでSwagger等のツールを使い齟齬を発生させない仕組みが大事であることを再認識しました。
節子、それViewControllerやない…、FatViewControllerや…。
ViewControllerはいろんな処理を書きやすいためつい、節子になりそうですがUIの処理とビジネスロジックが混ざってしまうとテストがしづらくなってしまいます。
UIKitをimportしないPresenterを作り責務を分けることでテストしやすくなります。
設計に関してはメリットデメリットがあるのでなかなか選定が難しいですが、責務を分離しテストしやすくすることに関しては実装コストを上昇することを防ぐためにも必ずやっていきたいです。 dev.classmethod.jp
具体例とクイズで学ぶ、Swiftの4種類のエラーの使い分け
Swiftのエラーには
- Simple domain errors
- Recoverable errors
- Universal errors
- Logic failures
があり、どのようにエラーハンドリングしたいかで利用するエラーを決めることが大事とのことです。発表の後半はクイズ形式であったため、参加者が考える機会がありとてもいいなと思いました。
@koherさんはQiitaでもSwiftのエラーについて記事にされていますので下記も一緒に読んでみるといいかと思います。
qiita.com
qiita.com
Build high performance and maintainable UI library
UIのテストは困難であるが、
- データの流れを１方向にする
- 状態をモデルに分離する
- 振る舞いをモックに置き換える
などを実践することでテストが可能であることをわかりやすく解説されて参考になりました。
発表された内容はブログにもまとめられていますので、こちらもチェックしてみてください。 blog.kishikawakatsumi.com
RxSwiftのObservableとは何か
Observerパターンの解説からRxSwiftの実装を紐解いていくかたちでの丁寧な発表で、
各Observableの違いをとても理解しやすかったです。
発表原稿をQiitaにアップされているので合わせて読むと良いと思います。
qiita.com
ディープリンクの設計と実装
speakerdeck.com
WebがRESTfullなURLであれば基本的にそれにあわせてアプリのURL設計をしていけばよいとのことです。
ただ、UITabBarControllerやUINavigationControllerの階層など考慮すべきことも多いのでをしっかりと検証しないとUXを低下させてしまいそうなので気をつける必要がありそうです。
新しい画像フォーマットHEIFを用いたiOSアプリの通信量削減
speakerdeck.com
現在はWebPで配信しているがiOS11からHEIFに対応したので検証したところ約50%通信量削減に成功。
問題点は特許の関係からiPhoneを爆買い（48台程度）する必要がある（笑）
Qiitaに補足が上がっていたのでこちらも合わせてどうぞ。
qiita.com
コード生成による静的なDependency Injection
speakerdeck.com
DIすることで疎結合になるがインスタンス生成が面倒になることを解消しようとするアプローチでの発表でした。
テストしやすくするためにはDIは重要なので参考にしたいと思いました。
iOSDCで「コード生成による静的なDependency Injection」について話した & 口頭原稿を公開 github.com
サポート効率を上げるためのロギング環境構築
bugsnagではアプリのいろんなところに仕込むだけで、パンくずログが取得できるので、バグの改修に役立つ。
エラーコードをしっかりと定義し管理することが大事。
再現できないバグは多くの人にコストがかかるのでしっかりログをとることが大事であると思いました。
まとめ
今回初めてiOSDCに参加しましたが、一言で言うと「最高」でした。
スタッフ、スポンサー企業、スピーカー、参加者が作り上げているイベントという感じでとてもよかったと思います！
特にスタッフ、スポンサー企業、スピーカーの皆様ありがとうございました。
知り合いもほとんどいないなかでの参加でしたが、
パックマンルールを呼びかけて頂いたおかげで初対面の方ともたくさんお話することが出来ました。
運営の方ありがとうございます！
パックマンルール、輪になって話す時は一人分入ってこられるスペースを作りましょう！
— にわタコ (@niwatako) 2017年9月16日
#iosdc #a pic.twitter.com/An3LdcgXqv
また、ノベルティもたくさん頂きました。
来年も開催されれば必ず参加したいと思います。あとCfP出したいなと思います！