Лучший способ использовать RestKit в приложении для iPhone - PullRequest
Новая
       11

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

49 голосов
/ 14 апреля 2011

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

Я думаю о построении так, чтобы контроллеры в моем приложении были полностью независимы от RestKit.Например,Если бы у меня был экран входа в систему, в обычном сценарии RestKit (на основе примеров программ, а также нескольких записей в блоге, созданных разработчиками RestKit), у вас будет контроллер, реализующий протокол RKRequestDelegate, и используйте RKClient для вызова службы в передаче Controller.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 Ответ

73 голосов
/ 14 апреля 2011

Я являюсь автором 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 вы можете сделать несколько вещей:

  1. Обнулить делегата, чтобы вы не потерпели крах при обратном вызове
  2. Просить очередь запросов отменить любые запросы: [[RKRequestQueue sharedQueue] cancelRequestsWithDelegate:self];

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

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

Best, Blake

...