2/21でドリコム株式会社様で開催された「エンジニア総選挙」でのLT登壇資料になります。 「社会で働くエンジニアが大集合！エンジニア総選挙を開催します！」 https://www.wantedly.com/projects/273166 iOSアプリにおける新機能開発やUI実装を実現するための前段として実践する「UI実装の試し打ち」におけるプロセスと機能実現のために方針立てをする過程を自分なりにまとめました。 特に今回はUIとの繋ぎになる処理部分の実現過程における考察を中心として展開しています。

1. Approach of Prototyping for making
Application User Interface about iOS.
Fumiya Sakai (Just1factory)
2019/02/21 エンジニア総選挙 @ DRECOM Inc.

2. 自己紹介
・Fumiya Sakai
・Mobile App Engineer
アカウント:
・Twitter: https://twitter.com/fumiyasac
・Facebook: https://www.facebook.com/fumiya.sakai.37
・Github: https://github.com/fumiyasac
・Qiita: https://qiita.com/fumiyasac@github
発表者:
・Born on September 21, 1984
これまでの歩み:
Web Designer
2008 ~ 2010
Web Engineer
2012 ~ 2016
App Engineer
2017 ~ Present

3. ほんの少しだけ告知と宣伝
「少しの工夫とアイデアでできる表現集」として、
これまでサンプル開発や実務の中で培ったノウハウ
等から、UI実装いくつかのまとまったサンプル実装
を例にUI構築をする上で重要な実装ポイントやアイ
デアを紹介していく形式にしてみました。
本書の収録サンプルはこちらから:
https://github.com/fumiyasac/ios_ui_recipe_showcase
念願の「iOSアプリ開発 UI実装であると嬉しいレシピブック」が商業誌に㊗
概要:
Amazonにて電子版の予約受付中です:
https://www.amazon.co.jp/dp/B07NQDXY1F

4. 今回取り組む事になったきっかけ
UI実装のプロトタイピングを元に実装検討する機会があった
とあるアプリにおける新機能実装でデザインやアイデアの実現可能性を探る:
このフェーズでポイントとなるキーワードは「再現性」と「懸案事項」を押さえること！
その1. 参考アプリはPinterestのホーム画面:
→ 写真表示コンテンツではよく用いられる表現ではあるが細部まで考慮する場合難易度は高い
その2. API通信を伴う＆コンテンツ管理用の画面を新規に作成する:
→ API通信処理等の部分は既存でも一部あるが今回はそこがメインになる機能であった
その3. 初期開発の段階で専任で着手できるのは自分だけ:
→ 最初の道筋を立てることができないとドミノ倒し式に引き継いだ際につらみが生まれる

5. 今回の発表でのサンプルコード
実際に動かせるコードもご用意しました & 解説コメントも残しました。
https://github.com/fumiyasac/MasonryStyleLayout ※ドキュメントはWIP

6. サンプルで作成した画面構成
実際のアプリと参考アプリでの構造を見比べてポイントを洗い出す
Pinterestの細部を観察してみると、かなり細部まで手がかかったInteraction/Animationになっている。
メイン部分は
似ている
細かな部分は
かなりシビア

7. まずは自分なりに方針を作ってみる
デザインや構想をメンバーから聞いた時点での自分が考えたものをまとめる
今回の実装が「自分が以前に体験したもので応用できる実
装で実現できるか？」という問いかけをする。
なぜやるのか:
画面のイメージ図解や基づく処理で必要なものを書き出し
て採用するアーキテクチャ等を決める材料とする。
何を書くのか:
観点. 今後他のチームメンバーやビジネス側・デザイナー・
プロダクトオーナーとの認識合わせのための資料
重要:はじめは自分なりで構わないのでイメージを持つ

8. 必要なライブラリの選定を行う
上手に活用できるものを探すためにサンプルや紹介記事を参考に選定する
例1. APIリクエスト・レスポンス等の非同期通信処理へのコントロール:
例2. Pinterest風の並び方を実現するためのUIライブラリ:
PromiseKit:
APIからのデータ取得クラス内の処理で利用
https://github.com/mxcl/PromiseKit
WaterfallLayout:
UICollectionViewを利用した高さが異なるセルの並び表現で利用
https://github.com/sgr-ksmt/WaterfallLayout
利用経験があるBolt-Swiftよりもシンプルだった
決め手👏 :
構造がシンプルで実装も綺麗😍
決め手👏 :
観点. UI実装関連のライブラリに関しては「Forkの余地」や「デモのシンプルさ」も意識すると良い

9. どんなアプリアーキテクチャが良いかを判断する
API通信や想定する挙動からどちらが良さそうかを判断する材料を見出す
アーキテクチャの観点からの考察:
状態更新のリクエスト
ViewController ViewModel Model (Entity)
API Server Request / Response
利用するデータの作成
UI側への変更を伝える 利用するデータの受取
State
観点1. DataBinding機構はデザインから想定する挙動だとあった方が良さそうと判断した
観点2. DataBinding機構は必要ではあるがメンバーの志向を加味してRxSwiftの利用はここは見送った
観点3. NotificationCenterを活用したDataBinding機構を利用して実現する方針を今回は採用した

10. UI実装に必要な細かいテクニックの共有
UI実装に関するTipsを「知っているか・知らないか」が勝負のポイントになる
UIStackView
UIScrollView
高さが可変
リロード時に
高さも更新
高さ固定
height ≧ 0
priority = 1000
height = ●●
priority = 250
部品用クラス
UICollection
View
高さ固定
部品用クラス
例. 高さが可変する要素への制約
観点. 複雑なView構造をとりうる場合には
部品用クラスやContainerViewを利用して分
離する形をとる。
@IBOutletで扱うのはpriority=250の方の制約
重要:Storyboard全体の保守性向上への工夫

11. UIに関する要素をComponentのような形で切り出しておく
InterfaceBuilderの場合はXibファイルでViewの部品クラスを作るようにする
React.jsの考え方からヒントを得た構造
Atomic Designの考え方を元に要素設
計をして部品の形へと分解・構築する

12. API通信を想定したMockサーバーの構築
1. https://www.webprofessional.jp/mock-rest-apis-using-json-server/
2. https://blog.eleven-labs.com/en/json-server
API通信と連動するUI挙動は実際に通信をしてみないとわからない点もある
node.js製の便利ライブラリ「json-server」の参考資料:
観点1. API処理に関してはエラー発生時のデザインを先に確認した上での実装
をしておきたかった。
観点2. 今回のデザインではページング処理とデザインの変化が連動する挙動な
ので、レスポンス形式と画面における整合部分の処理が一番重要だった。
なぜやるのか:
今回採用したもの. node.js製の「json-server」での擬似レスポンスの作成
今後検討するもの. Golang & MySQLのDocker環境を準備しての環境
アプローチ:

13. UI表現で確定していない場所への配慮
確定していない部分は先回りした実装で挙動を確認する形をとる
観点1.
UIPageViewControllerでの
複数画像がある際の考慮。
観点2.
画像表示部分のアスペクト
比に関する考慮。
観点3.
遷移元からデータを引き継
いで表示→APIリクエスト
で再度更新させる形式。
先回りした実装例:

14. UnitTestで最低限担保するべきものを決める
API通信部分の正常処理に関してはテストコードで想定する形を決める
例. ViewModel部分の初期化処理:
テストしやすい様に「Dependency Injection」を想定しておくとより良い。
重要:レスポンスをクライアント側で正しく捌けているかを確認するためのテスト
何を準備するのか:
Mock … Protocolを利用してAPI通信の代用として振る舞う
Stub … レスポンス相当のJSONファイル
MockやStubを利用して置き換えられるような形に予め実装すること。

15. その他議論しておくと良さそうな観点について
デザインの細部や期待している部分に齟齬がないようにするために
AdobeXD等のデザインから挙動などを想定する:
実装過程の中で「価値定義」から外れてしまわないように「共通認識」を大切にしていきましょう。
そもそもユーザーに提供する価値は何なのか？という根本を忘れない:
鵜呑みにせずに、少しでも疑問があれば確認をする。
早めにプロトタイプ開発を実践することで本実装時にリスクとなりうる場所を周知する。
楽観的な見積もりによる思わぬリスクへの配慮をする:
デザインの意図を含む「目に見えないもの」の部分の認識合わせにも配慮する。
コード実装時に「どちらが担うべき処理なのか？」という観点からも考察する。

16. 今回の発表内容でお話できなかった部分について
本日お話した内容に関しては後ほどQiitaにも展開しようと思います。
https://qiita.com/fumiyasac@github の方でその他iOSアプリのUI実装Tips展開中です！

17. 今回のまとめ
既存アプリにおける新機能実装時の試し打ちをする習慣は役に立ちそう
Point1) まずは疑ってかかる
このサンプル開発を通じて:
ある意味で本日の発表内容は良いプロダクトを作成する上では「留意しなければいけない点」ではあれど、なか
なか期間等の制約で難しい部分もあるかもしれません。怪しいと感じた部分をいきなり実装するよりも、ワンクッ
ション「予習」するプロセスをはさむことで、つなぐ処理のポイントや懸案事項をあぶりだせると思います。
Point2) 再現可能性を探る Point3) ポイントを見つける
表現に関するUI実装でのアタリをつけることで工数短縮やさらに進んだ工夫ができる余地を生み出す
アーキテクチャやAPI通信等の責務以外の部分についてもできるだけ先に配慮をする習慣を持つ
誤った楽観視をしないためにも不安である部分をなるべく洗い出すことで心理的不安をなくす
いうても細かな不具合とかはポロポロ出るんでそこは優しさで😅

18. Thank you for listening !