Hints for the Next Step
This topic gives some hints for the next step after you have completed the Hello Thing-IF tutorial.
After completing this tutorial, we advise you to read the following topics to understand Kii Cloud further.
Check Kii Cloud Overview
Kii recommends you to grasp the Thing-IF SDK's functionalities before you get started with the full-scale design of your IoT solution. The topics in Thing-IF SDK will help you to design your solution properly while you can skip topics for unnecessary features. The Hello Thing-IF tutorial does not include some features such as the trigger, with which you can execute commands automatically.
When you enter the development phase, check Thing-IF SDK v2 Development Guides to learn how to implement your program.
Start a New Project
Especially when you develop your mobile app, you will create a new project and then incorporate the Thing-IF SDK there instead of modifying the sample app.
See the platform-specific steps under Thing-IF SDK v2 Development Guides to learn how to incorporate the Thing-IF SDK.
Also, as mentioned in those steps, Kii recommends to you try Push Notification Tutorials if you add the push notification feature to your mobile app.
These hints might help you to design a full-scale solution.
Use the Pseudo User without Login
The pseudo user feature allows you to implement functions which need a user of the mobile app. With this feature, you can create a KiiUser without the username, password, or explicit login, and get and retain only an access token which indicates the logged-in status. The pseudo user cannot log in again.
See Thing-IF SDK v2 Development Guides to learn how to create a pseudo user. For more information about the pseudo user feature, see the following topics.
Port to Non-Linux Hardware
Prepare OS-dependent processes by using Implementing OS-dependent Processes for the Thing SDK Embedded, as a reference to adjust the thing program for your target hardware and OS. The Thing SDK Embedded is a library used in the Thing-IF SDK.
Auto-generate vendorThingID with UUID
If it is difficult to set unique values to things as vendorThingID at factory shipment, you can automatically generate vendorThingID from data like UUID on the mobile app. In this scenario, after the mobile app onboards the thing, transfer the thingID and thing's access token assigned by Kii Cloud to the thing via Bluetooth and so on. Use the thingID and thing's access token to initialize the thing.
The thing needs several bytes of non-volatile memory to save the transferred thingID and access token.
See the Onboarding from the mobile app section in the Onboarding topic to learn how to implement it.
The current Thing Interaction Framework processes only the last version of state information in JSON format. However, your application might need to process more complex information.
If you plan to use application data in any of the following ways, use the data management features of the Kii Cloud SDK to tune the way to store data. Implement the thing program and mobile app to use the Kii Cloud SDK in your IoT solution according to the guidance in Tuning with Kii Cloud SDK for Thing. Also, it is effective to grasp the whole picture of the Kii Cloud SDK with Hello Kii.
You might need to use time-series changes in state information on the mobile app for graphs and so on. In this case, you can work with such history data by storing KiiObjects generated in time series in a bucket in the thing scope and getting them in the order of time.
Kii is planning to release a new version of Thing Interaction Framework which can process the history of state information. This built-in feature assumes that state information will be saved at a predefined interval. However, if you cannot estimate the interval to send state information or you want to save all of the history data, the Kii Cloud SDK can support your needs in the way mentioned above.
Note that state history data should not be saved too frequently because it will affect the API usage or service use fee and the server performance.
You can process relatively small binary data by converting it to a string with an encoding method like Base64 but it is appropriate to use the object body feature for data like images from web cameras.
In this case, create KiiObjects which store object bodies in a bucket in the thing scope and then browse and use them from the mobile app. Note that the object body feature serves well for purposes like saving visitors' face photos but it is unsuitable for resource-extensive processes like real-time video sharing with the mobile app via Kii Cloud.
It is efficient to use the Kii Cloud SDK if you want to save data, not per thing but per user. For example, it is efficient in storing measurement history data from the weight meter. This scenario would apply to a case where multiple users share one thing but each user should have access to their own data only.
Create KiiObjects in a bucket of the KiiUser who is the thing owner. This implementation provides strong security because buckets in the user scope exist per user and others cannot access KiiObjects in such buckets without a password.
Note that you need to grant write access to the thing because things cannot write to owners' buckets by default.