视图控制器之间通信的最佳方式是什么？

Question

作为 Objective-C、cocoa 和 iPhone 开发的新手，我强烈希望充分利用该语言和框架。

我使用的资源之一是斯坦福大学的 CS193P 课堂笔记，它们留在网上。 它包括讲义、作业和示例代码，并且由于该课程是由 Apple 开发人员提供的，所以我绝对认为它是“来自马口铁”。

课程网站：
http://www.stanford.edu/class/cs193p/cgi-bin /index.php

第 08 讲涉及构建一个基于 UINavigationController 的应用程序的作业，该应用程序将多个 UIViewController 推送到 UINavigationController 堆栈上。 这就是 UINavigationController 的工作原理。 这是合乎逻辑的。 然而，幻灯片中有一些关于 UIViewController 之间通信的严厉警告。

我将引用这张严肃的幻灯片：
http://cs193p.stanford.edu/downloads/08-NavigationTabBarControllers.pdf

第 16/51 页：

如何不共享数据

• 全局变量或单例
  • 这包括您的应用程序委托
• 直接依赖会降低代码的可重用性
  • 而且更难调试& 测试

好。 我对此感到沮丧。 不要盲目地将用于视图控制器之间通信的所有方法放入应用程序委托中，并在应用程序委托方法中引用视图控制器实例。 公平的。

再进一步，这张幻灯片告诉我们应该做什么。

第 18/51 页：

数据流最佳实践

• 弄清楚确切需要沟通的内容
• 为视图控制器定义输入参数
• 为了在层次结构上进行备份通信，使用松散耦合
  • 为观察者定义通用接口（例如委托）

这张幻灯片后面是一张占位符幻灯片，讲师随后使用 UIImagePickerController 的示例显然演示了最佳实践。 我希望这些视频可用！ :(

好吧，所以...我担心我的 objc-fu 不是那么强。我对上面引用中的最后一行也有点困惑。我一直在谷歌上搜索这一点并且我发现一篇看起来不错的文章讨论了观察/通知技术的各种方法：
http://cocoawithlove.com/2008/06/ Five-approaches -to-listening-observing.html

方法 #5 甚至将委托表示为一种方法！ 除了......对象一次只能设置一个委托。 那么当我有多个视图控制器通信时，我该怎么办？

好吧，这就是团伙的安排。 我知道我可以通过引用应用程序委托中的多个视图控制器实例轻松地在应用程序委托中执行我的通信方法，但我想以正确的方式执行此类操作。

请回答以下问题，帮助我“做正确的事”：

1. 当我尝试在 UINavigationController 堆栈上推送新的视图控制器时，谁应该执行此推送。 我的代码中的哪个类/文件是正确的位置？
2. 当我在不同 UIViewController 中时想要影响其中一个 UIViewController 中的某些数据（iVar 的值）时，“正确”的方法是什么？
3. 假设我们一次只能在一个对象中设置一个委托，那么当讲师说“为观察者定义一个通用接口（如委托）”时，实现会是什么样子？ 如果可能的话，伪代码示例在这里会非常有帮助。

Answer 1

这些都是很好的问题，很高兴看到您正在进行这项研究，并且似乎关心学习如何“正确地做事”，而不是仅仅将其拼凑在一起。

首先，我同意之前的答案，这些答案重点关注在适当的时候将数据放入模型对象中的重要性（根据 MVC 设计模式）。 通常您希望避免将状态信息放入控制器中，除非它是严格的“表示”数据。

第二，请参阅斯坦福大学演示文稿第 10 页，了解如何以编程方式将控制器推送到导航控制器上的示例。 有关如何使用 Interface Builder “直观地”执行此操作的示例，请查看 本教程。

第三，也许是最重要的一点，请注意，如果您在“依赖关系”的背景下考虑斯坦福大学演讲中提到的“最佳实践”，那么它们会更容易理解。注入”设计模式。 简而言之，这意味着您的控制器不应该“查找”完成其工作所需的对象（例如，引用全局变量）。 相反，您应该始终将这些依赖项“注入”到控制器中（即通过方法传入它所需的对象）。

如果遵循依赖注入模式，您的控制器将是模块化且可重用的。 如果你考虑一下斯坦福大学的演示者来自哪里（即，作为苹果员工，他们的工作是构建可以轻松重用的课程），可重用性和模块化是重中之重。 他们提到的所有共享数据的最佳实践都是依赖注入的一部分。

这就是我回应的要点。 我将在下面提供一个使用依赖注入模式与控制器的示例，以防有帮助。

通过视图控制器使用依赖注入的示例

假设您正在构建一个列出多本书的屏幕。 用户可以选择他/她想要购买的书籍，然后点击“结帐”按钮进入结帐屏幕。

要构建它，您可以创建一个 BookPickerViewController 类来控制和显示 GUI/视图对象。 它从哪里获取所有图书数据？ 假设它依赖于 BookWarehouse 对象。 所以现在你的控制器基本上是在模型对象（BookWarehouse）和 GUI/视图对象之间代理数据。 换句话说，BookPickerViewController 依赖于 BookWarehouse 对象。

不要这样做：

@implementation BookPickerViewController

-(void) doSomething {
   // I need to do something with the BookWarehouse so I'm going to look it up
   // using the BookWarehouse class method (comparable to a global variable)
   BookWarehouse *warehouse = [BookWarehouse getSingleton];
   ...
}

相反，依赖项应该像这样注入：

@implementation BookPickerViewController

-(void) initWithWarehouse: (BookWarehouse*)warehouse {
   // myBookWarehouse is an instance variable
   myBookWarehouse = warehouse;
   [myBookWarehouse retain];
}

-(void) doSomething {
   // I need to do something with the BookWarehouse object which was 
   // injected for me
   [myBookWarehouse listBooks];
   ...
}

当苹果公司的人谈论使用委托模式来“通信备份层次结构”时，他们仍然在谈论依赖项注入。 在此示例中，一旦用户选择了他/她的书籍并准备好结账，BookPickerViewController 应该做什么？ 嗯，这并不是它真正的工作。 它应该将工作委托给其他对象，这意味着它依赖于另一个对象。 因此，我们可以修改 BookPickerViewController init 方法，如下所示：

@implementation BookPickerViewController

-(void) initWithWarehouse:    (BookWarehouse*)warehouse 
        andCheckoutController:(CheckoutController*)checkoutController 
{
   myBookWarehouse = warehouse;
   myCheckoutController = checkoutController;
}

-(void) handleCheckout {
   // We've collected the user's book picks in a "bookPicks" variable
   [myCheckoutController handleCheckout: bookPicks];
   ...
}

所有这一切的最终结果是，您可以给我您的 BookPickerViewController 类（以及相关的 GUI/视图对象），我可以轻松地在我自己的应用程序中使用它，假设 BookWarehouse 和 CheckoutController 是我可以实现的通用接口（即协议）：

@interface MyBookWarehouse : NSObject <BookWarehouse> { ... } @end
@implementation MyBookWarehouse { ... } @end

@interface MyCheckoutController : NSObject <CheckoutController> { ... } @end
@implementation MyCheckoutController { ... } @end

...

-(void) applicationDidFinishLoading {
   MyBookWarehouse *myWarehouse = [[MyBookWarehouse alloc]init];
   MyCheckoutController *myCheckout = [[MyCheckoutController alloc]init];

   BookPickerViewController *bookPicker = [[BookPickerViewController alloc] 
                                         initWithWarehouse:myWarehouse 
                                         andCheckoutController:myCheckout];
   ...
   [window addSubview:[bookPicker view]];
   [window makeKeyAndVisible];
}

最后，您的 BookPickerController 不仅可重用，而且更易于测试。

-(void) testBookPickerController {
   MockBookWarehouse *myWarehouse = [[MockBookWarehouse alloc]init];
   MockCheckoutController *myCheckout = [[MockCheckoutController alloc]init];

   BookPickerViewController *bookPicker = [[BookPickerViewController alloc] initWithWarehouse:myWarehouse andCheckoutController:myCheckout];
   ...
   [bookPicker handleCheckout];

   // Do stuff to verify that BookPickerViewController correctly called
   // MockCheckoutController's handleCheckout: method and passed it a valid
   // list of books
   ...
}

Answer 2

这种事情总是一个品味问题。

话虽如此，我总是更喜欢通过模型对象进行协调（#2）。 顶层视图控制器加载或创建它需要的模型，每个视图控制器在其子控制器中设置属性来告诉它们需要使用哪些模型对象。 大多数更改都是通过使用 NSNotificationCenter 在层次结构上进行传达的； 触发通知通常内置于模型本身中。

例如，假设我有一个带有帐户和交易的应用程序。 我还有一个 AccountListController、一个 AccountController（它通过“显示所有交易”按钮显示帐户摘要）、一个 TransactionListController 和一个 TransactionController。 AccountListController 加载所有帐户的列表并显示它们。 当您点击列表项时，它会设置其 AccountController 的 .account 属性并将 AccountController 推入堆栈。 当您点击“显示所有交易”按钮时，AccountController 会加载交易列表，将其放入其 TransactionListController 的 .transactions 属性中，并将 TransactionListController 压入堆栈，依此类推。

比如说，如果 TransactionController 编辑了交易，它会在其交易对象中进行更改，然后调用其“保存”方法。 “保存”发送 TransactionChangedNotification。 当事务更改时任何其他需要刷新自身的控制器都会观察通知并更新自身。 TransactionListController 大概会； AccountController 和 AccountListController 可能会，具体取决于他们想要做什么。

对于＃1，在我的早期应用程序中，我在子控制器中有某种​​ displayModel:withNavigationController: 方法，可以进行设置并将控制器推送到堆栈上。 但随着我对 SDK 越来越熟悉，我已经不再这样做了，现在我通常让父母推动孩子。

对于#3，请考虑这个例子。 这里我们使用两个控制器，AmountEditor 和 TextEditor，来编辑交易的两个属性。 编辑者实际上不应保存正在编辑的交易，因为用户可能决定放弃该交易。 因此，他们都将其父控制器作为委托，并调用其方法来说明是否更改了任何内容。

@class Editor;
@protocol EditorDelegate
// called when you're finished.  updated = YES for 'save' button, NO for 'cancel'
- (void)editor:(Editor*)editor finishedEditingModel:(id)model updated:(BOOL)updated;  
@end

// this is an abstract class
@interface Editor : UIViewController {
    id model;
    id <EditorDelegate> delegate;
}
@property (retain) Model * model;
@property (assign) id <EditorDelegate> delegate;

...define methods here...
@end

@interface AmountEditor : Editor
...define interface here...
@end

@interface TextEditor : Editor
...define interface here...
@end

// TransactionController shows the transaction's details in a table view
@interface TransactionController : UITableViewController <EditorDelegate> {
    AmountEditor * amountEditor;
    TextEditor * textEditor;
    Transaction * transaction;
}
...properties and methods here...
@end

现在是 TransactionController 中的一些方法：

- (void)viewDidLoad {
    amountEditor.delegate = self;
    textEditor.delegate = self;
}

- (void)editAmount {
    amountEditor.model = self.transaction;
    [self.navigationController pushViewController:amountEditor animated:YES];
}

- (void)editNote {
    textEditor.model = self.transaction;
    [self.navigationController pushViewController:textEditor animated:YES];
}

- (void)editor:(Editor*)editor finishedEditingModel:(id)model updated:(BOOL)updated {
    if(updated) {
        [self.tableView reloadData];
    }

    [self.navigationController popViewControllerAnimated:YES];
}

需要注意的是，我们定义了一个通用协议，编辑者可以使用该协议与其所属的控制器进行通信。 通过这样做，我们可以在应用程序的其他部分重用编辑器。 （也许帐户也可以有注释。）当然，EditorDelegate 协议可以包含不止一种方法； 在这种情况下，这是唯一必要的。

Answer 3

我明白你的问题了。

发生的事情是有人对 MVC 架构的想法感到困惑。

MVC 由三个部分组成：模型、视图和控制器。所提到的问题似乎没有充分的理由将其中两个部分组合在一起。 视图和控制器是独立的逻辑部分。

所以......你不想有多个视图控制器......

你想要有多个视图，以及一个在它们之间进行选择的控制器。 （如果您有多个应用程序，您也可以有多个控制器）

视图不应该做出决定。 控制器应该这样做。 因此，任务、逻辑以及让你的生活更轻松的方法是分离的。

所以..确保你的视图能够做到这一点，提供一个很好的数据视图。 让您的控制器决定如何处理数据以及使用哪个视图。

（当我们谈论数据时，我们谈论的是模型......一种存储、访问、修改的良好标准方式......我们可以将其打包并忘记的另一个单独的逻辑部分）

Answer 4

假设有两个类A和B。

类A的实例是

A aInstance；

A 类创建 B 类的实例，作为

B bInstance；

在 B 类的逻辑中，您需要在某个地方通信或触发 A 类的方法。

1) 错误的方式

您可以将 aInstance 传递给 bInstance。
现在从 bInstance 中的所需位置调用所需方法 [aInstance methodname]。

这本来可以满足您的目的，但是释放时会导致内存被锁定而不是释放。

如何？

当你将aInstance传递给bInstance时，我们将aInstance的retainCount增加了1。
当释放 bInstance 时，我们会遇到内存阻塞，因为 bInstance 永远无法将 aInstance 的保留计数变为 0，因为 bInstance 本身就是 aInstance 的对象。

进一步，由于aInstance被卡住，bInstance的内存也会被卡住（泄漏）。
因此，即使稍后释放 aInstance 本身，它的内存也会被阻塞，因为 bInstance 无法释放，而 bInstance 是 aInstance 的类变量。

2）正确的方法

通过将aInstance定义为bInstance的delegate，就不会出现aInstance的retaincount变化或内存纠缠。

bInstance 将能够自由调用 aInstance 中的委托方法。
bInstance 释放时，所有变量将由其自己创建并释放
在aInstance的释放中，由于bInstance中没有aInstance的纠缠，因此它会被干净地释放。