Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

@zmarkan @zmarkan Developer tools company blog.pusher.com Chat API Hiring in Shoreditch Trusted by 150k+ devs pusher.com | @pusher

Slide 3

Slide 3 text

@zmarkan Contents of this talk ● Libs 101 ● API Design ● Development & Testing ● Releasing ● Docs ...and more!

Slide 4

Slide 4 text

@zmarkan We libs because... Avoid duplicating logic - Best Practice Sharing == Caring It’s a great way to enrich your We want to be paid

Slide 5

Slide 5 text

@zmarkan Libraries are a collection of classes and methods that encapsulate common, shared functionality.

Slide 6

Slide 6 text

@zmarkan Libs != Apps Libraries are NOT end products Smaller, more lightweight than apps Many x Many apps/lib ratio

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

@zmarkan Product is about the User ● Developers (like you and I) ● Varied backgrounds, levels of experience ● User experience -> Developer experience

Slide 9

Slide 9 text

@zmarkan the truth about developers Library users are Developers… … developers are very lazy, so... libraries should enable laziness.

Slide 10

Slide 10 text

@zmarkan API

Slide 11

Slide 11 text

@zmarkan The API is to a library what the USER INTERFACE is to an APP

Slide 12

Slide 12 text

@zmarkan Things I mean by API Entry points Interaction points Data model Errors & Exceptions

Slide 13

Slide 13 text

@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

Slide 14

Slide 14 text

@zmarkan Builder Poor person’s named args … and optional args Ensures constructor is passed correct values, and validates its state before building the class

Slide 15

Slide 15 text

@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

Slide 16

Slide 16 text

@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)

Slide 17

Slide 17 text

@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

Slide 18

Slide 18 text

@zmarkan RX in brief observable .filter(//condition) .flatMap(//transformation) .subscribe(//handleSuccess, //handleError) Not shown: one million operators, threading, ...

Slide 19

Slide 19 text

@zmarkan RX… but It’s still a power user feature Callbacks are still often preferred provide RX adapter as an optional extra?

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

@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

Slide 22

Slide 22 text

@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, ...

Slide 23

Slide 23 text

@zmarkan When things go ● Let it crash! ● Early ● Often Ensure the error messaging is spot on Add links in error messages to explanations

Slide 24

Slide 24 text

@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!

Slide 25

Slide 25 text

@zmarkan DEV & TEST

Slide 26

Slide 26 text

@zmarkan Performance or Be wary of: ● Library size => App size ● Memory leaks ● Build times ● Needless dependencies

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

@zmarkan API should be beautiful. Implementation should f*****g work.

Slide 29

Slide 29 text

@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

Slide 30

Slide 30 text

@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

Slide 31

Slide 31 text

@zmarkan

Slide 32

Slide 32 text

@zmarkan (Semantic) Versioning 2.0 Major[.]Minor[.]Patch ● Major: Breaking changes ● Minor: New features ● Patch: Hotfixes Shouldn’t ever happen ● semver.org

Slide 33

Slide 33 text

@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)

Slide 34

Slide 34 text

@zmarkan Releasing (the right way) Maven Central JCenter Jitpack Artifactory Maven dir on S3 Managed services free for OSS More DIY just add server

Slide 35

Slide 35 text

@zmarkan DOCS

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

@zmarkan Quickstart a.k.a. “Let me copypaste something”

Slide 38

Slide 38 text

@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

Slide 39

Slide 39 text

@zmarkan JavaDoc ● Cheap to make ● Automagically generated ● (Just add comments!) ● Great in Android Studio ● Host it alongside your other docs

Slide 40

Slide 40 text

@zmarkan Libraries enable app developers to be lazy. Docs enable library developers to be lazy.

Slide 41

Slide 41 text

@zmarkan The takeaways Libs 101 API design Development Releasing Support

Slide 42

Slide 42 text

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