On 5/15/12 11:18 AM, Alex Zavatone wrote: > Yes, and I've tested it and we haven't had a problem with this. I > trust your advice, yet all I can see is that if the data transmission > fails mid 4KB data transfer, it would hang. In the case where the > URL is invalid or unreachable, we have a dict to read from on the > device.
In the "real world" things never behave normally. Here are just a few issues that can (and by Murphy's Law, will) come up but won't trigger a validity/reachability failure: - The network is reachable but DNS is slow or unavailable. - A caching DNS server has a stale record, directing traffic to a wrong machine whose firewall silently drops packets on the floor (i.e. no reject message sent). - The client is running inside a captive network that is not detected by iOS. (This happens surprisingly often, as far as I can tell in cases where the captive network passes ICMP traffic but not TCP/UDP.) - As you indicated, data transmission fails mid-transfer. This could happen for a reason as simple as walking into a basement or tunnel. (I recall once standing at a construction site, watching in horror as a backhoe drove right through a fiber bundle, instantly killing all my connections.) Of course, until a TCP timeout is reached, this is indistinguishable from a slow connection. (Cf. the Two Generals' Problem.) You really can't assume that a network connection will ever complete in any finite period. In fact, you have to assume that any given connection will take an indeterminate (worst-case: infinite) amount of time. > Well, the Apple HUI guidelines have been taking some strange > directions recently on the Mac end of things. I'm sticking with what > I know will provide a tried and true expected (good) user experience. I disagree that splash screens are a good user experience. > I'm doing it because it's simply lame to display an empty TVC and > then have it fill in as content appears like an HTML page. I don't know what you mean by "lame." That guidance is because it *appears* to the user to be faster when you display the empty TVC. There is an even more important reason not to just throw in a splash screen as Default.png, though. As the devices get faster (and your code more efficient), Default.png will be on the screen for a shorter period of time. Eventually you will get the jarring experience of a splash screen flashing for a moment before the UI draws. This is a terrible, strobe-like user experience. The options then are two-fold: 1) Present a UIImageView of Default.png in -applicationDidFinishLaunchingWithOptions:. This allows you to subsequently do a controlled presentation of the UI without a strobe effect, but irritates users because you are now actively impeding their ability to actually use the app. 2) Drop the splash screen and replace it with an "empty" (non-localized) UI image. I think of this as analogous to watching movies. One reason that watching movies on iTunes is more pleasant than DVD or Blu-ray is that I don't have to suffer through Hollywood's version of a splash screen: Copyright notices. > I'm missing your point. Are you saying don't use a graphic > (Default.png) when the app launches or the approach I used back last > century with Director? I'm not familiar with Director. I'm saying: grab a screenshot of the initial screen and edit out any elements that will vary by locale (e.g. text, dynamically sized controls, etc.) and use that. Alternatively, create a xib that matches your UI but without any such localized elements, and use a screenshot of that xib. The latter requires maintaining two xibs, though, so I usually just go the Acorn (or Photoshop, or Pixelmator, pick your poison) route. -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.com _______________________________________________ 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
