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

Building Android SDK

Building Android SDK

Presented at,
- "GoogleIO 2017 Extended" Event in Mumbai hosted by MADMeetup
- Meetup hosted by GDG Toronto Android https://www.meetup.com/toandroiddev/events/250883174/

Youtube link: https://www.youtube.com/watch?v=epwAhLWkPCY

Jigar Brahmbhatt

May 17, 2017
Tweet

More Decks by Jigar Brahmbhatt

Other Decks in Programming

Transcript

  1. Importance of tech talks Conferences/Meetups are not about teaching specifics,

    but all about inspiring and enlightening others about a topic At work, one may find a guide or mentor, but at the end everything depends on self-learning 2
  2. Why build an SDK? To build a product around it

    A paid SDK or an open-sourced library 4
  3. 5 To make your code re-usable/modular Thinking in terms of

    SDK design tends to improve quality of program that you write To build a product around it Why build an SDK?
  4. Characteristics of a good SDK 6 Reference: How To Design

    A Good API and Why it Matters - Joshua Bloch - https://www.youtube.com/watch?v=heh4OeB9A-c
  5. Characteristics of a good SDK 12 ‣ Methods taking int

    or null values ‣ Should I init on main thread or worker thread? ‣ Ask client to have your declarations in their manifest ‣ Encapsulation is not just for theory Difficult to misuse!
  6. Characteristics of a good SDK 13 Difficult to misuse! return

    Collections.unmodifiableList(list); return list; ‣ Methods taking int or null values ‣ Should I init on main thread or worker thread? ‣ Ask client to have your declarations in their manifest ‣ Encapsulation is not just for theory
  7. 14 @MainThread @WorkerThread @AnyThread @NonNull @IntDef, @StringDef Fail fast (Exceptions)

    @LayoutRes, @StringRes, etc @RequiresPermission, @RequiresApi @IntRange, @FloatRange Characteristics of a good SDK Difficult to misuse!
  8. 16 try {
 return xyzAPI.init(context);
 } catch (PermissionsNotSatisfied ignored) {


    } Characteristics of a good SDK Easy to read and maintain for users
  9. 17 ImageLoadingOptions imageLoadingOptions = new ImageLoadingOptions .Builder()
 .load(url)
 .diskCacheStrategy(DiskCacheStrategy.SOURCE)
 .build();

    
 ImageLoader.downloadInto(iv_optionIcon, imageLoadingOptions); Characteristics of a good SDK Easy to read and maintain for users
  10. 18 ImageLoadingOptions imageLoadingOptions = new ImageLoadingOptions .Builder()
 .load(url)
 .diskCacheStrategy(DiskCacheStrategy.SOURCE)
 .build();

    
 ImageLoader.downloadInto(iv_optionIcon, url); Characteristics of a good SDK Easy to read and maintain for users
  11. 20 Characteristics of a good SDK ‣ Builder Pattern for

    initialization, config etc ‣ Fluent interfaces ‣ Allows values like keys to be set via manifest metadata ‣ Create extendable APIs for more advanced control ‣ Provider both sync and async versions of methods, if applicable Use popular patterns!
  12. 23 Characteristics of a good SDK Method counts 23 ‣

    Proguard ‣ Java Synthetic Method ‣ Libraries which your library uses Exploring Java's Hidden Cost - Jake Wharton - https://www.youtube.com/watch?v=WALV33rWye4
  13. 26 ‣ No need to create full fledged first version

    ‣ Get core functionality/architecture VERY right ‣ Tip: Start your process with 2-3 page of top level documentation and get it validated ‣ Should be easy to evolve Solid beginning is necessary
  14. 27 Define state of objects passed to/returned from library methods

    Reference: The Mutable State Monster and How to Defeat it - Anup Cowkur - https://www.youtube.com/watch?v=lE9XnvBV-ys
  15. 28 Define state of objects passed to/returned from library methods

    @MainThread
 public void signUp(@NonNull User user, Callback<User> callback) {
 Validate.notNull(user, "user");
 .............
 Auth.signUp(user, userCallback);
 }
  16. 29 Define state of objects passed to/returned from library methods

    @MainThread
 public void signUp(@NonNull User user, Callback<User> callback) {
 Validate.notNull(user, "user");
 .............
 Auth.signUp(user, userCallback);
 } What if client change this user in middle of something?
  17. 30 Define state of objects passed to/returned from library methods

    @MainThread
 public void signUp(@NonNull User user, Callback<User> callback) {
 Validate.notNull(user, "user");
 .............
 Auth.signUp(new User.Builder(user).build(), callback);
 }
  18. Use interface type in an API instead of implementation type

    sendEvent(HashMap<String, Object> events)
  19. Use interface type in an API instead of implementation type

    sendEvent(HashMap<String, Object> events) sendEvent(HashMap<String, String> events)
  20. Use interface type in an API instead of implementation type

    sendEvent(Map<String, Object> events) sendEvent(HashMap<String, Object> events) sendEvent(HashMap<String, String> events)
  21. Use interface type in an API instead of implementation type

    setTextToAView(String text) setTextToAView(CharSequence text)
  22. Resource Prefix ‣ Remember resources like abc_actionbar_etc_etc? ‣ Prefix your

    resources to save from potential issues or misuse after manifest merger ‣ Utilize power of Gradle!
  23. Resource Prefix ‣ Remember resources like abc_actionbar_etc_etc? ‣ Prefix your

    resources to save from potential issues or misuse after manifest merger ‣ Utilize power of Gradle! android {
 resourcePrefix 'haptik_'
 }
  24. Resource Prefix ‣ Remember resources like abc_actionbar_etc_etc? ‣ Prefix your

    resources to save from potential issues or misuse after manifest merger ‣ Utilize power of Gradle! android {
 resourcePrefix 'haptik_'
 }
  25. Be cautious about permissions ‣ Make sure you’re not adding

    permissions for client app without clearly specifying ‣ Make sure your lib’s third party dependencies don’t add extra unnecessary permissions ‣ Analyze manifest of final APK via AndroidStudio ‣ Force remove if not necessary <uses-permission android:name="android.permission.USE_CREDENTIALS"
 tools:node="remove" />