Using Parse to replace Core Data - ios

Question

I just found out about Parse's Local Data Store and it looks like a SQL database that handles online/offline syncing.
I'm writing an application for a client who wants something similar to the contacts app. Contacts can be added/edited offline, or added on a different device, and they all need to sync properly and not create duplicate entities.
Is using Parse Local Data Store a viable option?
I do this in the App Delegate did finish launching with options method:
query.findObjectsInBackgroundWithBlock {
(objects: [AnyObject]?, error: NSError?) -> Void in
if error == nil {
if let objects = objects as? [PFObject] {
PFObject.pinAllInBackground(objects, block: nil)
}
} else {
println("Error: \(error!) \(error!.userInfo!)")
}
}
Then in my initial view controller I do this:
query.findObjectsInBackgroundWithBlock {
(objects: [AnyObject]?, error: NSError?) -> Void in
if error == nil {
if let objects = objects as? [PFObject] {
self.athleteArray = objects
self.tableView.reloadData()
}
} else {
println("Error: \(error!) \(error!.userInfo!)")
}
}
However, I assume because the App Delegate query runs in the background, the data store hasn't received objects when the view controller runs because the tableview shows up empty.
When I launch the app again later, the objects are there because the data store has been populated.
How can I manage syncing objects (in real-time, no second app launching) using Parse's Local Data Store? Am I doing something incorrectly?

Answer 1

Parse and Core Data solve different problems. Parse is a cloud data store with a bunch of useful ancillary services. Core Data is an Objective-C Object Graph persistence system. The first thing to ask yourself is:
1) Every Parse query potentially costs the developer money and the user bandwidth and latency. Are these costs worth the price paid?
2) Parse's local data store has in my experience been less reliable than I would like. It may be sufficiently reliable for your needs. Only you can tell? I've chosen to use both Core Data and Parse in my most recent app.
3) Synchronizing data is hard. Parse, by being the "truth in the cloud," may make this easier. But not through the local data store. Each synchronizing app will need to scan a non trivial amount of its local database and compare it with the cloud. There are ways to mitigate this but comparison against the "truth" will be required and merge conflicts handled.
4) Parse's local data store is not a shared resource, as you appear to believe. The local datastore lives in each app's sandbox and is isolated. Parse is doing some things to allow sharing for Watch extensions and that may blow open with watchOS v2. But I would not count on it until Parse ships it.
That last point is very important. Parse is, at their heart, a web technology company. They believe in rapid technology turns. If they don't quite get it working now, they will soon. As a developer, this means you should not jump on their new technologies until they've iterated releasing the tech a few times.
I find that the path to success with Parse lies with using them for what they do well when you start your project. It is unclear that they will evolve at anywhere the speed you need to meet your goals and they have little incentive to bend that rate for a new app.