如何在两个控制器中相同地使用 modalViewController?

发布于 2024-08-28 22:43:12 字数 1174 浏览 9 评论 0原文

我正在使用 Three20 TTMessageController 在我的应用程序中。我已经弄清楚如何使用它,添加了一堆其他东西(包括 TTMessageControllerDelegate 方法和 ABPeoplePickerNavigationControllerDelegate 方法)。经过一番努力才弄清楚后,它对我来说非常有用。

我现在遇到的麻烦是一个设计问题:我想在两个不同的地方以相同的方式使用它,包括使用相同的委托方法。我当前的方法是将所有代码放入一个继承自 NSObject 的单个类中,称为 ComposerProxy,并且我只是让使用它的两个控制器使用代理,如下所示:

ComposerProxy *proxy = [[ComposerProxy alloc] initWithController:this];
[proxy go];

go 方法构造 TTMessageController,配置它,将其添加到 UINavigationController 中,并呈现它:

[self.controller presentModalViewController: navController animated: YES];

这很好用,因为我将所有代码都很好地封装在 ComposerProxy 中,并且在我想要使用它的任何地方只需要上面两行。

但缺点是我无法在不崩溃的情况下dealloc代理变量。我也无法autorelease它:同样的问题。

所以我想知道我的代理方法是否是一种糟糕的方法。通常如何封装一堆这样的行为,而不需要在使用它的类中使用大量重复代码?我是否需要向我的 ComposerProxy 添加一个委托类,并让控制器负责在假设的 ComposerDidFinish 方法或类似方法中关闭模态视图控制器?

很多TIA!

I'm using the Three20 TTMessageController in my app. I've figured out how to use it, adding on a bunch of other stuff (including TTMessageControllerDelegate methods and ABPeoplePickerNavigationControllerDelegate methods). It works great for me, after a bit of a struggle to figure it out.

The trouble I'm having now is a design issue: I want to use it identically in two different places, including with the same delegate methods. My current approach is that I've put all the code into a single class inheriting from NSObject, called ComposerProxy, and I'm just having the two controllers that use it use the proxy, like so:

ComposerProxy *proxy = [[ComposerProxy alloc] initWithController:this];
[proxy go];

The go method constructs the TTMessageController, configures it, adds it to a UINavigationController, and presents it:

[self.controller presentModalViewController: navController animated: YES];

This works great, as I have all my code nicely encapsulated in ComposerProxy and I need only the above two lines anywhere I want to use it.

The downside, though, is that I can't dealloc the proxy variable without getting crashes. I can't autorelease it, either: same problem.

So I'm wondering if my proxy approach is a poor one. How does one normally encapsulate a bunch of behaviors like this without requiring a lot of duplicate code in the classes that use it? Do I need to add a delegate class to my ComposerProxy and make the controller responsible for dismissing the modal view controller in a hypothetical composerDidFinish method or some such?

Many TIA!

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

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

发布评论

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

评论(1

故事与诗 2024-09-04 22:43:12

从我上面看到的来看,崩溃并不一定表明设计很糟糕——很可能是因为内存管理问题而崩溃。也许控制器被过度释放,很难说 - 你会遇到什么样的崩溃?

虽然当前的设计看起来不错,但另一种选择是创建 类别。该类别将添加(到导入该类别的 UIViewController 子类)呈现模态 TTMessageController 所需的所有代码,而不需要您复制或使用继承。

@interface UIViewController ( Composer )
// categories can't add instance vars, so return the new controller if you need to store it...
- (TTMessageController *)presentMessageController;
@end

@implementation UIViewController ( Composer )
- (TTMessageController *)presentMessageController {
    // contents of ComposerProxy#go except referring to 'self' instead of 'self.controller'
}
@end

From what I see above, the crashes don't necessarily indicate a poor design - chances are it's crashing on a memory management issue. Maybe controller is over-released, hard to say - what kind of crash are you getting?

While the current design seems fine, an alternative would be to create a category on UIViewController. The category would add (to UIViewController subclasses that import the category) all the code necessary for presenting a modal TTMessageController without requiring you to duplicate or use inheritance.

@interface UIViewController ( Composer )
// categories can't add instance vars, so return the new controller if you need to store it...
- (TTMessageController *)presentMessageController;
@end

@implementation UIViewController ( Composer )
- (TTMessageController *)presentMessageController {
    // contents of ComposerProxy#go except referring to 'self' instead of 'self.controller'
}
@end
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文