2010-04-16 3 views
1

Я использую Three20TTMessageController в своем приложении. Я выяснил, как использовать его, добавив кучу других вещей (включая методы TTMessageControllerDelegate и методы ABPeoplePickerNavigationControllerDelegate). Это отлично работает для меня, после некоторой битвы, чтобы понять это.Как использовать modalViewController одинаково в двух контроллерах?

Проблема, с которой я столкнулся сейчас, связана с проблемой дизайна: я хочу использовать ее одинаково в двух разных местах, в том числе с теми же методами делегата. Мой текущий подход заключается в том, что я поместил весь код в один класс наследует от NSObject, называется ComposerProxy, и я просто с двумя контроллерами, которые используют это использовать прокси-сервер, например, так:

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

go метод строит TTMessageController, настраивает его, добавляет его к UINavigationController, и представляет его:

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

Это прекрасно работает, так как у меня есть все мой код хорошо воплощен в ComposerProxy и мне нужно только вышеупомянутые две строки в любом месте я хотите использовать его.

Недостатком, тем не менее, является то, что я не могу перечислить proxy без возникновения сбоев. Я не могу autorelease его, либо: та же проблема.

Итак, мне интересно, плохо ли мой прокси-подход. Как обычно инкапсулировать кучу подобных действий, не требуя много дублирующего кода в классах, которые его используют? Нужно ли добавить класс делегата в мой ComposerProxy и заставить диспетчера отвечать за отклонение модального контроллера представления в гипотетическом методе composerDidFinish или некоторых таких?

Многие TIA!

ответ

1

Из того, что я вижу выше, аварии не обязательно указывают на плохой дизайн - скорее всего, это проблема с управлением памятью. Может быть, контроллер перевыполнен, трудно сказать - какой крах вы получаете?

Хотя текущий дизайн кажется прекрасным, альтернативой было бы создание category на UIViewController. Категория добавит (в подклассы 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 
+0

А, я не думал добавлять категорию. Это очень хорошая идея (я сделал это для других вещей, а не для контроллеров). Я полагаю, что категория добавляет все делегаты, которые она реализует. Проблема с памятью, я думаю, связана с тем, что вызывающий класс не поддерживает прокси-объект в атрибуте экземпляра, поэтому, если он его освобождает, он работает неправильно, потому что ссылки на него отсутствуют. Обдумывал, есть ли способ исправить это, но в любом случае переход к категории - лучшая идея. Благодаря! – theory