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
On Wed, Nov 3, 2010 at 9:33 PM, Bret Foreman bret.fore...@gmail.com wrote:
The background threads are in IntentServices
IntentService already has and uses a background thread and is not
designed to fork other threads.
If I use createPendingResult in the
calling Activity then I end up with a
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
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 background threads are in IntentServices and I've run into issues
no matter what method I use. If I use createPendingResult in the
calling Activity then I end up with a PendingIntent object, which does
not fit into the startService method that kicks off the IntentService.
Perhaps I can use a
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?
On Wed, Nov 3, 2010 at 6:33 PM, Bret Foreman
On Mon, Nov 1, 2010 at 9:29 PM, Bret Foreman bret.fore...@gmail.com wrote:
Well, I ran a few experiments and haven't yet found a way to make this
work. The problem is that I have a set of background threads that are
updating various rows in an SQLite database. I also have a UI thread
that
On Sun, Oct 31, 2010 at 12:01 AM, Doug beafd...@gmail.com wrote:
To be fair, the javadoc for Intent.filterEquals() says nothing about
if or when a broadcast intent would be dropped for any reason. Or do
you think it's implied?
That's because broadcasts aren't dropped. I don't know what
Well, I ran a few experiments and haven't yet found a way to make this
work. The problem is that I have a set of background threads that are
updating various rows in an SQLite database. I also have a UI thread
that needs to know about those updates so the widgets can be updated.
I believe
On Oct 30, 12:18 pm, Mark Murphy mmur...@commonsware.com wrote:
I know I've read about this behavior in this forum in the past but I
can't find in the documentation where this duplicate elimination logic
is described in detail. Mostly, I just want to differentiate the
Intents enough that
On Sun, Oct 31, 2010 at 3:01 AM, Doug beafd...@gmail.com wrote:
To be fair, the javadoc for Intent.filterEquals() says nothing about
if or when a broadcast intent would be dropped for any reason. Or do
you think it's implied?
Whoops. I misread the original question, thinking we were talking
11 matches
Mail list logo
