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

10-ish Things about Android Library Development

10-ish Things about Android Library Development

Talk given at Droidcon London Bytes meetup


Zan Markan

May 09, 2017


  1. @zmarkan Zan Markan @zmarkan LIBRARY DEVELOPMENT 10-ish things about Android

  2. @zmarkan @zmarkan Developer tools company blog.pusher.com Chat API Hiring in

    Shoreditch Trusted by 150k+ devs pusher.com | @pusher
  3. @zmarkan Contents of this talk • Libs 101 • API

    Design • Development & Testing • Releasing • Docs ...and more!
  4. @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. @zmarkan Libraries are a collection of classes and methods that

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

    more lightweight than apps Many x Many apps/lib ratio
  7. @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. @zmarkan Product is about the User • Developers (like you

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

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

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

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

    Data model Errors & Exceptions
  13. @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
  14. @zmarkan Builder Poor person’s named args … and optional args

    Ensures constructor is passed correct values, and validates its state before building the class
  15. @zmarkan Building the - Static inner class - … called

    Builder - setters mutate its state, returning this - build() constructs the main object - build() validates the view state AS SEEN IN RETROFIT
  16. @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)
  17. @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
  18. @zmarkan RX in brief observable .filter(//condition) .flatMap(//transformation) .subscribe(//handleSuccess, //handleError) Not

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

    are still often preferred provide RX adapter as an optional extra?
  20. @zmarkan for the λ Consider functional interfaces ...they can be

    replaced with lambdas easily Used with Retrolambda, Kotlin, Java 8 Power users tend to like them. Be nice to your power users.
  21. @zmarkan @nnotations Add validation features - NotNull, Nullable Value types

    - AutoValue, AutoParcel Build Annotations to write code for you Use Square/JavaPoet More: Jason Feinstein’s talk from CodeMotion Tel Aviv 2016
  22. @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: Annotations, Operator overloading, Extension methods, ...
  23. @zmarkan When things go • Let it crash! • Early

    • Often Ensure the error messaging is spot on Add links in error messages to explanations
  24. @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!
  25. @zmarkan DEV & TEST

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

    App size • Memory leaks • Build times • Needless dependencies
  27. @zmarkan ...my lib ain’t one! - Avoid private fields in

    parent classes - Prefer anonymous inner classes to lambdas - Avoid needless dependencies (again) - Proguard rules More: Jake Wharton’s talk from 360AnDev I got 65k problems, but...
  28. @zmarkan API should be beautiful. Implementation should f*****g work.

  29. @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
  30. @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
  31. @zmarkan

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

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

    the JAR/AAR in your project (Bad idea in most cases) • Include project as a Git submodule (Even worse idea in all cases)
  34. @zmarkan Releasing (the right way) Maven Central JCenter Jitpack Artifactory

    Maven dir on S3 Managed services free for OSS More DIY just add server
  35. @zmarkan DOCS

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

    apps • JavaDoc • Wiki pages • Yes, even tests! • Mix & Match!
  37. @zmarkan Quickstart a.k.a. “Let me copypaste something”

  38. @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
  39. @zmarkan JavaDoc • Cheap to make • Automagically generated •

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

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

  42. @zmarkan @zmarkan fin Blog: www.spacecowboyrocketcompany.com Twitter: @zmarkan Github: @zmarkan Email:

    zan@[pusher.com | markan.me]