- Zav
On May 15, 2012, at 10:44 AM, Jens Alfke <j...@mooseyard.com> 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 (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
