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接続後に名前を変更するとクラッシュしてしまう
- 一般的にチーム開発でstoryboardsは使うべきではない
- iOS9のアンカー
- コードを見ただけではレイアウトが明確ではない
- シンプルだけどわからない
- Cartography
- もっと見やすくするためにはこれが良い
- オペレータのオーバーロードを活用
- 例：線形方程式
- マージン、パディングがある
- 何が起こっているかよくわかる
状態管理
- 基本的なレイアウトができたら様々なステートを理解すべき
- ロード中、ロードに成功、ロードに失敗
- 3つのステートはRestAPIを使ったアプリでは一般的
- どのように管理するのが良いのか
- フラグで管理？
- よく見るけど素晴らしくない
- どのような状態かわかりにくい
- フラグで管理？
- データとフラグを独立で管理
- フラグが設定されていないときだけ表示すべき
- このようなデータを表すEnumを使って欲しい状態でviewを初期化できる
- didSetブロックでswitchを使って状態を変更
- 教訓
- Enumなどを活用することによってVCを簡素化できる
- 曖昧な状態を排除することができる
- ロジックを一元化できる
ペーターラビットと繰り返される物語
- 表示非表示を一括してできたら良い
- 各状態のプロトコルを共有するといい
- 各状態の挙動をプロトコルで表現したい
- viewにデータをローディングし、それがどうなるかが知りたい
- ローディングview, エラーview, データセットできるように
- updateメソッドを用意すれば良い
- 教訓
- プロトコルを活用することで重複コードを削減できる
- ロジックを1箇所に固めることができる
まとめ
- Resultは成功と失敗を簡単に区別できる
- Cartographyはコードの可読性を上げるためにオペレータをオーバーロードして使う
- Enumを使ってビューを操作するコードを一箇所にまとめられる
- プロトコル思考によってコードの重複を避けられる
Q&A
関連
- UI作成
その他このトークに関する情報源
- try! Swift 2017 Tokyo に参加してきた - 2. 1日目 - My Favorite Things - Coding or die.
- UIをSwiftyに書く | try! Swift Tokyo 2017 #tryswiftconf Day1-10 聞き起こし - niwatakoのはてなブログ
- [速報レポート] try! Swift TOKYO 2017 1日目 午後I #tryswiftconf ｜ Developers.IO
