Extended RKObjectMappingProvider to store collections of object mappings for different use cases. The framework
now stores object mappings, serialization mappings, an error mapping and a pagination mapping using the context
support. Contexts can be added to the provider via method calls or extension via a category.
Initialization
I need the object paginator's object loaders to
know about the various header settings of
the RKClient when it constructs them. However,
the paginator should not depend on an RKObjectManager.
The proposed solution is to pass a block that lets
an outsider custom configure the object loaders
that get created. The object manager shows how
it is done.
Error Handling
We don't want to have a separate set of error handling
if using a paginator versus using an RKObjectLoader.
When an error is encountered, the paginator should
allow access to the underlying RKObjectRequest that
produced the error.
Cleanup
The contained object loader needs to nil out the delegate
before going away.
NSLogs changed to RKLog
Pagination computation
The page count can be computed when the pagination
parameters are mapped. Note you must use the ceil
operation to compute this value. If there are 3.1 pages
that means there are 4 pages.
Added RKLogWarning for aiding in further debugging. So far unable to trap this in a unit test, but have had
several complaints about the issue on the mailing list.
* Added support for monitoring by IP address or hostname as well as local Wifi and Internet access generally
* Eliminated usage of synchronous calls to obtain reachability flags during status checks
* Reworked SystemConfiguration reachability callback to cache flags
* RKClient now monitors Internet access instead of hostname based reachability by default. baseURLReachabilityObserver eliminated in favor of reachabilityObserver. It is now a retain property that can be customized
* Queue suspension is now tied to the reachability observer rather than baseURL mutation
This can happen when using keyPaths to traverse an object graph and is hard to anticipate when
defining mappings. RestKit will now perform a sanity check before recursively performing
relationship object mapping operation and will log a warning if the relationship targets
a collection containing another collection. At the debug logging level, RestKit will log
The fix for such scenarios is to use KVC collection operators (such as @unionOfObjects,
@unionOfArrays, etc.) to flatten the collection out into a collection of dictionaries.
Since OM 2.0 connection of relationships happened during the object mapping operation
instead of aggregately at the end of the process. In this commit, we have introduced a lightweight
queue for deferring portions of the mapping operation until a larger aggregate mapping has completed.
The changes are as follows:
* Introduced RKMappingOperationQueue for queueing portions of mapping. This is a synchronous queue modeled off
of NSOperationQueue that does NOT use threading (for Core Data friendliness).
* RKObjectMappingOperation now has a RKMappingOperationQueue queue property that defaults to nil
* RKObjectMappingOperation instances built via RKObjectMapper will has a mapping operation queue
assigned to the property.
* If a queue is present, RKManagedObjectMappingOperation will use it to defer the connection of relationships.
* At the end of an RKObjectMapper process, the mapping operation queue used by all mapping operations created
during the process will be executed. This allows all relationships to be connected after all object creation
has completed.
The queue is general purpose, though currently only used for the connection of relationships.
Fix of RKObjectMappingOperation does not respect forceCollectionMapping (Issue #341) This fixes#341. A solid pull request with good tests. I ran through it prior to his new test coverage last night and it looked good with no discernible side-effects. With the new test coverage, the added code gets exercised appropriately.
