- MagicalRecord has good reputation as a framework that further abstracts CoreData goodness. So when thinking about the "RestKit to CoreData" piece, it is only natural to get excited about news like: RestKit is built, in part, on top of MagicalRecord !!!
CoreData is desirable because of classes like NSFetchedResultsController.h which help to efficiently manage the results returned from a Core Data fetch request. Have a look at the comments for that class and it makes its own usefulness painfully apparent.
- Now CoreData is built upon DataSources such as SQL-lite so I feel that there is an inherent difference in the query language of CoreData which has been written for relational databases versus nosql DBs like CouchDB … but I could be wrong about this and need to collect the opinions of others in the dev community on this matter.
If all I'm worried about is the smoothness with which a UITableView updates when used solely against an embedded CouchMobile/TouchDB/SyncPoint instance then I should get and see what it the user experience for the GrocerySync app feels like.
- Look at CouchUITableSource
- Based on https://github.com/couchbaselabs/TouchDB-iOS/wiki/FAQ:
- Couchbase Mobile 2.0 is implemented in an interpreted language (Erlang) whose runtime library needs to be bundled in. This make me think that IF CouchCocoa is the client interfacing with it then CouchUITableSource ends up helping out the same way as NSFetchedResultsController.
- TouchDB is inherently different because it’s using SQL for storage, rather than a custom append-only B-tree implementation. Does this mean that it far better suited for a head on CoreData integration + optimization? *Shrug* ... anyway CouchUITableSource is still there to help for now.