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.

117c1e7c12a469a052f1361b6599af31?s=128

Zan Markan

March 17, 2017
Tweet

Transcript

  1. 2.

    @zmarkan ©Copyright @zmarkan 2017 About Me Developer for 8+ years

    Mostly Android, mobile >> See also: emoji overuser
  2. 3.

    @zmarkan ©Copyright @zmarkan 2017 == DevTools company == Realtime ==

    Sessions == making.pusher.com == Hiring in London
  3. 4.

    @zmarkan Contents of this talk • Libs 101 • API

    Design • Development & Testing • Releasing • Docs ...and more!
  4. 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
  5. 6.

    @zmarkan Libraries are a collection of classes and methods that

    encapsulate common, shared functionality.
  6. 7.

    @zmarkan Libs != Apps Libraries are NOT end products Smaller,

    more lightweight than apps Many x Many apps/lib ratio
  7. 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...
  8. 9.

    @zmarkan Product is about the User • Developers (like you

    and I) • Varied backgrounds, levels of experience • User experience -> Developer experience
  9. 10.

    @zmarkan the truth about developers Library users are Developers… …

    developers are very lazy, so... libraries should enable laziness.
  10. 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
  11. 15.

    @zmarkan Construction in Code iOS: Named Parameters, Optionals Android: (Overloaded)

    Constructors, Builders Both: Sensible defaults >> Customisation
  12. 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
  13. 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)
  14. 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
  15. 20.

    @zmarkan RX… but It’s still a power user feature Callbacks

    are still often preferred provide RX adapter as an optional extra?
  16. 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, ...
  17. 22.

    @zmarkan When things go • Let it crash! • Early

    • Often Ensure the error messaging is spot on Add links in error messages to explanations
  18. 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!
  19. 25.

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

    App size • Memory leaks • Build times • Needless dependencies
  20. 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
  21. 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
  22. 29.
  23. 30.

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

    Minor: New features • Patch: Hotfixes Shouldn’t ever happen • semver.org
  24. 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)
  25. 32.

    @zmarkan Releasing (the right way) : Carthage, CocoaPods Simple, git-based

    tools with some workspace-gen : Maven Central, JCenter, Jitpack Maven-based dependency managers ^^
  26. 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!)
  27. 35.

    @zmarkan 50 shades of Docs • Quick Start • Sample

    apps • Java/Swift Doc • Wiki pages • Yes, even tests! • Mix & Match!
  28. 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
  29. 38.

    @zmarkan JavaDoc & SwiftDoc • Cheap to make • Automagically

    generated • (Just add comments!) • Great in IDEs: Android Studio & XCode • Host it alongside your other docs