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

Framework Oriented Programming

Framework Oriented Programming

Have you ever tried to reuse code from your mobile apps and you haven’t been able to? Did you start using frameworks only when Apple suggested it for Watch Extensions? With more platforms coming out, there's a clear need of bundling logic that can be reused and shared in multiple platforms. Frameworks will help us with that and will benefit our application code bases in many ways. Learn how to do it, with or without dependency manager involved, recommendations and some caveats you must keep in mind. Start building your own Foundation frameworks, reusable, well designed, and with single responsibilities.

B0a336761194918a853deeff1f22b537?s=128

Pedro Piñera Buendía

May 24, 2016
Tweet

More Decks by Pedro Piñera Buendía

Other Decks in Technology

Transcript

  1. Framework Oriented Programming Pedro Piñera @pepibumur ⌚"#$

  2. Hello It's me (From the other side London)

  3. iOS Developer at SoundCloud @pepibumur

  4. Framework Oriented Programming • Started with GitDo • Applying principles

    to SoundClound • Ideas/Principles together in a repository (Reference) • Feedback is welcome !
  5. Index • Context • Principles • Advantages • How to?

    • Open Questions • SoundCloud attempt • Downsides • Conclusions
  6. Index • Context • Principles • Advantages • How to?

    • Open Questions • SoundCloud attempt • Downsides • Conclusions
  7. Context Before 2008 OSX == 1 Bundle* *Xcode project target

  8. Context 2008 Apple launches iPhone Software Development Kit ! (Developers

    move to iOS. New platform, frameworks,... New exciting area)
  9. Context After 2008 iOS == 1 Bundle* OSX == 1

    Bundle* *Xcode project target
  10. 2011

  11. Context 2011 CocoaPods released Dependency Resolving + Integration + Community

    !
  12. Context After 2011 iOS == 1 Bundle* OSX == 1

    Bundle* X Bundles (External Dependencies) *Xcode project target
  13. Context 2015 ⌚ "

  14. OMG That's Awesome

  15. Trying to reuse ! your code base

  16. Context 2015 iOS == 1 Bundle* OSX == 1 Bundle*

    tvOS == 1 Bundle* watchOS == 1 Bundle*
  17. How to reuse code? (across platforms) Frameworks

  18. Swift ❤ Dynamic Frameworks (OSX, iOS, watchOS, tvOS) • Allow

    embedded resources (images, fonts, ...) • Dynamically linked (No duplicated symbols) • Swift code
  19. Framework Oriented Programming Coding your apps organizing your code base

    in reusable & multiplatform code bundles Best Practices, Principles, Advices.. github.com/pepibumur/framework-oriented-programming
  20. Index • Context • Principles • Advantages • How to?

    • Open Questions • SoundCloud attempt • Downsides • Conclusions
  21. Frameworks Stack SoundCloud Approach

  22. 1. Single Responsibility SOLID inspired

  23. 1. Single Responsibility SOLID inspired

  24. Responsibility? CoreData access layer?

  25. Responsibility? CoreData access layer? Storage access layer?

  26. Responsibility? CoreData access layer? Storage access layer? Keychain access layer?

  27. Responsibility? CoreData access layer? Storage access layer? Keychain access layer?

    Models?
  28. Responsibility? CoreData access layer? Storage access layer? Keychain access layer?

    Models? !
  29. 1. Single Responsibility Start from a high level

  30. 1. Single Responsibility Slice them progressively

  31. 1. Single Responsibility Slice them progressively

  32. 2. Vertical dependencies (Over Horizontal)

  33. 3. Lower in the stack Fewer external dependencies

  34. 4. One Step Dependencies

  35. 4. One Step Dependencies

  36. 5. Internal by default

  37. 6. Final SOLID inspired (open/closed)

  38. 6. Final SOLID inspired (open/closed)

  39. 6. Final SOLID inspired (open/closed)

  40. 6. Final SOLID inspired (open/closed) final class Person { let

    name: String } class Alien: Person { // Compiler complains }
  41. 7. Framework models Don't share lower frameworks models upwards

  42. 7. Framework models Don't share lower frameworks models upwards

  43. 7. Framework models Don't share lower frameworks models upwards //

    Persistence class Author: NSManagedObjectModel { let name: String } class Track: NSManagedObjectModel { let author: Author } // ListenersKit struct StreamTrackEntity { let name: String let authorName: String }
  44. 7. Framework models Don't share lower frameworks models upwards struct

    StreamTrackEntityAdapter { func adapt(track: Track) -> StreamTrackEntity { return StreamTrackEntity(name: track.name, authorName: track.author.name) } }
  45. 8. Platform Abstraction SOLID inspired (DI)

  46. But... There's platform specific logic Examples - No NSFetchedResultsController in

    macOS - NSIndexPath is slightly different for watchOS.
  47. 8. Platform Abstraction Macros! #if os(OSX) // OSX logic #else

    // Other platforms logic #endif
  48. 9. Protocol Oriented Interfaces SOLID inspired (DI)

  49. 9. Protocol Oriented Interfaces SOLID inspired (DI)

  50. 9. Protocol Oriented Interfaces SOLID inspired (DI)

  51. 9. Protocol Oriented Interfaces SOLID inspired (DI)

  52. 9. Protocol Oriented Interfaces SOLID inspired (DI)

  53. 10. Core/Testing (aka your project Foundation frameworks)

  54. 10. Core/Testing Accessible from all the Frameworks • Extensions •

    Logging • Analytics • Architectural components (e.g. Reactive)
  55. Index • Context • Principles • Advantages ! • How

    to? • Open Questions • SoundCloud attempt • Downsides • Conclusions
  56. Multiplatform apps Only working on the UI ⌚"#$

  57. Multiplatform apps Only working on the UI ⌚"#$

  58. Experimentation import MyAppKit • Prototyping • Playgrounds

  59. New products With similar core needs Because you want to

    reuse code, right?
  60. New products With similar core needs Because you want to

    reuse code, right?
  61. Open Source And benefit from the community Build pieces of

    code that you'd be proud of open sourcing
  62. Specialized teams From UI lovers to Core Data experts (clearly

    defined team boundaries)
  63. Specialized teams From UI lovers to Core Data experts (clearly

    defined team boundaries)
  64. Index • Context • Principles • Advantages • How to?

    • Open Questions • SoundCloud attempt • Downsides • Conclusions
  65. How to? There are multiple options (I'll show you some)

  66. How to? CocoaPods

  67. How to? CocoaPods • ✅ Easy setup (each Framework .podspec)

    • ✅ You don't have to worry about Xcode Frameworks configuration • ✅ Same setup for local/external dependencies • ❌ .podspec cannot point to another local .podspecs • ❌ CocoaPods sucks if you don't version.
  68. How to? Local podspec discovery # Networking ~> Core dependency

    not found pod 'Networking' pod 'Core' pod 'AppKit'
  69. How to? Local podspec discovery pod 'Core' pod 'Networking' #

    Core has already been resolved pod 'AppKit'
  70. How to? Manual • ✅ More control over the workspace

    • ❌ Cumbersome setup (Build Settings) • External dependencies can be checked out with Carthage/Git Submodules.
  71. How to? Hybrid

  72. Index • Context • Principles • Advantages • How to?

    • Open Questions • SoundCloud attempt • Downsides • Conclusions
  73. Open Questions External Dependencies? RECOMMENDATION ⾠ • If CocoaPods for

    local: Use it also for external. • If manual setup: Use Carthage for checking out external dependencies carthage update • With the binary. • Adding the project to the workspace: --no-build
  74. Open Questions Versioning? Git repo per framework? RECOMMENDATION ⾠ 1.

    Keep it in the same repository (fast iterations) 2. Move it once it consolidates. (sporadic changes) 3. Then version it! (snapshots in time)
  75. Open Questions Static or Dynamic? RECOMMENDATION ⾠ - Objective-C &

    not shared ~> Static - Objective-C && shared ~> Dynamic - Swift && .* ~> Dynamic The more dynamic the worse load time
  76. Open Questions Migrate existing project RECOMMENDATION ⾠ - Start with

    Core/Testing - Move Foundation components down. - Continue building layers progressively. You'll figure out how couple your code is !
  77. Index • Context • Principles • Advantages • How to?

    • Open Questions • SoundCloud attempt • Downsides • Conclusions
  78. We failed at our first try Why?

  79. 1. We didn't version with CocoaPods I'm not against CocoaPods!

    Local Pods + No versioning + Team = It Sucks
  80. 2. Too many frameworks • No clear responsibilities • Crossed

    dependencies • Messy dependency tree • Very small responsibilities
  81. None
  82. None
  83. None
  84. Index • Context • Principles • Advantages • How to?

    • Open Questions • SoundCloud attempt • Downsides • Conclusions
  85. Lack of documentation (Targets Configuration) Tip: Use CocoaPods and copy

    the configuration
  86. Storyboards/Xibs in Frameworks Sucks ! Tip 1: Keep them in

    the application target Tip 2: Reuse UI only if it's in code
  87. Frameworks code recognition Sucks even more !

  88. Index • Context • Principles • Advantages • How to?

    • Open Questions • SoundCloud attempt • Downsides • Conclusions
  89. Very time-saver for multi-platform projects

  90. Helps with less coupled code (defined boundaries)

  91. Setup requires some Xcode Build Settings knowledge Unless you use

    CocoaPods
  92. Minimize external dependencies (KISS) (avoid more than 2 levels)

  93. Use your commonsense When deciding the Frameworks you need (don't

    get inspired from Javascript) • Try to have only those that you really need.
  94. Configuration depends on your project • New project? • Existing

    project to migrate? • Many external dependencies? • Not that many? • Already using CocoaPods? • How many people in your team?
  95. References • Library Oriented Programming: Justin Spahr-Summers • The Unofficial

    Guide to xcconfig files • CocoaPods • Carthage • pepibumur/framework-oriented-programming • Static & Dynamic libraries • Creating your first iOS Framework
  96. Thanks Questions? ! SpeakerDeck Slides: http:/ /bit.ly/22m4lwi