StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
1618578
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2009-10-24T17:29:36.537
FavoriteCount
0
LastActivityDate
2009-10-24T17:29:36.537
LastEditDate
LastEditorUserId
0
OwnerUserId
35999
ParentId
1618503
PostTypeId
2
Score
19
ViewCount
0
LastEditorDisplayName
text
Body
Core Data is not nearly as complicated as you describe. Generally, an iPhone app has a "main" managed object context, which is generally owned by the app delegate. So long as you can get the app delegate (hint: <code>[[UIApplication sharedApplication] delegate]</code>) you have access to the managed object context. I like to define a static global variable to hold a reference to my app delegate to make life easier. There's generally a one-to-one correspondence between <code>NSFetchedResultsController</code> instances and <code>UITableView</code> instances. Aside from populating table views, it's exceedingly rare that you would need an <code>NSFetchedResultsController</code>. If you have a number of similar views (e.g. a tab bar that lets you view the same data in different ways a la the iPod app), it would behoove you to create a single base class that configures the <code>NSFetchedResultsController</code> and derive your specific view controllers from that. Now, when you create view controllers to edit an object, it's generally a good idea to do that in a separate managed object context. If the user cancels, you just discard the context and the changes go away. Again, you don't really need an <code>NSFetchedResultsController</code> for this because these views are only concerned with a single object. When you're done editing, you <code>save:</code> the managed object context. The objects that manage your other managed object contexts should implement the <code>NSFetchedResultsControllerDelegate</code> methods to keep the table view in sync. Again, this can be implemented in a base class so you can generalize this functionality for related view controllers.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PODesign pattern for Core Data iPhone App
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USAlex
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. PODesign pattern for Core Data iPhone App
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.