I’m designing my app’s communication layer such that all http requests will be initiated by threads created in the context of a local service. My concern is about how to properly handle responses.
I read about several approaches and it seems that broadcast receivers are most loosely coupled in respect to the current activity instance receiving the callback notification. However, I’m concerned about missing notifications while an activity is in a pause state or simply recreated due to a configuration change… For example: t1 – User initiates long running request. t2 – Activity shows a progress dialog and sends an Intent to the service to start the async call. t3 – User tilts the device, causing configuration change t4 – OnPause is called, unregistering the broadcast receiver t5 – Service thread broadcasts completion intent (no registered receivers) t6 - Activity is recreated t7 – OnResume is called registering broadcast receiver t8 – Activity is not aware of the completion broadcast. I thought about overcoming this by tracking request/response in persistent storage and querying the state in OnResume before registering a new broadcast receiver... but my gut feeling tells me this is an overkill particularly for ad-hoc requests, plus there is no guarantee that the persistent state will reflect the valid state of a particular async call if the process would be killed when the call is in progress... overall resulting in many edge cases to handle. Does the environment provide a way to “queue-up” broadcast intents for a particular activity? Any robust/simple alternatives? Thanks, -Itai -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
