1. You shall not crash!
It is much harder to gain trust, than it is to lose it, when your SDK code crashes a customer’s app you can lose them right at this moment and it may be irreversible. You must consider all edge cases and deal with them, you must catch all your exceptions and handle them.
2. You shall have good designed and easy to use and understand interfaces!
When a developer develop a bad designed code, in most cases its going to hit up few or dozens developers head in this code’s lifetime, when an SDK developer develop a bad design code, it may hit thousands or millions of developers in the head. Keep in mind that all integrations with your interfaces should be a one liner or at least as easy and short as possible, you are potentially saving millions of hours that will be used to create great things instead.
3. Remember the holiness of end users device resources
Minimize your CPU usages, your memory footprint, avoid causing excessive GCs, try to minimize and postpone IOs and Network usage, Use caching wisely.
4. You shall be prepared to be used in a multithreaded environment
This is a tricky one: problems may rise when your SDK interfaces are being used in a multithreaded environment. You may want to overload a combination of function with function that combines them into an atomic operation to keep your users out from dealing with multithreading issues like race conditions and deadlocks.
5. You shall avoid depending on other 3rd party SDKs
When you depend on other 3rd party SDKs you are bloating the resources needed for using your SDKs, you may raise licensing issues when using your SDK and it may make companies think twice before depending on your SDK.
6. Honor legacy and backward compatibility
Yeah, using the latest technologies and libraries is exciting and fun, but if it will break your users code completely it may not worth it. You should keep in mind that you want older apps that uses older technologies to become or stay your customers. That’s why, btw, as of the time I wrote the article, it seem much more common to write SDKs in Java since its much easier to be compatible or at least easy to integrate to Kotlin with Java code, then it is the other way around.
7. You shall not bear false witness of what your interfaces do
That’s just too obvious…
8.Remember APK/AAR size and method count limitations and the overhead to overcome them
If your SDK is multi feature, you may split it to several SDKs with some common SDK that they all use. This way you can deliever to your customers exactly what they need.
9. You shall extend your interfaces to adopt new technologies
Either by using Kotlin extension function or Java’s default functions, remember to
10. You shall provide a great documentation with examples
Yeah, you should…
Liked this article? feel free to share it with friends and colleagues!
Have more commandments to add? go ahead and add a comment in this post!
One reply on “Ten Commandments For Developing a SDK on Android”
[…] We could simply write them to disk immediately after every event, but if we look back at rule 3 of Ten Commandments For Developing a SDK on Android (which applies to simple android applications too) then we should spare some of that IO overhead to […]