views:

50

answers:

2

This is the best tutorial I found so far on migrating data across apps:

http://www.mobileorchard.com/lite-to-paid-iphone-application-data-migrations-with-custom-url-handlers/

But it only discusses the case where you have total control over how the data is represented, such as would be the case if you were constructing your own archivable plist objects and moving them in and out of your documents directory. What if your app uses Core Data and you want to migrate a store across apps?

In my case I want to have a free app's Core Data store get picked up by a paid app at launch. Let's assume that I am going to use the pasteboard process as described above, such that iOS provides a great mechanism for saving NSData, launching an app, and claiming the NSData. So, how do you wrap a Core Data package in NSData?

To make this even feasible, let's assume that the free version uses the same model or a subset model of the full version such that lightweight migration is confirmed functional. Is it possible to get the contents of a persistent store, feed them into an NSData object, and then unpack the NSData object to a new store? I'm just guessing that this would be a persistent store... the real question is, what would such an object be?

A: 

You probably want to use an NSFileHandle to read and write the store. That should just byte copy the file such that it copies the file from app to app without changing its structure. If you write with NSData, you would get an XML plist file which would be useless.

However, IIRC, can't you do an in-app upgrade i.e. convert a lite version to a paid version in place? Somebody should check me on that.

TechZen
A: 
NSPersistentStore *store = ...;    
NSData *data = [NSData dataWithContentsOfURL:[store URL]];

< pass it through the pasteboard >

[data writeContentsToURL:newURL atomically:NO];

The file at newURL is now a persistent store. You can add it to a persistent store coordinator in the usual way.

This has several drawbacks compared to the recommended way of migrating stores to a different location in the file-system.

  1. You need to pull the entire store into memory.
  2. There are no safe-guards as to whether any contexts hooked up to the store are saved or not.
Aderstedt
Thanks, that was great.
SG1