Core Data on A+ programming moments

One (not)weird trick to save your sanity with NSFetchedResultsController

Tue, 18 Feb 2014 00:00:00 +0000

I have no idea how many weeks I have wasted debugging issues that come down to this problem. I am pretty mad at myself for forgetting this, but oh boy, it’s not gonna happen anymore. Oh no.

Ok, so you have NSFetchedResultsController driving either a collection view or table view. And when customer is looking at those views, you want the changes to animate in/out, as Apple has ask us to do since the days when iOS was called iPhone OS. To do that, you need to implement the four horsemen of NSFetchedResultsControllerDelegate methods.

However - and this is the trick - you don’t need to do that when those views are not visible. You only need to call reloadData on end of changes. However, I guarantee you that 95% of iOS devs leave those four methods as they are. And experience hair-pulling mind-cracking EXC_BAD_ACCESS crashes all over the place, in darn background threads that cause postNotification:..:... and what not. And you have questions about this on StackOverflow being answered with

oh, just set self.fetchedResultsController.delegate to nil in viewWillDisappear and problem goes away. Re-set it on viewWillAppear

You don’t say! Well, it sure goes away, but you also lose all the changes and your views do not reflect the current state of data source. And then when you try to animate, more crashes ensue…

oh, that’s easy to fix. Just add [self.collectionView reloadData] in viewWillAppear…

AAARRGGHHH!

No. Do not do any of that crap.

For the love of your sanity and the trust of your customers, make sure you always have this in your code:

- (void)controller:(NSFetchedResultsController *)controller didChangeSection:(id <NSFetchedResultsSectionInfo>)sectionInfo
           atIndex:(NSUInteger)sectionIndex forChangeType:(NSFetchedResultsChangeType)type
{
	if (self.collectionView.window == nil)
		return;

	...	
}

- (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject
       atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type
      newIndexPath:(NSIndexPath *)newIndexPath
{
	if (self.collectionView.window == nil)
		return;

	...	
}


- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller {

	if (self.collectionView.window == nil) {
		[self.collectionView reloadData];
		return;	
	}
	
	...
}

and the equivalent for table view.

Update (Jul 25th, 2014): Kyle Fuller correctly points out on Twitter that this above is subject to race condition issue: that .window might become (or not) nil in-between these various delegate calls. It’s better to collect the changes as they happen and then when you get to controllerDidChangeContent: decide what to do, based on .window value.
Which is exactly what I do in the UICV category mentioned below, but overlooked that when writing the blog post.

To repeat: if your views are not in the currently visible window, then simply do reloadData. That is all. Class dismissed.

The code above is just a dummy thing. For my part, I have a custom category for NSFetchedResultsController and UICollectionView that does this automatically without repeated checks for window in each method, but the essence is what I wrote above.

You can find the UICollectionView category at GitHub.

Fix corrupted SQLite3 database

Sun, 22 Sep 2013 00:00:00 +0000

I tackled a very strange support request last few days, which escalated to the point that customer extracted the .sqlite database from the iPhone and sent it to me. I’m a SQLite3 rookie, but this worked for this particular case and I need to write for future reference. :)

When trying to open the file, Base would complain that file is either encrypted or damaged. When I placed it on my test device and started the app, it would immediatelly crash with this message in the console:

disk image is malformed

This usually happen if database file is accessed while still in use, but it can also happen if app is terminated during the save. In any case, I now needed to fix the database file and here’s how to do that.

Fixing damaged SQLite3 file

Copy it to some folder and open that folder in Terminal. Then type sqlite3 DBNAME.sqlite and Return to enter into sqlite3 shell, then do this:

.mode insert
.output s.sql
.dump
.exit

Now, open this s.sql file in any editor and remove all BEGIN TRANSACTION and ROLLBACK statements you find, as well as any lines where you see ERRORs mentioned.

Then re-build the fixed database:

sqlite3 FIXED.db < s.sql

You will most likely lose some records, but will probably mean you now have a working database.

One additional tidbit: at the sqlite shell, this is the command to check integrity:

PRAGMA integrity_check;

If it results in anything except ok, database is corrupted.

Using State Preservation with Core Data

Thu, 12 Sep 2013 00:00:00 +0000

In previous post on state preservation and restoration, I presented the basics. This post deals with something that’s fairly common in data-driven apps.

Core Data is one of my favourite iOS frameworks; I use it in almost all of my apps, anything that requires even a minor object graph. So, let’s see how to save/restore state of table views (it’s the same for collection views) fueled by NSFetchedResultsController.

In Couch to 5k apps, this Runs tab contains UITableViewController subclass. We know from previous post that we should adopt UIDataSourceModelAssociation protocol for its data source:

@interface ProgressViewController : UITableViewController < NSFetchedResultsControllerDelegate, ..., UIDataSourceModelAssociation >

To refresh your memory - this view controller is created in App Delegate, as top level VC for the Runs tab. Thus I only need to set its restorationIdentifier and UIKit will do the rest (no need for the restoration class).

- (id)initWithStyle:(UITableViewStyle)style {
	
	self = [super initWithStyle:style];
	if (self) {
		self.restorationIdentifier = RTRunStateIdentifierPROGRESS;
		...
	}
	...
}

Saving state

To save the state, the main thing is to choose the modelIdentifier - a string to uniquely identify NSManagedObject (subclass) that corresponds to each cell.

The obvious choice is NSManagedObjectID as it’s universal identifier for the given object. To convert it into string, use [[NSManagedObjectID URIRepresentation] absoluteString] thus for my case the method looks like this:

- (NSString *)modelIdentifierForElementAtIndexPath:(NSIndexPath *)idx inView:(UIView *)view {
	
	if (!idx || !view) return nil;
	
	NSManagedObject *oneSession = [self.fetchedResultsController objectAtIndexPath:idx];
	return [[oneSession.objectID URIRepresentation] absoluteString];
}

And that’s all that’s needed to preserve the (scrolling) state.

Restoring state

This was more fun to figure out and it takes 3 steps:

get NSManagedObjectID, using managedObjectIDForURIRepresentation: method of NSPersistentStoreCoordinator
use that to load actual NSManagedObject from the NSManagedObjectContext using existingObjectWithID:error: method
finally get NSIndexPath that we are after, from NSFetchedResultsController using indexPathForObject:

Here’s the full method:

- (NSIndexPath *)indexPathForElementWithModelIdentifier:(NSString *)identifier inView:(UIView *)view {
	
	if (!identifier || !view) return nil;
	
	// get the objectID first from PSC 
	NSManagedObjectID *objectID = [self.managedObjectContext.persistentStoreCoordinator managedObjectIDForURIRepresentation:[NSURL URLWithString:identifier]];
	if (!objectID) return nil;

	// then fetch the object from MOC 
	NSError *error = nil;
	NSManagedObject *oneSession = [self.managedObjectContext existingObjectWithID:objectID error:&error];
	if (error) {
		NSLog(@"ERROR getting Session object from MOC:\n%@", [error localizedDescription]);
		return nil;
	}
	if (!oneSession) return nil;
	
	// finally get the index path from NSFRC 
	NSIndexPath *indexPath = [self.fetchedResultsController indexPathForObject:oneSession];
	
	// iOS 6 bug workaround: 
	// Force a reload when table view is embedded in nav controller or scroll position is not restored.
	[self.tableView reloadData];
	
	return indexPath;
}

The workaround at the end is hopefully going away quickly, as we all move to iOS 7 only apps.

Always use isEqualToString for string comparisons

Sat, 09 Jan 2010 01:28:10 +0000

While working on my iPhone app Quickie, I encountered one of many examples why you must always check your code on the actual device.

Quickie uses Core Data for storage and in one particular place I was comparing the NSString variable to a NSString-typed property of my CoreData class, QuickieList. Like this:

if (QuickieList.listName != theListName)

listName is defined as NSString and theListName is obviously that as well. In this particular instance, both of those had the value of “test”.

In the iPhone Simulator (running on 10.6.2) this comparison returned false, but on the iPhone running 3.1.2 it returned true. When changed into:


if (![QuickieList.listName isEqualToString:theListName])

result was the same.

Never – I repeat – never assume that simulator testing will be fine, even for seemingly small things. It can bite you when you least expect it.