Think about it for a moment - you've got only one pipe, and over the air that's not really all that fast. I doubt you win anything by trying to squeeze images through simultaneously.
On Jan 18, 8:53 pm, And-Rider <[email protected]> wrote: > yes if i send my calls i a sequential manner it should not be an > issue. But in certain cases asynchronous calls do help us to speed up > the performance a lot > > For example if i have a listview and in each row if i have an image to > download then asynchronous calls would be much faster. In this case > unfortunately time out happens in a synchronous manner. So if i send > five calls the in a asynchronous manner those calls are not timing out > in an asynchronous manner. I think this should probably be a bug... > > On Jan 18, 11:44 pm, JP <[email protected]> wrote: > > > On Jan 18, 7:28 am, And-Rider <[email protected]> wrote: > > > > In that case the network connectivity check would fail. It will show > > > as if we have an network connection but we actually don't have an > > > internet connection. > > > This can be the case at any point, regardless of data link. Still, > > checking for network connectivity is helpful - I use it to display > > message to the user. > > > > Another case that we might face is that if a user is traveling in an > > > area where the network connectivity is fluctuating. > > > Exactly, see above. > > > > In this cases is it not necessary for us to set a proper timeout..?. > > > And if the timeout happens in a synchronous manner then it might take > > > a long time for the last call to time out. > > > I use a sequential model to work off the various calls to the server > > side over time. This means I didn't have to deal with the problem > > you've found and cannot offer a direct answer. There certainly is the > > possibility that the first connection blocks the following on the SDK/ > > Android level, for whatever reason. Some code diving would be in order > > to get to the bottom of this. The question could be raised if that's > > an effective use of your time, it wouldn't get you anywhere solving > > the problem... > > From what I can say, I'd recommend to switch to a sequential, managed > > model with an adequately low connect and read TO. Android (the mobile > > environment in general) isn't like the fixed side where you might have > > the latitude to whip up a bunch of threads to work off various tasks > > in parallel. The constraints of the environment just don't allow > > nearly as much play.
-- 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
