There are a few reasons why I want to do this in a service: 1) In my development roadmap, the web services interface will eventually be contained in a content provider accessed by multiple applications. The service container is a good intermediate step. 2) A lot of things can happen when web services are involved - some data fetches might time out, the network might be unavailable or congested, the server might throttle the number of parallel fetches allowed for a given account. The service container is a good place to handle the complex logic of handling all these conditions and presenting a sensible result to the data consumer. 3) I'm dealing with a collection of web services, each of which has its own authentication policies. The service container is a good place to manage that.
On Nov 4, 1:22 pm, Dianne Hackborn <hack...@android.com> wrote: > 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
