Due to issues related to archive builds and flakiness with configurations other
than Debug and Release, it is impossible to use the automatic include/ build path
to avoid adding header search paths. Switching to requiring a fixed set is simpler
and eliminates the need for the rsync process.
* Reorganized tests to accommodate split into Logic & Application.
* Eliminated 'Spec' naming in favor of 'Test' as the suite is entirely based on SenTest.
* Pulled majority of testing support classes up into the library and documented them.
* Introduced RKApplicationTests app for running the RKTableController UI tests
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.
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.
When building for the iphonesimulator sdk we still want i386. Without
this change, when building from the command line, xcode is failing
to autotodect the dependency of the application project on the RestKit
project in a workspace.
In iOS 5, Apple has removed armv6 from $ARCHS_STANDARD_32_BIT. This can
result in RestKit being built against armv7 only when you are really trying
to build against the iOS 5 SDK, be deploy to 4.x devices. App store validation
will fail in these situations.
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.
* Builds on work started by @OpenFibers.
* Should eliminate all cache warnings.
* Added FileMD5Hash library for efficiently computing MD5 for files
* Extended RKParams to return composite MD5 for all attachments
* Implemented MD5 method on each RKParamsAttachment instance
* Updated RKRequest to utilize new MD5 sums and enabled cache keys for RKParams
These issues has been open for some time. I have added thorough unit test coverage
for scenarios of mutating the HTTP AUTH credentials on the RKClient and on individual
RKRequest instances. Everything seems to work fine.
Also added RKAuthenticationExample to RKCatalog for testing. Needs to be updated with
support for using OAuth.
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.
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.
NSDateFormatters, added a preferredDateFormatter for use when serializing dates to strings,
replaced the use of the description method for date encoding to strings with invocation of the
preferredDateFormatter, added new attribute transformation strategy from NSDate -> NSString properties
(also using the preferred date formatter), and provided customization support for date handling globally
and on a per-mapping basis. closes#200, closes#313, closes#309, closes#308
