Thanks, that helps. First question: do you really want to use a Service at all? This sounds like a typical scenario where an app would just start a thread in the background to fetch the data. Basically how the browser works.
You actually don't want a service for this kind of thing, because for the case it makes a difference (the user leaves your app, memory is running low, and now we are looking for things to kill) it would be better to *let* the system kill your process than to put it into a tighter fix by telling it with a Service that you should be kept around. Since you can always re-fetch the data from the server, the absolute worst case of not using a service is that when the user returns to your app whatever you were in the process of fetching when they left is still not there and needs to be fetched again. This is the kind of thing where I would just make a singleton for my data access, that has a thread to do network fetches in the background. When an activity wants to show the data, it gets the singleton, asks for the data, and gives a callback to be called when the data is ready (if it wasn't immediately available). On Thu, Nov 4, 2010 at 8:19 AM, Bret Foreman <bret.fore...@gmail.com> wrote: > Dianne, > > Let me back up and give more context. My Activity draws various > TextViews and other UI elements with data from a local SQLite > database. When it can't find the data it needs locally, it draws a > placeholder icon and generates a request to a web service for the > data. The interface to the web service is enclosed in an IntentService > which handles the background activity associated with the web service. > When the data comes back, the IntentService places it in the SQLite > database and generates a broadcast Intent back to the Activity, which > has registered a receiver to receive the Intent. The Intent includes a > tag so the Activity knows which UI element can now be drawn with local > data. This tag is held in an Extra Bundle inside the Intent. > > This all works about 2/3 of the time. However, about 1/3 of the > messages are being "lost" somehow. No exceptions are being thrown and > there is no message in the logcat that seems associated with the > receiver dropping messages. > > One added wrinkle is that my Activity encounters 10 UI elements where > local data is missing and so it generates 10 calls to the > IntentService in the space of a few milliseconds. 6 or 7 Intents are > returned and 3 or 4 are missing. The exact number returned varies > depending on the run. The entire process takes about 10 seconds. > > My understanding from Mark Murphy is that this is expected behavior, > that Intents that look similar and arrive close by in time are > considered duplicates and one of them is dropped. > > This behavior is not that hard to demonstrate in a test project so I > could generate a case in b.android.com if you think what's happening > is contrary to what should happen. It occurs to me that the Android > regression tests may not cover the case of multiple calls to the > IntentService spaced over a short period of time and sending back > multiple Intents. If you think the behavior I'm seeing is incorrect > then it sounds like there is a concurrency problem in the > sendBroadcast method of the IntentService. Maybe sendBroadcast is not > re-entrant? > > > On Nov 3, 8:15 pm, Dianne Hackborn <hack...@android.com> wrote: > > I can't even follow what you are doing. First you were talking about > > broadcast receivers, now you are talking about > Activity.createPendingResult. > > > > Could we back up and start with a high-level picture of what you are > trying > > to accomplish? > > > > > > -- > 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<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
