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

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]