My point is not the theory of sync vs. async but rather the reality that you'll be better off to work off the downloads in sequence. When you drop the TOs low enough, there will be no more than a few seconds that you may lose. The upside, you'll actually get this done...
On Jan 18, 10:50 pm, And-Rider <rahulregunat...@gmail.com> wrote: > D..oh! I am really not sure about this but sending a asynchronous call > has certain advantages than synch calls since if the first call gets > blocked due to certain reasons the response that you get for the next > few calls will also be delayed. > > I feel that asynchronous(calls that do not block) are always better > than blocking calls since each call will be independent of the > other... > > On Jan 19, 10:10 am, JP <joachim.pfeif...@gmail.com> wrote: > > > 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 <rahulregunat...@gmail.com> 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 <joachim.pfeif...@gmail.com> wrote: > > > > > On Jan 18, 7:28 am, And-Rider <rahulregunat...@gmail.com> 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 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
