Tweet
Tweet

Slide 1

Slide 1 text

©Copyright @zmarkan 2017 DEVELOPMENT Zan Markan @zmarkan 1 10-ish things about Android Library

Slide 2

Slide 2 text

©Copyright @zmarkan 2017 ©Copyright @zmarkan 2017 About Me Developer for 8+ years Mostly Android, mobile >> 2

Slide 3

Slide 3 text

©Copyright @zmarkan 2017 ©Copyright @zmarkan 2017 == DevTools company == Realtime == Hiring in London 3

Slide 4

Slide 4 text

©Copyright @zmarkan 2017 Contents of this talk ● Types of Libs ● API Design ● Development & Testing ● Releasing ● Docs ...and more! 4

Slide 5

Slide 5 text

©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

Slide 6

Slide 6 text

©Copyright @zmarkan 2017 Also... the users Library users are Developers… … developers are very lazy, so... Libraries should enable laziness. 6

Slide 7

Slide 7 text

©Copyright @zmarkan 2017 API 7

Slide 8

Slide 8 text

©Copyright @zmarkan 2017 Things I mean by API ● Entry points ● Interaction points ● Data model ● Errors & Exceptions 8

Slide 9

Slide 9 text

©Copyright @zmarkan 2017 Entry points ● Constructors ● XML definitions ● Static Factory Methods ● Builders 9

Slide 10

Slide 10 text

©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

Slide 11

Slide 11 text

©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

Slide 12

Slide 12 text

©Copyright @zmarkan 2017 Methods & Models ● Follow SOLID principles ● Naming, Naming, Naming ● Don’t surprise your users! ● (But you can delight them) 12

Slide 13

Slide 13 text

©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.

Slide 14

Slide 14 text

©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

Slide 15

Slide 15 text

©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

Slide 16

Slide 16 text

©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

Slide 17

Slide 17 text

©Copyright @zmarkan 2017 DEV & TEST 17

Slide 18

Slide 18 text

©Copyright @zmarkan 2017 I got 65k problems, but... 18 Optimise to: ● Improve performance ● Keep the method count low ● Keep the APK size small

Slide 19

Slide 19 text

©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

Slide 20

Slide 20 text

©Copyright @zmarkan 2017 API should be beautiful. Implementation should f*****g work. 20

Slide 21

Slide 21 text

©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

Slide 22

Slide 22 text

©Copyright @zmarkan 2017 release++ 22

Slide 23

Slide 23 text

©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

Slide 24

Slide 24 text

©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

Slide 25

Slide 25 text

©Copyright @zmarkan 2017 Release - viable options ● Jitpack ● Maven Central ● Jcenter ^^ All with their respective gradle plugins! 25

Slide 26

Slide 26 text

©Copyright @zmarkan 2017 Release - private options ● Free: ○ Self-Hosted Artifactory ○ Maven on S3 (or any other bucket) ● Paid: ○ Sonatype Nexus ○ JFrog Bintray 26

Slide 27

Slide 27 text

©Copyright @zmarkan 2017 Documentation 27

Slide 28

Slide 28 text

©Copyright @zmarkan 2017 50 shades of Docs 28 ● Quick Start ● Sample apps ● JavaDoc ● Wiki pages ● Yes, even tests! ● Mix & Match!

Slide 29

Slide 29 text

©Copyright @zmarkan 2017 Quickstart a.k.a. “Let me copypaste something” 29

Slide 30

Slide 30 text

©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

Slide 31

Slide 31 text

©Copyright @zmarkan 2017 JavaDoc ● Cheap to make ● (Almost free, actually) ● Awesome in Android Studio ● Automagically generated ● Host it alongside your other docs 31

Slide 32

Slide 32 text

©Copyright @zmarkan 2017 Libraries enable app developers to be lazy. Docs enable library developers to be lazy. 32

Slide 33

Slide 33 text

©Copyright @zmarkan 2017 10-ish things... 33

Slide 34

Slide 34 text

©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

Slide 35

Slide 35 text

©Copyright @zmarkan 2017 ©Copyright @zmarkan 2017 fin 35 Blog: www.spacecowboyrocketcompany.com Twitter: @zmarkan Github: @zmarkan Email: zan@[pusher.com | markan.me]