Isaac Newton, the father of modern software engineering, called it “Standing on the shoulders of giants”. Modern development is exciting as it gets easier and easier, partly because of the wealth of resources available at our fingertips. One category of these resources are libraries, SDKs, and frameworks. This talk will be a guide into the considerations that go into building a library for both iOS/Swift and Java/Android. We will be taking cues from both my personal experience, as well as from studying how the leaders in the field do it.

1. Mobile Library Development
Stuck between a Pod and a Jar file
Zan Markan @zmarkan
AMSTERDAM 16 - 17 MAY 2017

2. @zmarkan
Zan Markan @zmarkan
LIBRARY DEVELOPMENT
stuck between a pod and a jar file

3. @zmarkan©Copyright @zmarkan 2017
About Me
Developer for 8+ years
Mostly Android, mobile
>>
See also: emoji overuser

4. @zmarkan@zmarkan
Developer tools company
blog.pusher.com
Chat API
Hiring in Ldn
Trusted by 150k+ devspusher.com | @pusher

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

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

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

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

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

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

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

12. @zmarkan
API

13. @zmarkan
The APIis to a library what the
USER INTERFACE
is to an APP

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

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

16. @zmarkan
Construction in Code
iOS: Named Parameters, Optionals
Android: (Overloaded) Constructors, Builders
Both: Sensible defaults >> Customisation
Also in Kotlin on Android!

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

18. @zmarkan
Methods & Models
When in doubt - go S.O.L.I.D.
Naming, Naming, Naming!
Don’t surpriseyour users!
(But you can delight them)

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

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

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

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

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

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

25. @zmarkan
DEV & TEST

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

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

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

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

30. @zmarkan

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

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

33. @zmarkan
Releasing (the right way)
: Carthage, CocoaPods
Simple, git-based tools with some workspace-gen
: Maven Central, JCenter, Jitpack
Maven-based dependency managers ^^

34. @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!)

35. @zmarkan
DOCS

36. @zmarkan
50 shades of Docs
● Quick Start
● Sample apps
● Java/Swift Doc
● Wiki pages
● Yes, even tests!
● Mix & Match!

37. @zmarkan
Quickstarta.k.a.
“Let me copypaste something”

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

39. @zmarkan
JavaDoc & SwiftDoc
● Cheap to make
● Automagically generated
● (Just add comments!)
● Great in IDEs: Android Studio & XCode
● Host it alongside your other docs

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

41. @zmarkan
The takeaways
Libs 101
API design
Development
Releasing
Support

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