I am working on a simplistic two-way communication model with Spark. The idea is that someone could push a button attached to the Spark which would trigger an alert. (This is simple to do with IFTTT.) The alert recipient should then be able to respond and the Spark would display the response.
I am struggling on the latter piece particularly since I would like to make the response free form. (Think a simplified text or email that would be displayed.) Can someone provide guidance on the most efficient way to do this? Should I use IFTTT functionality or something else?
That makes sense. I have played with functions, but the requirement to use an advanced REST client to submit the correctly structured request is extraordinarily confusing to me. Don’t get me wrong, I have tested it out and gotten it to work, but I cannot understand how to use it in a way that a normal (read: non-technical) person can use in an intuitive and secure manner. (Can you point me to any resources on this topic?)
My original thought was to rely on IFTTT for both alerting based on the button condition and then publishing an event as you indicate. However, I am still trying to get my head around how I would do that and hence the question.
Finally, your TCP question is curious too. Any link to more information on that?
I guess what this all comes down to is that I understand Arduino/Spark programming reasonably well, but generally struggle with using the REST API in a way that is simple and secure. I use it all the time with a REST client on my phone and laptop, but that approach really limits Spark interaction to techie nerds like me.
I really need to better understand how to really leverage the API. Unfortunately, I don’t think that Spark’s docs are strong in this area. They simply tell you how to call the API and assume that the reader know how to create an app outside of Arduino that can properly structure the call. It is quite overwhelming and I am not even sure where to begin to learn this.
Sorry for the venting and thank you for the suggestions!
It all depends on how you're planning on using it. You can create a mobile app, a web page, a C program, a windows app, etc. There are multiple options you can choose to visualise your data. I am personally biased towards a web-interface since that's pretty much platform independent as long as you can open a browser.
Let's say you'd create a webapp and decide to use the SparkJS library to call Spark.function(). You could create a text box in which people could insert their message, after which it gets send as the argument when they press some button. That's how I made this page. That works pretty well, as long as you keep the 63 character limit in mind. You could of course choose to break the message up in to smaller parts on the client side, send them separately, and combine them on the Core. @bko made some really neat tutorials on how to interact with your Core using a web interface. You can find them in the tutorial category (search for "bko" in there). The SparkJS library can be used to complement that, and perhaps make it a little bit easier.
IFTTT can definitely be used to trigger alerts. Webhooks might also be really neat to use. I regard to sending answers back via IFTTT; I'm not sure whether IFTTT is most suitable for that. I haven't really played with it that much, but I think it's going to be troublesome setting up. Not sure if there's an easy way to fill in any text, and send that without having to configure some new recipe. I could be wrong though!
Sadly, I won't be of much help here. I know the option of TCP exists, but have never tried it. You can try searching the forum for it, since there are several topics about it. Also, a more general Google search might be able to provide you more adequate information. Perhaps some of the other people over here can chime in and shed some light on your options (@kennethlimcp, @peekay123)
The docs are in no ways perfect, but in this regard, I'm afraid there's not a lot more that can be done. In the docs, that is. They're meant to document the functions, and that's exactly what they do. They tell you what the functions expect in order to make them work. How you decide do that it entirely up to you. Just like the documentation of your car will tell you there's a steering wheel in there, but not how you're supposed to use it.
Advantage: you're entirely free to choose how you're going to use it.
Disadvantage: you're entirely free to choose how you're going to use it.
It's not that the docs (or the ones writing them) don't want to tell you how to use the API, but it's nearly impossible to do so. Almost every programming language can, in one way or the other, make a REST request. To provide instructions for each and every one of them would be a humongous task, and very prone to errors.
The great thing is that it's not necessary. The API doesn't care how you construct your requests, as long as they comply with the specified rules. If it expects a header and a body, you should give it those things. Your whole external process can be one big black box, as long as it outputs a header and a body compatible with the standards set by the API. The same goes the other way around. No matter what you Spark does, it will always output a header and a body(for example!). As long as you know that, you can take that into consideration when you design the receiving end.
To put it into simply terms: they give you the tools, it's up to you to use them
Compare it with the documentation of a nail (those things you hit). "In order to use the nail, an impulse needs to be applied on the flat end". The guys writing the nail's docs aren't going to tell you to use a hammer. For all they care, you use a shovel, which also works. You could even hit it with a screwdriver if you'd like to. As long as you can provide the required impulse, it doesn't matter what you use.
Compare that to the Spark docs:"in order to use the API, a properly structured REST request must be applied". No one is telling you what to use, since there is no "perfect" way to do it, rather, there are different ways. You can create such a request by javascript, C/C++, Python, etc. It doesn't matter which one you chose, as long as it complied with the specs.
It's not the docs you've got problems with, it's the lack of examples. The great thing about a standard is the fact that there are multiple sources to find the required info. Any guide telling you how to create a REST request is going to work here But there's always the tutorials category if you're looking for something specific. I believe the guys/girls at Spark are also working on some examples.
I'm going to stop typing now, or I might as well sell this as a novel Feel free to ask any more question you might have. I'll try to answer them to the best of my abilities. Good luck!
@Moors7, well said
To jump to your side, @JL_678 if you could give us some more info of what particular way to trigger the response you’re thinking of, would limit the abundance of possible answer to this short question.
If the other end has got a Core too, the answer will be completely different to the answer for a smart phone, or the one for a log fire and wet blanket response
I don’t disagree with @Moors7 points and am trying to decide how I get to the end goal. To his point, creating Spark functionality requires significantly more than just Arduino programming knowledge, and unfortunately, my knowledge of Web development is limited. Admittedly, this is my problem and not Spark’s, but I am rapidly realizing this challenge as I graduate to more advanced projects.
Regarding the end point, I am thinking that the remote person would interact via a mobile device. Hence I would want to use a Mobile friendly communication method like email, sms or perhaps even a mobile app.
But there's always the tutorials category if you're looking for something specific. I believe the guys/girls at Spark are also working on some 
Feel free to ask any more question you might have. I'll try to answer them to the best of my abilities. Good luck!
