NOIncrementalStore support

[colemancda]

NOIncrementalStore will block its thread while fetching data. NOAPI and NOAPICached store will be integrated into NOIncrementalStore (as properties, categories, in the implementation itself. SNCStore will have a context that serves as cache and a child store that uses NSIncremental store.

[colemancda]

Ok, so there are 2 branches for NOIncrementalStore.

Branch 1

• NOIncrementalStore-support branch integrates NOAPI and NOAPICachedStore and migrates their code into a NSIncrementalStore subclass. NOIncrementalStore uses semaphores that will block the fetch requests and faulting methods and return the data from the server.

Pros:

• Correct way of implementing a NSIncrementalStore. Uses options dictionary instead of custom properties (besides a NSURLSession property) for server Schema and uses self.URL property correctly.

Cons:

• Blocks the serial queue on the context that calls it, requiring a separate context for each server request if they are to be performed concurrently.
• Cannot synchronize with a cache context because fetch requests are not changes, ergo the cached context will not send NSManagedObjectContextObjectsDidChangeNotification, ergo useless for fetched results controller.

Branch 2

• NOIncrementalStore-support-2 branch's NOIncrementalStore uses a NOAPICachedStore as a property and immediately returns cached values while fetching remote data in the background. The faulting works the same way, returning cached data and sending notifications when the remote fault request (GET) completes.

Pros:

• Fetch results work better then in NOIncrementalStore-support and a single context can be used (besides the cached context of course but that is sorta hidden).

Cons:

• Incorrect way of implementing NSIncrementalStore. Not only is self.URL ignored, but the requests are forwarded to another class (not a superclass) and the calling context's managed object model is ignored for a custom property. The options initialization dictionary is ignored.
• While the fetched results work better then in NOIncrementalStore-support and do not block the context's thread, the error and results from the remote fetch have to be forwarded through NSNotificationCenter and custom notifications.

---

In the end, NSIncrementalStore does not seem suited for network fetches. While there are way to forward the errors, still have concurrency, and while the Objective-C classes would make network communications completely object oriented, the implementation in the main branch does the best job for what its supposed to do, even if the API could be improved on.