Re: Indicate loading while bindings read from Core Data
Re: Indicate loading while bindings read from Core Data
- Subject: Re: Indicate loading while bindings read from Core Data
- From: Matt Neuburg <email@hidden>
- Date: Sun, 05 Nov 2006 11:56:01 -0800
- Thread-topic: Indicate loading while bindings read from Core Data
On Sun, 5 Nov 2006 09:52:54 -0600, Brad Siegfreid <email@hidden> said:
>This is my first time posting to the list. By day I'm a server-side
>Java developer but started working with Cocoa a little while ago to
>create an application that I eventually hope to release to the
>public. I feel that I've started to connect with the Cocoa way of
>doing things but I'm a little stumped by something.
>
>I have a document that displays data from Core Data in a table using
>bindings. The document has the potential to be quite large with small
>sets starting at 10,000 records or more. My problem is that when
>loading a document there is a noticeable but not unacceptable delay
>from rendering the window to the rendering of data in the table. Its
>enough of a delay that I feel I should provide some feedback. I
>haven't found a good place to provide a loading message since the nib
>seems fully loaded and now I have to wait for the bindings to do
>their magic.
Okay, I blew my previous answer slightly. To be more precise, answering
caused me to do some experimentation which improved what I do.
So, here's what I do NOW. :)
Don't let your principal window show automatically on start. Don't let you
NSArrayController in the nib do "automatically prepares content", and don't
bind its "managedObjectContext".
Okay, now there is no delay getting things started. So, when the app
finishes launching, put up a splash window of some sort to give the user
something to look at. Then:
* In code, bind your NSArrayController's "managedObjectContext"; this causes
your first delay as the data are read in (unless you are using SQLite, but
I'm not - I'm using XML).
* In code, tell the NSArrayController to fetchWithRequest:nil merge:NO
error:nil.
When that call returns you are ready to rock and roll, so take down the
splash window and put up your principal window.
Just to give an idea of the times involved here, here's some logging from my
app as it starts up on a slow machine (G3/600):
2006-11-05 11:39:14.427 Diary[1012] awakening from nib
2006-11-05 11:39:14.539 Diary[1012] binding to MOC
2006-11-05 11:39:22.960 Diary[1012] calling fetch
2006-11-05 11:39:24.127 Diary[1012] done calling fetch
So, you can see that the first delay is about 8 seconds, and the second
delay is about 1.5 seconds. The splash screen is present during both (I put
it up as soon as we awake from the nib), so the user is not mystified.
Note that AFAIK there is no way to track what happens during the first
delay; you just have to wait. (But that is a penalty I am willing to pay,
because I really, really do want to keep my data in XML format.) You could
track the progress of the second delay by way of your entity's
awakeFromFetch, but this is hardly worth it since this is not the delay
that's taking a long time! :)
Hope this helps. m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden