I absolutely agree with you, Alan!
The question is not only still remains open, but now (due introduction the
room-library) becomes even more controversial.
I'd like to see a united logic of interaction between all parts
AOSP(especially framework's API)
*ContentProvider's -> Cursors ->
I know this almost a 6 year old post, but I am experiencing the exact issue
that you have measured in a production application, and am wondering if
anything more ever came of your research? I have a custom cursorAdapter
that is handling a cursor with ~10k rows in some instances. While scrolling
It makes sense that getCount() on the cursor might involve reading all
the rows even if it probably doesn't actually instantiate all the
objects as Bob Kerns correctly points out.
A work around is to do a seperate select count(*) with the same
where clause but this is only an estimate of the
What you say makes sense Bob, but testing seems to indicate the
Android SQLite implementation isn't so proper.
I have a simple app that creates 20001 rows in a table, each with an
int _id 2 varchar fields.
Getting the count of rows via db.rawQuery(select count(*) from
table, null) and getting
Ah, the difference between theory and practice is that in theory,
there IS no difference, but in practice, there IS.
What platform did you do this on?
I was afraid getCount() was going to turn out to be slow. But I'm
puzzled that it's slow, but SELECT COUNT(*) FROM TABLE is relatively
quick.
Hehe, that was my reply when I started the project sigh.
A crude use case example is where the records are like short log
entries, and you want to scroll through them to watch events over a
time span. You need a big window, since in some time frames, there
may be few records; in others, there
A crude use case example is where the records are like short log
entries, and you want to scroll through them to watch events over a
time span. You need a big window, since in some time frames, there
may be few records; in others, there may be thousands -- the data
density varies you can't
Hehe, that was my reply when I started the project sigh.
A crude use case example is where the records are like short log
entries, and you want to scroll through them to watch events over a
time span. You need a big window, since in some time frames, there
may be few records; in others, there
Thanks Mark.
Use the LIMIT and OFFSET terms on your SELECT statement to obtain data in
smaller chunks. Create a wrapping adapter (like my EndlessAdapter) that
only loads chunks when the user scrolls to the bottom of thelistand
therefore needs more data.
Doing the load in smaller chunks
Thanks Mark.
Use the LIMIT and OFFSET terms on your SELECT statement to obtain data in
smaller chunks. Create a wrapping adapter (like my EndlessAdapter) that
only loads chunks when the user scrolls to the bottom of thelistand
therefore needs more data.
Doing the load in smaller chunks
Is the list/adapter just creating 20K objects as it walks the result
set?
No, but your database query is probably making a 100K roster of objects or
more. Only as many views as are needed for the visible rows in the list
will be created.
--
Mark Murphy (a Commons Guy)
http://commonsware.com
On Feb 2, 3:31 pm, THill thill.dr...@gmail.com wrote:
Thanks Mark.
Use the LIMIT and OFFSET terms on your SELECT statement to obtain data in
smaller chunks. Create a wrapping adapter (like my EndlessAdapter) that
only loads chunks when the user scrolls to the bottom of thelistand
Thanks.
Mark's comment about the object roster is what I was curious about.
SimpleCursorAdapter calls Cursor.moveToPosition() every time the list
calls bindView(), so I was wondering what the cursor does with result
set when -- i.e., does it create objects (presumably indexes into
the db file)
Mark's comment about the object roster is what I was curious about.
SimpleCursorAdapter calls Cursor.moveToPosition() every time the list
calls bindView(), so I was wondering what the cursor does with result
set when -- i.e., does it create objects (presumably indexes into
the db file) for
That's what I feared. I was hoping the cursor was only keeping
primitive references to the data in the db file.
If I'm going to be doing many smaller queries keeping the results
around, sounds like I might as well keep the objects myself. Lets me
index across the varying data density also.
There's still the lifecycle handling -- if I have this ArrayList, and
I want to keep it across rotates, I could keep it in a static. The
trick is knowing when to release/null it. First thought is to set a
flag in onRetainNonConfigurationInstance, otherwise I'll release it if
the flag isn't
Because that's what a smart person would do I'm an idiot for not
thinking about it before asking grin. That's two whacks -- I'm
outta here.
Need more caffeine...
Cheers,
tim
On Feb 2, 3:10 pm, Mark Murphy mmur...@commonsware.com wrote:
There's still the lifecycle handling -- if I have this
On Feb 2, 2:00 pm, Mark Murphy mmur...@commonsware.com wrote:
...
A Cursor represents the entire result set. If you run a query for
20K rows
and 5 columns, you will instantiate 100K objects at the time the
query is
actually run.
...
Actually, that shouldn't be quite right. (I know you know
The standard reply is going to be you'll never actually need to view
all 20K rows, so either page it out or filter the results to a more
manageable number. Then again, if an end user is willing to scroll
through 20K rows, they might be willing to wait 5s for it to load :)
Past that, I assume
19 matches
Mail list logo
