在 iPhone 应用程序中使用 RestKit 的最佳方式

发布于 2024-11-01 16:01:03 字数 1560 浏览 3 评论 0原文

我正在编写一个 iPhone 应用程序,我终于 决定< /a> 使用 RestKit 作为连接 REST 服务的框架。

我考虑构建的方式是让我的应用程序中的控制器与 RestKit 完全无关。例如。如果我有一个登录屏幕,在通常的 RestKit 场景中(基于示例程序以及 RestKit 开发人员创建的一些博客条目),您将让控制器实现 RKRequestDelegate 协议并使用 RKClient 来调用 Controller 中的服务,传递self(控制器)作为委托。我想对开发控制器和视图的用户隐藏这一点。

我的想法如下。我将有一个 LoginService 来登录用户。将有一个 LoginServiceDelegate 协议,它有两种成功和失败的方法。并且Controller可以实现LoginServiceDelegate并调用LoginService中的login方法并获得成功或失败回调。然而,要做到这一点,我需要某种方式让我的 LoginService 将调用委托回控制器。 RestKit 不允许我执行此操作,而我能够执行此操作的唯一方法是使用 LoginServiceDelegate 初始化 LoginService,将该委托存储为属性,并在成功登录或失败时调用委托中的适当方法。

这使我的控制器代码库保持在最低限度,并完全隐藏了 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

干杯!

I am writing an iPhone application and I have finally decided to use RestKit as the framework for connecting to REST Services.

The way I am thinking of building is to have the Controllers in my application be completely agnostic to RestKit. For eg. If I had a login screen, in the usual RestKit scenario (based on example programs as well as few blog entries created by the RestKit developers) you will have the controller implement the RKRequestDelegate protocol and use the RKClient to call the service in the Controller passing self ( the controller) as the delegate. I would like to hide that from the User developing the Controllers and views.

What I am thinking of is the following. I will have a LoginService which will login the user. There will be protocol LoginServiceDelegate which has two methods for success and failure. And the Controller can implement the LoginServiceDelegate and call the login Method in LoginService and get a success or failure callback. However to do this, I will need some way for my LoginService to delegate the calls back to the controller. RestKit does not allow me to do this and the only way I am able to do this by initializing the LoginService with a LoginServiceDelegate, storing that delegate as a property and calling the appropriate method in the delegate on successful login or failure.

This keeps my Controller codebase to a minimum and hides completely how the LoginService works and what framework it internally uses. The use of delegate also de-couples the Controller from the Models and so we have a good MVC thing going. However I am concerned about the implications of the Model class retaining the Controller object since it is holding onto the delegate.

How would you use RestKit ? If you think my approach is good , what would you change to make it better ? If you dont like my approach would like your feedback as to why you think it is not a good practice.

This below code snippet should give you a better 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

Cheers !!!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

温柔女人霸气范 2024-11-08 16:01:03

我是 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];< /code>

从内存管理/内务处理的角度来看,这就是您需要担心的所有问题。我通常最终要做的另一件事是为我的身份验证生命周期事件创建通知。根据我的经验,你总是需要观察它们来更新 UI。

你走在正确的道路上,而且设计也很好。

最好的,
布莱克

I'm the author of RestKit and we advocate using such patterns to build higher level abstractions on top of RestKit. I generally build my callbacks and such around a model object rather than creating a new LoginService type of object, but either way is fine. In my example, you would do something like:

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

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

In any case, the other thing I would recommend is changing your delegate from a retain to an assign. In your dealloc method, you can do a couple of things:

  1. Nil out the delegate so you won't get crashed by a callback
  2. Ask the request queue to cancel any requests: [[RKRequestQueue sharedQueue] cancelRequestsWithDelegate:self];

That's about all that you need to worry about from a memory management / house-keeping perspective. The other thing that I typically always wind up doing is creating notifications for my authentication life-cycle events. You just always wind up needing to observe them to update UI somewhere in my experience.

You are on the right track and the design is fine.

Best,
Blake

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文