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.
* When the reachabilityObserver property of RKClient is nil, assume we have reachability
* When the baseURL configured contains an IP address or localhost, use hostname based reachability
* Else fall through to using Internet reachability if the user has not configured an observer directly
* 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
Cleaned up @rodchile's excellent work integration OAuth 1.0 and 2.0 into RestKit. Changes
are as follows:
* Introduced new RKRequestAuthenticationType to replace the forceBasicAuthentication and other
methods for influencing how authorization works.
* Moved TDOAuth code into Vendor/
* Renamed authorization code flow classes and delegate methods for clarity.
* 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
* Factored out display of alerts into RKAlert interface that hides the differences between UIKit and OS X Cocoa.
* Added macosx to supported platforms to enable build on OS X.
* Configured project to use conditional architectures to enable building on OS X and iOS from the same targets.
* Implemented a bare-bones OS X example app.
* Create `rake build` task for building RestKit against iOS and OS X SDK for quick testing.
