[android-developers] Re: Async pattern required (professionals welcome)

2012-09-06 Thread itai
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  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 proj

[android-developers] Re: Async pattern required (professionals welcome)

2012-09-05 Thread Doug
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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more op

[android-developers] Re: Async pattern required (professionals welcome)

2012-08-29 Thread Sean O'Neil
Keep a reference to the current Context inside your AsyncTask. Then in your 
onCreate(), either start up new tasks if they aren't running, or set the 
new Context in them if they are.

On Wednesday, August 29, 2012 3:25:31 PM UTC-4, 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 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