Hi, Why don't you keep the reachability check running even if the user cancels, and just not start a new one if one is already running?
Rolf On Sat, Nov 5, 2011 at 12:17 AM, simarx <[email protected]> wrote: > I guess ultimately, I'm after the cleanest and most effective way to > determine whether there is an active internet connection. Using the > Reachability helper classes is ok - but when it takes a "long time" for the > check to respond on occasions, it just makes it very awkward to control > workflow where the task needs to run in a linear fashion. > > Eg. in my app, I have a login box that uses a web-service to validate the > user. Before calling the webservice I want to check if there is an internet > connection. So during this check I display a busy indicator and have a > cancel-button to abort the reachability check cleanly if the check is taking > too long. Obviously, the cancel-button can give control back to the user, > but if they hit LOGIN again, the code will kick off a new thread with > another long running reachability check. These threads will close cleanly > which is ok as long as the user doesn't get too trigger happy. > > Not sure if there is any solution to this. If the phone is going to take 30+ > seconds to determine if an internet connection exists, the user is going to > have to just wait before they are told there is no connection available. > > Is there any clean alternative? > > > -- > View this message in context: > http://monotouch.2284126.n4.nabble.com/2-Threading-Questions-tp3990347p3992016.html > Sent from the MonoTouch mailing list archive at Nabble.com. > _______________________________________________ > MonoTouch mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/monotouch > _______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
