O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

部品に切り分けて考えるView構造とライブラリを上手に活用したUI実装

466 visualizações

Publicada em

Swift愛好会 #40の登壇資料になります。

アプリ開発時におけるUI実装を検討していく中で、UIライブラリの活用や整理も含め、コード内部のアーキテクチャ等にも配慮した形にする際のヒント等についても幅広い?感じでご紹介できればと思います。

Publicada em: Tecnologia
  • Seja o primeiro a comentar

部品に切り分けて考えるView構造とライブラリを上手に活用したUI実装

  1. 1. 部品に切り分けて考える View構造とライブラリを上手に活用したUI実装 Fumiya Sakai (Just1factory) 2019/05/10 Swift愛好会 #40 @ ジーズアカデミー
  2. 2. 自己紹介 ・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
  3. 3. ほんの少しだけ告知と宣伝 「少しの工夫とアイデアでできる表現集」として、 これまでサンプル開発や実務の中で培ったノウハウ 等から、UI実装いくつかのまとまったサンプル実装 を例にUI構築をする上で重要な実装ポイントやアイ デアを紹介していく形式にしてみました。 本書の収録サンプルはこちらから: https://github.com/fumiyasac/ios_ui_recipe_showcase 念願の「iOSアプリ開発 UI実装であると嬉しいレシピブック」が商業誌に㊗ 概要: Amazonにて電子版の予約受付中です: https://www.amazon.co.jp/dp/B07NQDXY1F
  4. 4. 今回取り組む事になったきっかけ UI実装のプロトタイピングを元に実装検討する機会があった とあるアプリにおける新機能実装でデザインやアイデアの実現可能性を探る: このフェーズでポイントとなるキーワードは「再現性」と「懸案事項」を押さえること! その1. 参考アプリはPinterestのホーム画面: → 写真表示コンテンツではよく用いられる表現ではあるが細部まで考慮する場合難易度は高い その2. API通信を伴う&コンテンツ管理用の画面を新規に作成する: → API通信処理等の部分は既存でも一部あるが今回はそこがメインになる機能であった その3. 初期開発の段階で専任で着手できるのは自分だけ: → 最初の道筋を立てることができないとドミノ倒し式に引き継いだ際につらみが生まれる
  5. 5. サンプルで作成した画面構成 実際のアプリと参考アプリでの構造を見比べてポイントを洗い出す Pinterestの細部を観察してみると、かなり細部まで手がかかったInteraction/Animationになっている。 メイン部分は 似ている 細かな部分は かなりシビア
  6. 6. まずは自分なりに方針を作ってみる デザインや構想をメンバーから聞いた時点での自分が考えたものをまとめる 今回の実装が「自分が以前に体験したもので応用できる実 装で実現できるか?」という問いかけをする。 なぜやるのか: 画面のイメージ図解や基づく処理で必要なものを書き出し て採用するアーキテクチャ等を決める材料とする。 何を書くのか: 観点. 今後他のチームメンバーやビジネス側・デザイ ナー・プロダクトオーナーとの認識合わせのための資料 重要:はじめは自分なりで構わないのでイメージを持つ
  7. 7. 今回の発表でのサンプルコード 実際に動かせるコードもご用意しました & 解説コメントも残しました。 https://github.com/fumiyasac/MasonryStyleLayout ※Swiftバージョンはまだ4.2です
  8. 8. UI実装に必要な細かいテクニックの共有 UI実装に関するTipsを「知っているか・知らないか」が勝負のポイントになる UIStackView UIScrollView 高さが可変 リロード時に 高さも更新 高さ固定 height ≧ 0 priority = 1000 height = ●● priority = 250 部品用クラス UICollection View 高さ固定 部品用クラス 例. 高さが可変する要素への制約 観点. 複雑なView構造をとりうる場合には 部品用クラスやContainerViewを利用して分 離する形をとる。 @IBOutletで扱うのはpriority=250の方の制約 重要:Storyboard全体の保守性向上への工夫
  9. 9. UIに関する要素をComponentのような形で切り出しておく InterfaceBuilderの場合はXibファイルでViewの部品クラスを作るようにする React.jsの考え方からヒントを得た構造 Atomic Designの考え方を元に要素設 計をして部品の形へと分解・構築する
  10. 10. UI表現で確定していない場所への配慮 確定していない部分は先回りした実装で挙動を確認する形をとる 観点1. UIPageViewControllerでの 複数画像がある際の考慮。 観点2. 画像表示部分のアスペクト 比に関する考慮。 観点3. 遷移元からデータを引き継 いで表示→APIリクエスト で再度更新させる形式。 先回りした実装例:
  11. 11. その他議論しておくと良さそうな観点について デザインの細部や期待している部分に齟齬がないようにするために AdobeXD等のデザインから挙動などを想定する: 実装過程の中で「価値定義」から外れてしまわないように「共通認識」を大切にしていきましょう。 そもそもユーザーに提供する価値は何なのか?という根本を忘れない: 鵜呑みにせずに、少しでも疑問があれば確認をする。 早めにプロトタイプ開発を実践することで本実装時にリスクとなりうる場所を周知する。 楽観的な見積もりによる思わぬリスクへの配慮をする: デザインの意図を含む「目に見えないもの」の部分の認識合わせにも配慮する。 コード実装時に「どちらが担うべき処理なのか?」という観点からも考察する。
  12. 12. この結果を踏まえてこんな感じのサンプルが出来上がりました 画面でのDemoとご一緒にお楽しみください サンプルコードはこちら https://bit.ly/2WAkMIG ※今はSwift4.2だけどアップデートもしていく予定です💦
  13. 13. 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でも良い
  14. 14. 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環境を準備しての環境 アプローチ:
  15. 15. UnitTestで最低限担保するべきものを決める API通信部分の正常処理に関してはテストコードで想定する形を決める 例. ViewModel部分の初期化処理: テストしやすい様に「Dependency Injection」を想定しておくとより良い。 重要:レスポンスをクライアント側で正しく捌けているかを確認するためのテスト 何を準備するのか: Mock … Protocolを利用してAPI通信の代用として振る舞う Stub … レスポンス相当のJSONファイル MockやStubを利用して置き換えられるような形に予め実装すること。
  16. 16. このサンプルで利用した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等を確認する もし自前でつくるならば?という問いを持つ: 機能開発やデザイン変更の過程の中でライブラリでの仕 様担保が難しくなった場合の代替案を自分の中に持つ。
  17. 17. 実務でRxSwift + MVVMを利用するための布石にもなった ある意味では比較することができたので「改めての便利さ」に気づく 関連するキーワード一覧: RxSwift / MVVM / Kick Starter / Dependency Injection / API Client / Mock & Stub … RxSwiftを活用する・活用しない場合の比較ができた: 実はRxSwiftについては結構昔から苦手意識を持っていたが、実務で利用した際の肌感が予習できた。 「UI実装と組み合わせる際に注意すべき点はどこか?」という考察から仮説検証の際にも役に立った。 画面構成において要素が複雑な場合への対処法や整理方法の考察:
  18. 18. 今回のまとめ 既存アプリにおける新機能実装時の試し打ちをする習慣は役に立ちそう Point1) まずは疑ってかかる このサンプル開発を通じて: ある意味で本日の発表内容は良いプロダクトを作成する上では「留意しなければいけない点」ではあれど、なかな か期間等の制約で難しい部分もあるかもしれません。怪しいと感じた部分をいきなり実装するよりも、ワンクッ ション「予習」するプロセスをはさむことで、つなぐ処理のポイントや懸案事項をあぶりだせると思います。 Point2) 再現可能性を探る Point3) ポイントを見つける 表現に関するUI実装でのアタリをつけることで工数短縮やさらに進んだ工夫ができる余地を生み出す アーキテクチャやAPI通信等の責務以外の部分についてもできるだけ先に配慮をする習慣を持つ 誤った楽観視をしないためにも不安である部分をなるべく洗い出すことで心理的不安をなくす いうても細かな不具合とかはポロポロ出るんでそこは優しさで😅
  19. 19. Thank you for listening ! 紹介しきれなかった実装の詳細については、是非ともコード等をご覧頂けましたら幸いです😆 皆様もおすすめのライブラリやUI実装に関するTIPSがあればまた教えてくださいませ🎤

×