Jon, that sounds very plausible.
Yes the background process is updating the same stuff that is displayed,
although it is mostly inserts.
That wouldn't explain the problem with finger gesture detection, but this
problem is so fuzzy it could be anything.

Anyway, how to proceed from here? Do you know how the actual locking
mechanism works? It seems (http://www.sqlite.org/lockingv3.html) that they
use page level locking. I assume the list adapter's getCount() uses all
records, so probably also the last page where new inserts are added!?

I got an ANR when resuming the app. Maybe that is the same cause? It hangs
in native_fill_window.

 at android.database.sqlite.SQLiteQuery.native_fill_window(Native Method)
  at android.database.sqlite.SQLiteQuery.fillWindow(SQLiteQuery.java:71)
  at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:153)
  at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:139)
  at android.database.AbstractCursor.moveToPosition(AbstractCursor.java:167)
  at android.database.AbstractCursor.moveToFirst(AbstractCursor.java:244)
  at
com.newsrob.DashboardListActivity$DashboardListAdapter.notifyDataSetChanged(DashboardListActivity.java:231)
  at
com.newsrob.AbstractNewsRobListActivity.refreshUI(AbstractNewsRobListActivity.java:287)
  at
com.newsrob.AbstractNewsRobListActivity.onResume(AbstractNewsRobListActivity.java:311)
  at
com.newsrob.DashboardListActivity.onResume(DashboardListActivity.java:81)
  at
android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1224)
  at android.app.Activity.performResume(Activity.java:3360)
  [..]


2009/2/19 Jon Colverson <jjc1...@gmail.com>

>
> On Feb 19, 8:21 am, Mariano Kamp <mariano.k...@gmail.com> wrote:
> > Ok, now the guesstimeasurement I do is that I look at the time the
> > background is yellow. This time is very brief, when the background thread
> is
> > not running and went to 4 seconds when the background thread is running
> and
> > half of that when the background thread is running with the background
> prio.
> >
> > Maybe that is already what can be achieved? I was expecting that the
> > foreground activity (the db update etc.) with a running background
> activity
> > would be almost as fast as without a background activity when using the
> low
> > prio.
>
> It seems to me that your problem is less to do with CPU usage and
> scheduling than it is to do with contention on the database.
> Presumably the background thread is also updating the database as it
> downloads new articles. Does it hold locks on the database for a long
> time while it is doing that? If you yield or sleep that thread while
> it holds a lock then it will still not let the other thread update the
> database.
>
> --
> Jon
>
> >
>

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

Reply via email to