WebImageView race conditions in WebGalleryAdapter

[gradha]

I've released an application using some droid-fu widgets. The program works ok most of the time, but sometimes the WebImageView widgets seem to not update correctly their picture. When a WebImageView downloads the image for the first time, it seems to work always. However, when the WebImageView is loading the image from the memory/disk cache, sometimes the image doesn't reach the widget and the widget shows the loading resource instead forever. Sliding the cell out of the view and back in reloads fixes the problem.

It's quite difficult to explain, not reproducible, and most surely depends on the phase of the moon, so I don't know what do do about it. In fact, since this is best seen in a WebGalleryAdapter and that means I'm not using any of my code, the race condition bug must be present in either the gallery widget or the WebImageView widget.

I've put a 11MB video of the effect I experience at: http://dl.dropbox.com/u/145894/droid-fu-gallery.mp4. The app can be downloaded free from https://market.android.com/details?id=net.efaber.irekia. You can see in the video how many of the icons for "loading" are replaced correctly by the image after I scroll them out of the screen, and there's no network update or any other kind of work being done in the background.

[mttkay]

Thanks! We have experienced some flakiness w.r.t. to caching images, too. I believe it's a bug in ImageLoader / ImageCache, which is used by WebImageView. I remember spending almost a day on this trying to figure out the problem, and failed. I see this happening very rarely, so eventually we moved on.

I don't feel like spending another day debugging the entire thing, but if I happen to find the issue, I'll let you know.

[mttkay]

Also, I will post an announcement soon-ish that I will discontinue Droid-Fu. I have moved most parts of Droid-Fu to ignition, which can be understood as an attempt to re-launch Droid-Fu in a more modular way, with proper build and release management. It also cleans up with some bad naming / package organization, and rids some of the more intrusive parts entirely (there will be no more DroidFuApplication you have to inherit from, since that breaks compatibility with Roboguice).

There will be no more fixes going into Droid-Fu from our end, since we focus our efforts on ignition now.

[jasonschwarz]

For what it's worth, you can see the problem replicated pretty reliably (and on massive scale) in Encountr (particularly v2.81 -- grab a copy from http://encountr.net/download/Encountr281.apk -- warning: the app is definitely NSFW and probably includes gay nudity, so you won't want to check it out if you're on a train or something).

Things that seem to make the problem worse: SSL latency & refused connections due to thread-exhaustion, and especially Sprint 4G network-thrashing (when the phone can't make up its mind whether it wants to use 3G, 4G/wimax, or wi-fi, and starts madly thrashing between them without settling on any single one long enough for a http request to survive from start to finish). The closest equivalent I can think of on a European UMTS phone might be if you went down to the basement & the phone couldn't decide between using a very, very weak 3G signal or trying to use the neighbor's open wi-fi leaking in through the window.

The changes somebody made a few months ago to show default images for broken links also seem to be a little bit too eager to give up, and seem to not distinguish between a true 404 response and a more transitory response that you might get if the SSL handshaking failed and the connection were simply refused. Also, it seems to keep a LOT fewer images cached now than it used to... the version from last year seemed to keep copies around for at least days, if not weeks. The new version seems to discard cached images if you simply scroll them more than 30 or 60 images into the past (I think this might also be causing our problem with SSL connection exhaustion... that problem seems to have started right around the time lots of users started using a new release of Encountr that used the more recent DroidFu build with new caching behavior). I'm also pretty sure it's not doing keep-alives, and is negotiating new connections for every single image request. Now that Droid-Fu is officially deprecated, I might try ripping out everything not directly required by WebImageView to get it down to a more grok-able size, then try and figure it out myself. The current version is kind of overwhelming to try working through backwards. ;-)