Library Development - Stuck Between a Pod and a Jar File

Talk given at AppDevCon Amsterdam on 17 March 2017.
The talk explores the similarities and differences between iOS and Android when it comes to library development, and guides through the whole library development lifecycle.

Transcript

1. @zmarkan Zan Markan @zmarkan LIBRARY DEVELOPMENT stuck between a pod and a jar file
2. @zmarkan ©Copyright @zmarkan 2017 About Me Developer for 8+ years Mostly Android, mobile >> See also: emoji overuser
3. @zmarkan ©Copyright @zmarkan 2017 == DevTools company == Realtime == Sessions == making.pusher.com == Hiring in London
4. @zmarkan Contents of this talk • Libs 101 • API Design • Development & Testing • Releasing • Docs ...and more!
5. @zmarkan We libs because... Avoid duplicating logic - Best Practice Sharing == Caring It’s a great way to enrich your We want to be paid
6. @zmarkan Libraries are a collection of classes and methods that encapsulate common, shared functionality.
7. @zmarkan Libs != Apps Libraries are NOT end products Smaller, more lightweight than apps Many x Many apps/lib ratio
8. @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...
9. @zmarkan Product is about the User • Developers (like you and I) • Varied backgrounds, levels of experience • User experience -> Developer experience
10. @zmarkan the truth about developers Library users are Developers… … developers are very lazy, so... libraries should enable laziness.
11. @zmarkan API
12. @zmarkan The API is to a library what the USER INTERFACE is to an APP
13. @zmarkan Things I mean by API Entry points Interaction points Data model Errors & Exceptions
14. @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
15. @zmarkan Construction in Code iOS: Named Parameters, Optionals Android: (Overloaded) Constructors, Builders Both: Sensible defaults >> Customisation
16. @zmarkan Builder Poor person’s named args … and optional args Ensures constructor is passed correct values, and validates its state before building the class
17. @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)
18. @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
19. @zmarkan RX in brief eventStream .filter(//condition) .flatMap(//transformation) .subscribe(//handleSuccess, //handleError) Not shown: one million operators, threading, ...
20. @zmarkan RX… but It’s still a power user feature Callbacks are still often preferred provide RX adapter as an optional extra?
21. @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: Macros, Annotations, Operator overloading, Extension methods, ...
22. @zmarkan When things go • Let it crash! • Early • Often Ensure the error messaging is spot on Add links in error messages to explanations
23. @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!
24. @zmarkan DEV & TEST
25. @zmarkan Performance or Be wary of: • Library size => App size • Memory leaks • Build times • Needless dependencies
26. @zmarkan API should be beautiful. Implementation should f*****g work.
27. @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
28. @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
29. @zmarkan
30. @zmarkan (Semantic) Versioning 2.0 Major[.]Minor[.]Patch • Major: Breaking changes • Minor: New features • Patch: Hotfixes Shouldn’t ever happen • semver.org
31. @zmarkan Releasing (how not to do it) • Manually include the builds in your project (Bad idea in most cases) • Include project as a Git submodule (Even worse idea in all cases)
32. @zmarkan Releasing (the right way) : Carthage, CocoaPods Simple, git-based tools with some workspace-gen : Maven Central, JCenter, Jitpack Maven-based dependency managers ^^
33. @zmarkan Releasing (privately) : Carthage, CocoaPods << Work with private git repos ^^ : Sonatype Nexus, Artifactory Pro, Jitpack ^^ hosted solutions, will cost you : Maven repo on S3, Artifactory OS ^^ free as in (just add server!)
34. @zmarkan DOCS
35. @zmarkan 50 shades of Docs • Quick Start • Sample apps • Java/Swift Doc • Wiki pages • Yes, even tests! • Mix & Match!
36. @zmarkan Quickstart a.k.a. “Let me copypaste something”
37. @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
38. @zmarkan JavaDoc & SwiftDoc • Cheap to make • Automagically generated • (Just add comments!) • Great in IDEs: Android Studio & XCode • Host it alongside your other docs
39. @zmarkan Libraries enable app developers to be lazy. Docs enable library developers to be lazy.
40. @zmarkan The takeaways Libs 101 API design Development Releasing Support
41. @zmarkan ©Copyright @zmarkan 2017 fin Blog: www.spacecowboyrocketcompany.com Twitter: @zmarkan Github: @zmarkan Email: zan@[pusher.com | markan.me]