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

Transcript

1. Building Android SDK/Library Jigar Brahmbhatt @jabbar_jigariyo
2. 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
3. Why build an SDK? 3
4. Why build an SDK? To build a product around it A paid SDK or an open-sourced library 4
5. 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?
6. 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
7. Characteristics of a good SDK 7 Easy to use, even without documentation
8. Characteristics of a good SDK 8 Fabric.with(context, new Crashlytics()); Easy to use, even without documentation
9. Characteristics of a good SDK 9 Picasso.with(context) .load(“http://i.imgur.com/DvpvklR.png") .into(imageView); Easy to use, even without documentation
10. Characteristics of a good SDK 10 Must have great documentation!
11. Characteristics of a good SDK 11 Difficult to misuse!
12. 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!
13. 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
14. 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!
15. 15 Characteristics of a good SDK Easy to read and maintain for users
16. 16 try {
 return xyzAPI.init(context);
 } catch (PermissionsNotSatisfied ignored) {
 } Characteristics of a good SDK Easy to read and maintain for users
17. 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
18. 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
19. 19 Characteristics of a good SDK Use popular patterns! Take reference from popular SDKs!
20. 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!
21. 21 Characteristics of a good SDK Solid sample code/application! Very very important!
22. 22 Characteristics of a good SDK Method counts Hurts Android specifically!
23. 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
24. Misc Tips!
25. 25 Solid beginning is necessary
26. 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
27. 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
28. 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);
 }
29. 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?
30. 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);
 }
31. Use interface type in an API instead of implementation type (Can’t stress enough)
32. Use interface type in an API instead of implementation type sendEvent(HashMap<String, Object> events)
33. Use interface type in an API instead of implementation type sendEvent(HashMap<String, Object> events) sendEvent(HashMap<String, String> events)
34. 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)
35. Use interface type in an API instead of implementation type setTextToAView(String text)
36. Use interface type in an API instead of implementation type setTextToAView(String text) setTextToAView(CharSequence text)
37. Resource Prefix
38. 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!
39. 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_'
 }
40. 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_'
 }
41. Use ${applicationId} without fail
42. Use ${applicationId} without fail <provider android:name="android.support.v4.content.FileProvider"
 android:authorities="${applicationId}.haptiklib.fileprovider"
 android:exported="false"
 android:grantUriPermissions="true">
 <meta-data android:name="android.support.FILE_PROVIDER_PATHS"
 android:resource="@xml/yourlib_provider_paths" />
 </provider>
43. Use ${applicationId} without fail <!-- Custom Permission -->
 <permission android:name="${applicationId}.permission.XYZ"
 android:protectionLevel="signature" />
44. consumerProguardFiles
45. consumerProguardFiles consumerProguardFiles 'proguard-consumer-rules.txt' Add our proguard rules in your proguard file
46. consumerProguardFiles consumerProguardFiles 'proguard-consumer-rules.txt'
47. Beware of default variant https://developer.android.com/studio/projects/android-library.html#publish_multiple_variants
48. Be cautious about permissions
49. 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" />
50. It’s DIFFICULT to build a solid SDK!
51. It’s DIFFICULT to build a solid SDK! Expect to see mistakes after release
52. Thank you Twitter: @jabbar_jigariyo