Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Building stable and flexible libraries

Building stable and flexible libraries

Keishin Yokomaku

December 17, 2014
Tweet

More Decks by Keishin Yokomaku

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  3. Agenda
    • Stability
    • Flexibility

    View Slide

  4. Make libraries STABLE

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  22. Make libraries FLEXIBLE

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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, …

    View Slide

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

    View Slide

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

    View Slide