Returning NO on canEditRowAtIndexPath, but can edit if scrolled - objective-c

Question

So I've been looking for an answer to this interesting issue I came across but haven't had very much luck. Basically I have a UITableView preloaded on initial app launch with a few objects using CoreData, and the ability for the user to add more.
I allow deleting of cells in the table, except for the items I have initial pre-loaded. So I perform a check in my canEditRowAtIndexPath method and return NO if the selected item is one of these pre-loaded items. Everything works great until I scroll down far enough for one of the items to be offscreen, and then when it snaps back the item that shouldn't be editable, is now editable.
I'm fairly new to iOS development, so I'm hoping this is a rather amateur issue - but I can't seem to find the answer.
Any help is appreciated.
- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath
{
DataLayer *dl = [DataLayer alloc];
// Get all items from Favorites
NSArray *results = [dl FetchAll:#"Favorites"];
// Get currently selected cell properties
FavoritesTableCell *selectedCell = [tableView cellForRowAtIndexPath:indexPath];
Favorites *fav = [Favorites alloc];
NSMutableArray *genItems = [[NSMutableArray alloc] init];
// Get only records that are default app items
for(int a = 0; a < [results count]; a++){
fav = [results objectAtIndex:a];
if ([fav.generic isEqualToNumber:[NSNumber numberWithInt:1]]) {
[genItems addObject:fav];
}
}
// Loop through default items to determine if editable
for (int i = 0; i < [genItems count]; i++) {
fav = [genItems objectAtIndex:i];
if ([fav.title isEqualToString:[selectedCell.nameLabel text]]) {
return NO;
}
}
return YES;
}

Answer 1

The root of the problem is that this method is basing it's answer on the content of a table view cell (selectedCell) rather than the model.
Table views reuse cells. As they are scrolled off the view, the "new" cells that appear are really the same object's that just disappeared on the other side of the table. So that selectedCell is not a good reference for a question that ought to be put to your model.
The code needs to be structured like this:
Your model is a NSMutableArray that starts with a few items you add. You need to know which items are originals, not to be removed:
#property (nonatomic, strong) NSMutableArray *favorites;
#property (nonatomic, assign) NSMutableArray *genericFavorites;
// at init, imagine these strings are your preloaded core data
[self.genericFavorites addObject:#"generic favorite object a"];
[self.genericFavorites addObject:#"generic favorite object b"];
[self.favorites addItemsFromArray:self.genericFavorites];
You'll use self.favorites as your model, that is when table view asks numberOfRowsInSection, you'll answer self.favorites.count. In cellForRowAtIndexPath, you'll lookup the item in self.favorites[indexPath.row] and configure the cell with data from that object. self.genericFavorites just helps you remember which objects are original, not added by the user.
If the order remains fixed, then your canEditRow logic is simple:
- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath
return indexPath.row >= self.genericFavorites.count;
}
But if, as maybe your code implies, the user can reorder these items, then your canEditRow has more work to do, but it can do that work without reference to the table cells (which as I indicated, are unreliable):
// get the object at indexPath.row from our model. Answer NO if that object was preloaded
// from the app (if genericFavorites containsObject:), YES otherwise
- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath
Favorite *favorite = self.favorites[indexPath.row]; // this is your model after user has edited, reordered, etc
return ![self.genericFavorites containsObject:favorite];
}