iphone - una - no se pudo verificar la app tutuapp

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

Question

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

La forma en que pienso construir es hacer que los controladores de mi aplicación sean completamente independientes de RestKit. Por ej. Si tuviera una pantalla de inicio de sesión, en el escenario habitual de RestKit (basado en programas de ejemplo y en algunas entradas de blog creadas por los desarrolladores de RestKit), el controlador implementará el protocolo RKRequestDelegate y usará el RKClient para llamar al servicio en el controlador. self (el controlador) como el delegado. Me gustaría ocultar eso al usuario que desarrolla los controladores y las vistas.

Lo que estoy pensando es lo siguiente. Tendré un LoginService que ingresará al usuario. Habrá protocolo LoginServiceDelegate que tiene dos métodos para el éxito y el fracaso. Y el Controlador puede implementar el LoginServiceDelegate y llamar al método de inicio de sesión en LoginService y obtener una devolución de llamada correcta o incorrecta. Sin embargo, para hacer esto, necesitaré una forma para que mi LoginService delegue las llamadas nuevamente al controlador. RestKit no me permite hacer esto y la única forma en que puedo hacer esto es inicializando el LoginService con un LoginServiceDelegate, almacenando ese delegado como propiedad y llamando al método apropiado en el delegado al iniciar sesión o falla exitosamente.

Esto mantiene mi base de código de Controller al mínimo y oculta completamente cómo funciona LoginService y qué framework internamente usa. El uso de delegado también desvincula al Controlador de los Modelos, por lo que tenemos un buen MVC. Sin embargo, me preocupan las implicaciones de que la clase Model retenga el objeto Controller, ya que está reteniendo al delegado.

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

Este fragmento de código a continuación debería darle 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!

Answer 1

Soy el autor de RestKit y abogamos por usar dichos patrones para crear abstracciones de mayor nivel sobre RestKit. Generalmente construyo mis devoluciones de llamada y tal alrededor de un objeto modelo en lugar de crear un nuevo tipo de objeto de servicio de inicio de sesión, pero de cualquier manera está bien. En mi ejemplo, harías 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 retener a una asignación. En su método dealloc, puede hacer un par de cosas:

1. No elimine al delegado para que no se bloquee por una devolución de llamada
2. Solicite a la cola de solicitudes que cancele las solicitudes: [[RKRequestQueue sharedQueue] cancelRequestsWithDelegate:self];

Eso es todo de lo que debe preocuparse desde una perspectiva de administración de la memoria / mantenimiento de la casa. La otra cosa que siempre termino haciendo es crear notificaciones para mis eventos de ciclo de vida de autenticación. Siempre terminas necesitando observarlos para actualizar la interfaz de usuario en algún lugar de mi experiencia.

Estás en el camino correcto y el diseño está bien.

Mejor, Blake