NSFetchedResultsController / Core Data

[redbirdo]

The NSFetchedResultsController seems to me to be rather complex and
difficult to get to grips with. Is it just me? And to any experienced
people who may be lurking around here are the benefits of using it
worth it? It seems to me that they need to be!

Seriously though... After all the work it took me to get Pararazzi1
working I didn't bother with the extra credit. However, I felt it
would really be useful to do the extra credit for Paparazzi2 and it
didn't look too complicated (haha!) so off I went.

It has taken me ages to get to grips with NSFetchedResultsController
to the extent that I can delete and move table rows. Even then, as I
only have two people rows in my table, I'm still not 100% sure it will
work for all cases! (yes, yes, I know I could set up more data and
test it to be sure but I've spent so much time on this already)

For a sanity check on in my moveRowAtIndexPath method, can anyone
comment on whether the following is the correct approach?:
1) update the order attribute of any Person objects affected by the
move
2) refetch the contents of the peopleRC using performFetch
3) save the MOC which triggers the RC delegate methods to update the
table view
I do the refetch before the save to ensure that the objects in the
peopleRC are in the correct order before the table view is updated.

I have 10 years of C++ and Java under my belt, albeit before a long
break to have kids. That includes previous exposure to an object
database and also to EJBs with similar concepts to core data.
Nevertheless, I feel as though I am learning to program all over
again, except this time I'm rubbish at it!!!

Then it doesn't help when I'm searching around the internet for stuff
and coming across comments from developers to the effect that they
don't use core data because its too slow. Is this really the case or
does it depend how you implement it? Or is it something you should
only use if you really need the automatic synch between data and view
and the ability to undo/redo etc?

Thanks
Vicki

[Lenny Teng]

Hi Vicki,

I'm not experience enough to answer your questions, but I can share with you how I implemented my moveRowAtIndexPath method.  I implemented a little differently:

1) In my fetched array I removed the object at sourceIndexPath and inserted the object at destinationIndexPath

2) Updated the order attribute of any Person objects affected by the move (same as your step 1)

3) Save the MOC which triggers the RC delegate methods to update the table view (same as your step 3)

Since I updated the fetched array directly, I didn't have to do the refetch to keep things in sync.  What do you think?

Thanks,

Lenny

---

From: redbirdo <vicki...@googlemail.com>
To: iPhone Application Development Auditors <iphone-appd...@googlegroups.com>
Sent: Sat, March 6, 2010 7:13:57 AM
Subject: [iPhone-AppDev-Auditors] NSFetchedResultsController / Core Data

--
You received this message because you are subscribed to the Google Groups "iPhone Application Development Auditors" group.
To post to this group, send email to iphone-appd...@googlegroups.com.
To unsubscribe from this group, send email to iphone-appdev-auditors+unsub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iphone-appdev-auditors?hl=en.

[weejayuk]

Vicki

I agree with you.
Paparazzi 2 with the extra credits is very tough.
Hooking a table to a data source to add, delete and move data should
be do-able and have a coherent documentation set to match it. I think
the tutorial
http://developer.apple.com/IPhone/library/documentation/DataManagement/Conceptual/iPhoneCoreData01/Introduction/Introduction.html
is good, but falls short of giving you the full picture. The book I
have 'The iPhone Developer's cookbook' has core data as chapter, but
does not cover all that is needed.
I've done lots of coding (in the Microsoft world !) where this kind of
thing was easy(er). With core data and the table view I am as
surprised as you at the difficulty in getting something as easy as
add, delete, move on a data linked table working. I've had a good look
about and seen no comprehensive examples.
I've not done the reorder yet. I had a think about it this morning and
took the dog for a walk instead!
The delete I did was as follows:

in CommitEditingStyle:
if it is a delete, delete the object in the model,
save it
do a fetch

then delete the row in the tableview.

this worked, but seemed clumsy and wrong to me! but it worked...!

on your safari books thing "Core Data for iPhone: Building Data-Driven
Applications for the iPhone and iPod Touch
By: Tim Isted" might be worth looking at. I don't have it since I
dont have a subscription, but it popped up in my many searches for
info.

Hope this helps or at least makes you feel better that you are not
alone.

Will

[Bill]

Vicki, you are definitely not alone. I did ok on Paparazzi1, and opted
to skip the extra credit to try to catch up with the assignments. I
figured I'd go back later to do the extra credit stuff. Boy, was I
wrong! I wound up spending about 9 days working through Paparazzi2,
and I'm still not quite finished with the regular assignment, much
less the extra credit. Each roadblock led me to reading more
documentation on Core Data, and a lot had to do with how to accomplish
things programmatically instead of using IB. On my first pass, I
invoked the code for the FetchedResultsController and did the same
fetch for every single tableView method. It worked, but it felt icky
to look at.

It's only due to sporadic and strange crashes, specifically on the
PersonListViewController, that I decided to go back and just see if I
could do it more cleanly. And I still get a crash every time I try to
set an NSPredicate, so that part just doesn't work in this app. I was
able to build a test app that worked, so I definitely feel flummoxed
by several bits of Core Data, and I don't like the slow pace with
which I get bits of Paparazzi2 to work. Definitely a labor of love.

At this point, I'm re-watching the lectures to see if more of it
sticks out, and maybe there are more hints that I missed the first
time around. Josh talks really fast sometimes, and I missed many
things the first time.

I'm glad for people on this list, and code samples or tutorials on the
'net, which have helped immensely in supplementing the lectures.

Ok, back to Core Data. ;-)

Bill

[weejayuk]

Thinking about your solution to the moveRowAtIndexPath method. I was
thinking about doing a similar job, with having an order attribute in
the Person table. I know it will work, but from a MVC perspective I
think that having a persistent attribute related to how something is
displayed, stored in the model object seems wrong. I know this is a
little pedantic, and in this case a little trivial, but would be
curious to hear from others, how they would go about solving the
problem of needing persistent data for a specific view that is
related to the model, but not part of it?

To illustrate, if we were viewing the person data from a number of
different tables, each with their own customised order, and we wanted
to persist those orders, where would you store it.

Hypothetical I know, but I'm curious.

I hope this is clear....
Thanks
Will

[redbirdo]

Will

I don't see the person order in this case as a display order but as
the default 'person order' in all cases where a person order is
required. I'm making this assumption based on my development
experience. In real life I'd ask users/customer (if available) or make
a best guess based on my knowledge of the application. The fact is,
when you are doing an assigment like this you have to make these sort
of assumptions. You could ask the tutor, but TBH I think you'd find
they're not bothered about details like this - as long as you document
your assumptions to show you've considered it.

In a real world app you would hopefully have a better idea of how the
'person order' fits into the app as it evolves and whether it is a
significant order or truly just a display order. If the later and as
you suggested a separate order were required for a number of different
views (perfectly feasible) then off the top of my head I would have an
Entity called e.g. PersonViewOrder which captures the order for a
particular person in a specific view. That is I would separate the
ordering behaviour from the Person entity. However, depending on the
type of persistent store this could have an increased resource
overhead (storage/performance) and therefore not be recommended for a
single person ordering.

Vicki

[redbirdo]

Well, its nice to know I'm not the only one!

Lenny,

Your solution sounds cleaner than mine. However, I'm not sure I
understand it.

When you say:

>1) In my fetched array I removed the object at sourceIndexPath and inserted the object at destinationIndexPath

When you say 'fetched array' what do you mean?

I'm kind of assuming you don't mean the array returned by
'myResultsController,fetchedObjects' as its an NSArray, not an
NSMutableArray. Futhermore, according to the class reference, the
fetchedObjects property is intended to be readonly. Even if it happens
to be castable to an NSMutableArray that would be undocumented
behaviour and could change in a future SDK update. In fact, I would
expect the method to return a copy of the array (containing the same
Person objects) as it shouldn't be possible to alter the internal
state of the FRC without calling a method - that would break
encapsulation. Nevertheless, it does happen - I suspect I've done it
myself!

Note - I see the ordering as part of the internal state of the FRC, as
itowns the fetch request and therefore the sort order. I don't see the
content of the Person objects as being part of the internal state of
the FRC.

So, how are you getting your fetched array?

Vicki

[weejayuk]

Vicki

Thanks for your views. I agree with you. Nice to have it confirmed.

Cheers
Will

[Lenny Teng]

Vicki - your assumption is correct.  I should have been more careful with my terminology, especially given the subject of this thread.  Anyways, here is how I got my fetched array:

array = [[NSMutableArray alloc] initWithArray:[moc executeFetchRequest:request error:&error]];

I initially completed the assignment using FRC, but I also found it complex and confusing, especially when trying to complete the extra credit.  Then when I discovered the 'moc,exectueFetchRequest' it just seemed cleaner to me. So I changed my code around a little bit to take advantage of the array I set up above.  After that, this whole assignment was simply easier to implement and made more sense to me.

---

From: redbirdo <vicki...@googlemail.com>
To: iPhone Application Development Auditors <iphone-appd...@googlegroups.com>

Sent: Sun, March 7, 2010 1:54:33 PM
Subject: [iPhone-AppDev-Auditors] Re: NSFetchedResultsController / Core Data

[redbirdo]

Lenny

Thanks for that - that sounds like a good compromise between the FRC
functionality and something a bit more 'readable'!

How do your RC delegate methods get triggered? Are you still using an
FRC as well as the array?

Thanks
Vicki

[Lenny Teng]

Vicki - after setting up the array, there was no longer a need for the FRC.  I just looked at my code again to make sure, and there are no references to a FRC.  Hence, there are no RC delegate methods as well.  Row moving and deletions were accomplished via UITableViewDataSource Protocol per the documentation: 

http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/TableView_iPhone/ManageInsertDeleteRow/ManageInsertDeleteRow.html#//apple_ref/doc/uid/TP40007451-CH10-SW1

---

From: redbirdo <vicki...@googlemail.com>
To: iPhone Application Development Auditors <iphone-appd...@googlegroups.com>

Sent: Sun, March 7, 2010 6:50:28 PM

Subject: [iPhone-AppDev-Auditors] Re: NSFetchedResultsController / Core Data

[weejayuk]

I would like to retract my earlier moan and point people towards the
iPhoneCoreDataRecipes example provided by Apple. It gives you all you
need to do most of the Core Data stuff.

On 8 Mar, 00:56, Lenny Teng <lenny_t...@yahoo.com> wrote:
> Vicki - after setting up the array, there was no longer a need for the FRC.  I just looked at my code again to make sure, and there are no references to a FRC.  Hence, there are no RC delegate methods as well.  Row moving and deletions were accomplished via UITableViewDataSource Protocol per the documentation:
>

> http://developer.apple.com/iphone/library/documentation/UserExperienc...
>
> ________________________________
> From: redbirdo <vicki.cl...@googlemail.com>

> To: iPhone Application Development Auditors <iphone-appd...@googlegroups.com>
> Sent: Sun, March 7, 2010 6:50:28 PM
> Subject: [iPhone-AppDev-Auditors] Re: NSFetchedResultsController / Core Data
>
> Lenny
>
> Thanks for that - that sounds like a good compromise between the FRC
> functionality and something a bit more 'readable'!
>
> How do your RC delegate methods get triggered? Are you still using an
> FRC as well as the array?
>
> Thanks
> Vicki
>
> --
> You received this message because you are subscribed to the Google Groups "iPhone Application Development Auditors" group.
> To post to this group, send email to iphone-appd...@googlegroups.com.

> To unsubscribe from this group, send email to iphone-appdev-aud...@googlegroups.com.

[Bill]

I second Will's reference to the iPhoneCoreDataRecipes code sample on
the developer website. It has lots of really good stuff for the
Paparazzi assignments.

Bill

[wgp...@gmail.com]

+1 for Recipes sample

[Phong]

I just recently found CS193P and have been working on core data on my
own using Jeff LaMarche et al's More Iphone SDK Development. Part 1 of
the book provides solid 6 chapters on Core Data that I found useful. I
was reading Apple's programming guide but going through a detailed
example was very useful for me. It seems that Core Data has some
rough parts that perhaps will be fixed with the recent 3.2 beta? But
the chapters has explanations that helped.

http://www.amazon.com/More-iPhone-Development-Tackling-Beginning/dp/143022505X/ref=sr_1_1?ie=UTF8&s=books&qid=1268355569&sr=8-1

- Phong

On Mar 8, 11:48 am, "wgp...@gmail.com" <wgp...@gmail.com> wrote:
> +1 for Recipes sample

[Jazmin]

Hi Vicki,
I just wanted to comment that saving the MOContext does not trigger
the update of the table view. The table view is changed the moment the
cell is dragged to the new position.

thank you.