Tnx, I figured that as well. It's just that I was overwhelmed by all these weak/unspecified framework guarantees, which I decided to avoid all together.
Almost done :) On Sep 6, 7:44 am, Doug <[email protected]> wrote: > It sounds to me like you are aware of everything you need to know to > construct a solution that works for you. Fire up your threads and get to > it! To really do this right, though, you need an http fetcher, a disk > cache for fetched images, and a memory cache for only the most recently > fetched images. And you need to check each one of these in reverse order > to get the best performance for a ListView with images that must scroll > quickly. > > Overall, this is not exactly an easy problem to solve. I just shipped a > solution for a prominent app I work on, and it took weeks of work and > several eyeballs to iron out all the details. > > Doug > > > > On Wednesday, August 29, 2012 12:25:31 PM UTC-7, itai wrote: > > > I’m struggling to figure out a straight forward design for the > > following scenario: > > > A user clicks a button which results in sending an http request > > asynchronously to fetch a list of image URL’s (e.g some json > > collection response). > > Upon completion, a ListView would need to be populated with the images > > referenced by the URL’s (e.g each list view item would issue its own > > async http requests to download and display the image). The image > > being downloaded will always be the most recent for the proper > > recycled image. > > > I’m concerned about three situations: > > > 1. Configuration change can happen at any stage which will replace the > > Activity instance receiving the async results with a new instance, > > hiding already displayed images – My understanding is that the > > solution for this is to maintain a some list of all active async tasks > > on the initiating instance and transfer them all together in > > onRetainNonConfigurationInstance(), However; my concern here is from > > the doc’s: “This function is called purely as an optimization, and you > > must not rely on it being called”, Does this mean that a configuring > > change can happen and function won’t be called ?@! > > > 2. A different activity comes into the foreground, causing the > > executing activity to be in "pause state" while still getting updates > > from the in-progress async operations – Here I’m not sure if there is > > any violation (e.g updating an Activity UI in pause state). > > > 3. A different activity comes into the foreground, causing the > > executing activity to be paused and subsequently killed (the entire > > process is killed) due to memory pressure - In this case I would want > > to: > > > a. Know that this is the case before it happens. > > > b. Save to persistent storage all the *new* images if and only If all > > the downloads have completed, if not, I would like to save all > > existing images that where present before the whole download process > > kicked in (if present from a past download). > > That way if the user navigates back to Activity and the process is > > recreated, I can load the persisted information and have the user see > > a snapshot of images either from a previous request or a new request > > (no interleaving) > > > Initially I was inclined to use AsyncTask’s (1 AsyncTask for getting > > the Url’s and X others for the images) and use > > onRetainNonConfigurationInstance, to correct instance binding in case > > of a configuration change… )I have yet to figure out how to detect the > > process recycling case from configuration change before hand as there > > is no defined order between onSaveInstanceState / > > onRetainNonConfigurationInstance and I don’t want to persist the > > information at every configuration change). However, after watching > > Virgil’s google i/o presentation “Building Rest Clients” it seems > > there is a recommended approach, to perform all the network calls > > through a service which is supposed to decrease the likelihood of the > > process from being killed. However, after further investigating this > > it seems like a major overkill with many pitfalls of its own as it > > requires implementing a 2 way messaging protocol possible involving > > queuing messages, with no obvious way on how to handle callbacks in a > > way that address the concerns outlined above, so I prefer to avoid > > this risk unless absolutely required. > > > So to sum up, I would really appreciate a professionals feedback on > > this, as I'm kind of new to android... so if you feel like sharing an > > *explanation* on how to do this right, great!! > > > If you feel this is work and you can provide a concise and *correct* > > sample that address all the concerns above, I would be happy > > compensate, pypal works :) > > > -Itai > > > e: itaitai2003 … the at sign … yahoo .. com > > > p. s > > > No need for actual communication/imaging or persistence logic, simple > > mock will do, without Fragments – I don’t use them, I don’t need them > > in my project. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
