Meilleure façon d'utiliser RestKit dans une application iPhone

Question

Je suis en train d'écrire une application iPhone et j'ai finalement décidé d'utiliser RestKit en tant que cadre pour la connexion à des Services REST.

La façon dont je suis la pensée de bâtiment est d'avoir les Contrôleurs de ma demande sera complètement agnostique à RestKit. Pour eg. Si j'avais un écran de connexion, dans l'habitude RestKit scénario (basé sur l'exemple des programmes ainsi que quelques entrées de blog créé par le RestKit développeurs), vous aurez le contrôleur de mettre en œuvre les RKRequestDelegate protocole et le RKClient à appeler le service le Contrôleur de passage de l'auto ( le contrôleur) en tant que délégué. Je voudrais le cacher à l'Utilisateur de développer les Contrôleurs et les vues.

Ce que je pense est le suivant. Je vais avoir un LoginService qui va de connexion de l'utilisateur. Il y aura protocole LoginServiceDelegate qui dispose de deux méthodes pour la réussite et l'échec. Et le Contrôleur peut mettre en œuvre la LoginServiceDelegate et d'appeler la Méthode d'ouverture de session dans LoginService et obtenir un succès ou de l'échec de rappel. Cependant, pour ce faire, j'ai besoin d'une certaine façon pour mon LoginService de déléguer les appels vers le contrôleur. RestKit ne me permet pas de le faire et la seule façon que je suis capable de faire cela par l'initialisation de la LoginService avec un LoginServiceDelegate, le stockage que délégué à la propriété et de l'appel de la méthode appropriée à l'délégué sur le succès de la connexion ou de l'échec.

Cela permet de maintenir mon Contrôleur de la base de code à un minimum et cache complètement la façon dont le LoginService qui fonctionne et ce cadre, il utilise en interne. L'utilisation de déléguer également de couples le Contrôleur à partir des Modèles et nous avons donc une bonne MVC chose. Cependant, je suis préoccupé par les implications de la classe du Modèle en conservant le Contrôleur de l'objet, car il est maintenant sur le délégué.

Comment voulez-vous utiliser RestKit ? Si vous pensez que ma démarche est la bonne , qu'aimeriez-vous changer pour le rendre meilleur ? Si vous n'aimez pas mon approche aimerions avoir vos commentaires pour expliquer pourquoi vous pensez que ce n'est pas une bonne pratique.

Cet extrait de code ci-dessous devrait vous donner une meilleure idée

@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

Je suis l'auteur de RestKit et nous favorisons l'utilisation de ces modèles pour construire des abstractions de plus haut niveau sur le dessus de RestKit. En général, je construire mon rappels et ces autour d'un modèle de l'objet plutôt que de créer un nouveau LoginService type d'objet, mais de toute façon est bien. Dans mon exemple, vous pourriez faire quelque chose comme:

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

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

En tout cas, l'autre chose que je recommande est en train de changer votre délégué de un à conserver à un ayant droit. Dans votre méthode dealloc, vous pouvez faire une ou deux choses:

1. Néant le délégué, afin de ne pas être écrasé par un rappel
2. Demandez à la demande de la file d'attente pour annuler toutes les demandes: [[RKRequestQueue sharedQueue] cancelRequestsWithDelegate:self];

C'est tout que vous avez besoin de s'inquiéter à partir d'une gestion de la mémoire / maison de maintien de la perspective. L'autre chose que j'ai généralement toujours du vent jusqu'à faire est de créer des notifications pour mes authentification du cycle de vie des événements. Vous venez toujours du vent par avoir besoin de les observer à la mise à jour de l'INTERFACE utilisateur, quelque part dans mon expérience.

Vous êtes sur la bonne voie et le design est très bien.

Mieux, Blake