Consensus on lazy loading Bitmaps in an Adapter (emphasis on Bitmap.recycle()) [closed]

Question

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
   
2. An adapter can have multiple Views for the same ID (calls to getView(0) are very frequent)
   
3. There is no guarantee that a view will not be lost instead of recycled (consider List/GridView resizing or filtering by text)
   
4. A separation of views and data/logic (as much as possible)
   
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.
   
6. Purging Bitmaps sufficiently distant from the current position in the list/grid, preferably only when memory is needed
   
7. Calling recycle() on every Bitmap that is to be discarded.
   
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.
   
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.
   
10. (optional) do not rely on notifyDataSetChanged (which, afaik, refreshes all visible, potentially very complex, list items) for updating a single ImageView
    
11. setTextFilterEnabled(true) (as in ArrayAdapter. Its implementation of Filterable replaces the data array visible to the other Adapter methods, therefore changing indexes of the views, so they cannot be used as IDs to link to the Bitmaps).
    
12. Usable in ExpandableList (affects the order the thumbnails are shown in)

Please forgive me if this had been answered. I've searched for months, and not found a solution.

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).
This also precludes relying on SoftReferences, which could have taken care of some of the other points.
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).
Search for "OutOfMemoryError: bitmap size exceeds VM budget" or "android bitmap recycle".
Yes, I am resampling the Bitmaps.

Gallop

Could you, possibly, describe what do you want to achieve in your code? – Spiegelman

@alex What I want to achieve is a universal abstract adapter that can be used in any ListView or GridView with minimal changes, like implementing the methods that create the entryview, download the Bitmap and return the ImageView to be updated. For example, I expect the addition of the ExpandableList methods to be easy, with no modifications to the image management needed on account of some assumptions made when designing the adapter. I am not asking to have the adapter coded for me, only for a mechanism that manages the Bitmaps as described – Gallop

On # 5, our implementation of the async dl mechanism "abuses" the AsyncTask class - which taps the internal thread pool that's already available, posting images back as progress updates & doesn't exit until requested by the Activity. Works nicely for 2+. FYI. – Axis

"closed as not a real question" - It was clear in the context of the many partial solutions for async. download already present on SO, but I guess the question should be self-contained. Clarified and reposted. – Gallop

It's a shame this question was closed. I disagree that it's not a real question. These are still issues that would be wonderful to have solutions consolidated in one place. I disagree with Kev. – Syndesmosis