とりあえずやってみればいいじゃん

とりあえずやってみればいいじゃん

エンジニア関連のことについてつらつら書くブログ

3/2 UIをSwiftyに書く #tryswiftconf

try!Swiftのセッションまとめシリーズです。Sommer Panageさんの「Writing your UI Swiftly」についての記事になります。

資料

www.slideshare.net

内容

  • 小さな会社におり、一からswiftで書けることにわくわくしていた
  • 書いているうちに同じようなパターンを何度も書いていることに気づいた
    • 特にUIの部分
  • 今日は4つのパターンについて話す

シュレディンガーの結果

  • データをバックエンドから取得する
  • 結果は成功と失敗2つのケースがある
  • ありうる結果が4種類があるが、2つは期待していない結果なのでハンドリングしなくていいはず
  • Resultというオブジェクトを使う
    • 成功したらT型、失敗したらError型が返ってくる
  • この話の教訓
    • Result,Enumを用いることでより正確にエラー処理ができる

レイアウト

  • 結果を表示するとなるとレイアウトを考えなければならない
  • AutoLayout
    • 古くはlayoutSubviews()でやっていた
    • 複数のデバイスサイズでは無理
  • storyboards、xib
    • 一般的にチーム開発でstoryboardsは使うべきではない
      • どこが変更されたかわかりにくい
      • マージが大変
    • 文字列で識別されているという
    • Outlet接続後に名前を変更するとクラッシュしてしまう
  • iOS9のアンカー
    • コードを見ただけではレイアウトが明確ではない
    • シンプルだけどわからない
  • Cartography
    • もっと見やすくするためにはこれが良い
    • オペレータのオーバーロードを活用
    • 例:線形方程式
      • マージン、パディングがある
      • 何が起こっているかよくわかる

状態管理

  • 基本的なレイアウトができたら様々なステートを理解すべき
    • ロード中、ロードに成功、ロードに失敗
    • 3つのステートはRestAPIを使ったアプリでは一般的
  • どのように管理するのが良いのか
    • フラグで管理?
      • よく見るけど素晴らしくない
      • どのような状態かわかりにくい
  • データとフラグを独立で管理
    • フラグが設定されていないときだけ表示すべき
    • このようなデータを表すEnumを使って欲しい状態でviewを初期化できる
    • didSetブロックでswitchを使って状態を変更
  • 教訓
    • Enumなどを活用することによってVCを簡素化できる
    • 曖昧な状態を排除することができる
    • ロジックを一元化できる

ペーターラビットと繰り返される物語

  • 表示非表示を一括してできたら良い
  • 各状態のプロトコルを共有するといい
  • 各状態の挙動をプロトコルで表現したい
    • viewにデータをローディングし、それがどうなるかが知りたい
    • ローディングview, エラーview, データセットできるように
    • updateメソッドを用意すれば良い
  • 教訓
    • プロトコルを活用することで重複コードを削減できる
    • ロジックを1箇所に固めることができる

まとめ

  • Resultは成功と失敗を簡単に区別できる
  • Cartographyはコードの可読性を上げるためにオペレータをオーバーロードして使う
  • Enumを使ってビューを操作するコードを一箇所にまとめられる
  • プロトコル思考によってコードの重複を避けられる

Q&A

  • enum以外の方法は使ったことありますか?
    • ほとんど一般化されたenumを使っている
    • 他のアプローチを検討することもあるが、お気に入りはEnum

関連

その他このトークに関する情報源

togetter

Writing your UI Swiftly #tryswiftconf - Togetterまとめ