This document discusses how to build stable and flexible libraries. To make libraries stable, it recommends using entity classes over primitive types, implementing threading synchronization techniques, and aligning object lifecycles. To make libraries flexible, it suggests considering annotations versus listeners, allowing customization of resources, and splitting packages by domain. The overall goal is to create libraries that are both robust and customizable for clients.

1. Building stable
and flexible libraries
@KeithYokoma - Drivemode, Inc.
potatotips #12

2. KeithYokoma
Keishin Yokomaku
Drivemode, Inc.
Android Engineer
GitHub: https://github.com/KeithYokoma
e-Book: http://amzn.to/1mZNydv

3. Agenda
• Stability
• Flexibility

4. Make libraries STABLE

5. Make libraries STABLE
• Entity class declaration
• Multi-thread compatibility
• Lifecycle management

6. Make libraries STABLE
• Entity class declaration
• Don’t
• Do
void setToken(String token, String type, String refresh, long by);
void setToken(AccessToken token);

7. Make libraries STABLE
• Entity class declaration
• Hard to remember the type of args
• Not Type-Safe(ref. Effective Java)
void setToken(String token, String type, String refresh, long by);

8. • Entity class declaration
• Easy to remember the type of args
• Type-Safe
void setToken(AccessToken token);
Make libraries STABLE

9. Make libraries STABLE
• Multi-thread compatibility
• Synchronization
• Immutable entity
• Thread pool and callback lifecycle
• Singleton implementation

10. Make libraries STABLE
• Multi-thread compatibility
• Synchronization
• “synchronized” block
• Synchronization utils(CyclicBarrier, …)
• Atomicity(AtomicInteger, …)
• “volatile” field

11. Make libraries STABLE
• Multi-thread compatibility
• Immutable entity
• Immutable entity is thread safe

12. Make libraries STABLE
• Multi-thread compatibility
• Thread pool and callback lifecycle
• Reduce thread initialization cost
• Align callback lifetime with “Context”
• Do NOT callback to dead object

13. Make libraries STABLE
• Multi-thread compatibility
• Singleton implementation
• Be aware of “Lazy Initialization”

14. // NOT thread safe!!
public class Singleton {
private static Singleton sInstance;
public static Singleton getInstance() {
if (sInstance == null) {
sInstance = new Singleton();
}
return sInstance;
}
}
Case Study
Multi-thread compatibility

15. Make libraries STABLE
• Multi-thread compatibility
• Singleton implementation
• “synchronized” block
• Double checked locking
• Initialization on demand holder

16. private static Singleton sInstance;
public static synchronized Singleton getInstance() {
if (sInstance == null) {
sInstance = new Singleton();
}
return sInstance;
}
Case Study
Multi-thread compatibility

17. private static volatile Singleton sInstance;
public static Singleton getInstance() {
if (sInstance == null) {
synchronized (Singleton.class) {
if (sInstance == null) {
sInstance = new Singleton();
}
}
}
return sInstance;
}
Case Study
Multi-thread compatibility

18. static class Holder {
public static final Singleton SINGLETON = new Singleton();
}
public static getInstance() {
return Holder.SINGLETON;
}
Case Study
Multi-thread compatibility

19. Make libraries STABLE
• Lifecycle management
• Object lifetime alignment

20. Make libraries STABLE
• Lifecycle management
• Object lifetime alignment
• Lifecycle methods of various “Context”
• onCreate/onDestroy
• onStart/onStop, onResume/onPause

21. Make libraries STABLE
• Lifecycle management
• Object lifetime alignment
• Naming convention
• add/remove, register/unregister
• start/finish, initialize/destroy

22. Make libraries FLEXIBLE

23. Make libraries FLEXIBLE
• Annotations vs Listeners
• Customizable resources
• Split package by domain

24. Make libraries FLEXIBLE
• Annotations
✓ Fast and easy development for client
✓ Automatic code generation(with apt)
✗ Slow(both runtime and apt takes time)
✗ Hard to dig into library itself

25. Make libraries FLEXIBLE
• Listeners
✓ Faster than annotations(runtime)
✓ Simple architecture
✗ Client should maintain the lifetime

26. Make libraries FLEXIBLE
• Annotations and Listeners
• Do NOT call methods of dead object

27. • Customizable resources
• If the library has UI resources…
• Theme should be customizable
• What about layout resources?
Make libraries FLEXIBLE

28. • Customizable resources
• At least you need to…
• Define ID resources that the library uses
• Otherwise layout may not be customized
Make libraries FLEXIBLE

29. Make libraries FLEXIBLE
• Split package by domain
• Avoid exceeding 65k method limit
• Less effort to strip out codes not used

30. Make libraries FLEXIBLE
• Split package by domain
• e.g. Guava
• guava, guava-gwt, guava-annotations, …
• e.g. Google Play Services 6.5
• play-services, play-services-wearable, …

31. –Joshua Bloch
“Never make the client do anything
the library can do for the client.”

32. Building stable
and flexible libraries
@KeithYokoma - Drivemode, Inc.
potatotips #12