狠狠撸

部品に切り分けて考える

View構造とライブラリを上手に活用したUI実装
Fumiya Sakai (Just1factory)
2019/05/10 Swift愛好会 #40 @ ジーズアカデミー

自己紹介
?Fumiya Sakai
?Freelance iOS 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

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

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

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

似ている
細かな部分は

かなりシビア

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

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

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

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

UI表現で確定していない場所への配慮
確定していない部分は先回りした実装で挙動を確認する形をとる
観点1.

UIPageViewControllerでの
複数画像がある際の考慮。

観点2.

画像表示部分のアスペクト
比に関する考慮。

観点3.

遷移元からデータを引き継
いで表示→APIリクエスト
で再度更新させる形式。
先回りした実装例:

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

この結果を踏まえてこんな感じのサンプルが出来上がりました
画面でのDemoとご一緒にお楽しみください
サンプルコードはこちら https://bit.ly/2WAkMIG ※今はSwift4.2だけどアップデートもしていく予定です?

MVVMパターンを利用したDataBinding機構を利用する
API通信や想定する挙動からどちらが良さそうかを判断する材料を見出す
アーキテクチャの観点からの考察:
状態更新のリクエスト
ViewController ViewModel Model (Entity)
API Server Request / Response
利用するデータの作成
UI側への変更を伝える利用するデータの受取
NotificationCenterを活用したDataBinding機構

※iOSアプリ設計パターン入門第7章MVVMを参考
API通信処理の基本構造で利用したライブラリ一覧:
Alamofire / SwiftyJSON / PromiseKit
UnitTestを配慮してMock化できるようにする
※Alamofire + SwiftyJSON → URLSession + Codableでも良い

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環境を準備しての環境
アプローチ:

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

このサンプルで利用したUIライブラリをざくっとご紹介
細かなUI表現部分の構築においてそのままだと難しい部分に活用しています
BTNavigationDropdownMenu:
https://github.com/PhamBaTho/BTNavigationDropdownMenu
Floaty:
https://github.com/kciter/Floaty
FSPagerView:
https://github.com/WenchaoD/FSPagerView
Toast-Swift:
https://github.com/scalessec/Toast-Swift
ActiveLabel.swift:
https://github.com/optonaut/ActiveLabel.swift
デザイン面での拡張に対応できるものを選択する:
機能面やアニメーション等も加味した上で試していく。

→ ライブラリに収録されているExample等を確認する
もし自前でつくるならば？という問いを持つ:
機能開発やデザイン変更の過程の中でライブラリでの仕
様担保が難しくなった場合の代替案を自分の中に持つ。

実務でRxSwift + MVVMを利用するための布石にもなった
ある意味では比較することができたので「改めての便利さ」に気づく
関連するキーワード一覧:
RxSwift / MVVM / Kick Starter / Dependency Injection / API Client / Mock & Stub …
RxSwiftを活用する?活用しない場合の比較ができた:
実はRxSwiftについては結構昔から苦手意識を持っていたが、実務で利用した際の肌感が予習できた。
「UI実装と組み合わせる際に注意すべき点はどこか？」という考察から仮説検証の際にも役に立った。
画面構成において要素が複雑な場合への対処法や整理方法の考察:

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

Thank you for listening !
紹介しきれなかった実装の詳細については、是非ともコード等をご覧頂けましたら幸いです?
皆様もおすすめのライブラリやUI実装に関するTIPSがあればまた教えてくださいませ?

狠狠撸

部品に切り分けて考える痴颈别飞构造とライブラリを上手に活用した鲍滨実装

More Related Content

部品に切り分けて考える痴颈别飞构造とライブラリを上手に活用した鲍滨実装