Лучший способ использовать RestKit в приложении iPhone

Я пишу приложение для iPhone, и, наконец, решил использовать RestKit в качестве основы для подключения к службам REST.

То, как я собираюсь строить, - это иметь контроллеры в моем приложении полностью агностически для RestKit. Напр. Если бы у меня был экран входа в систему, в обычном сценарии RestKit (на основе примеров программ, а также нескольких записей в блоге, созданных разработчиками RestKit), у вас будет контроллер, реализующий протокол RKRequestDelegate, и использование RKClient для вызова службы в проходе контроллера self (контроллер) в качестве делегата. Я хотел бы скрыть это от пользователя, разрабатывающего контроллеры и представления.

Я думаю о следующем. У меня будет LoginService, который войдет в систему пользователя. Будет протокол LoginServiceDelegate, который имеет два метода для успеха и неудачи. Контроллер может реализовать функцию LoginServiceDelegate и вызвать метод входа в LoginService и получить успешный ответ. Однако для этого мне потребуется какой-то способ для моего LoginService делегировать вызовы обратно контроллеру. RestKit не позволяет мне это делать и единственный способ, которым я могу это сделать, инициализируя LoginService с помощью LoginServiceDelegate, сохраняя этот делегат как свойство и вызывая соответствующий метод в делегате при успешном входе в систему или сбое.

Это сводит кодовую базу моего контроллера к минимуму и полностью скрывает, как работает LoginService и какие рамки он использует внутри. Использование делегата также отключает контроллер от моделей, и поэтому у нас есть хорошая вещь MVC. Однако я обеспокоен последствиями класса Model, сохраняющим объект Controller, поскольку он удерживает делегата.

Как бы вы использовали RestKit? Если вы считаете, что мой подход хорош, что бы вы изменили, чтобы сделать его лучше? Если вам не нравится мой подход, вам понравятся ваши отзывы о том, почему вы считаете, что это не очень хорошая практика.

Этот ниже фрагмент кода должен дать вам лучшую идею

@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

Приветствия!!!

Ответ 1

Я автор RestKit, и мы выступаем за использование таких шаблонов для создания абстракций более высокого уровня поверх RestKit. Обычно я создаю свои обратные вызовы и такие вокруг объекта модели, а не создавая новый тип типа LoginService, но в любом случае это нормально. В моем примере вы бы сделали что-то вроде:

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

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

В любом случае, другое, что я бы рекомендовал, это изменить делегат от сохранения до назначения. В вашем методе dealloc вы можете сделать несколько вещей:

Извлеките делегата, чтобы вы не пострадали от обратного вызова
Запросить очередь запросов для отмены любых запросов: [[RKRequestQueue sharedQueue] cancelRequestsWithDelegate:self];

Что обо всем, что вам нужно беспокоиться из соображений управления памятью/ведения домашнего хозяйства. Другое, что я обычно делаю, это создание уведомлений о событиях жизненного цикла аутентификации. Вам просто всегда приходится следить за ними, чтобы обновить интерфейс где-то в моем опыте.

Вы на правильном пути, и дизайн в порядке.

Бест, Блейк