Question

I am writing an iPhone application and I have finally decided to use RestKit as the framework for connecting to REST Services.

The way I am thinking of building is to have the Controllers in my application be completely agnostic to RestKit. For eg. If I had a login screen, in the usual RestKit scenario (based on example programs as well as few blog entries created by the RestKit developers) you will have the controller implement the RKRequestDelegate protocol and use the RKClient to call the service in the Controller passing self ( the controller) as the delegate. I would like to hide that from the User developing the Controllers and views.

What I am thinking of is the following. I will have a LoginService which will login the user. There will be protocol LoginServiceDelegate which has two methods for success and failure. And the Controller can implement the LoginServiceDelegate and call the login Method in LoginService and get a success or failure callback. However to do this, I will need some way for my LoginService to delegate the calls back to the controller. RestKit does not allow me to do this and the only way I am able to do this by initializing the LoginService with a LoginServiceDelegate, storing that delegate as a property and calling the appropriate method in the delegate on successful login or failure.

This keeps my Controller codebase to a minimum and hides completely how the LoginService works and what framework it internally uses. The use of delegate also de-couples the Controller from the Models and so we have a good MVC thing going. However I am concerned about the implications of the Model class retaining the Controller object since it is holding onto the delegate.

How would you use RestKit ? If you think my approach is good , what would you change to make it better ? If you dont like my approach would like your feedback as to why you think it is not a good practice.

This below code snippet should give you a better idea

@protocol LoginServiceDelegate;

@interface LoginService : NSObject <RKRequestDelegate>{
    NSObject<LoginServiceDelegate> *_loginServiceDelegate;

}

@property (retain, nonatomic) NSObject <LoginServiceDelegate> *loginServiceDelegate;

- (id) initWithDelegate:(NSObject<LoginServiceDelegate>*) loginServiceDelegate;

- (void) login:(NSString *)username withPassword:(NSString *)password;

@end

@protocol LoginServiceDelegate
@optional

- (void) loginSuccess:(LoginInfo *) loginInfo;

- (void) loginFailure:(NSString *) message;

@end

Cheers !!!

Answer 1

I’m the author of RestKit and we advocate using such patterns to build higher level abstractions on top of RestKit. I generally build my callbacks and such around a model object rather than creating a new LoginService type of object, but either way is fine. In my example, you would do something like:

@implementation RKUser
- (void)loginWithDelegate:(NSObject<RKUserAuthenticationDelegate>*)delegate {}
@end

@protocol RKUserAuthenticationDelegate
- (void)userDidLogin:(RKUser*)user;
- (void)userDidFailLoginWithError:(RKUser*)user;
- (void)userDidLogout:(RKUser*)user
@end

In any case, the other thing I would recommend is changing your delegate from a retain to an assign. In your dealloc method, you can do a couple of things:

1. Nil out the delegate so you won’t get crashed by a callback
2. Ask the request queue to cancel any requests: [[RKRequestQueue sharedQueue] cancelRequestsWithDelegate:self];

That’s about all that you need to worry about from a memory management / house-keeping perspective. The other thing that I typically always wind up doing is creating notifications for my authentication life-cycle events. You just always wind up needing to observe them to update UI somewhere in my experience.

You are on the right track and the design is fine.

Best,
Blake