Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Declarative UIKit

A Declarative UIKit

Exploring novel UIKit subclasses that offer a more declarative and idiomatic approach to UI design in Swift.

Eeb061c8b2816b771920da1b3e7904a3?s=128

Swift India

April 27, 2019
Tweet

Transcript

  1. A Declarative UIKit Exploring novel UIKit subclasses that offer a

    more declarative and idiomatic approach to UI design in Swift.
  2. A Declarative UIKit Exploring novel UIKit subclasses that offer a

    more declarative and idiomatic approach to UI design in Swift.
  3. UIKit Considered Harmful (… could be worse!)

  4. UIKit • Derived from AppKit • Written predominantly in Objective-C

    • Heavy usage of the delegate pattern • Historical baggage (from springs & struts to Auto Layout etc.) • Retroactively fits modern conveniences/APIs • Written before Swift was introduced
  5. General Problems • Architecturally limited by language constraints of Objective-C

    • Forces imperative code • Complexity of “correctness” sharply increasingly • Conflates model and rendering • Spawns monolithic controllers (think multiple delegates)
  6. Examples of Retrofitting • attributedText in UILabel • UITableViewAutomaticDimension •

    Size classes • UILayoutGuide • UIStackView (non-rendering class)
  7. UITableView • The bane of a UIKit developer’s life •

    Driven by highly imperative code • Heavily delegate based • Forces centralized UITableViewCell setup code • Requires considerable setup for to work with Auto Layout • Soul-sucking clusterf***
  8. What is declarative code? • A method of abstraction •

    Code that expresses “what” without going into the “how” • The “how” is left as an implementation detail
  9. Benefits • Expressivity • Separation of concerns • Decreased developer

    cognitive load • Requires developer to distinguish between design and implementation - richer/clearer mental model
  10. Making Something Declarative • Describe code in terms of the

    “what”, not the “how” • Decentralize responsibility across smaller, interchangeable units • Turn business logic into a function of data - generic UI components
  11. Writing Declarative Swift • Use protocols to separate the “what”

    from the “how” • Invert traditionally centralized APIs using protocols to diffuse responsibility • Think in terms of a generic scope, don’t make any assumptions • Make heavy use of generic parameters
  12. Reimagining UIKit in Swift • Closures over delegates • Heavily

    usage of protocol-oriented programming (UILayoutGuide could be a protocol!) • Generic parameters for dependency injection (for e.g. appearance classes etc.) • Value types???
  13. Making UITableView Declarative • Take a look at UITableViewDataSource -

    11 functions • Create descriptor for UITableViewCell • Create descriptor for UITableView sections • Create descriptor for UITableView • Write UITableView subclass to wrap descriptor
  14. Design Choices • Protocols over shims • No attempt at

    creating a generic UITableViewCell UI descriptor - cell descriptors must still vend a UI subclass • Generic type parameters over type erased protocol existentials • Associated types over simply using Array
  15. Why is UIKit so bad? • Mobile devices have evolved

    • Design has evolved • Applications have become increasingly complex • Apple needs to maintain legacy code/support • Based on AppKit and NeXTSTEP • Written in Objective-C
  16. Flutter • Closest to an ideal declarative UI framework •

    Separation of concerns exemplified (model and rendering completely separate) • Composable widget architecture, conceptually simple • Built with a fresh, modern perspective - does not suffer from historical constraints
  17. Thank You @vatsal_manot