FWIW: this is a well-received variant of the MVP pattern that applies very nicely to iOS ... http://atomicobject.com/files/PresenterFirstAgile2006.pdf
-Luther On Wed, Jun 26, 2013 at 1:23 AM, Luther Baker <lutherba...@gmail.com> wrote: > Hi Rick, > > Warning ... my suggestion does not actually solve your problem as stated > and I fear it runs the risk of starting a strange heretical war :( as I'm > not sure how folks in this group will receive the suggestion ... but if > this is indeed your own project, you may want to take a look at the MVP > pattern <http://en.wikipedia.org/wiki/Model-view-presenter>. > > I'd suggest that a strong reference to a Core Data entity in your view > code is a code smell. It sounds like you're asking for trouble. Solutions > requiring connected entities in the view generally lead to some very dark > corners in the code. And yes, Apple's SDK seems to encourage and make it > very convenient but ideally, Core Data should be completely abstracted away > - down beneath the model layer. > > I hope this is somewhat helpful. I don't mean to criticize. I never like > to post a question and get an answer back that basically says "You > shouldn't be doing that anyway" - so know that is not my intent here. Its > the "give a man fish ...vs... teach a man to fish" style of answer that I > strove to achieve with this response. > > At any rate, remember, it's just a suggestion ... and as such, it, too, > comes with its own set of caveats. > > -Luther > > > > > > On Tue, Jun 25, 2013 at 5:36 PM, Rick Mann <rm...@latencyzero.com> wrote: > >> A bit of additional info: >> >> The only job I can't delete is my "active" job. I keep a strong reference >> to that object in a view controller. I have that view controller set up to >> listen for changes to the MOC, and to forget that active object if it is >> deleted, but this seems to be what's causing the problem. >> >> If I first set that reference to nil, and THEN delete the object, I don't >> get the problem. >> >> But this clutters my delete code; I'd rather just watch for changes to >> the MOC. Is that unreasonable? >> >> On Jun 25, 2013, at 15:30 , Rick Mann <rm...@latencyzero.com> wrote: >> >> > I have a situation in which I can't delete one of my core data objects >> from a UITableView. The list is built using NSFetchedResultsController, and >> I delete the objects after the user swipes to delete with >> > >> > Job* obj = [self.resultsController objectAtIndexPath: inIndexPath]; >> > [obj.managedObjectContext deleteObject: obj]; >> > >> > I then save the MOC. >> > >> > My -controller:didChangeObject:atIndexPath:forChangeType:newIndexPath: >> delegate method gets called with NSFetchedResultsChangeDelete, and I call >> > >> > [self.tableView deleteRowsAtIndexPaths: @[ inIndexPath ] >> withRowAnimation: UITableViewRowAnimationAutomatic]; >> > >> > But then, as part of the same MOC -save: call, it gets a >> NSFetchedResultsChangeInsert. Interestingly, the address of the object >> inserted is the same as the address of the object that was just deleted, as >> is its x-coredata URI, but all of its properties have default values. >> > >> > If I then try to delete the object again, it's data is <fault>, and the >> MOC -save method returns false, but no NSError is returned. >> > >> > Any ideas? >> > >> > >> > -- >> > Rick >> > >> > >> > >> > >> > _______________________________________________ >> > >> > 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/rmann%40latencyzero.com >> > >> > This email sent to rm...@latencyzero.com >> >> >> -- >> Rick >> >> >> >> >> _______________________________________________ >> >> 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/lutherbaker%40gmail.com >> >> This email sent to lutherba...@gmail.com >> > > _______________________________________________ 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
