RKTableController provides a flexible, integrated system for driving iOS table views using
the RestKit object mapping engine. Local domain objects can be mapped into table cells within a
collection or presented for editing as part of a form. There are three flavors of table controllers
available:
* Static Tables: RKTableController can be used to render simple static tables that are composed of RKTableItems
presented in RKTableSections. Table items can quickly be built and added to a table without a backing model
or can have content object mapped into them for presentation.
* Network Tables: RKTableController can also render a table with the results of a network load. The typical use
case here is to have RestKit retrieve a JSON/XML payload from your remote system and then render the content into
a table.
* Core Data Tables: RKFetchedResultsTableController can efficiently drive a table view using objects pulled from a
Core Data managed object context. Typical use-cases here are for the presentation of large collections that are
pulled from a remote system, offering offline access, or speeding up a UI by using Core Data as a fast local cache.
RKTableController supports a number of bells and whistles including integrated searching/filtering and pull to refresh.
There's currently a known issue for appledoc (https://github.com/tomaz/appledoc/issues/147) that causes it to fall over when it encounters a method declaration in an implementation that is missing a type (even if its in the header file). While this is valid Objective-C, lets update this to allow appledoc to go on its merry little way.
* Fix 1 declaration relating to atKeyPath: in RKObjectMapper.m
* Fix 2 declarations relating to atKeyPath: in RKObjectMapper_Private.h
* Fix 1 declaration relating to atKeyPath: in RKObjectMappingOperation.m
All declarations were changed to declare keyPath as an (NSString *).
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.
