On Feb 9, 2016, at 3:37 PM, Jens Alfke <j...@mooseyard.com> wrote:

> 
>> On Feb 9, 2016, at 10:38 AM, Alex Zavatone <z...@mac.com> wrote:
>> 
>> Simply put, if we can detect that this user is has turned off Airplane mode, 
>> we can respond in a more cautious manner.
> 
> But you can run into the same behaviors if the user has turned WiFi and/or 
> cellular off and then back on.

Yup.

> The Airplane Mode switch is just a ‘macro’ that turns WiFi, cellular and 
> Bluetooth off (or back on) at once. You can also get race conditions if the 
> device has been away from WiFi and then comes in range of a network that 
> takes a little while to negotiate. (Usually if you’re listening for 
> reachability of a specific host, you won’t hit these in-between states, 
> though.)
> 
> The way we deal with this is to retry HTTP requests, if they fail with some 
> common transient IP-level errors like ‘no route to host’ or ‘connection reset 
> by peer’. The retry delay doubles after each failure, and most types of 
> requests give up after 3 failures, so the delays are like 1, 2, 4 seconds.

That’s what I would like to do.

However, we have a 4 deep nested set of classes (I didn’t write this and if I 
did, I should be shot), when the operation fails at the lowest level… nothing 
happens.

No return statement indicating an error and in all the classes above it, we 
have the same issue.

That’s what’s obvious.  

Obviously, this a problem, but possibly not the only problem.  

See where I am with this?  It could easily (wait, wait, it is) a snake pit.

        (Caveat, yes, you’re right, but my boss will kill me until this gets 
higher priority to address.)

However, all is not lost.  A certain Hoerl type character pointed me to a 
pretty nice SO answer which references to some getIPAddress code from some so 
called “Jens” character for testing if Airplane Mode (or the equivalent) is on.

Well, as luck would have it, I’m already using it, just not in that manner.

SO, before I go digging into a “very bad world”, we can at least run a test by 
our client to see what his device is seeing - connectivitywise.


Then, we can determine if I should prepare to descend into the pit of darkness.

Hopefully, I’ll be able to gut and rebuild the monstrosity before that has to 
happen.  

Thanks again guys.  

Alex Zavatone
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to