1) Why should a developer working on IoT solutions take time out to learn what Thing-IF is? What makes Thing-IF special, new, worth learning about?
IoT solutions are inherently quite complex because they consist of multiple layers. Most IoT solutions consist of:
- the thing layer (sensor or device),
- the service layer (typically in the cloud) and
the interaction layer (mobile apps, web apps and APIs exposed for integration with other services).
Now, to create a full IoT solution that works cohesively, all three layers have to work seamlessly - and making that happen not only requires multiple skill-sets (for example - firmware developers, service developers, app developers etc.), but also a lot of coordination between the skill-sets. This typically requires a lot of coding at multiple layers.
Fortunately, many IoT scenarios have frequently repeated best practice patterns around interaction between the three layers (sensor, cloud, apps). The Thing Interaction Framework (Thing-IF) encapsulates these best practices to make these most used sensor-cloud-app interaction patterns easy to implement with very little code. Plus it is extensible to cater to uniqueness of each use case. That's why Thing-IF is particularly special for developers.
2) How does Thing-IF reduce the time/cost effort for developers working on new IoT applications?
Thing-IF focuses on specific (but very common) functional patterns in IoT solutions:State registration and retrieval - for example the thing or sensor frequently updates some data to the cloud - and that data is needed in mobile appsAction and command execution - for example, a command can be sent from the mobile app or even another service - and based on the command, the thing or sensor needs to do something
Trigger driven command execution - specific commands being executed when certain conditions are met (data in the cloud)To achieve these functions, typically one needs to code in firmware, server-side (cloud) and on the app side. The state, triggers, commands, querying, condition evaluation, notification mechanism etc. all need to be coded across the three layers.
What Thing-IF does is, it makes you achieve these interactions very easily with just client-side coding alone. The mechanics of sending commands, receiving, triggering, notifying, registering state, saving state, querying state etc. are all made available by the framework itself - and exposed as APIs. Better yet - they're given to you, the developer, as SDKs! Both C SDK (for thing layer) and as Android/iOS SDKs for the mobile app developer. This saves significant amount of coding time as the heavy lifting is done by the framework itself.
The nice thing is, the framework doesn't impose any schema on you. You define the schema for your own use case.
3) What level of "new learning" is required for developers to implement new IoT applications using Thing-IF? Is it simply a matter of reading the API documentation?
It is really simply a matter of going thru our docs and looking thru APIs. There is no new technology or language to learn. Just figure out what your solution needs - and use the relevant APIs.
We have terrific getting started guide for Thing-IF. SDK docs are pretty easy to read too.
4) Are Thing-IF example applications available, that could potentially be used as the basis of a developer's own new IoT application?
The aforementioned docs cover good examples. See those for development steps involved.
5) What financial costs are involved for using the Thing-IF platform when a developer creates a new IoT application?
Developers can either sign-up thru our dev portal and try or request for trial credentials from us. Regarding pricing - our folks is sales would be able to help you set up once we understand your use case or scenario, deployment model (public/dedicated/private cloud) etc.
6) Thing-IF SDK is an extension of the Kii Cloud. Why should IoT developers seek to develop new applications that will specifically utilize Kii Cloud, versus other possibilities?
As discussed above, IoT solutions are quite complex. Significantly removing the burden on even one component of the solution greatly speeds up the time to market and operations/maintenance aspects of the solution. If the solution developer uses Kii as the platform, they can leverage much needed service layer functionalities easily thru APIs and SDKs (including Thing-IF, user management, data management, device management, analytics, push notifications, A/B Testing, Geo queries etc.) without having to develop all that backend layer. Kii's platform is customizable - so in case you need some custom backend functionality, you can extend our cloud thru what we call Server Extensions.
Furthermore, they don't even have to worry about operations because Kii takes care of operations, scaling, performance etc. Basically it is a cloud based IoT platform that takes care of the backend needs of IoT solutions.
This means that IoT solution developers can focus on the other 2 layers (thing, apps) which are the most user-visible parts of the solution. They can focus on differentiation over there. Plus, because there is no need to develop backend nor to operate it or maintain it, the time to market significantly improves.
Also, when you take the solution global, Kii is world-wide - so as long as you're coded to our APIs, your solution becomes really portable across regions. So for instance, a US based IoT solution developer wants to take their solution to China market - no problem; the solution just works even though the platform itself might be running on different infrastructure. Whether it is AWS it is running on or Aliyun, you don't have to care - it just works because we work on both and more.
Believe me, developing all of this backend functions isn't easy. Especially in a scalable, performant way across geographies. Why do it when we already did it for you?
Another advantage of choosing Kii is - on the distribution side. For many IoT solutions, the right channel (carriers and retailers for example) makes all the difference. Kii is a founder of the Space ecosystem (iotspace.org) and is the platform driving Space. So if your product is already on Kii, then it makes it easier for you to try to leverage the distribution side.
7) Thing-IF SDK is new. How "complete" is this initial version, how "solid", how "usable" for a developer? How would you answer concerns of this type from new developers who might consider using Thing-IF?
Thing-IF just happens to be the newest of a long list of features on our solid platform used by global customers. We believe it is quite solid and quire ready for developers. In use already.
Kii has been a platform of choice for many customers, including global brands like DOCOMO, Toshiba, Kyocera, Alibaba, KDDI, Yankon and more.
8) What links would you like to provide to help developers get started with Thing-IF?
Getting started: http://docs.kii.com/en/starts/thingifsdk/
SDK guide: http://docs.kii.com/en/guides/thingifsdk/
SDK references: http://docs.kii.com/en/references/