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.
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.
Other changes include:
* Eliminated the RKObjectFactory protocol and implementations. Object mapping instances themselves are
now responsible for instantiating target objects for mapping.
* Introduced RKObjectAbstractMapping superclass for RKObjectMapping and RKObjectPolymorphicMapping.
* Updated example applications to use block object loaders (RKTwitter and RKTwitterCoreData)
* Refactored method signatures of RKObjectMapper, RKObjectMapping, and RKObjectMappingProvider to reflect the
existence of abstract mapping types. This was necessary to make polymorphic mappings integrate cleanly.
* Fixed overlap in RestKit error domains between network and object mapping. fixes#208
* Introduces RKRequestCache for cacheing responses (supports ETag conditional GET, use cache if available, use cache on error, etc.) closes#75
* Updates to Three20 layer to eliminate need for intermediary TTTableItem classes closes#76
* Fixes to ensure iOS 3.x compatability:
* Switched compiler to Clang
* Updated conditional checks for UIBackgroundTask symbols to ensure runtime safety on iOS 3.x
* Removed unnecessary linkage against UIKit and CoreFoundation from library targets
* Fix for issue where RKRequest objects could become stuck in infinite loop within RKRequestQueue loadNextInQueue if you start
a request and then cancel immediately. On cancel only decrement loadCount if the request has start loading. refs #122
* Removed RestKit from inheritance hierarchy
* Mappings are implemented as concrete classes
* Mapper is much more flexible & powerful
* Much more robust error handling
* Serialization is reimplemented as an object mapping operation
* Added ability to serialize to JSON natively
* Reworked Core Data integration
* Simplified the codebase substantially
* Cleaned up various mismatches in method signatures that were preventing documentation generation
* Removed naked ampersands from comments as they cause XML parser failures during docset generation via appledoc
