Should I understand and edit the given source code on github (which will take a significant amount of time for me) or should I wait for android SDK for easy making of android app, As there are too many classes in code. What Would You suggest?
Just read the cloud code API, and learn the curl commands. It’s generally just doing http request. Event subscription maybe a bit more tricky but I have no doubt there already plenty of library to use on Android with slight (to no) modification needed.
But Tinker app src code contains much more than that , Why have they used all those class file? Sorry I don’t want to be rude.
Not sure about Android side of things, but on iOS there are plenty that you don’t really need.
Ultimately you just need to do 3 main API calls, reading variables, calling functions, and subscribing to events.
You don’t need to login, just paste the access token in directly (or just hard code it).
You don’t need to claim, rename, or do anything against your Core meta data.
You don’t need to flash a firmware from your app.
Unless you want to.
Even implementing your own tinker app is not that hard…
2 Likes
I can second this, with some comments added.
Storing tokens inside the app or, even worse, hard code them should be avoided. As a safe place the keychain is an option.
However, the main cause of problems is expiration. Sooner or later tokens will expire. Maybe this will change in the future, but right now this is wishful thinking. You will install a future bug.
An option is to use your spark account directly, request all your tokens and use the one that fits best. If there is none, you want to create a new one. This is pretty easy, once you are logged in. Most of the web-service page you may find are going this path.
IMHO you have to claim your core to pair it against your tokens, but otherwise agreed.
It depends on. For simple task controlling a core with the Tinker app is absolute sufficient.
More sophisticated tasks almost mandatory require some programming, and then you're off the hook.
1 Like
It's not bug, it's feature. You'd want a way to sever the connection if someone else got access to the token, or you, yourself, accidentally upload the token to github during dev time. Kill the token, use a new one. If it expires, just paste in the new one. Not a big deal, especially it'll save plenty of time during prototyping / tinkering stage (which I think where the OP is at).
If you have and want to spend the time to implement everything right at first go, sure, why not? My suggestions were focusing on building the MVP for the app (which is what I believe Spark is focusing on as well for the hardware side).
I'd assume when one is ready for mass production, they should contact Spark directly and will be provided with (similar but) different sets of API access, by that time you should have secured the funding and time to implement everything properly.