为什么不强制严格的单例应用程序委托对象在NIB中使用？ [英] Why not enforce strict singleton application delegate object to use in NIBs?

问题描述

我只是在圈子里跑了一圈，所有来到实例化一个应用程序委托对象在辅助NIB，不是 NSMainNibFile 。令人惊讶的是如何让两个应用程式代表踢到周围，意味着你有 managedObjectContexts 。

我可以让我的应用程序委托类一个单例？并在更多的XIB中安全实例化它？

此外，在stackoverflow上有一些提到 [[UIApplication sharedApplication] delegate]

$ c>是一个singleton，但它不出现 UIApplicationDelegate 协议保证，也不是超类 UIResponder 单例，。

[edit]看起来你可以在 UIApplicationMain中删除delegateClassName for iOS，并且主要的NIB加载委托对象，所以如果使用主NIB，你可以创建在OSX上看到的App Delegate对象模式。

[edit2]一个新的非文档应用程序的MainMenu.xib的屏幕截图。使用此对象创建项目，使用窗口属性创建应用程序委托类。问题是在其他NIB中得到一个很方便的对象，并且该对象与 [NSApp delegate]相同

解决方案

被投票，然后投票决定为零，因为谁知道为什么，我继续调查我自己的答案。我认为使你的应用程序委托类真正单例，所以你不能导致头痛与NIBs是有用的。 我不明白为什么它是有害的。我认为如果你的应用程序有一个单一的用户界面，让应用程序委托拥有所有NIB的核心数据堆栈并不是不合理。然而，推荐的设计模式将比每个窗口或视图控制器通过ManagedObjectContext指针，并通过文件的Owner占位符访问MOC，而不是使用App Delegate对象。

但是另一方面，共享用户默认控制器单例的不同之处在于，它在每个NIB中都有一个特殊的对象。我们不必传递每个控制器一个指针，使每个视图都可以访问它。这只是无所不在。应用程序委托是不同的。在每个NIB中没有共享应用程序委托对象。是的，有理由永远不会与NIBs中的应用程序代表交谈，但这不是对问题的回答。

所以，一个答案。

Singleton设计模式：
很久以前，Apple在此弃用的参考文档 - 创建Singleton实例

我想让我的应用程序委托类实现是strict实现，而不是有一个工厂方法可以创建应用程序委托类的其他对象。这里的一个不同的特点是 [NSApp委托] 是主指针而不是应用程序委托类函数。

严格实现必须为我的应用程序委托类重写allocWithZone（如alloc调用allocWithZone）。

  +（MYAppDelegate *）allocWithZone ：（NSZone *）zone 
 {
 if（[NSApp delegate] == nil）return [super allocWithZone：zone]; 
 return [NSApp delegate]; 
} 
 
  - （MYAppDelegate *）copyWithZone：（NSZone *）zone 
 {
 return self; 
} 
  

Init只返回 [super init] 很好，所以不需要覆盖。

看起来工作。

[update]我也在使用 NSBundle 调查NIB载入 loadNibNamed：owner：topLevelObjects： - 但似乎我会得到一个数组回来一个新的应用程序委托对象，甚至从该方法。该方法允许获得指向NIB中顶级对象的指针，而无需另外为它们创建插座。仍然似乎最好的方法来获取应用程序委托对象在一个XIB而不是MainMenu是使用类似上面的代码。

[另一个更新] 为什么可能有害：根据本文档，我有充分的理由相信，即使使用ARC，这个答案增加了[NSApp委托]的保留计数，但是如果我觉得好的做一个桥梁和释放的应用委托在dealloc的窗口/视图控制器有一个顶级对象的应用程序委托。此外，代表应用程式委托类别之外的程式码。

I just ran myself round in circles, all coming down to having instantiated an app delegate object in a secondary NIB that wasn't the NSMainNibFile. Amazing how having two app delegates kicking around means you have separate managedObjectContexts.

Here's a thought-- could I make my application delegate class a singleton? And safely instantiate it in more XIBs? What would that break?

Also, there are some mentions on stackoverflow that [[UIApplication sharedApplication] delegate] is a "singleton" but it doesn't appear that UIApplicationDelegate protocol guarantees that, nor is the superclass UIResponder a singleton, either. So could I shoot myself in the foot in this regard on iOS as well?

[edit] Looks like you could nil out the delegateClassName in UIApplicationMain for iOS and have the main NIB load the delegate object, so you could create the App Delegate object pattern seen on OSX, if using a main NIB.

[edit2] Screenshot of what MainMenu.xib looks like for a new non-document application. The project gets created with this object, app delegate class gets created with a window property. The issue is getting that nice handy object in other NIBs, and that object being the same as [NSApp delegate]

解决方案

Okay, after the question having been voted up, and then voted down to zero because of who-knows-why, I've continued to investigate my own answer. I think it's useful to make your app delegate classes true singletons so you can't cause headaches with NIBs. I can't see why it would be harmful. And I think if your app has a single user interface, it's not unreasonable to have the app delegate own the core data stack for all NIBs. However, the recommended design pattern would be to than have each window or view controller be passed the ManagedObjectContext pointer, and to access the MOC through the File's Owner placeholder rather than using an App Delegate object.

Yet on the other hand, things are different with the "Shared User Defaults Controller" singleton, which gets a special object in every NIB. We don't have to pass every controller a pointer to it so that every view can access it. It's just omnipresent. The app delegate is different. There's no "Shared App Delegate" object in every NIB. Yes, there are reasons to never talk to the app delegate in NIBs, but that's not an answer to the question.

So, an answer.

Singleton design patterns: Covered long ago by Apple in this deprecated reference document-- Creating a Singleton Instance.

Turns out what I want my application delegate class to implement is the "strict" implementation, rather than having a factory method which could create other objects of the app delegate class. The one different feature here is having [NSApp delegate] be the master pointer rather than an app delegate class function.

The strict implementation has to override allocWithZone for my application delegate class (as alloc calls allocWithZone).

+ (MYAppDelegate*)allocWithZone:(NSZone *)zone
{
    if ([NSApp delegate] == nil) return [super allocWithZone:zone];
    return [NSApp delegate];
}

- (MYAppDelegate*)copyWithZone:(NSZone *)zone
{
    return self;
}

Init just returning [super init] is fine, so it needs no override.

Seems to work. I'll update this if not.

[update] I have also been investigating NIB loading using NSBundle's loadNibNamed:owner:topLevelObjects: -- but it appears that I'd get an array back with a new app delegate object, even from that method. The method allows getting pointers to the top-level objects in the NIB without having otherwise created outlets for them. Still seems the best method to get an app delegate object in a XIB other than MainMenu is to use something like the code above.

[another update] Why it could be harmful: According to the the section "Top-level Objects in OS X May Need Special Handling" in this document, there's good reason for me to believe that, even with ARC, this answer of mine increases the retain count on [NSApp delegate], but heck if I feel okay doing a bridge and a release on the app delegate in dealloc for the window/view controllers that have a top-level object for the app delegate. Plus that means code outside the app delegate class.

这篇关于为什么不强制严格的单例应用程序委托对象在NIB中使用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！