Develop Reference

Options on Android for real time sending of data to a server?

I am currently working on a small scale project to prove something works, I currently have a smart band device which has an Android SDK.
From this device I use the SDK to track a users heart rate in real time.
So my Android application receives updates to the heart rate in real time.
This was fairly easy to do however I now need to send this data in real time from the Android device to the server as efficiently as possible.
To start with battery drain is OK as initially this is just a proof of concept.
I have limited experience with sending large amounts of data to a server in real time and I was wondering if anyone has an ideas on what might be the best approach on Android?
I have looked into Sync Adapters but these seem to be more about keeping data aligned between the client and the server, this is something I am not concerned about. Another approach would be to see if the RequestQueue from Volley might work but again I am unsure if looking into this is even worthwhile?
Should I be looking into creating a Service and somehow using a socket to transfer the data?
EDIT: It looks like IntentService may be the best option for handling the task execution but I am assuming http requests would be too heavy for the client and I should look into something else for the transfer?

I am working on similar kind of project but the wrist band I am dealing with is Empatica E4. Please bear in mind that I am not an expert developer, therefore I am also looking forward for corrections in my design. Also, I will try to justify my idea step-by-step and as much as I can. I hope that this will give you some hints for your application and help others as well.
So, my current architecture looks like;
First of all, Empatica has also provided an Android SDK to receive the data. SF stands for Sampling Frequency whereas EDA, Temp, BVP and AccXYZ are my sensors in wrist band. Each sensor has different sampling frequency and the maximum is 64 Hz which gives you 15 ms interval between each samples. This interval is quite challenging to perform all the operations, therefore I buffer the sensors data in (Volatile LinkedBlockingQueue) FIFO queue so that I don't miss any sample. This was all happening in the service of my application.
Now, I have a Runnable task that I have used with ScheduledExecutorService to collects samples from the queue with the interval of 250 ms (you can vary it as per your need but I used 250 ms considering my needs, network latency and the device performance) and put them in a single JSON object. Number of samples that this Runnable task collects are varying for each sensor, which are, BVP: 16 samples, AccXYZ: 8 samples, Temp: 1 sample and EDA: 1 sample. At the output, I have a JSON object with the data to be sent to my server.
For transferring data to my server, I am using HTTP POST request. The reasons are easy, fast, efficient and good for concurrency. I am using Volley framework which will handle all my network related issues by itself. So I just add the JSON object in the Volley RequestQueue and my client is done here. As you mentioned, you can use socket connection to achieve your goal but I have to use multiple devices, therefore in my case, sockets can be problematic to achieve concurrency. I also tried to do it manually by using HttpURLConnection but the code was becoming tedious and hard to handle.
Finally, I have a REST API (in Python) on my server side which will handle the POST requests, parse the data and insert it in my MySQL database. As of now, I am still working on this REST API to parse the data and store it in DB. However, I have tested my application and I am successfully receiving the data from my device to the server.
Regarding your question "Should I be looking into creating a Service and somehow using a socket to transfer the data?", it's an excellent option if you are working on a single device. If more than one device, i think Http is better option.
Regarding your second question, I don't think Http would be heavy for the client and Volley is taking all your pain on itself. You just have to make a request queue and voila !!! You can find plenty of good tutorials for volley and I particularly followed this.
I hope my answer will help you a little.
PS: As I am still working on this thing and I have not come up with the final product yet, therefore I cannot surely tell about the risks involved in it but I will keep you updated if something new happens. Also, I am open to any suggestions and ideas that can help. Lastly, the picture above is not very detailed, I made it for you, just to share how I am dealing with the same idea.

How to deal with slow Web services?

I have created a webserivce using C# on .NET and I'm consuming the same in an android application. At times while testing I notice that the web service is annoyingly slow and does not show results for minutes altogether. I don't want to put my user through this behavior of the application.
I am basically looking for a way such that the communication between the application and the web service can become faster.
PS: I am using asynctask function already to provide a separate thread while calling the web service. STILL it takes minutes at times to extract results from it.
Any help is appreciated!:]

I can't tell if you're saying the web service is slow or if it's just slow to be consumed on an Android device.
If the web service is slow on all devices I'd suggest first eliminating the possibility that it's just the speed of the web connection you're testing on. Obviously there isn't much that can be done about that. If the service is simply slow to respond I'd recommend running some profilers to determine where the slowdown is. If it can't be made more efficient perhaps this is a task better suited to be first requested and placed in a queue. When the task is complete alert the device that the data is ready.
If the Android device is slow I'd also recommend some profiling to determine what's eating up the processor.
Sorry if I'm stating the obvious here but these are the only options I can think of.

server client android application vs client only

Hi i'm relatively new to android programming and am trying to do the following. I want to create a messaging system in which immediate response is not (at least for now necessary). I am completely new to networking / socket programming but have followed this:
http://www.tutorialspoint.com/python/python_networking.htm
and have kinda got my head around it.
I have the following question with regards to best practice.
What are the advantages/disadvantages of method A and B.
Method A:
Have a server and client running on the app.
Method B:
Have a client running on the app and pinging the server every minute for data.
Apart from the obvious that Method B doesn't allow real time which is better suggested? Does a server application take too much memory / CPU / battery etc? I know a lot of IM apps exist, how do they work?
Thank you in advance

Why not use push notifications?
http://developer.android.com/guide/google/gcm/index.html

I would recommend Google Cloud Messaging but last time I checked you needed a dedicated server to install it. Or Am i wrong? I only had a shared server so:
method A: the difficult part, considering its a mobile device, would be to keep the connection alive when your phone changes IP (another wifi network for example) and
method B: you could make small simple messages in order to check if there is something new and update in that case. My app sent around 500 bytes every 30 seconds and I didnt have any battery related problems. It also didnt slow the phone down.

Design and logic for client/server networking games

I am creating a simple android game that deals with multiplayer and connecting to server. This is what I want to achieve for my game.
Client sends keystroke movement to server.
Server accepts input, update the state and calculates and returns new position to client
Client gets new position and update the screen.
I already have some code written and so my one of my threads sends keystroke to server, waits for the new position, then update the screen. The thing is there is lag between the player's movement. I think it has to do with latency. I also tried two thread, one for sending/receiving data from server and another is updating the screen. But it didnt' solve my latency problem.
Can anyone suggest a good design for networking game?
Do I need to do early prediction?
Do I need separate thread for fetching data and rendering screen?
P.S.This is my first time creating a network game so i have no idea what im doing.

The structure I prefer to use is to have one thread updating graphics and logic on the client side, and then one thread receiving and sending data to the server. If you have problems with latency, there is a magic option which might solve it if you want data to be sent continously. (at least this is the syntax if you are using java)
mySocket.setTcpNoDelay(true);
This option solved my latency issues when I sent real-time coordinates over a network.
Edit: I think TCP by default waits and bunches together data before sending it, which could be a problem if you want to send small updates fast.

Best technology for client-server Android App

I need to make for school an app that runs on Android. Actually there are two apps, a client and a server. Ther server runs on a PC while the clients run on Android devices. I want to know what is the best technology for this. I know RMI and WebServices are not implemented in Android so what are the alternatives (besides actually communicating with sockets in the traditional way). One alternative that I did not look into is REST, but I will need to be able to notify a client once another client has done something, similar to turn base games where Player A notifies Player B that he made his move.
Like I said, sockets do the trick, but are little low-level compared to RMI and WebServices and only want to use those as a last resort.

Keep it simple. Use REST and have the clients poll for updates.
Also, if you get to a point down the road where you need to scale, this solution is actually fairly easy to scale because your servers do not need to maintain connections. Since there is no shared state between a particular server and the client (there is shared server between the application and the client), you can easily add more servers to handle the polling and put them behind a load balancer.
You can also add in caching so that the polling just gets the exact same response without causing a re-compute of the response. You would then be able to have the back-end game-state servers update the caches when the game state changes. This would let you poll much more frequently and still have a very flexible, scalable architecture.

For a turn-based game you can take a look at XMPP (e.g. Smack) that is traditionally used for instant messaging. It would also be interesting to create a game using C2DM that is used for push notifications.
You can also look into HTTP streaming which is essentially an unending HTTP response in which player moves are fed into.
Alternatively you can look into binary messaging systems that are more suited for real-time games but still applicable such as RabbitMQ (what's wrong with a smooth turn-based game?).