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

Library Development - Stuck Between a Pod and a Jar File

Library Development - Stuck Between a Pod and a Jar File

Talk given at AppDevCon Amsterdam on 17 March 2017.
The talk explores the similarities and differences between iOS and Android when it comes to library development, and guides through the whole library development lifecycle.


Zan Markan

March 17, 2017

More Decks by Zan Markan

Other Decks in Programming


  1. @zmarkan Zan Markan @zmarkan LIBRARY DEVELOPMENT stuck between a pod

    and a jar file
  2. @zmarkan ©Copyright @zmarkan 2017 About Me Developer for 8+ years

    Mostly Android, mobile >> See also: emoji overuser
  3. @zmarkan ©Copyright @zmarkan 2017 == DevTools company == Realtime ==

    Sessions == making.pusher.com == Hiring in London
  4. @zmarkan Contents of this talk • Libs 101 • API

    Design • Development & Testing • Releasing • Docs ...and more!
  5. @zmarkan We libs because... Avoid duplicating logic - Best Practice

    Sharing == Caring It’s a great way to enrich your We want to be paid
  6. @zmarkan Libraries are a collection of classes and methods that

    encapsulate common, shared functionality.
  7. @zmarkan Libs != Apps Libraries are NOT end products Smaller,

    more lightweight than apps Many x Many apps/lib ratio
  8. @zmarkan All about that Lib... What: Libraries, Frameworks, SDKs Type:

    General libs, UI Widgets, Serverside, Testing Access: Publicly vs Privately accessible Pricing: FOSS, Free to use vs Commercial API: DSL, Reactive, n other things...
  9. @zmarkan Product is about the User • Developers (like you

    and I) • Varied backgrounds, levels of experience • User experience -> Developer experience
  10. @zmarkan the truth about developers Library users are Developers… …

    developers are very lazy, so... libraries should enable laziness.
  11. @zmarkan API

  12. @zmarkan The API is to a library what the USER

    INTERFACE is to an APP
  13. @zmarkan Things I mean by API Entry points Interaction points

    Data model Errors & Exceptions
  14. @zmarkan Entry points (where people first interact with your code)

    They allow you to instantiate and configure the library In “Code”: Constructors, Builders, Factories In UI: Widgets
  15. @zmarkan Construction in Code iOS: Named Parameters, Optionals Android: (Overloaded)

    Constructors, Builders Both: Sensible defaults >> Customisation
  16. @zmarkan Builder Poor person’s named args … and optional args

    Ensures constructor is passed correct values, and validates its state before building the class
  17. @zmarkan Methods & Models When in doubt - go S.O.L.I.D.

    Naming, Naming, Naming! Don’t surprise your users! (But you can delight them)
  18. @zmarkan (R)X-Factor Aysnc as a stream of events Allows chaining,

    and functional operations Support all the things: RxSwift, RxJava (even PHP!) More: Paco Estevez makes AWESOME Rx libs/articles/talks
  19. @zmarkan RX in brief eventStream .filter(//condition) .flatMap(//transformation) .subscribe(//handleSuccess, //handleError) Not

    shown: one million operators, threading, ...
  20. @zmarkan RX… but It’s still a power user feature Callbacks

    are still often preferred provide RX adapter as an optional extra?
  21. @zmarkan DSL-o-Matic 9000 Make your own little programming language… ...by

    inventing a syntax that works for you! Examples: Hamcrest, Rx, Kotlin Anko Techniques: Macros, Annotations, Operator overloading, Extension methods, ...
  22. @zmarkan When things go • Let it crash! • Early

    • Often Ensure the error messaging is spot on Add links in error messages to explanations
  23. @zmarkan Anatomy of a “nice” Error Type: Illegal Input Message:

    Request unsuccessful, reason: malformed auth token Link: https://example.com/errors/123456 Explain things here!
  24. @zmarkan DEV & TEST

  25. @zmarkan Performance or Be wary of: • Library size =>

    App size • Memory leaks • Build times • Needless dependencies
  26. @zmarkan API should be beautiful. Implementation should f*****g work.

  27. @zmarkan Testing it & Loving it The easy: Unit Tests

    The hard: Integration Tests with an app The smart: fooding More in: David Schreiber-Ranner’s talk from Droidcon Vienna 2016
  28. @zmarkan Tracking & Analysis Problem: No Google Analytics for libraries

    Track at the service level? Listen and talk to users fooding: Redux unless you’re Fabric
  29. @zmarkan

  30. @zmarkan (Semantic) Versioning 2.0 Major[.]Minor[.]Patch • Major: Breaking changes •

    Minor: New features • Patch: Hotfixes Shouldn’t ever happen • semver.org
  31. @zmarkan Releasing (how not to do it) • Manually include

    the builds in your project (Bad idea in most cases) • Include project as a Git submodule (Even worse idea in all cases)
  32. @zmarkan Releasing (the right way) : Carthage, CocoaPods Simple, git-based

    tools with some workspace-gen : Maven Central, JCenter, Jitpack Maven-based dependency managers ^^
  33. @zmarkan Releasing (privately) : Carthage, CocoaPods << Work with private

    git repos ^^ : Sonatype Nexus, Artifactory Pro, Jitpack ^^ hosted solutions, will cost you : Maven repo on S3, Artifactory OS ^^ free as in (just add server!)
  34. @zmarkan DOCS

  35. @zmarkan 50 shades of Docs • Quick Start • Sample

    apps • Java/Swift Doc • Wiki pages • Yes, even tests! • Mix & Match!
  36. @zmarkan Quickstart a.k.a. “Let me copypaste something”

  37. @zmarkan Sample code • Should be small, confined apps •

    … often alongside libraries in the same repo • Should reflect your libraries’ features • Can go in-depth for more advanced features
  38. @zmarkan JavaDoc & SwiftDoc • Cheap to make • Automagically

    generated • (Just add comments!) • Great in IDEs: Android Studio & XCode • Host it alongside your other docs
  39. @zmarkan Libraries enable app developers to be lazy. Docs enable

    library developers to be lazy.
  40. @zmarkan The takeaways Libs 101 API design Development Releasing Support

  41. @zmarkan ©Copyright @zmarkan 2017 fin Blog: www.spacecowboyrocketcompany.com Twitter: @zmarkan Github:

    @zmarkan Email: zan@[pusher.com | markan.me]