Issue
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,
- activity registers a receiver for network responses
- activity initiates a network operation by starting an intent service
- 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,
- first, don't use intents to communicate between activity and service
- create two blocking queues: network requests and responses in say the application class
- service starts a thread that
take()
's from the request queue - activity starts a thread that
take()
's from the response queue - activity
offer()
's to the request queue when it wants to start a network operation - service
offer()
's to the response queue when post the result of a network operation
Solution
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:
- Activity starts, a so called, sticky service.
- Service registers the receiver for network responces.
- Service maintains an Ibinder object with the needed information based on the network responces.
- Activity bounds to the service whenever it wants and retrieve the Ibinder object with the info and does the required actions.
- When it's time to end the application, Activity stops the service and finishes itself.
Hope this helps...
Answered By - ChD Computers
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.