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
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?
Characteristics of a good SDK 9 Picasso.with(context) .load(“http://i.imgur.com/DvpvklR.png") .into(imageView); Easy to use, even without documentation
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!
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 @MainThread @WorkerThread @AnyThread @NonNull @IntDef, @StringDef Fail fast (Exceptions) @LayoutRes, @StringRes, etc @RequiresPermission, @RequiresApi @IntRange, @FloatRange Characteristics of a good SDK Difficult to misuse!
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!
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 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 Define state of objects passed to/returned from library methods @MainThread public void signUp(@NonNull User user, Callback callback) { Validate.notNull(user, "user"); ............. Auth.signUp(user, userCallback); }
29 Define state of objects passed to/returned from library methods @MainThread public void signUp(@NonNull User user, Callback callback) { Validate.notNull(user, "user"); ............. Auth.signUp(user, userCallback); } What if client change this user in middle of something?
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!
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_' }
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_' }
Use ${applicationId} without fail android:authorities="${applicationId}.haptiklib.fileprovider" android:exported="false" android:grantUriPermissions="true"> android:resource="@xml/yourlib_provider_paths" />
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 android:name="android.permission.USE_CREDENTIALS" tools:node="remove" />