MMRecord reached another milestone today as it was updated to 1.3.0. This is the second major update in 3 months, and includes a few fixes from 1.2.0 as well as a few handy new features.

A key feature in the latest version is the addition of two new MMRecordOptions blocks. MMRecordOptions is a little-known feature of MMRecord that provides some specialized request parameters that allow you to customize request and parsing behaviors.

MMRecord now includes the ability to inject a primary key for a given record into the request via an optional block. This is a handy option because sometimes an API response doesn’t include a way to uniquely identify the item. Sometimes this happens when you use a certain identifier to request a resource, but that identifier isn’t returned as part of the response. The optional primary key injection block allows you to pass that identifier back into the response parsing process to act as the primary key, or to create your own key if you need to. Most of the time you won’t need this, but when you do need it it should prove very useful :)

A popular request has also been support for AFNetworking 2.0. MMRecord has always provided implicit support for AFNetworking 2.0, because the library is designed to work with any networking library. We’ve used AFNetworking 2.0 and MMRecord on a few projects here at Mutual Mobile, but we haven’t had a subspec or example that specifically shows how these two work together. Thats all fixed in MMRecord 1.3.0, and a new AFMMRecordSessionManagerServer subclass of MMServer has been added as a subspec that implements the MMServer interface using AFNetworking 2.0. You can use this as is for simple use cases, or customize it for more complex ones as needed. And of course, the AFMMRecordResponseSerializer introduced in MMRecord 1.2.0 is still here as well.

Its still great seeing the feedback from folks on MMRecord. Try out the new features and let me know what you think!