Consensus on lazy loading Bitmaps in an Adapter (emphasis on Bitmap.recycle())
I see a truckload of suggestions for this, but none (that I've found) take all factors into account, the factors being:

1. Asynchronous downloading, without duplication (of downloaders and Bitmaps), with canceling downloads/assigning of images that would no longer be needed anyway<br>
2. An adapter can have multiple Views for the same ID (calls to getView(0) are very frequent)<br>
3. There is no guarantee that a view will not be lost instead of recycled (consider List/GridView resizing or filtering by text)<br>
4. A separation of views and data/logic (as much as possible)<br>
5. NOT starting a separate Thread for each download (visible slowdown of UI). Use a queue/stack (LinkedBlockingQueue?) and thread pool, or somesuch.... but need to end that if the Activity is destroyed.<br>
6. Purging Bitmaps sufficiently distant from the current position in the list/grid, preferably only when memory is needed<br>
7. Calling recycle() on every Bitmap that is to be discarded.<br>
8. External memory may not be available (at all or all the time), and, if used, should be cleared (of ONLY the images downloaded here) asap. Also consider Activity destruction/recreation by Android.<br>
9. Data being changed: entries removed (select in list, button to remove, immediate refresh) and added in a background Thread (list refreshed on demand). Already downloaded Bitmaps should be kept, as long as the entries they're linked to still exist.<br>
10. (optional) do not rely on notifyDataSetChanged (which, afaik, refreshes all visible, potentially very complex, list items) for updating a single ImageView<br>

Please forgive me if this had been answered. I've searched for months, and not found a solution.<br>
<br>
The requirements seem reasonable to me, but each one adds a dimension of difficulty, especially Bitmap.recycle, which needs to be called during operation and on Activity destruction (note that onDestroy, even onStop might not be called).<br>
This also precludes relying on SoftReferences, which could have taken care of some of the other points.<br>
Yes, it is necessary, or I get OutOfMemoryError even after any number of gc, sleep (20s, even), yield and huge array allocations in a try-catch (to force a controlled low memory situation).<br>
Search for "OutOfMemoryError: bitmap size exceeds VM budget" or "android bitmap recycle".<br>
Yes, I am resampling the Bitmaps.
Consensus on lazy loading Bitmaps in an Adapter (emphasis on Bitmap.recycle())
===

I see a truckload of suggestions for this, but none (that I've found) take all factors into account, the factors being:

1. Asynchronous downloading, without duplication (of downloaders and Bitmaps), with canceling downloads/assigning of images that would no longer be needed anyway<br>
2. An adapter can have multiple Views for the same ID (calls to getView(0) are very frequent)<br>
3. There is no guarantee that a view will not be lost instead of recycled (consider List/GridView resizing or filtering by text)<br>
4. A separation of views and data/logic (as much as possible)<br>
5. NOT starting a separate Thread for each download (visible slowdown of UI). Use a queue/stack (LinkedBlockingQueue?) and thread pool, or somesuch.... but need to end that if the Activity is destroyed.<br>
6. Purging Bitmaps sufficiently distant from the current position in the list/grid, preferably only when memory is needed<br>
7. Calling recycle() on every Bitmap that is to be discarded.<br>
8. External memory may not be available (at all or all the time), and, if used, should be cleared (of ONLY the images downloaded here) asap. Also consider Activity destruction/recreation by Android.<br>
9. Data being changed: entries removed (select in list, button to remove, immediate refresh) and added in a background Thread (list refreshed on demand). Already downloaded Bitmaps should be kept, as long as the entries they're linked to still exist.<br>
10. (optional) do not rely on notifyDataSetChanged (which, afaik, refreshes all visible, potentially very complex, list items) for updating a single ImageView<br>

Please forgive me if this had been answered. I've searched for months, and not found a solution.<br>
<br>
The requirements seem reasonable to me, but each one adds a dimension of difficulty, especially Bitmap.recycle, which needs to be called during operation and on Activity destruction (note that onDestroy, even onStop might not be called).<br>
This also precludes relying on SoftReferences, which could have taken care of some of the other points.<br>
Yes, it is necessary, or I get OutOfMemoryError even after any number of gc, sleep (20s, even), yield and huge array allocations in a try-catch (to force a controlled low memory situation).<br>
Search for "OutOfMemoryError: bitmap size exceeds VM budget" or "android bitmap recycle".<br>
Yes, I am resampling the Bitmaps.