You could always avoid this by writing your own subclass of View rather
than using ListView.
On Thursday, December 13, 2012 9:08:40 AM UTC-6, Nicholas Campion wrote:
Doing some more research, I'm wondering if the issue is the view recycling
methodology for GridView. It *appears* that its only caching one view
offscreen, one grid view child, which when a 'row' of the grid is more then
one view, causes a some chunkiness as the row comes on screen and the rest
of the views are built. Anyone else looked at this?
On Wednesday, December 12, 2012 10:47:38 PM UTC-6, Nicholas Campion wrote:
I'm wondering if anyone could give me ideas about how the Google Play app
implements its list of apps (e.g. the search results page). I'm
specifically interested in how it handles the apps icon because, it appears
to be lazy loaded (flinging down the list will show a placeholder) but it
seems to be able to instantly show (read: never see the placeholder) the
icon when you scroll the app list in the other direction. My experience has
been that when rebuilding using a recycled view, there is lag when
'repopulating' the ImageView as it displays the placeholder image and then
the desired bitmap when ready.
I have implemented the following:
1. In memory and on disk cache
2. Sub-sampling of images
3. View recycling
I still get this clunky experience that, when a recycled view is used and
the bitmap must be loaded, even from memory, the app shows the placeholder
image. Is the issue just with GridView or is there something else I should
look at?
--
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
