Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

So you've got that awesome SDK...

DZone's Guide to

So you've got that awesome SDK...

· ·
Free Resource

A familiar situation. Today developers in many cases are called engineers because they assemble existing components together and make those work as a clock mechanism. Or, at least that's how it should work. How many of the developers actually know what's going on behind the third-party library blocks? Not to say that a whole bunch of those are open source, how many of the developers actually look at that source code?

And as much as I want to emphasize on the fact that this talk is about SDKs targetting mobile devices, all points below can be applied to full-sized application libraries. So before you are going to add a reference to the next library you will be using, try answering these questions.

1. Are you sure that the library is optimized?

Performance is very important no matter what platform you're developing for, but especially important on mobile devices where computing capabilities are extremely limited. I am not implying in any way that SDKs are necessarily slow, but it is always a good idea to test some of the capabilities in the context of tasks that you plan on performing with your application. Stress testing can be done both by analyzing source code (well, in this case it is hard to call it stress testing - more like code analysis) or by trying to call some methods in a more intensive manner (e.g. by passing large chunks of data).

2. Do you need all the functionality provided by the library?

If you need to use a 5MB DLL to have a simple method call to generate a MD5 hash, then you might re-think your strategy regarding the usage of third-party libraries. And after all, if there are only a couple fo calls involved, maybe you should:

a) Look for a library much more compact. Some of the most popular libraries come in regular and compact builds (specifically targeting mobile devices).

b) Implement the functionality on your own (exception being the case when you are going to use specialized functionality that might be out of your area of expertise [lame excuse, I know] or something that is going too long to implement).

3. Is the library error-free?

Stress testing helps here too. Of course you should have some time before you get it to production, and that is the time allocated for testing. Make sure that every call you make returns proper results and if something is wrong, either change the library or make sure that you handle exceptions properly. This should be done at the early development stages as later on it will be harder to figure out the possible error sources.

4. Are you sure the SDK does what it claims to do?

As surreal as it seems, some libraries might go beyond the declared functionality by performing undocumented data manipulations. This might include data collection and passing it to untrusted sources. This specifically applies to libraries that are designed for web interactions and that are requesting such details as user credentials. Make sure that no user-related information is collected that shouldn't be there. This applies (not only but including) to ad frameworks - you should be well aware as a developer of what information is going to be collected/stored/sent.

These 4 questions are essential if you want to avoid future problems with users who will complain about privacy or performance issues. Users don't care what SDK you use - they care about getting things done the right and the most efficient way. And if there will be problems caused by the application, the developer will be the one to blame, so bottom line is: make sure you know very well what you use.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}