* Provides for the registration of route either by class and method or via symbolic name
* Changed routes representation from simple dictionary to RKRoute model
* Eliminated RKRouter as a protocol
* Migrated RKObjectRouter to Network layer and renamed to RKRouter
* Added router as property of RKClient, RKObjectManager now proxies access
classes to eliminate issues with duplicated objects. closes#611, #612, #613, #618
* NSEntityDescription is now aware of the primaryKeyAttribute. Can be configured via
Interface Builder within Xcode or programatically.
* Added findByPrimaryKey: interface to the Core Data extensions.
* Relaxed dependencies on RKManagedObjectMapping across the system now that primaryKey is
available without a reference to the mapping.
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.
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
* 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
This prevents didSendData RKRequestDelegate method from being called before didStartLoading.
Remove goOffline and goOnline support from RKObjectManager. This did not work in the current implementation.
