Hello!

I want to create an app that is listening for received data and triggers something on that event.

I know how to listen to incoming SMS messages, which can trigger the app to start and that works well. But what if I don't want to send an SMS to the phone but still want the same effect? Like, just sending some data from a server to trigger the app on the phone? Is that possible? If so, what would I use?

Thanks in advance for any replies
/Damonh

Hi,

Make the app to maintain a constant Socket connection with a server and listen for some data. Regularly check if the connection is still up. I don't know how reliable this sounds to you, so another option is to make the app regularly check the server for queued events.

Android developers

Hello appforce and thanks for the quick reply!

I have some reading up on servers to do (I'm just somewhat familiar with socket connections but I've never implemented them myself). But I'm happy that it doesn't seem like a big deal

About the reliability. If the connection would for some reason be lost, would it be fine to just establish it again without the user noticing, since the app will still be run hidden (until the "correct" data is received)?

Hi Demonh,

Well, depending on your needs it's not always "not a big deal". How fast you need to respond to the event?

And reconnection on lost connection is not that easy to detect, without regular checking.

Android developers

Thanks again:)

A response within seconds would be great, a response within a couple of minutes is still ok. The app "just" needs to receieve some data and update some variables a couple of times every day - and every time it's been updated it should notify the user by popping up on screen. So, if it takes a little time from that the data is sent from the server to the app actually being triggered, that's fine.

So, what if I'd go for the first alternative: Attempting to maintain a constant Socket connection with a server and listen for some data, regularly checking if the connection is still up?

Define some heartbeat token that will be passed around. I can be a short sequence sent from client with some answer from the server. If client doesn't get response within timeout period or catch an Exception - reconnect. There is no way to find out broken connection at the very moment it breaks. If you have 2 threads - one for heartbeat and one blocked on input, listening for the events - you'll have "instant" reaction as long as connection is running. You will get extra latency only in the cases when event occurred while connection is broken and still in timeout frame.

If you go for the simple approach, pick some time for scheduled event checks initiated by client. It's a tradeoff between reaction time and traffic load + battery life. That's how GMail app works - I find that notifications on new emails are "instant" enough

Android devlopers

Sounds promising. So how about if I decide I just want to check for updates (defined in the client) at a couple of given times a day (and otherwise just idle and not check the connection unless I need to update "soon"), that should have a rather small impact on battery life right?

And what if the number of client apps checking the server in this way grows large, would it have a huge impact on reaction time or are we still talking "email notification time", i.e. usually within seconds?

And yes, sending some sort of "check" or heartbeat and reconnecting on a timeout was what I had in mind before Again, sounds easy enough Gonna look up how to do it!

I believe if you choose your update interval between 1 and 5 mins you won't have to worry about battery life. If your token is small enough you can even go lower. Anyway, you can see some real-life values if you leave the app running for a longer period and check what Android reported in "Battery use" section of "About phone" (you won't hit top 5 if you code it wisely).

Client count will not cause server slow, but open connections are limited resource and having too many clients can reach server's max. My advise when many clients are expected: open connection once every 1-5 mins, check for events, close the connection.

Android developers

Good stuff. Sounds like it can do what I need at a reasonable cost.

Thanks a lot again for the great advice!