Re: iOS app launching speed
Re: iOS app launching speed
- Subject: Re: iOS app launching speed
- From: Alex Zavatone <email@hidden>
- Date: Tue, 15 May 2012 19:56:39 +0000 (GMT)
- Zav
On May 15, 2012, at 10:44 AM, Jens Alfke <email@hidden> wrote:
On May 15, 2012, at 9:48 AM, Alex Zavatone wrote:
I didn't want to display the main screen (TVC), until the main data had loaded (a 4 KB data set) and serialized.
I'm wondering if with a larger data set, the approach should be to have the first scene use the same graphic as the launch screen, fire off an async http load (through GDC or which preferred method?),
NSURLConnection. Use the async API (with delegate).
display a little spinner if the delay takes longer then 1.25 seconds,
Why not cache the data from the previous run and load that from local storage at launch? It’ll be super fast. Then at the same time you also fire off an async HTTP request, and when that response comes back you can update the UI if it has different data. (As an optimization, make it a conditional GET by adding an If-None-Match: or If-Modified-Since: header so the server only has to send you the data if it’s changed from what you’ve already got.)
We are caching (saving in a pList) the data from the previous launch. It falls through and uses the previously saved data if we can't get to the internet. Now, what I'm unclear on at this point (I've never truly truly trusted some system to cache stuff for me) is how the system knows if the data online is newer than the data we've got. I trust that the caching method you're mentioning is different than saving to a pList?
Maybe an overview is in order.
Start up
Fetch list of contents JSON & serialize & save to device as pList
If we fail, load from pList if present
Display lovely data in TVC
User selects one of those items in the TVC cells
Load 3 sets of data based on item selected ala 2 JSON files and PNGs & save as pLists and PNGs
If we fail, load from pList and stored PNGs if present
User can then hop around the app and enjoy the lovely data.
If user goes back to the Start TVC and selects another cell, the above process proceeds relative to the new item selected.
Start data is 4KB. Optimized (sans spaces and tabs), 3 KB. Zippedy fast to load and display.
Secondary data is 33 KB, 17 KB optimized (tabs, spaces and returns removed).
Images are between 80 and 460 KB.
This way you also get offline support — the app will work properly if there’s no network, instead of just spinning forever.
Yeah, in my current approach, as long as the data is loaded once, it's there in the app's documents folder and can be loaded if the user has no internet connection or the file can't be found.
Native apps are different from web apps, and one big benefit is that they don’t need to be hamstrung by network performance. So it’s important to make them work well with slow or no network; otherwise you might as well just write a web app.
Oh, god no. That's just a horrific thought. One key concept in my approach was to make sure the data is loaded before the user needs it. Remember, I come from ye olden world of Director and Shockwave (served a 4 year sentence at Macromedia), when we could preload data, write our own async foundation classes and make sure that data was there before it's time to draw the screen, then draw the whole screen at once. None of this HTMLy let stuff come in piece by piece, which is visually ugly.
Thanks much.
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden