iOSDCJapan2019 レポート

初めまして。ふみっちです。今回、iOSDCJapan2019に初参加してきたので、レポートを残したいと思います。

はじめに

今回はCyberAgentさんからチケットを支給してもらい、スカラシップとして参加しました。僕の他にも4人のスカラシップ当選者がいて、同世代のエンジニアと繋がれたことも嬉しく思います。ありがとうございました!

iOSDCとは

iOSDC JapanはiOS関連技術をコアのテーマとした技術者のためのカンファレンスです。

その名のとおり、iOS関連の話をテーマにしたカンファレンスです!

f:id:fummicc1:20190907010032p:plain
iOSDC!!

また、ブースにはいろいろな企業さんがいて沢山話を聞けます。

f:id:fummicc1:20190907010213p:plain
iOSDCのブースの様子

Day0 (9/5)

Day0は17:30からの開始でした。時間的にセッションの数も少なったですが、1つセッションについて書きたいと思います!

スクリーン配信機能の実装が大変だったので知見をお伝えします (@FromAtom)

ReplayKitのお話でした。ReplayKitとは動画配信を行うためのフレームワークです。なお、僕は使ったことがないです。。。(笑) ですが、ライブ配信は夢があり、いつか使ってみたいという思いの元、聴講させていただきました。

概要

今回は、iOS9からiOS11までにReplayKitがどのように変化を遂げたのかという話の元、何に注意すべきなのかやどの実装が大変だったかを経験談として話してくれました。

  • 資料ツイート

感想

ReplayKitiOS9以前では画面配信機能が備わっていなく、録画をすることしかできなかったことに驚きました。 また、UIScreen.main.isCapturedで現在画面配信をしているかの取得ができるようですが、Airplayで画面共有をしていてもtrueを返すようでそこらへんの制御にも知見が重要だなと感じました。 それでも、2年前は動画配信をコントロールセンターから配信できなかったことを考えると、現在は画面の一部のみを録画・配信することはReplayKitを使うだけでは実現が難しいようですが、数年後にはそういったものも可能になってくると面白いと感じました!期待が募りました。

Day1 (9/6)

結果的にDay1もDay2もOPは出ませんでした。睡眠と作業に時間を当てました。

ライブラリのインポートとリンクの仕組み完全解説(@k_katsumi)

おそらく誰もが使用したことのあるライブラリですが、よく目にするエラー例えば、

  • No such module 'Alamofire'
  • undefined symbols for architecture...
  • compiled with Swift 5.1 can not be imported...

ここら辺を例として取り上げられていて、実際にどういったときにこのようなエラーが出るのか・どういった原因でこのようなエラーが出るのかを詳しく解説していました。 また、

など、一言で他のコードを使用するといっても沢山の分別があり、それらは非常に細かく自分1人で勉強するのはなかなか難しいので、非常に貴重でありがたいセッションとなったと思います。

感想

正直、難しかったです。。。(笑)
しっかりと解説はされていたのですが、ファンダメンタルな話でBundleを持つのがフレームワークで持たないのがライブラリという話があったのですが、いまいちバンドルの実感が薄く、ピントこなかったのでこういったことも理解できるようになりたいと思いました。

以下、僕がセッション中にメモをしたBundleの説明の内容です。

Bundleとは...

開発を便利にするために一定のルールに沿ったディレクトリを持ったもの

• 一定のルール ... コード以外のもの(Resourcesなど)を含めることができるディレクトリ構造。

ライブラリの話は後日復習して理解を深めたいと思います!また、kishikawaさんは非常にiOS界隈で有名な方でそういった方を目にできるものカンファレンスの魅力だと感じました。

クロマキー合成を使い透過動画をAR空間に表示する(@shmdevelop)

このセッションは僕個人としてすごく興味のある知識で元々すごく楽しみでした。
僕個人で作ってみたARアプリがあるのですが、現状に加えてMetalとデプスを使用してARの背景に動画を流せるようにしたいというモチベーションがあって、Ask The Speakerでその話もできたので大満足です!

概要と感想

まずは、Metal入門を購入して勉強することをお勧めしていました。この本は僕も読んでいるのですが、一からMetalやShaderの説明が日本語で書かれていて確かに買って損はないと思います。
MSLの書き方にも少し触れていました。内容は割愛しますが、クロマキー合成をやるならMetalの知識は外せないなという印象でした。Metalの勉強頑張りたいと思います。 そんなこんなでニッチな内容のセッションでしたが、開けてみるとめちゃくちゃ楽しかったです!このセッションはこういうこともできるんだぜ!大変だけど勉強しよう! って思ってもらえたら良いようで、気を楽にして聞くことができました。

  • 資料ツイート

詳しくは資料にあるのですが、途中demoを多く使用してくださっていて、見ていて飽きませんでした。本当に楽しかったです。

f:id:fummicc1:20190907012348p:plain
デモ動画のスクリーンショット

ask the speakerで話した内容(メモ)

  • ARSessionにARFaceTrackingConfigurationを設定していれば、ARFrame.capturedDepthDataにアクセスすれば、ARKitでもデプスを取得できて、CVpixelBufferが使える。
  • CVPixelBufferからMTLTextureを生成可能
    • 前面の動画のキャプチャデータは取得可能。
  • 後ろの背景はシェイダーを使用して、全て透明にする。

この方法でAR空間内で背景を切り取り任意の動画を表示することが実現できるかもみたいな話をしました。(検証はしていないです。)
もうちょっとMSLを自分で書けるようになってきたら実際に作ってみたいと思います!

iOSDC茶会

楽しかった・おいしかったです。ご飯が秒で無くなった気がします。そのくらい沢山の人がいるのだなということです。

f:id:fummicc1:20190907015643j:plain
友達に撮ってもらいました

f:id:fummicc1:20190907015715p:plain
おやつの絵

ブース

  • SwiftUIBookゲット!
  • AbemaTV iOS Tech Bookゲット!
  • Push通知証明書周りのチートシートゲット!
  • 企業さんのステッカーゲット!
    f:id:fummicc1:20190907021215j:plain
    かなりステッカーが増えました!
    沢山ゲットしました!(笑) 他にも、話ができただけでも楽しかったです。ありがとうございました。

Day2

この日は作業もしたかったので、セッションは午後からの参戦でした。

おひる

おひるは実はスカラシップ生とサイバーエージェントさんの社員さんと一緒にご飯を食べる機会が与えられていました。 また、Day1のお昼の時に自分のコードをみてもらいたいと社員さんにお願いしたらこのお昼の時間で実際にコードをみてもらえました。感謝です。ありがとうございます。

Day2はここで学んだことでiOSDCきて良かったと思えるくらいの内容が知れたので(セッションとは)、主に感じたこと・学んだことを記録したいです。

github.com

テスト

僕は以前からテストが永遠に理解できませんでした。これが一週間前に理解できないままなんとなく書いていたテストコードです。

/// ユーザー作成ができるかのテスト
func testUserRegistration() {
    let session = URLSessionMock()
    session.data = Data()
    session.error = nil
    let database = APIMock(session: session)
    let request = URLRequest(url: URL(string: "http://localhost:8080")!)
    database.read(type: User.self, urlRequest: request) { (value, error) in
        XCTAssertNotNil(error)
    }
}

自分でも何をしたいのか分からないテストを書いていました。

そこで実際に現場でiOSエンジニアをしている方から話を聞かせていただいて大分テストを行うモチベーションが理解できました!

話を聞いた後での自分の理解としては

ユニットテストは失敗してほしいときにちゃんと失敗するか・成功してほしいときにちゃんと成功するか を簡単に検証したいときに行う。
ちゃんと成功・失敗 ... バリデーションが上手くいくか。シリアライズ・デシリアライズが上手くいくか など。

API通信を実際に踏ませても踏ませなくても良い。目的で変えるべき。

API通信を実際に踏ませるべきテスト ... インターネット接続の検証 とか?
API通信を実際に踏ませないテスト ... データがきちんと入っているときに正常なデータが返せるかを調べたい。

という感じです。(間違ってたらすいません。mm)
同時にProtocolを積極的に使用するメリットなどもテスト書くと理解できるなと感じました。

例えば、リポジトリを以下のように用意します。

protocol APIRepository {
    func create<V: EntityModel>(value: V, collectionName: String) -> Single<Void>
    func update<V: EntityModel>(value: V, collectionName: String) -> Single<Void>
    func read<V: EntityModel>(collectionName: String) -> Single<[V]>
    func delete<V: EntityModel>(value: V, collectionName: String) -> Single<Void>
}

ここで、実際にクライアントアプリでAPI通信を使用してユーザーデータを取得する際にはこのAPIRepositoryに準拠したクラスAPIClientなどを作成してそこに実装を書いていくと思います。勿論、Realmなどを使用したローカルにデータを永続化できるAPIにもこのプロトコルは準拠できると思います。

(この実装だとFirebaseを使用しているので、collectionNameという引数があります。Rest ful APIを叩く場合とは別にRepositoryを作成する必要が現段階ではありそうです。)

加えて、このAPIRepositoryに準拠したAPIRepositoryMockを用意するとテストが簡単に行えます。

このように、どのAPIを使用したとしてもAPIRepositoryで抽象化されているのでAPIに変更が走ってもドメイン層などで修正を強いられることが防げたり、ドメイン層ではユーザーのメンタルモデルとして、データを保存したい・データを取得したいといったことに柔軟に対応できるのかなと感じました。

ですが、create/ delete/ updateメソッドの返り値がSingle<Void>という実装で良いのかが疑問であったりしてこの辺りの理解を深めていけるように頑張ります。

設計まわり

設計周りに関しては、しっかりInputとOutputを分けられている点やRepositoryクラスを作成している点は良かったようでした。

ですが、シングルトンを使わないでユーザー自身の管理をするベストプラクティス的なものを理解しきれなかったので、もう少し勉強を進めていきたいです。

ちなみに、iOSDCが終わってからなんだかFluxやReduxに興味が出始めたのでFluxで設計されたサンプルアプリを作り始めました。なかなかFluxで実装されたサンプルプロジェクトが見つからなかったり、見つかっても大規模なプロジェクトに当てはめられた実装が多く、学習コストが高いなと感じました。ですが、実装していく中でデータフローが明確に一方向だなという認識を持ってコードを書けたのでFluxを体験することができて良かったです。

github.com

最後に

Day1の最後に同じスカラシップで参加していた人たちで写真撮りました。ずっと一緒には行動できなかったのですが、話をしてみると実際にいくつかインターンをしている人たちが多く刺激になりました。今の所感としては大学の勉強もがんばりつつ、春は就業型インターンをしたいと思いました。(単位がほしい。切実)

また、学生でこういったスカラシップに当選している人は自分の作品を持っていることが多いので、そろそろApple Storeに何か作品を出したいなと感じました。 昔トイレまっぷというアプリを作ってそのままアップデートできていないので、このアプリをまずは改良できるように開発を続けていこうと思います。

f:id:fummicc1:20190907012741p:plain