My robust/simple alternative goes like this:

1. Activity shows data taken from a ContentProvider.
2. Activity sends an Intent to an IntentService to get new content.
3. Service fetches content asynchronously and inserts it into the
ContentProvider.

Through configuration changes or whatever, the framework keeps my
Activity in sync with its data.


On Aug 28, 11:48 am, itai <i...@live.com> wrote:
> 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to