CoreData versus AeroGear Pipe

gistfile1.md

CoreData

In CoreData your class has to inherit from the ManagedObject class. In addition to that some odd infrastructure needs to be setup (E.g. a PersistentStore a "managed object context", a model file, and if needed some property mappings).

Once that is done, the create and update is pretty simple.

Create:

Task* task =  // Tasks inherits from ManagedObject
  [NSEntityDescription
    insertNewObjectForEntityForName:@"Task"
    inManagedObjectContext:__managedObjectContext];

// set properties:
task.title = @"Created via CoreData and AFIncrementalStore";
...

// store the beast:
[self.managedObjectContext save:nil]; // nil, because we don't give a NSError pointer..........

Update:

// update the task title......
for (Task* t in results) {
  if ([t.title isEqualToString:@"CoreData Task"]) {
    // update
    t.title = @"Updated by CoreData/AFIncrementalStore";
    [self.managedObjectContext save:nil];
    }
}

The managedObjectContext:save updates (commits) ALL outstanding changes to the "object graph".

Fetching:

Fetching data is done with the NSFetchRequest class (you can apply filters with NSPredicate), like here:

NSFetchRequest *request = [[NSFetchRequest alloc] init];

[request setEntity:
  [NSEntityDescription entityForName:@"Task"
              inManagedObjectContext:__managedObjectContext]];

NSArray *results = [moc executeFetchRequest:request error:&error];

If you are more UI (UITableView) it is recommended to use the NSFetchedResultsController and its delegate protocol.

AeroGear

AeroGear-iOS has a minimal weight, no complex infrastructure is needed. The developer (currently) is responsible for his data model, and can use the pipes to work against remote endpoints:

// save or update 
[mypipe save:taskObject success:^(id responseObject) {
    // LOG the JSON response, returned from the server:
    NSLog(@"CREATE RESPONSE\n%@", [responseObject description]);
} failure:^(NSError *error) {
    // when an error occurs... at least log it to the console..
    NSLog(@"SAVE: An error occured! \n%@", error);
}];

CoreData and(vs) AeroGear

First of all the programming model is way different, and I initially thought to move the CoreData fetch/store API into a Pipe, but I more and more dislike that:

• It forces CoreData fans to give up their loved and well-known programming model.
• Side effects when folks start to mix both ways.

As said, some infrastructure work on CoreData is needed, for every application, but lots of that can be factored out into a util/plugin.

Moving forward

Right now I am looking into keeping the EXISTING CoreData programming model and (for CoreData only) skipping the pipe. It feels more natural for CoreData folks...

The idea is to be still working with the AeroGear backend, by providing some sort of utility that is responsible for setting up the infrastructure. The util also would understand alternative URL mappings and other config settings like the AuthModule.

The API/util will basically contain an AeroGearPersistentStore and when actived, it uses the AeroGear settings for the remote persistence...

But I guess the downside is... that we are not using the AGPipe for CoreData.... At least that's my current thinking

AeroGear IncrementalStore

The plugin will be for iOS5 (only), since we leverage the NSIncrementalStore API. Internal a HTTP client is taking care of talking to the "AeroGear backend", based on configuration... (working, but room for improvement).

Next step is the move the "Infrastructure" creation (e.g. ManageObjectContext) also into the "AG CoreData Plugin".