在给出的许多答案中都有一些很好的信息,但没有一个完全解决这个问题。
该问题询问如何在视图控制器之间传递信息。给出的具体示例要求在视图之间传递信息,但考虑到iOS自称的新颖性,原始海报可能是指视图控制器之间,而不是视图之间(没有viewControllers的任何参与)。似乎所有的答案都集中在两个视图控制器上,但如果应用程序发展到需要在信息交换中包含两个以上的视图控制器,该怎么办?
最初的海报还询问了Singleton和AppDelegate的使用。这些问题需要回答。
为了帮助其他人看这个问题,谁想要一个完整的答案,我将尝试提供它。
应用场景
与其进行高度假设、抽象的讨论,不如考虑具体的应用。为了帮助定义两个视图控制器情形和两个以上视图控制器情形,我将定义两个具体的应用场景。
场景一:最多需要两个视图控制器共享信息。
见图一。
应用程序中有两个视图控制器。有一个ViewControllerA(数据输入表单)和一个ViewController B(产品列表)。产品列表中选择的项目必须与数据输入表单中文本框中显示的项目相匹配。在这种情况下,ViewControllerA和ViewControllerB必须彼此直接通信,而不能与其他视图控制器通信。
场景二:两个以上的视图控制器需要共享相同的信息。
见图二。
应用程序中有四个视图控制器。这是一个基于选项卡的应用程序,用于管理家庭库存。三个视图控制器显示相同数据的不同过滤视图:
ViewControllerA-奢侈品ViewControllerB-非保险项目ViewControllerC-整个住宅库存ViewControllerD-添加新项目表单
无论何时创建或编辑单个项目,它也必须与其他视图控制器同步。例如,如果我们在ViewControllerD中添加了一条船,但它还没有投保,那么当用户转到ViewControllerA(豪华物品)和ViewControllerC(整个住宅库存)时,船必须出现,但当用户转到ViewControllerB(非投保物品)时则不会出现。我们不仅需要关注添加新项目,还需要关注删除项目(可以从四个视图控制器中的任何一个中删除),或编辑现有项目(可以在“添加新项目表单”中允许,将其重新用于编辑)。
由于所有视图控制器都需要共享相同的数据,所以所有四个视图控制器都必须保持同步,因此,每当任何单个视图控制器更改基础数据时,都需要与所有其他视图控制器进行某种通信。很明显,在这种情况下,我们不希望每个视图控制器直接与其他视图控制器通信。如果不明显,考虑我们是否有20个不同的视图控制器(而不是4个)。每当一个视图控制器发生更改时,通知其他19个视图控制器中的每一个会有多困难和容易出错?
解决方案:代表和观察者模式,以及Singleton
在场景一中,我们有几个可行的解决方案,正如其他答案所给出的
赛格牌手表代表直接设置视图控制器上的财产NSUserDefaults(实际上是一个糟糕的选择)
在场景2中,我们还有其他可行的解决方案:
观察者模式单身者
单例是类的一个实例,该实例是其生命周期中唯一存在的实例。单例的名字来源于它是一个实例。通常,使用singleton的开发人员有特殊的类方法来访问它们。
+ (HouseholdInventoryManager*) sharedManager; {
static dispatch_once_t onceQueue;
static HouseholdInventoryManager* _sharedInstance;
// dispatch_once is guaranteed to only be executed
// once in the lifetime of the application
dispatch_once(&onceQueue, ^{
_sharedInstance = [[self alloc] init];
});
return _sharedInstance;
}
现在我们了解了单例是什么,让我们讨论单例如何适合观察者模式。观察者模式用于一个对象响应另一个对象的变化。在第二个场景中,我们有四个不同的视图控制器,他们都想知道底层数据的更改。“底层数据”应该属于单个实例,即单例。“了解更改”是通过观察对单例所做的更改来实现的。
家庭库存应用程序将具有一个类的单个实例,该类旨在管理库存项目列表。经理将管理一系列家庭用品。以下是数据管理器的类定义:
#import <Foundation/Foundation.h>
@class JGCHouseholdInventoryItem;
@interface HouseholdInventoryManager : NSObject
/*!
The global singleton for accessing application data
*/
+ (HouseholdInventoryManager*) sharedManager;
- (NSArray *) entireHouseholdInventory;
- (NSArray *) luxuryItems;
- (NSArray *) nonInsuredItems;
- (void) addHouseholdItemToHomeInventory:(JGCHouseholdInventoryItem*)item;
- (void) editHouseholdItemInHomeInventory:(JGCHouseholdInventoryItem*)item;
- (void) deleteHoueholdItemFromHomeInventory:(JGCHouseholdInventoryItem*)item;
@end
当主库存项的集合发生更改时,视图控制器需要了解此更改。上面的类定义并没有说明这将如何发生。我们需要遵循观察者模式。视图控制器必须正式遵守sharedManager。有两种方法可以观察另一个对象:
关键值观察(KVO)NSNotificationCenter。
在场景2中,我们没有使用KVO可以观察到的HouseholdInventoryManager的单个属性。因为我们没有一个易于观察的属性,所以在这种情况下,必须使用NSNotificationCenter实现观察者模式。四个视图控制器中的每一个都将订阅通知,sharedManager将在适当的时候向通知中心发送通知。库存管理器不需要知道任何关于视图控制器或任何其他类的实例的信息,这些类可能有兴趣知道库存项集合何时发生变化;NSNotificationCenter负责这些实施细节。视图控制器只需订阅通知,数据管理器只需发布通知。
许多初学者程序员利用了这样一个事实,即在应用程序的生命周期中始终只有一个应用程序委托,它是全局可访问的。初级程序员利用这一事实将对象和功能填充到appDelegate中,以方便从应用程序中的任何其他位置进行访问。仅仅因为AppDelegate是单例并不意味着它应该替换所有其他单例。这是一个糟糕的实践,因为它给一个类带来了太多负担,打破了良好的面向对象实践。每个类都应该有一个易于解释的明确角色,通常只需通过类的名称。
每当您的应用程序代理开始变得臃肿时,就开始将功能删除到单例中。例如,核心数据堆栈不应该留在AppDelegate中,而是应该放在它自己的类coreDataManager类中。
工具书类
管理视图控制器之间的数据流在视图控制器之间传递数据Objective-C中的异步JSON请求