Develop Reference

Android What happens during HTTP transaction if Device sleeps?

I couldn't produce this example which iam about to explain, so i post this here to give me more info about it.
Lets say that we want to make an http request to receive a JSON object from a server. We hold no wakelocks nor we make our app a foreground. We make the connections and we wait for our response from server.
What if the device goes to sleep at that very moment (waiting for the
JSON object). Do we get the object when the device awakes or we get a
timeout exception?
NOTE
Do not involve doze mode in this example. Just that device goes to sleep.
Thank you

When an Android is kept idle, the device locks and then it goes to
deep sleep mode. In deep sleep mode the Android system, closes the
existing network connections like TCP or UDP. If your app is connected
to a server, it loses connection to the server and tries to reconnect
based on the reconnect attempt methods configured for the client. But
if your app is the server, all the client will lose connection to the
server, and you have to start the socket again in server and try to
connect once again from the clients.
From https://stackoverflow.com/a/33366487/806328
retrofit just "listens" for network connection, when it loses it - connection time out error after specified time

In this case, your device will got to sleep and you will get Activity Life Cycle Method Call back that is onPause() and onStop while your service will be running. This process will not make your webservice call stop. Once you get response from server your app will get call back (if you have implemented). And nothing bad will happen until you have killed your app before going to sleep. If after web service you may be accessing some variables belonging to activity that started web service. This will lead crashing.call. When you undo sleeping state you will get call back of onStart and onResume That means when your device went to sleep it did not kill your activity.

Android: when should application notify the server client disconnection

I read the Last Safe Method to be called before killing the application in Android is OnPause.
Suppose I have client running on Android that is a part of location based Client/Server application. I have some design issues:
When I create the main activity I though it is logicall to start a service that connects to the server (running on my computer) and updating it in with the user location.
Now, when the application is active I want to present the user some information. Even if the user paused the activity I want the service keep running in the background and update the server. I also want the server to know when user disconnected.
Now because OnPause is the last safe method guaranteed to be called by the system, I don't know where it's best to notify the server of user disconnection.

How to get results from a background service but still keep it running in android

I'm developing this dating app that allows users to browse profiles downloaded from a server.
But I'm not sure what kind of thread or service I should be using to do the uploading to and downloading from the server.
It has to be a service that runs in the background that first connects to the server via a socket and then waits for commands from user input (from the UI thread).
I read about the Service and IntentService classes.
IntentService seems to be appropriate except that it is destroyed once it has finished its job and returned a result to the calling thread. I need it to keep listening for requests.
I could start a new service each time but that means I would have to reconnect to the server with each request (let's say each time I browse a profile). That doesn't seem right.
Can anyone tell me what is the best approach for this purpose?

If you are asking about how to make the client send download/upload requests outside UI thread, then you could try using AsyncHttpClient. I've been using that in almost every application I developed, and it is highly reliable.
But if you want to send data from server to the client (in other words, client keep listening for any incoming data), I recommend you to use GCM. Here is a step-by-step tutorial of implementing GCM in Android device.

Android application design choice

I am new to android development. I want to create an application that opens a connection to another device in LAN and send /receive request/responses. Its like a GMote application.
I am thinking about creating a service in which I create the connection. My activity will have to send/receive using this service. The connection will remain open as long as the service is running or the devices are in LAN range.
Can there be any performance issue with such approach, like any cost of communication between activity and service? Some of the actions in my application can send message after 200 millisec delays for 2-4 seconds.
The other way is to create the connection in activity, but then I have to create it every time my activity starts. The OS can terminate the activity any time if it is not in focus.
Which approach is best suited for such used application?

Android Service design - start with activity or only when needed?

I'm an android noob that is looking for some advice on how to properly use a service in Android. I am building an app that will connect to a server on the Internet to get a data stream via TCP. That data then needs to get send out to another device that is connected via a bluetooth serial port. I want this to continue to function in the background while the user looks at a different activity.
The app will be a NTRIP client, which pulls real time RTK correction data from the Internet and sends it to a RTK GPS receiver that I connect to via bluetooth. The data rate will be about 500 bytes/second. The user interface is a single button to connect or disconnect the data stream and some text to show status of the GPS receiver. There are also a few settings that will need to be configured by the user such as the IP/port of the server to connect to and the bluetooth device to communicate with.
I think I need to have the main activity spawn a local service, and then have the service spawn a thread for the TCP stream and another thread for the bluetooth connection. Does this sound right?
What is the best model for the service in this scenario?
-Start(bind) the service every time the activity starts, and have the connect/disconnect button send commands to the service to start/stop the threads. If I go this route, the service will continue to run after the user disconnects and goes to another app. The service would need an inactivity timer to terminate itself.
-Start and stop the service when the user presses the connect/disconnect button. The service only runs when data is moving. If I do this, the activity will need to see if the service is running when the activity starts, in order to know if it should bind to the service or tell the user that the link is disconnected.
Thanks.

I'd go with your second option. Checking if a service is running or not is an easy task and also you won't consume unnecessary processing time which will be better for the battery life.
Just because you can run a service for a long time in the background doesn't necessarily mean that you also should do that. At least not all the time.

As android supports more than one entry point into the app, you could define two entry points in the Manifest.xml.
<category android:name="android.intent.category.LAUNCHER" /> defines, that this class could be started from the launcher. I guess that would work for a service, too. I would do two entry points. One which spawns the activity first and gives the user some configuration control. And another which simply spawns the service.
As you have no control over the lifetime of an activity i would not suggest to do anything which should not be ended by the system. If you have an incoming call your activity would simply die.
If the user starts the service you could create an widget with the button. If the user starts the activity you could start the service and the widget.
And if the user starts the widget, the user decides, what should happen with the service.

I'm not a Java or Android programmer so take what I say with a grain of salt. The normal way to handle blocking IO in Java is to use threads. It sounds like the data flow is unidirectional but for maximum flexibility I would create 3 threads, one for the UI, one for the TCP connection and one for the bluetooth connection. Communication between the UI and two worker threads could be done using shared variables (need to careful about synchronization, race conditions, etc). I would pass the data NTRIP data to the other worker using a multi-threaded queue data structure.
The worker thread for the NTRIP data would be roughly:
while (app running) {
if (connection enabled) {
if (not connected) {
c = connect to remote
}
data = get data from c
queue.put(data)
if (options reconfigured) {
close c
}
}
}
For the bluetooth thread:
while (app runnning) {
data = queue.get()
if (UI settings changed and connected) {
close connection
}
if (not connected) {
c = connect to remote
}
send data over connection
}
In the normal state, both workers are blocking on IO and will be consuming essentially no CPU time. Based on my experience, I would recommend you write your code to handle communication errors. For your code to work well in the real world you have to handle connections closing, hanging, etc. Making it robust will likely be the most time consuming part of the development.