This came up in another thread, but it is kind of its own topic, so I’m going to throw it out here.
What are the imp-lications (sorry) for bidirectional agent - mobile app communication. If a mobile device was able to send its network address to the agent whenever it changed, is there or should there be a way for the imp to store that information and then send requests to the mobile device when an event occurred. Good idea? Bad idea?
You can’t ping an external IP address of a mobile device…?
I can’t ping mine, and I’m also assuming that it would or could change with my location, and or switching to WiFi. I am specifically asking about how it might be handled on the Imp side, since handling it on the mobile side would be its own problem.
Even if you knew the IP address you couldn’t expect a TCP packet to get delivered to all mobile devices.
An HTTP request from the mobile device can be answered much later by the Imp. So it needs to be sent again regardless of the response. I can’t remember the details, so let’s wait for someone more knowledgeable to notice this thread. I do recall that the request can be answered much later before timing out. I can’t think of a better method short of creating yet another intermediate server. Can you?
No, and that is probably the answer for now. I’m not sure what would go into a proper service for communication with and iOS device, but I have heard @beardedinventor talk about using Parse, and I am reading through some tutorials by Ray Wenderlich. Maybe @Hugo will chime in and give us some insight. 
It could work if the timeout was for example 10 minutes. Then you could send the request to the Imp every 10 minutes. It would reply immediately when the status changed.
Mobile devices are generally behind carrier grade NAT; they are not contactable from the internet in general. Much like imps behind your firewall, they can only make outgoing connections.
So - for an imp to be able to send data to your phone, the phone needs to poll (or long poll) the agent, which will give instant data delivery whilst the long poll is active. If you want notifications at other times, you need to use a push service - the phone keeps an outbound connection open to the apple/android push notification service, and notifications form the agent (via a push service, right now) will get forwarded via this service to the phone.
I have an (incomplete) example for the Hannah Rev2 board that uses the longpolling technique to get “real time” data from an imp. See https://github.com/deldrid1/electric-imp-Hannah_Rev2.
My example uses javascript in a client webbrowser and is still a little flaky but should be easy enough to implement in a mobile app.
Interesting. So the iOS app would send a “status” request on a thread that didn’t block the main thread, and wait for the imp to reply. The imp would receive the request, and check if it has something to reply about. If it did, it would reply, and the process would repeat. If not, it would wait until it did, and then reply, and then process repeat.
That’s the basic idea. One other wrinkle is that the current request timeout for a request to an agent is only 60 seconds (but that is supposed to eventually be changed to 10 minutes). So you have to resend the long poll request every minute currently.
I also resync the state between each long poll request… As part of browser security you have to send an HTTP OPTIONS preflight message then your actual HTTP request when doing cross-domain JavaScript Ajax requests - this is fairly quick but with a fast event, like a button press and release on Hannah, it’s easy to have the client UI get out of sync.
The only other issue is that Agents only support 3 or 4 concurrent open requests (per imp) so you are slightly limited to the number of connected clients without using a server somewhere. Also, if you want messages when the app is closed you’ll have to go the push notification route like Hugo mentioned
I got the first part of this going, and I am pretty pleased with it, so I had to mention. For the security system application that I am working on, whenever I open the iOS app to control it, or the application is running and you pull it to the foreground, I wanted to be able to check on the state of the system, and then update the switch controls to the actual state of the device. The two states are essentially whether it is armed to send SMS messages and if the siren is armed. So, the app sends a status request to the agent, the agent asks the device, the device checks the variables and replies to the agent with the status, and the agent responds to the iOS app. Currently, I am performing a string compare on the response string and evaluating it with if statements that then set the On/Off status of the arming controls. I’m not sure if I can send JSON back in the response, but that would probably be more elegant. In any case it works, and now I can have multiple apps update themselves to the actual status of the system whenever they are opened. I suppose i could poll it regularly to make sure the state hadn’t changed while you were looking at it, but that isn’t likely to happen unless two people are simultaneously setting the state.
@deldrid1 You should be able to td 10 minute long polls now (well, just under if you want to be safe). We’re also now 8-bit clean the whole way if you wanted to send binary data.
8 bit clean means we need a new audio sampler example? No more Base64 encoding? Can you point me in the right direction Hugo?
Correct, no need for base64. Not sure we have an updated example… Tom/Matt?