3rd Party SDK/Framework Solution Considerations (Part 2)

3rd Party Solution Considerations (Part 2)

Now that we have a good clarity and understanding around the finer nuances and purposes of SDKs, Frameworks, Libraries, API’s, and REST API’s, let’s continue to dive further into the this subject.

In this post we’ll be comparing SDKs and REST APIs for mobile platforms.  I’m doing this because this blog has a mobile focus and in the mobile world, these are the two terms most often used.  One final note, going forward, the term API will be referring to RESTful APIs.

Now that we have our parameters for this discussion, let’s dive into the real question we’re here to address:

Why and when to use one over the other?

The first point I’d like to bring up is that on mobile, and most other platforms, the above question’s answer isn’t always going to be entirely binary.

You may very much have some or more of the following combinations:

• A single mobile SDK
• Multiple mobile SDKs
• A single API
• This may be a user API which may include, add, update, delete, etc
• This is a single interface, not a single end-point
• Multiple APIs
• This may be a user API, a vehicle API, a school registration API, etc
• SDK(s) which wrap API(s)
• SDK(s) which is/are supplemented by API(s)
• API(s) which is/are supplemented by mobile SDK(s)

Regardless of the any of the above combinations, the fundamental question still remains, when and why to use SDKs vs APIs and vice-versa.

SDKs:

When considering delivering your solution as an SDK, you need to first understand where SDKs are going to provide functionality which an API is not going to be able to.  This first point is referencing the hardware (HW) on the device.

While PWAs access hardware via calls through the browser as previously discussed, what we’ll call an SDK solution for PWAs may a series of JavaScript files.

However, this point still remains - if you need to make specific or extensive use of “on device” HW, you’re heading down a road to provide an SDK as part of your 3rd party supplied mobile solution.

Let’s take a look at the image below:

As we look at the above graphic, we see that some of the standard HW is presented such as the camera, gyroscope, GPS, and accelerometer.

The others I want to address with a bit more specificity.

Multimedia

There are a multitude of different scenarios here, especially since you can play music and display images and video via a PWA.  However, there are limitations you may need to overcome.  Limitations which you’ll need to allow the app developers ingesting your SDK to not worry about.

One such example is background processing/playing of music along with real-time notification when the music stops, a favorite song is playing, etc.

The point here is, the more multimedia control you want to give developers integrating your SDK, the more your solution is likely going to be an SDK.

External HW:

This is a less common solution today, but is going to become much more prominent as IoT becomes more common in our everyday lives.  Today, an example may be a blood pressure device you can plug into your phone.

This scenario comes into play when your organization may make a custom HW device.  To have the mobile phone connect/communicate with your device may be any of the following:

• BLE comms
• Socket/Network comms
• http(s) comms
• Directly plugged into the phone
• Etc…

Here, regardless of the communications pipeline, it isn't reasonable to expect developers to have to figure out all the nuances of your device’s communication - even if executed via a standard channel such as BlueTooth.  This isn’t likely going to get you device wide adoption.  Here, a well structured SDK delivered would be the likely expectation of a mobile app developer.

However, in the direct connect scenario, an SDK will be almost mandatory.

Disk:

Here is a piece which dives us right into understanding your customers.  First, yes as discussed in our PWA post, we can store data to disk via a PWA, but with some real restrictions and much less control.  However, with an SDK, we can store significant amounts of data to the device with near complete control.

Now, is this aways the best idea, or even necessary?  Sometimes absolutely and sometimes absolutely not.

As an SDK provider, you’re stating that anyone developing an app can at least compile your SDK in.  You may have some SDK keys to “activate” things, but that aside - if your customer is mostly commercial and you provide solid security, this may work just perfect.  But if you’re looking to support a super-duper secret ninja society - this may not be allowed at all!

This doesn’t mean you don’t deliver an SDK, if just may mean this portion of the argument for or against it, is out.

SDK Considerations:

A point here, as your SDKs tend towards more specialized capabilities, not only do they themselves tend to become rather complex, they also tend to become rather large.

If you remember from our previous post about user adoption - maintaining a small app size matters and if your SDK bloats the final mobile app, you may have some issues getting app developers to adopt your SDK.

Additionally, when offering an SDK to mobile app developers - if your SDK requires permissions to the device's HW such as the microphone or GPS - remember, those permissions will come through the app, not your SDK.  So, if you require hardcore GPS to maintain the functionality your SDK provides - the app can determine if it wants to allow that.  Again, it is the app’s profile/configurations which determine the permissions it will ask for.  Normally not an issue when properly advertised, but certainly a consideration.

And finally, not that you completely get away from this using an API, but when developing an SDK, and that SDK uses a particular cloud provider backend, you need to be careful to avoid clashes with the app’s initialization.

For example: Let’s say you’re deploying an SDK which leverages Google’s Firebase.  Additionally, there’s an app developer which uses Google’s Firebase for their cloud.  Well, in Firebase, there’s a configuration file with a default name that is read when the app initializes the Firebase connection.

So now, if your SDK and the app developer don’t put in a specific configuration name, and both read from the expected default file name - where data goes is anyone’s guess (probably to whoever made the last call to init) - but the data going back and forth…. well, that's up for grabs.

If we take a look at the image below, it gives a high level overview what this may look like (Here the light blue is the SDK’s resources and the dark blue being the app’s):

Essentially, the confusion in the diagram, is the exact confusion which takes place when resource conflicts happen between an SDK and its host app.  What gets initialized and what data goes where is anyone's guess.  The likely scenario is the app will crash, but if this architectural consideration isn't taken into account when your team first starts developing the SDK, this can be a huge pain to fix.  And you'll likely loose your customer in the process.

Now, all this said, these are not insurmountable issues, but it is absolutely something you need to keep a lookout for if you’re deploying mobile SDKs.

Ie: You’re ultimately responsible for the project - bringing this up with your engineers isn’t going to hurt you.

APIs:

When considering delivering your solution as an API, let’s look at the functionality an API is going to provide.  Here, API’s are going to provide direct access to your cloud infrastructure’s functionality, computing capabilities, and data storage.

Let’s take a look at the image below:

As we look at the above we see that the API provides its functionality to its clients via processing which takes place on an external system(s) but doesn’t give us the powerful control of on-device HW.

This is pretty straight forward but leads us into our next talking point which is some of the constraints you’ll want to consider when providing an API beyond just the HW consideration.

API Considerations:

First, taking a look at the image above, we see that there is a high degree of dependency on network connectivity when supplying an API.  While anyone working on their machine in an office is rarely worried about this, the mobile device certainly can be a very different story.

Our mobile devices are mobile and therefore the quality of the connection, which can change quickly must be at the front of a mobile team's mind.  This brings up the concern an app developer may have if they have a highly performant mobile app - even when off-line or in a constrained network environment.

Additionally, as we work from our machines from an office or have a cloud server running, calling APIs which require large volumes of data is normally of mild consequence.  Sure there’s a limit to this, but overall, we don’t typically think how much each packet is costing us when we’re using a web site or making REST API calls.

Again, I understand there are limits to this, but they’re more often pretty high limits.

However, this isn’t the same for mobile.  Your app developers pulling in your API may be extremely worried about their customer’s data plans, they may have a high number of customers in regions with less reliable network infrastructure.  So, if your API uses especially high data volume at high cyclic rates, or takes an enormously long time to send data back to the client - your API may not get the adoption you’re looking for.

The above points bring up why, when developers say “just develop an API, then we don’t care if our client is on a desktop, server, mobile device, etc.”

There are differences, and you should be aware of them.

SDK API Mutual Support:

As we look at some of the issues of both the SDK and APIs, there are some that you’re just not going to get around, but with proper knowledge and planing at higher levels in the organization, they’re very manageable, and much less painful to deal with.

Below are some scenarios to consider when looking at various ways an API can be supported by an SDK:

Have an app that requires high performance even when offline?  Have the SDK store some data that can be used until connection is good.

Have an API that’s data hungry?  Have the SDK perform some preprocessing.

Have an API which is computationally intensive on the backend causing slow responses?  Look to see what you can off-load to the SDK. Ie: Edge computing.

Also, while every API is most likely https - that’s great for encryption in transit, but if the data is sensitive and you don’t want it in plain text when stored in your cloud, the SDK can perform the encryption via the user’s public key on device, alleviating your API from some worries.

This is what we very often see in industry, having SDKs wrap, but also support some APIs.

Below is an image essentially outlining some of the various methodologies seen with SDK and mobile app integrations.

Conclusion:

As we finish up the initial component of this blog dealing with mobile development strategies, this finalization of 3rd party deployment hopefully brought everything full circle.

I hope I’ve provided you the information you need to understand and interpret your mobile engineers a little better.  If there is anything pertaining to mobile that you would like more information or clarity on, please feel free to reach out.

As we progress our conversations with this blog, we will next begin to explore today’s IoT, 5G, Edge, and Fog computing environments.