5

In my application I need a lot of CRUD stuffs: read records from the local SQLite database, insert objects and updating stuffs. Most of the queries are so simple that they won't block even if run on the UI thread, however in this application I want to adopt the Windows Phone pattern: an out animation started immediatelty and an in animation started when the result is delivered.

I planned to use an AsyncTask for the job, however I noticed that Honeycomb (and the compat package) introduces this new Loader framework. The main advantage seems that data loaded by a Loader survive config changes. The LoaderEx project by Commonsware bridges between SQLite and the framework, but some problems arise.

  1. Resources cleanup: I use a single activity, create the SQLiteOpenHelper in onCreate() and close it onDestroy(). Since the loader manager may still be running, i check it and set a pendingClose flag on my callbacks object, so it will close the cursor and the helper when load finishes. I think not closing the database is not harmful, but SQLite complains if you don't do it, and I don't like error messages :) The point here is that data doesn't survive config changes, so the Loader advantage vanishes

  2. How many loaders should I create? Let's say I have the beloved Customer and Order tables. Loaders are identified by ID's like CUST_L or ORD_L, but every time the user clicks on some summary I want to bring in a screen with the detail. Should I restart a loader with different params, or should I init a new one with a random ID? This may happen dozens of times. Is the Loader framework intended for lots of small running jobs, or just for a few long running tasks?

  3. What's the purpose of using ID's inside the LoaderCallbacks interface? Why not a simple initLoader(params, callback)? I don't think one can reuse some piece of logic inside a callback: eventually he will branch (with if-else or switch on ID) so I don't understand the point of giving an identifier to the callbacks object, instead of a naive approach one-callbacks-per-operation.

I'm asking this because the whole framework seems overengineered to me and without real utility. I don't understand the point of centralizing code with a LoaderManager, and I can't see any new opportunity AsyncTask did not offer.

The only win point is config changes survival, but I can't exploit it because of resources cleanup, and I can't figure out an alternative way to close the SQLiteOpenHelper because (quite obviously) the SQLiteCursorLoader requires it but clean it up is up to the user. So AsyncTask seems the winner choice here, but maybe I'm missing something.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
Raffaele
  • 20,627
  • 6
  • 47
  • 86
  • 2
    "I'm asking this because the whole framework seems overengineered to me and without real utility." -- I do not know about "overengineered", but personally, I just use `AsyncTask`. I created `LoaderEx` to demonstrate how to create alternative `Loader` implementations, but shortly after releasing it, I concluded that `Loader` was more annoyance than it was worth. The sole exception would be if you were completely going with `ContentProvider` and could use `CursorLoader`, in which case I am ambivalent about using that instead of `AsyncTask`. – CommonsWare Oct 11 '12 at 10:39
  • 1
    So basically you agree with my assumptions? Did I make any mistake in my reasoning? – Raffaele Oct 11 '12 at 10:45
  • "So basically you agree with my assumptions?" -- for #1, while I agree it is nice to close the database, bear in mind that this never happens if you use a `ContentProvider` facade around the database, so the fact that the `ContentProvider`-centric `Loader` framework does not necessarily make this easy is not surprising. For #2, I can neither agree nor disagree, as you asked a question rather than stated an opinion, and I do not have an answer. For #3, I neither agree nor disagree, as I haven't given your approach much thought, as I do not use `Loader` for much. – CommonsWare Oct 11 '12 at 10:57

1 Answers1

4
  1. Content providers are much more powerful than "raw-DB" approach. Lots of links on stackoverflow lead to discussions on this.
  2. LoaderManager tries to distinguish loaders by their IDs (what's why signature of initLoader specifies this argument). ID for loader is needed to re-deliver cached result in case if data for loader with specific ID already exists (hence no need to asynchronously re-load it again).
  3. restartLoader call forces LoaderManager to initiate async opertation specified by previously created loader. initLoader attempts to reuse existing loader before creating a new one.
  4. Fragments and Activities have their own LoaderManagers that don't overlap.

My experience shows that even though using Content Providers sounds like overkill to implement, it actually pays off pretty good in the future. Performance hit is insignificant (tried measuring it), UI-Data bindings are added out of the box (because of content observer and CursorLoaders being able to subscribe to Uri notifications), synchronicity implemented by framework via loaders. IMHO, whenever database is needed, using content provider with loaders most of the times is the best solution you can come up with.

Other scenarios that involve using database directly, will force you to implement everything manually.

Paul Turchenko
  • 831
  • 6
  • 8