Menu

Subscribe

Architecture and Setup Tips Using RestKit RKObjectManager

on Architecture, Core Data, REST, Objective-C, iOS, RESTkit

Problem:

RESTkit is a great framework for building RESTful client applications on iOS but it’s a bit cumbersome and is not that easy to set up right.
In our case we wanted to have a robust system that would allow us to extend it for potentially growing number of resources (i.e. endpoints/models) but at the same time leveraging the robustness of RESTkit’s internal networking and mapping implementation.

Solution:

Initially we looked at Alex Kurkin’s solution but we felt that it creates unnecessary and unused queues/pipeline for every RKObjectManager subclass. Instead we decided to go with a two-tier system where we have:

  1. Multiple ResourceNameManagers/Helpers that build up requests, prepare params, and interact (and also setup ResponseDescriptors) with shared RKObjectManager instance that performs the actual request/mapping operations.
  2. One RKObjectManager subclass that has common setup for HTTP headers and Core Data/Persistence Store.

Conclusion:

This solution gives us very flexible setup that is extendable. We can have as many ResourceManagers/Helpers or their subclasses as we want, and we encapsulate shared RKObjectManager setup which doesn’t create a lot of waste but at the same time can be extended and or subclassed.

If you have any questions or suggestions please feel free to share in the comments below.

__
Authors: Alex Bush @alex_v_bush & Adam Tierney @Adam_Tierney
Review & Editing: Alex Petropavlovsky @petropavlovsky