On 7/19/10 8:27 AM, "Keary Suska" <[email protected]> wrote:
> On Jul 18, 2010, at 8:19 PM, Gordon Apple wrote:
>
>>>> My main entity has three references (one-to-one and one-to-many) to
>>>> identical entities defined as class "File" (a managed object). File is not
>>>> defined in the graphical model and is the only class (for the referenced
>>>> entities) defined in the code. File has a back reference, and two
>>>> attributes, a user-assigned name and a code-assigned uniqueID integer, the
>>>> latter of which forms the main part of the actual (internal) file name when
>>>> file access is required. Actual files are stored in their respective
>>>> subfolders of the documents folder for each defined File entity.
>>>>
>>>> Question 1: The FRC is for the main entity and sorts on the main entity's
>>>> own name attribute. Is there anything is what I described above which
>>>> could
>>>> be interfering with using an FRC cache?
>>>
>>> I wouldn't assume so, but you haven't told us what "doesn't work" means.
>>
>> Here's the story. When the program is first launched, a folder of text
>> files is read and and is used to pre-populate the database. This appears to
>> work. However, even after saving and performFetch, the FRC will not get
>> section info when going to a tab view containing a tableView. If I quit the
>> app and relaunch, the table will populate correctly using the FRC. This is
>> not a good initial experience for the user when first launching the program.
>
> We would need to see code to make any useful recommendations. If you are
> saying that the exact same code functions correctly when *not* using a cache,
> but incorrectly when using a cache, I would suspect a bug of some sort. But
> then, the bug could be in your code...
Yes, that is what I am saying. I'm currently not using a cache in the
FRC because then it works. Of course, this is iPhone OS 3.2 because it's an
iPad. I don't know how 4.0 would behave.
>
>>>> Comment: I have yet to see any sample code or writeups on using CoreData
>>>> to
>>>> manage files, which seems like something that should be in common usage.
>>>
>>> Why? Core Data is about object graph management (and its persistence). It
>>> isn't about file system management. There are other classes for that.
>>
>> Well, it is not enough to define something in isolation. Many systems,
>> like browsers, are based on individual file storage. If there is a common
>> standard practice for handling file references in CoreData, I would prefer
>> to use it.
>
> Originally I was answering the wrong question. The right answer would be that
> there is almost nothing particular to persisting file references in Core Data
> vs any other approach. But I would also add that I bemoan the lack of examples
> for complex and advanced uses of Cocoa classes--it seems that examples deal
> primarily with common and simple cases.
Amen, brother. Like examples with a zillion UI types, but nothing about
how to communicate with them to do something useful. Sometimes I have to do
a lot of experimentation to find out what I need. For example, in the
UIAudioRecorder/Player, it is "running" when "paused". Nothing in the
reference. I added my own flags to get what I needed. Also, the
UIAlertView and UIActionSheet are lacking a "context" parameter which you
have to outboard so that the delegate can sort it out. (Freshly dealt with
in the past 24 hrs.) I assume that was an oversight, but it would have been
nice if they had suggested how to work around it in the references.
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
--
Gordon Apple
Ed4U
Little Rock, AR
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
