iOSDC Japan 2017 カンファレンスレポート

2日目トーク:結婚式を支えた技術,コード生成による静的なDependency Injection,Human Interface Guidelineから滲み出る限界感を考える

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

9月15日〜17日にiOSDC Japan 2017が開催されました。最終日の本編2日目も様々なテーマのもとに,32トーク,15LT,2企画トークが行われました。この記事では,この日の行われたトークの中から3つ取り上げて紹介します。

結婚式を支えた技術 Firebaseを活用したサーバレスiOSアプリケーション開発

ベストトーク賞10位に入賞したトーク結婚式を支えた技術 Firebaseを活用したサーバレスiOSアプリケーション開発」⁠スピーカーはiOSDC 2017のコアスタッフでもある@motokiee氏です。昨年結婚式を挙げる際に作成したiOSアプリ開発に関する話を披露しました。

@mtokiee氏

画像

motokiee氏は結婚式において「みんなスマホで写真を撮るものの,新郎新婦にその写真が送られることがあまりない」ということを解決すべき問題として挙げました。その上で写真が送られない原因を「写真を撮ってから送るまでの間にすることや,何を使って写真を共有するかの意思決定をするコストが大きいから」であると考え,⁠撮る」⁠アップロード」を同時に行うことができるアプリの開発を決意したそうです。

アプリ開発の目的(発表スライド16ページ目より)

画像

しかしそう決めた時には結婚式まで1ヶ月を切っていた上に非常に多忙な時期と重なっていました。そこで結婚式に間に合わせるために課題を整理し,やらないことを決めていきます。⁠ストアには出さず,DeployGateで配信する」もうすぐ出るSwift3ではなく)Swift2で開発する」そして「サーバサイド開発は行わず,Firebaseを使う」ということを決めました。

今回要件として挙げたことはFirebaseでほぼすべて実現可能でした。写真のタイムライン機能を実装するにあたってはDatabaseとStorageを,通知・お知らせ機能にはNotificationsとStorageを使ったそうです。Push通知に関してはその知見をiOSDCのアプリにも活かしています。

Firebaseを使ったアプリ実装(発表スライド37ページ目より)

画像

プロジェクトの進め方としては,やることを一元管理するためにGitHubのissueを使い,issueが更新されたらslackに通知するようにしたそうです。その際,非エンジニアの奥さんにもGitHubアカウントを作成してもらい,Push通知の文言の作成や配信のタスクを割り振ったそうです。このように奥さんにも手伝ってもらうことで,エンジニアという職業に対する理解,⁠一緒にやっている感」を感じてもらうことに繋がったとのことです。

結果的に開発は間に合い,本アプリを用いて約200枚の画像がアップロードされたようです。

コード生成による静的なDependency Injection

ベストトーク賞の8位に入賞したトークコード生成による静的なDependency Injection」⁠@_ishkawa氏が発表しました。

@_ishikawa氏

画像

最初はDIの基礎の説明から始まりました。DIは「必要なものを外から渡すこと」であると言い,画像ダウンローダを例にした説明がされました。

ImageDowonloader(発表スライドの7ページ目より)

画像

上記のコードは画像ダウンローダとしての要件は満たしています。しかしURLSession.sharedという固定のインスタンスを使っているため,URLSessionの挙動を変えたい時に差し替えがしづらくなってしまっています。そこで以下のようにコードを変えてみます。

DIを実現したImageDowonloader(発表スライドの8ページ目より)

画像

initializerでURLSessionを外部から渡すことでDIを実現できました。これにより以下の効能が得られました。

  • dependencyの切り替えが可能になり,その切替に際しImageDownloaderのコード変更は不要になった
  • dependencyの詳細を必要以上に決めなくてよく,ImageDownloaderの責務を小さくできた

一方,デメリットも存在します。dependencyの詳細を決めてからインスタンスに渡すという責務が外部に生じ,複雑なdependencyを渡す場合はその責務が重くなってしまいます。

複雑になるdependency(発表スライドの14ページ目より)

画像

この例の場合,一番左のものを作るために一番右のものまでインスタンスを取得しなくてはいけないことになってしまいます。そこで右のものを自動的に取得する仕組みを作るという発想に至ります。

インスタンスを自動で取得する方法は以下の2つの方法が考えられます。

  • DI用のinitializerを登録する
  • DI用のprovider methodを用意する

概要はAndroidのDaggerを例にして説明しました。SwiftではAndroidのDaggerのようにアノテーションを使うことができません。そこで代わりに,プロトコルを作成してDIで使用できるものであることを示したり,SourceKittenというライブラリを使ってSwiftのコード構造を取得したりと独自の工夫を示しました。

プロトコルにした意味は以下の2つの理由が挙げています。

  • provider methodの実装なしでこの構造が組める
    • テストなどで便利
  • 利用時に必要なものが揃っていることが保証される
    • 提供不足であればコンパイルエラーになる

自動的に取得できない際にdependencyになる場合はresolveメソッドのパラメータで渡すことによって解決できるとしています。

なお,@_ishkawa氏自身がこのトークの口頭原稿を公開しています。より詳しい情報を知りたい方はご覧ください。

著者プロフィール

須藤槙(すどうまき)

グロースハッカー,サーバサイドエンジニアを経て,今のところiOSエンジニアに落ち着いた人。日本酒とパワーメタルミュージックが好き。

自分で勉強会を主催したり,iOSDC 2017のコアスタッフ,女性エンジニア団体TECH PLAY女子部の運営,超小型人工衛星開発団体リーマンサットプロジェクトの技術部,広報部に所属したりしている。

Twitter:@akatsuki174

コメント

コメントの記入