0

I have a long running Content Provider, basically it is doing some searches in the cloud & returning a cursor w/ the results. My issue is that depending on the connection and load of the server. Results could take 5-7 seconds to return.

It seems that if I am using the Content Provider for predictive searches, that it is blocking additional queries (from the same activity) until the previous one returns.

Any suggestions on how to cancel the provider query?

I have tried using asyncTask & Thread, to no avail. It seems that I am still getting blocked on the Provider (resolver)

RandomMooCow
  • 734
  • 9
  • 23
Chrispix
  • 17,941
  • 20
  • 62
  • 70

2 Answers2

1

Maybe you should use the content provider only for accessing the local SQLite DB and do the long operations in a service.

Take a look at this video: Google I/O 2010 - Android REST client applications. It's about building a REST client application but you can use a similar architecture for the background stuff.

Gal Ben-Haim
  • 17,433
  • 22
  • 78
  • 131
  • Thought about this actually. Wanted to expose the results to people app search. Guess the content provider could connect to the service. It was basically modeled after the Exchange GAL search. Which is a provider. – Chrispix May 09 '12 at 18:51
0

Looks like in JellyBean, there is a new option to cancel() a content provider query.

I actually ended up taking your advise, and rewrote the content provider to get a cursor to a sqlitedb, and used an intent service to update the db.. Works pretty darn well..

I did run into one issue where if the provider gets killed, the client does not seem to get notified, and could keep sending service intents w/ no response.. A couple ways to handle this (in the provider I could change that to do a broadcast event w/ the original uri, that the cursor is disconnected, but that is somewhat slow)..

I ended up just answering my own question which may help someone in the event that a provider gets killed while you are connected...

Content Provider w/ Cursor - Gets Killed (how to notify client)

Community
  • 1
  • 1
Chrispix
  • 17,941
  • 20
  • 62
  • 70
  • I just worry about my own exceptions inside the content provider. Why do you worry if the content provider would be killed *outside of your code*? And regarding to your concern about cancelling a query to the content provider, maybe this could help: http://stackoverflow.com/questions/13740828/contentprovider-how-to-cancel-a-previous-call-to-delete –  Mar 27 '13 at 02:12
  • The reason you would want the client to know that the provider has been killed is because the reference to the Cursor would no longer update w/ relevant records. So the client would still continue to send service intents, but their cursor would not update. This way, they can check to see if the provider / cursor is still valid, and if not re-request a new cursor. As far as worrying about stuff outside my code, people have task managers which could technically kill the provider, take the cursor with it. This helps keep your app functioning and best user experience. – Chrispix Mar 28 '13 at 13:47
  • In that case I would just inform the users that task killers are worth nothing and harmful. I too, I do keep taking care a lot of user experience with my apps. But you do it harder than me. I admire your effort. I'm sure your users are spending great time with your app :-) –  Mar 28 '13 at 14:04