On 8 Jun 2015, at 16:03, Rick Mann <[email protected]> wrote: > So, the biggest problem has to do with network timeouts.
Indeed, timeouts are a problem, but mostly that's because folks come in with the assumption that timing out is the right thing to do. In a lot of cases it isn't. If the operation is user-visible, you should not implement a timeout. Rather, you should show status/progress and let the user cancel and retry the operation when they see fit. Historically I framed this as the 'kicked out the Ethernet cable' [1] problem: 1. user is using your app 2. user accidentally kicks out the Ethernet cable 3. things stop working 4. user rummages around under their desk and eventually figures out the problem 5. user comes up from their desk to discover that your app has timed out 6. user must manually retry Without the timeout the connection would have gone through as soon as connectivity was restored. With the timeout, you force the user through an unnecessary extra step. The only place where timeouts make sense IMO is when the operation is completely 'headless'. Share and Enjoy -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware [1] These days I should problem recast this as the "Wi-Fi / WWAN dead zone" problem (-: _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/macnetworkprog/archive%40mail-archive.com This email sent to [email protected]
