>> or better you could document that using your provider takes
>> significant time and that users should do the calls asynchronously. In
>> general it's good for applications to do content provider call
>> asynchronously, since even local database operations could become
>> pretty expensive. See the AsyncQueryHandler class, which handles much
>> of the thread for you when trying to do async queries, or you could
>> also use the wonderful UserTask class in the calling app to do the
>> query asynchronously.
>
> I had a look at the AsyncQueryHandler class. Since it's an abstract
> class,
> would i have to extend it to make it work? I tried looking for
> examples on
> Google on how to use this class but couldn't find anything. I found
> what it does but didn't find anything on How to use it.

Hopefully we'll get some samples up soon that use AsyncQueryHandler.
You do have to subclass it, since it calls the on*Complete() methods
on itself when the operations complete. All of the on*Complete() calls
happen on the UI thread, so it's safe to change the state of the UI.

> Also, i still have a doubt after your response.
> In my initial approach, when i was not using a Content Provider, i was
> using the UserTask class to make my network requests (So that my UI
> didn't make a blocking call and the data was received in a separate
> thread).
>
> In my new approach with a Content Provider, if the caller app is using
> the AsyncQueryHandler or the UserTask class, (which i think starts
> another thread) , does that mean the Content Provider doesn't need to
> use the UserTask class to make a network request or does it still need
> to make the request in a separate thread.?

UserTask pulls a thread from a thread pool and AsyncQueryHandler has a
single thread per process that it queues requests on. In either case
it's safe to use that thread to do the network access from within your
provider, as the main UI thread will continue to operate normally. If
your provider is hosted in a separate process from the calling
application the binder IPC system will block the calling thread in the
application process and pull a thread out of a thread pool to make the
request on your provider in your process. You can also safely block
the binder thread pool thread on a network operation.

-Jeff

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to