「iOSアプリ設計ナイト」レポート
本日2019年1月15日i「OSアプリ設計ナイト」に参加しました。 Picxivさんで開催されました。 レポートをしていきます。 各発表のメモと自分のコメントを残します。
はじめに
本日2019年1月15日iOSアプリ設計ナイトに参加しました。
Picxivさんで開催されました。
レポートをしていきます。
各発表のメモと自分のコメントを残します。
発表の内容は私の走り書きなので資料と異なることがあります。
正確な内容は資料をご確認ください。
資料が上がり次第この記事もアップデートします。
会の概要
connpassから抜粋です。
iOSアプリの設計について語る夜です。 日々抱えている、iOSアプリ設計に関する疑問やベストプラクティスをぶつけていきましょう。
ちょうどPEAKSから『iOSアプリ設計パターン入門』が発売されたので、 著者の方々を執筆登壇者としてお呼びして、わいわいやっていきます。 事前に本を読んでおくと、より理解しやすくなると思われますのでオススメです。
『iOSアプリ設計パターン入門』はこちらです。
タイムテーブル
- 「2つの同期 4つの状態」 @ktanaka117
- 「アプリ設計は何がつらいのか」 @takasekさん
- 「iOSアプリ設計パターン選定」 @d_dateさん
- 「テスタビリティの獲得方法」 @_ishkawaさん
- 「橋の下で安心して寝るための『iOSアプリ設計パターン入門』 かめいけ(@kameike)さん
「2つの同期 4つの状態」
@ktanaka117さんの発表。
資料はこちら。
以下は私のメモです。
アーキテクチャは２つある
- システムアーキテクチャ
- GUIアーキテクチャ
今日はGUIアーキテクチャを解説。
関心の根底ー＞Presentation
- オブザーバー同期
- 監視によるデータの同期
- pro:疎結合にデータ同期
- 欠点:どこから同期イベントが送信するのかわかりずらい
- フロー同期
- 手続きによるデータ同期
- pro:データフローが負いやすい
- 欠点:遠い場所にあるコンポーネント同士のデータ同期しずらい
4つの状態
データのコピー
- Screen State
- Viewの状態
- label.text etc
- Presentation State
- Presenterの状態
- Screen Stateデータ
- etc Twitterのいいね。表示と通信２つある
- Session State
- Modelの状態
- API/DBから取得するデータのキャッシュ
- Record State
- DataStoreの状態
- 永続化状態
GUIアーキテクチャを理解する
APIから取ってきたデータを表示する
- そのまま表示する場合
- 画面とAPIデータが動悸しない場合
- MVPなど
私のコメント
GUIアーキテクチャの歴史から紐解いて責務分割の考え方を解説していました。
要件によって（使い捨てか、長く使われるのか）使い分けるときの指針になる発表でした。
「アプリ設計は何がつらいのか」
@takasekさんの発表
アプリ設計のつらみ
- 状態とフローのつらみ
- オブジェクトの生存期間が長い
- Fluid Interfaces （2018年WWDCで提唱）
状態がミュータブルだからつらい
-> 純粋関数にする？でも副作用の取り組み元を作らないといけない
-> オブザーバーパターンが解決の道
- 要求変化のつらみ
- 前のバージョンとの整合性などを考慮して開発するのはつらい
テスト->チェッキング->開発者を助けるもの
リファクタリングのためにテストが必要
コンテキストのつらみ
外部との互換性がつらい
-> スキーマ定める
-> レスポンス設計(バージョニングする）
-> 新しいキーはoptional
つらみと戦う
- つらみと戦う
- つらみと逃げる
- 状態を減らす
- 同じ画面
- 永続化しない
パターンを知る->使い所を知る->パターンの限界を知る
私のコメント
アプリ設計は難しい（つらい）。でもパターンを知ることで使い所と限界を把握することで立ち向かうことができる。
場合によっては逃げることができる。
課題に立ち向かう指針に設計パターンを覚えるのが有効だなと思いました。
「iOSアプリ設計パターン選定」
@d_dateさん
「iOSアプリ設計」は3部構成
- 設計の概要解説 by @takasekさん
- 設計パターンの具体例
- 設定パターンの選定
API Client->どうやって設計する？
このパターンで作るという考えは🙅だめ(パターンを先に決めて作り始めるのはだめ）
- 機能要件は何？
- 非機能要件
- チームサイズとスキルセット
- そのパターンをリードできるエンジニアがいる？
- そのパターンを好きになれるか
13章に書いている。
非機能要件について
- 品質レベル
- 開発期間
- 通信失敗時のハンドリング
- エラーパターンはどのぐらいある?
↓
設計パターンに正解はない
正解はないけどテクニックはある。
ドメイン駆動設計(DDD)のRepositoryでAPI Clientの実装をする
実装コードをプロジェクターで共有
Repositoryにオンライン、オフラインでデータが得られたら、UseCaseからみたら何やってるかをわからなくする。
こうすると、嬉しいのか
-> 任意のデータオブジェクトでよい
-> モックでもいい
-> テストができる！！！！
パターンから選ぶというより、考えることがある。
パターンに無理やりはめようとしない。
概念を知って手数を増やす。
コメント
パターンに当てはめて作るのは悪手、状況をみて構築する、そして決めたパターンを責任もって開発し続ける覚悟が必要というプレゼンでした。
「表示ロジックにおけるテスタビリティの獲得方法」
@_ishkawaさんの発表
- テストが書きづらい
- コストに見合ってない
石川さんが取り組んだ例。
ベストではないかも一例で参考になればとのこと
例：Githubのトレンディングのリスト画面。
- 画面表示
- インジケーター表示
- 読み込み開始
- 読み込み完了
- インジケーター非表示
- リスト表示
- ☆のタップ時
- ボタンの状態を反転
- サーバーに反転状態を送信
テストするところ、上から下まで実施するのは難しい
- UIテストは実装も実行も高コスト
- タイムラインの制御が難しい
3. イベントのタイムライン。UIのイベントの都合、外部システムの都合がある - テスト対象の状況を用意しづらい
5. 外部のシステムの応答を切り替え
6. 環境によって不安定になる
１つずつ解消する
1. UIテストは実装も実行も高コスト
-> 検証しやすいモデルで表現
UIテストの意義
- UIテストでないと検証できないこと
- 状況に応じて使い分けると良い
- 画面の重要度
スケジューリング
- 仮想時間をスケジューリングする
- 入力が一瞬で終わる。
- 結果も一瞬で検証できる。
テスト対象の状況を用意しづらい
-> 環境ごとにプロトコルでインターフェイスを作る。
スタブだけなら実装は簡単
質問しました
疑問があったので石川さんに直接質問しました
- 質問：サンプルコードはCollectionViewだったが、一列セルなのでTableViewでよいのでは？
- ->回答：石川さん自身がいつもCollectionViewを使っているのでそれで解説した。TableView相当のCollectionViewを作るのはself sizingを利用すれば簡単に実現できるので。
- ->回答2:TableView相当をCollectionViewにすることはあるが、CollectionViewをTableViewにすることはないのでいつもCollectionViewにしている。
- 質問：UIテストでないと検証できないこととは具体的になんですか？各デバイスのレイアウト崩れ確認？
- ->回答: モデル層のテストをいくらしてもViewが表示される保証はない。Viewの表示メソッドが発火しているかどうかはUIテストをすることで保証できる。
私のコメント
テストしやすい設計の指針となる発表でした。
サンプルコードが自分が作るものと異なる書き方をしていたので勉強になりました。
「橋の下で安心して寝るための『iOSアプリ設計パターン入門』
かめいけ(@kameike)さんさんの発表。
デザインパターン入門で感銘を受けたそう。
古代のギリシャで橋を設計した人は橋の下で寝るという言葉がある。
->橋の下で寝る人は壊れない橋を作る人
複雑さを乗りこなすにはシンプルな中間状態が必要
設計パターン->中間状態のカタログ
入門の議論のカバレッジが広い！
ビジネス要件に対する表現<->設計パターン<->Swiftの表現、OSSの表現
Palcyの背景
Christopher Alexander
- 斬新的成長
- プロジェクトを縦に割る
- ViewControllerごとではなくて、画面名で分ける
- プロジェクトを縦に割る
- 設計の腕鳴らしとしてのBLocパターン
- GoogleのFlutter解説で出てきた
私のコメント
建築家のChristopher Alexanderさんの引用を提示しながら、「iOSアプリ設計パターン入門」の内容の有用性をお話していました。
設計についての歴史を紐解くのが興味深かったです。
まとめ
パターンを盲信してはいけないが、パターンを知れば設計という難しい問題に立ち向かうことができます。
パターンの知識は立ち向かう武器の土台になり、戦うのか、逃げるのかを選択することもできるようになるでしょう。
とても有意義なイベントでした。
「iOSアプリ設計パターン入門」に興味が出た方はぜひお手にとってください！