Question

We have a network client application, and we are trying to validate our approach to processing responses from the server in conjunction with device rotation. essentially, we do this,

1. activity registers a receiver for network responses
2. activity initiates a network operation by starting an intent service
3. service responds by broadcasting an intent it’s finished

our (perceived) problem is that when the device is rotated, the activity is destroyed / recreated. during the time between when the activity’s receiver is unregistered in onPause() and when it’s re-registered in onResume(), we may have missed the intent that is broadcast by the service.

is this a real problem?

if so, we have hypothesized the following solution,

1. first, don’t use intents to communicate between activity and service
2. create two blocking queues: network requests and responses in say the application class
3. service starts a thread that take()‘s from the request queue
4. activity starts a thread that take()‘s from the response queue
5. activity offer()‘s to the request queue when it wants to start a network operation
6. service offer()‘s to the response queue when post the result of a network operation

Answer 1

Yes this can happen in rare circumstances but it will happens for sure if the user receives a call. Again your activity will be paused and then resumed, If the user talks for a long time your activity will loose a bunch of broadcasts from the service.

My advice is that you must not use broadcasts to do two way communications between application’s in situations that a response from a component such as a service, requires immediate attention. What mechanism you will use is depending from the situation. In my latest project I am using a service in order to update an app-widget, in this scenario I am using static code in the service in order to do some queries or to request some actions.

Your thinking sounds good but it may hides a complex implementation, If I was in your position I would consider to use the built in service mechanism called Bound Services. I have not used it so far but it seems that it is covering your needs.

EDIT

So based on the bound services concept I propose the following flow:

1. Activity starts, a so called, sticky service.
2. Service registers the receiver for network responces.
3. Service maintains an Ibinder object with the needed information based on the network responces.
4. Activity bounds to the service whenever it wants and retrieve the Ibinder object with the info and does the required actions.
5. When it’s time to end the application, Activity stops the service and finishes itself.

Hope this helps…