[速報レポート] try! Swift TOKYO 2017 1日目 午後I #tryswiftconf

はじめに

try! Swift TOKYO 2017の午後のセッションが始まりました。

「毎日リアクティブ」 Agnes Vasarhelyiさん

概要

　この講演では、私の日々の経験からの例を使って、アプリ開発におけるリアクションプログラミングの実践的な使い方を紹介します。リアクティブプログラミングがどんなときに強力なツールになりえるのかを判断するヒントとともにコードの品質とパフォーマンスを脅かす可能性があるために避けるべきシナリオも紹介します。 このトークでは、様々なSwiftのリアクティブな実装を例示しながらリアクティブプログラミングの概念に焦点を当てていきます。

スライド

スライドは後ほど添付いたします。

説明

• リアクティブプログラミングを書くことについて
  
  • 簡潔に書ける
    
• この問題を非同期データに対して何らかのアクションをしなければならない時
  
  • stateを減らす
    
  • 変化に対してのリアクションを定義する
    
• Howではなくてwhatにフォーカスする
  
• コンセプトが同じなので一度学べば、ほとんどに適用できる
  
• ある時点を過ぎると複雑なコードを簡素化することができるようになる。
  
• ネットワークリクエストなどの非同期処理
  
• 非同期処理に関するstateの変更が当てはまる、このstateを減らしていくアプローチをする
  
• Streamのcombbine（ほかのAsyncOparationを例にする）
  
• 
  
• debugging
  
  • 従来のImperativeとはコールスタックが違う
    
  • 各frameworkにアタッチする機能が備わっている
    
• Fancy KVO
  
  • stateをアップデートするのではなく、bindを使って、アップデートをかける
    
• side effectをシグナルにインジェクトする
  
  • アプリのベーシックトラッキングを入れたい時など、必要な時に利用する
    
• Avoid Chaos
  
  • 知ってしまうとreactive behaviorを必要以上につかってしまう
    
    • 必要ないところでは使わない
      
• ReactiveなAPIを自分で作った時
  
  • 他の人たちに押し付けない

「Unsafe Swiftの安全性」 Ray Fixさん

概要

　Swiftは、デフォルトで直接メモリアクセスを許可しないことで、未定義の動作から保護します。 Swiftのunsafe系APIは、読みやすく、Unsafeでなくてはならない部分のみを書くのに役立ちます。

スライド

スライドは後ほど添付いたします。

説明

• デベロッパーは未定義な振る舞いは好まない
  
• Swift は安全を確保しようとしている
  
• メモリへの直接アクセスしようとしてない
  
  • UnsafePointerなどは提供している
    
• Dictonary、SetはLookupを提供している
  
  • HashAlogrithm
    
  • allocateを防ぐ
    
• チュートリアルを見てみてください

「クックパッドアプリのテストを味わう」 Kazuaki Matsuoさん

概要

品質やテストの話は往々にして提供するサービスやアプリのコンテキストに依存します。クックパッドのiOSアプリを題材にして、私たちが機能的な品質を保つためにどのようなテストを行ってきたかをお話します。特に、自動化されたテストに関してお話します。UIのリニューアルや様々な取り組みと変化だけではなく、Objective-CからSwiftへの書き換えなど、iOSを取り巻く環境は短い間に大きく変化しています。その中で、どのような取り組みにより最低限の不具合を防ぎ、iOSアプリをリリースし続けてきたのか。また、これにより得られた学びや、これからの取り組みに関してもお話しいたします。

スライド

説明

• テストにまつわる話です
• ユーザビリティテストやパフォーマンステストもあるが、今回はテストオートメーションの話をします
  
• UIテストがどれほど自分たちを支えているのか
  
• クックパッドのアプリをベース
  
  • 現在は10万行ほどコードがある
    
• 2週間から一ヶ月の間に5000 - 10000行変更が入る
• 最低限必要な品質について
  
  • クラッシュをしないこと
    
• Dichoromic Qualityについて
  
  • 時間とともに変化する品質
• 2014年頃からUIテストを着手始めている
  
• GUIのbehaviorのサイクルは外部（ユーザーから）と内部（コードから）からに分類される
  
• 自動化テストが実装されると効果的なのはUIテスト
  
  • 重要度はUnit Tests -> Intefration Tests -> UI Tests
    
  • マニュアルのテストはコストがかかる
    
    • 手動でやる必要があるテストを自動化することでコストが下がられる
      
• 今はスクリーンの遷移の8割にUI Testsに追加している
  
• テスト機能の追加
  
  • image diffを実装し、デザイナーにレイアウトチェックを行いやすくした
    
  • ネットワークトラフィックも見えるようにした
• 30％のコードがSwift に置き換わりつつある
  
• どのようにして大型アプリをre-enginiaringを施行してきたのか
  
  • 開発者の空き時間で行えるようなボリュームではない

「データレイヤを分離する」 Jon Bottさん

概要

真の階層化アーキテクチャ(MVVM, Viper, etc)において、データ層は全てのデータを必要とする他の層よりも下層部に置くべきです。残念ながら、CoreData や Realmなどのような同類の技術において、このレイヤーの実際の実装の詳細（スレッドやコンテクスト）は他のレイヤーやViewのロジックに浸潤する傾向があります。これは、アーキテクチャのスケール化を難しくします。そんな場合は旧来のSwiftオブジェクト(POSOs)を利用すればよいかと。失うものと克服できるものをセットで理解すれば、これを解決する事が可能となります。パフォーマンスを維持しながらPOSOに移行する方法について説明します。

スライド

スライドは後ほど添付いたします。

説明

• コードにおける誤解をどの要因防ぐか
  
• MVP - MVVM - VIPPER
  
• MVA
  
  • 必要最低限のアーキテクチャ
    
• 階層化の概念にはデータ層を切り離す
• データ層を切り離す
  
  • 境界線を越えるシンプルなデータはデータトランスファー層を使う
    
• DTOとは？
  
  • Plain OLD Ssift Objects (POSO)
    
• ModelObjectから変換するObjectを定義し、どこにでもいけるオブジェクトに変換する
  
• コンテキストもスレッドの問題も切り離すことができる
  
• デメリットもある
  
  • 生存管理は自分たちの責務になる
    
• それでもスレッドに関する問題が出た際に問題点が明らかになる

「UIをSwiftyに書く」 Sommer Panageさん

概要

この講演では、Swiftの構造と特性がアプリとUIのコードをより完結に書けるようにしているかということを探っていきます。 私たちは、UIレイヤーを構築する際の一般的な落とし穴と課題を見ていき、それを改善するためのSwiftyな方法を検討します。 Enumを用いたビューの状態のモデリング、有用なサードパーティ製のSwiftライブラリ、プロトコルによるビューの統一などを見ていきます。

スライド

説明

• 小さいアプリをSwiftを書くことはあったが、大きなアプリをSwiftを書くチャンスがでてきた
  
  • 見つけた4つのパターンに関して解決する方法をお話しします
    
• Schrödinger's cat in box Result
  
  • comptlitionでAPIの結果を返すコードの例
    
  • nilの場合もあるなど、繰り返しが発生する
    
  • Result<t, Error> を利用し、成功と失敗を返すようにする
    
    • これにより、2つのパターンのみのコードに簡略化することができる
      
• That little layout engine that could
  
  • Xibについて
    
    • XML diff
      
    • Merge Conflicts
      
  • Autolauoutをstoryborad上から使わないようにしている
    
  • Cartography を使ってコード上からautolayoutを使う
    
    • プログラマティックなautolayoutを組めるようになる
      
• Swiftlockes and three view states
  
  • REST APIを使ったアプリのローディング状態なのかエラー状態なのかの状態を持つのがほとんど
    
  • Stateをenumで定義する（ViewStateEnum）
    
  • stateプロパティにdidSetで状態変更時の処理を一元化する
    
• Repeated code
  
  • 互いの関係ないオブジェクト同士で共有したい振る舞いがあるとき
    
    • protocol で state と振る舞いを切り出す
      
    • generics を活用
      
  • 必要なViewに protocol に準拠させることで、繰り返しコード（反復）を防ぐ