On May 15, 2012, at 01:22 PM, Jens Alfke <j...@mooseyard.com> wrote:
On May 15, 2012, at 11:18 AM, Alex Zavatone wrote: Yes, and I've tested it and we haven't had a problem with this. But I thought you said you were trying to speed up launch time? Isn’t that the impetus for this thread? And we’re pointing out that waiting for a network request adds a lot of (very unpredictable) latency to your launch time. Ok, I guess I didn't do a great job of specifying what constitutes launch time and which display activities would trump launch speed. In addition to thinking about my current app, I'm looking forwards to my next project where this will be an issue. In the current app, the time to synchronously fetch, serialize and display 4 KB of JSON does not justify introducing unpleasant display behaviour by displaying the empty TVC first, then filling it in when the data gets there. From what I've seen during development, the launch time did vary - but you explained a lot of that as a result of the simulator setting up debugging. Right now, testing on two devices over two networks, my app has a 1 second launch time 'till the TVC with data is displayed. That's great. In the next project's case, I can't get away with a sync request at the start since we'll be dealing with much more data and would like to have a design in mind to ponder over while the spec is still being formalized. If you’ve tested it, all you know is the latency on the networks (and at the times) you’ve tested it. It doesn’t tell you how it’s going to perform on, say, a train. Or outside the US. Thankfully, I have experience testing connection speeds on 3G in the middle of the Kalahari while driving, but your point is noted. 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. You shouldn’t need to hang at all in that case. Just read the dict on the device at startup, and update from the network in the background. Wouldn't that display one data set and then another? OHHHH, load and use the local saved data set while loading the other data and storing that in the pList, which would then get used next time. I was thinking of keeping a version string in both data sets, or in a component file and only loading the new data file from the server if the version string is different. Surely though, this issue must already be solved and probably in a more efficient manner without having a separate file to hold a version string. 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. It was probably a necessary UX for apps in slow emulated runtimes that have to download content to start up at all; but for a very long time the best practice in native apps has been to avoid splash screens. You can’t just apply all of your ideas about Director development to a very different platform; that’s why you’re here asking questions, right? I'm certainly not applying all my ideas from Director hybrid CD ROMs and Shockwave, just the ones that I think make sense, and asking you guys (who have been doing iOS longer than I) if these approaches make sense or not. And I'm quite happy to get this much in-depth feedback. Thanks man. —Jens _______________________________________________ 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
