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

10-ish things about Android library development

117c1e7c12a469a052f1361b6599af31?s=47 Zan Markan
February 21, 2017

10-ish things about Android library development

This talk explores the considerations that go into library development for Android. From the types of libs out there, to API, development, release, and documenting it.

Given at Ljubljana Android Meetup on 22 February 2017

117c1e7c12a469a052f1361b6599af31?s=128

Zan Markan

February 21, 2017
Tweet

Transcript

  1. ©Copyright @zmarkan 2017 DEVELOPMENT Zan Markan @zmarkan 1 10-ish things

    about Android Library
  2. ©Copyright @zmarkan 2017 ©Copyright @zmarkan 2017 About Me Developer for

    8+ years Mostly Android, mobile >> 2
  3. ©Copyright @zmarkan 2017 ©Copyright @zmarkan 2017 == DevTools company ==

    Realtime == Hiring in London 3
  4. ©Copyright @zmarkan 2017 Contents of this talk • Types of

    Libs • API Design • Development & Testing • Releasing • Docs ...and more! 4
  5. ©Copyright @zmarkan 2017 The Landscape What: Libraries, Frameworks, SDKs Type:

    Java libs, UI Widgets, Android specific, Serverside, Testing Access: Publicly vs Privately accessible Pricing: FOSS, Free to use vs Commercial Packaging: JAR vs AAR API: Annotation-based, Reactive, n other things... 5
  6. ©Copyright @zmarkan 2017 Also... the users Library users are Developers…

    … developers are very lazy, so... Libraries should enable laziness. 6
  7. ©Copyright @zmarkan 2017 API 7

  8. ©Copyright @zmarkan 2017 Things I mean by API • Entry

    points • Interaction points • Data model • Errors & Exceptions 8
  9. ©Copyright @zmarkan 2017 Entry points • Constructors • XML definitions

    • Static Factory Methods • Builders 9
  10. ©Copyright @zmarkan 2017 Builder 10 • Poor man’s named args

    • … and optional args • Ensures constructor is passed correct values • Validates its state before building the class
  11. ©Copyright @zmarkan 2017 Building the 11 • Static inner class

    • Called Builder • setters mutate its state, returning this • build() constructs our target class • build() validates its state
  12. ©Copyright @zmarkan 2017 Methods & Models • Follow SOLID principles

    • Naming, Naming, Naming • Don’t surprise your users! • (But you can delight them) 12
  13. ©Copyright @zmarkan 2017 13 for the λ • Consider functional

    interfaces • They can be replaced with lambdas easily • Used in Retrolambda, Kotlin, Jack Compiler… • Power users tend to like it. Be nice to your power users.
  14. ©Copyright @zmarkan 2017 (R)X-Factor 14 • A (better) way to

    do async • Still a “power user” feature • Keep a callback option • Rx adapter as optional extra? More: Paco Estevez makes AWESOME Rx libs/articles/talks
  15. ©Copyright @zmarkan 2017 @nnotations 15 • Use to add validation

    features - @NotNull, @Nullable • Autovalue, Autoparcel value types • Build annotations to “write” code for you • Use Square/JavaPoet More in: Jason Feinstein’s talk from Codemotion Tel Aviv 2016
  16. ©Copyright @zmarkan 2017 When things go 16 • Let it

    crash • Early • Often • And ensure the error messaging is spot on • Links in error messages to explanations
  17. ©Copyright @zmarkan 2017 DEV & TEST 17

  18. ©Copyright @zmarkan 2017 I got 65k problems, but... 18 Optimise

    to: • Improve performance • Keep the method count low • Keep the APK size small
  19. ©Copyright @zmarkan 2017 ...my lib ain’t one • Avoid private

    fields in parent classes • Prefer annon inner classes to lambdas • Avoid needless dependencies • Proguard rules More: Jake’s talk from 360AnDev 19
  20. ©Copyright @zmarkan 2017 API should be beautiful. Implementation should f*****g

    work. 20
  21. ©Copyright @zmarkan 2017 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
  22. ©Copyright @zmarkan 2017 release++ 22

  23. ©Copyright @zmarkan 2017 (Semantic) Versioning 2.0 Major[.]Minor[.]Patch • Major: Breaking

    changes • Minor: New features • Patch: Hotfixes Shouldn’t ever happen • semver.org 23
  24. ©Copyright @zmarkan 2017 Release: Options 24 • Package the Jar/AAR

    • Bad idea in most cases ^^ • Include project as a Git submodule • Even worse idea in all cases
  25. ©Copyright @zmarkan 2017 Release - viable options • Jitpack •

    Maven Central • Jcenter ^^ All with their respective gradle plugins! 25
  26. ©Copyright @zmarkan 2017 Release - private options • Free: ◦

    Self-Hosted Artifactory ◦ Maven on S3 (or any other bucket) • Paid: ◦ Sonatype Nexus ◦ JFrog Bintray 26
  27. ©Copyright @zmarkan 2017 Documentation 27

  28. ©Copyright @zmarkan 2017 50 shades of Docs 28 • Quick

    Start • Sample apps • JavaDoc • Wiki pages • Yes, even tests! • Mix & Match!
  29. ©Copyright @zmarkan 2017 Quickstart a.k.a. “Let me copypaste something” 29

  30. ©Copyright @zmarkan 2017 Sample code 30 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
  31. ©Copyright @zmarkan 2017 JavaDoc • Cheap to make • (Almost

    free, actually) • Awesome in Android Studio • Automagically generated • Host it alongside your other docs 31
  32. ©Copyright @zmarkan 2017 Libraries enable app developers to be lazy.

    Docs enable library developers to be lazy. 32
  33. ©Copyright @zmarkan 2017 10-ish things... 33

  34. ©Copyright @zmarkan 2017 The 10-ish things 34 Libs let devs

    be lazy Familiar > Unexpected Convention -> Configuration Naming, naming, naming Release wherever sensible for you ...but always on a Maven repo Be Lambda enabler Use Semantic Versioning Beautiful outside, “ugly” inside Have (more) tests There is magic in the copy-paste
  35. ©Copyright @zmarkan 2017 ©Copyright @zmarkan 2017 fin 35 Blog: www.spacecowboyrocketcompany.com

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