La mejor forma de usar RestKit en una aplicación de iPhone

Estoy escribiendo una aplicación para iPhone y finalmente he decidido usar RestKit como marco para conectarse a los Servicios REST.

La forma en que estoy pensando en build es hacer que los controlleres en mi aplicación sean completamente agnósticos para RestKit. Por ejemplo, Si tuviera una pantalla de inicio de session, en el escenario habitual de RestKit (basado en progtwigs de ejemplo, así como pocas inputs de blog creadas por los desarrolladores de RestKit), el controller implementará el protocolo RKRequestDelegate y utilizará el RKClient para llamar al service en el controller. self (el controller) como el delegado. Quisiera ocultar eso al usuario que desarrolla los controlleres y las vistas.

Lo que estoy pensando es lo siguiente. Tendré un LoginService que iniciará session al usuario. Habrá protocolo LoginServiceDelegate que tiene dos methods para el éxito y el fracaso. Y el Controlador puede implementar LoginServiceDelegate y llamar al Método de inicio de session en LoginService y get una callback de éxito o falla. Sin embargo, para hacer esto, necesitaré algún modo para que mi LoginService delegue las llamadas al controller. RestKit no me permite hacer esto y la única manera que puedo hacer es inicializando el LoginService con un LoginServiceDelegate, almacenando ese delegado como propiedad y llamando al método apropiado en el delegado en el inicio de session o falla exitosa.

Esto mantiene mi base de código de Controller a un mínimo y oculta completamente cómo funciona el LoginService y qué marco utiliza internamente. El uso del delegado también elimina al Controlador de los Modelos y así tenemos un buen MVC. Sin embargo, me preocupan las implicaciones de la class Model que retiene el object Controller ya que se aferra al delegado.

¿Cómo utilizarías RestKit? Si crees que mi enfoque es bueno, ¿qué cambiarías para hacerlo mejor? Si no te gusta mi enfoque, te agradaría tu opinión sobre por qué piensas que no es una buena práctica.

Este siguiente fragment de código debería brindarte una mejor 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 

Saludos !!!

Soy el autor de RestKit y abogamos por usar dichos patrones para build abstracciones de mayor nivel en la parte superior de RestKit. Por lo general, creo mis callbacks y tal alnetworkingedor de un object model en lugar de crear un nuevo tipo de object LoginService, pero de cualquier manera está bien. En mi ejemplo, haría algo como:

 @implementation RKUser - (void)loginWithDelegate:(NSObject<RKUserAuthenticationDelegate>*)delegate {} @end @protocol RKUserAuthenticationDelegate - (void)userDidLogin:(RKUser*)user; - (void)userDidFailLoginWithError:(RKUser*)user; - (void)userDidLogout:(RKUser*)user @end 

En cualquier caso, la otra cosa que recomendaría es cambiar su delegado de un retenedor a un asignado. En su método dealloc, puede hacer algunas cosas:

  1. Nada del delegado para que no se bloquee con una callback.
  2. Pida a la queue de requestes que cancele las requestes: [[RKRequestQueue shanetworkingQueue] cancelRequestsWithDelegate:self];

Eso es todo sobre lo que debe preocuparse desde una perspectiva de gestión de la memory / mantenimiento de la casa. La otra cosa que normalmente termino haciendo es crear notifications para mis events de ciclo de vida de authentication. Siempre termina necesitando observarlos para actualizar la interfaz de usuario en algún lugar de mi experiencia.

Estás en el path correcto y el layout está bien.

Mejor, Blake