Pod for Great Good

Transcript

1. Pod for Great Good Building Modular Apps with CocoaPods

2. You have a problem.

3. You have an app.

4. It used to look like this: • Controllers • Views

   • Model • Helpers • Resources • Tests

5. It used to look like this: • Controllers • Views

   • Model • Helpers • Resources • Tests (I see you there!)

6. Now your app is here: • Controllers • Views •

   Model • Networking • Synchronization • Authentication • My Grandma • Old Stuff • Really Old Stuff • Analytics • Resources • Tests (Do we still need this? Oh right for that one thing…) (Oh, that’s where grandma went!)

7. Maybe it’s confusing. So? • Classes may fit into several

   categories • Grouping classes does not enforce the separation of intents per class

8. • Old Stuff • Really Old Stuff • Analytics •

   Resources • Tests

9. M O C K C E P T I O

   N

10. Enter the Pod

11. The Objective-C dependency management system

12. None

13. How does this begin to solve my problem?

14. Think Modularly. Reduce dependencies, build focused classes

15. Test Effectively. Test components in isolation, reduce duplication

16. Iterate Quickly. Update version numbers and go!

17. Design with Documentation in Mind. Think of the public interface

    from the beginning

18. Now you’re wondering:

19. How do I get to this magical land?! wow such

    modular much test many iteration

20. pod lib create [name]

21. Pod Structure • Assets • Classes • Project • README.md

    • WOWSuchLibrary.podspec (Remember to prefix your pod names!)

22. The Podspec • Author info • Description • Dependencies (other

    pods) • Required Frameworks • Supported platforms • Files

23. Example Podspec @version = "1.0.0" ! Pod::Spec.new do |s| s.name

    = "TAPI" s.version = @version s.summary = "Cotap API client" s.homepage = "https://github.com/cotap/TAPI" ! s.author = { "Delisa Mason" => "iskanamagus@gmail.com" } s.source = { :git => "https://github.com/cotap/TAPI.git", :tag => @version } s.source_files = 'Classes/Public/*.h' s.requires_arc = true s.public_header_files = ['Classes/Public/*.h'] ! # minimum deployment targets s.ios.deployment_target = '6.0' s.osx.deployment_target = '10.8' ! # pod dependencies s.dependency 'AFNetworking', '2.1.0' s.dependency 'ObjectiveSugar', '1.1.0' ! s.subspec 'Client' do |ss| ss.source_files = 'Classes/Client/*.{h,m}' end end

24. Assets • Images • Sounds • Core Data model •

    Storyboards, XIB files • et cetera

25. Classes • Pod source code

26. README.md “If you don’t have a readme, your code is

    bad and you should feel bad.” — Edsger Dijkstra

27. Project • Contains a default Podfile • Does not generate

    an Xcode project by default • Tests the pod under “real world” conditions

28. Build Example Pod Projects for OS X. (Where possible) Don’t

    wait on the simulator, get stuff done

29. Pod Structure ! • Assets • Classes • Project •

    Example • Example.xcodeproj • ExampleTests • Podfile • README.md • WOWSuchLibrary.podspec

30. Pod Example Podfile platform :osx pod 'WOWSuchLibrary', :path => ‘../'

    # Reference to the new pod pod "ObjectiveSugar" # Ruby-like collection operators/helpers ! target "ExampleTests", :exclusive => true do pod "Kiwi/XCTest" end

31. Pod Example Podfile pod 'WOWSuchLibrary', :path => ‘../' # Reference

    to the new pod pod "ObjectiveSugar" # Ruby-like collection operators/helpers ! target "ExampleOSXTests", :exclusive => true do platform :osx pod "Kiwi/XCTest" end target "ExampleiOSTests", :exclusive => true do platform :ios pod "Kiwi/XCTest" end For platform-specific files

32. pod install

33. Good Habits “Write the specifications of the library first before

    bringing in source code, to ensure the library can stand alone and has a distinct purpose.” ! — Abraham Lincoln

34. Finding Components in Existing Code • Choose a purpose for

    the library • (Hopefully) have an existing group of related files • Seed Classes and ExampleTests with the extraction • Have enough coverage to determine effectiveness

35. Common Places to Find Components • Data model and model

    classes • Reusable views • "Logic for X" • Classes for interacting with a particular web service • Reusable assets

36. Good Habits “While a component perhaps cannot be extracted from

    all large chunks of inter- dependent code, existing classes can be made more modular by extracting the methods implemented for a particular protocol into a separate class.” ! — Tom Cruise, “Top Gun”

37. Now your app is here: • Controllers • Views •

    Model • Tests • Pods • Networking • Model • Analytics • Authentication }• Separate git repos • Tests in isolation • Versioned

38. wow such modular much test many iteration

39. Flexibility. More shippin’, less rewritin’