0

What is the best way to get data from server as fast as it gets to it? (Like instant message, or simple broadcast for example).

I first thought about using miniature web server in android and get post requests to it with data. However with this approach I soon understood that I will get many problems with NAT and similar issues.

Later I thought about manually pooling the server from android, but it seems somewhat flaky approach to problem, because data is got in irregular intervals (like image with some text).

I was thinking about using something like webrtc or rtp to have connection between server, but these approaches are somewhat complex and half baked. I found very little info on those about data operation. Thought I managed to get in my „experiments“ video and sound transfer, I found very little info how to get data transfers.

What should I do? Now I am thinking about having some connection to server and getting some events in android, which when I got update in server could download everything from server.

Update:

My data is encode64 processed html5 canvas png image. Probably I will add to it some text data to blob. It is generated on webpage it should reach phone as fast as it can through server. The problem is part where image data goes from server to phone. Data size per request is ~50KB.

  • 1
    Could you clarify what type of data you are sending and expecting back from the server? This could determine what technology you should use and if there is a library out there to help you. – Keagan Ladds Mar 14 '14 at 9:24
  • Updated my post. – IBr Mar 14 '14 at 9:39
  • 1
    Looks like might need to write a custom protocol that keeps a connection open between the client and server and then send a message to the phone to tell it that the file is ready – Keagan Ladds Mar 14 '14 at 10:17
  • 2
    HTTP is not built for persistent, stateful, two-way communication. Using it to achieve this is using a hammer to insert a screw--it might work, but you're actually looking for a screwdriver. Create your own protocol and hold open a connection, maybe with push notification support for resuming connections after a long period of time because holding open a connection constantly won't make for happy users. – Phoshi Mar 14 '14 at 10:56
  • 1
    You might use Google's cloud messaging platform for notifying the app a file is available, and then simple HTTP for downloading the file. – GrandmasterB Mar 14 '14 at 15:22
1

I'm not quite sure about the scenario you are trying to describe but would a pub sub model help? Publish messages to a topic and have anyone who is interested in that information subscribe to the same topic. MQTT is a light weight pub / sub messaging protocol that only has 2 bytes of header and so is quick. There are several clients and servers available, some that are open source or free to use e.g. Eclipse Paho client and the Mosquito server.

  • I think something like that might work. I will look up to it. – IBr Mar 14 '14 at 11:17
  • Redis (which has a good pubsub protocol) and ZeroMQ are other possibilities. – user16764 Apr 13 '14 at 19:28
0

Depending on the device you're using, you're going to struggle. Android has a couple of problems in the design of its networking subsystem that are going to cause you grief.

The primary issue is power management. Android devices are, as a rule, mobile devices running on battery power for the majority of the time. Therefore, they conserve power as much as possible, aggressively putting the cpu to sleep whenever it hasn't been locked in an awake state. In many android devices, this causes the device to stop receiving packets on any wireless network it may be connected to. This makes a push protocol over wireless next to useless: in order for it to work you have to keep the cpu awake, which will kill the battery pretty quickly.

You may think you can solve this by not using the wireless network but connecting to your server over 3g, but this doesn't work. Android automatically prefers wireless over 3g when it is connected, and the only api that lets you use 3g by preference is only usable for short duration connections because it has a timeout that is limited to a short period (30s, iirc).

Now, if you can restrict your target device to one that supports wake-on-wlan, maybe you can make it work, but you'll find it tricky.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.