> On 2 Dec 2015, at 04:58, Carl Hoefs <newsli...@autonomy.caltech.edu> wrote: > > I was about to implement my own singleton class to act as an app-wide context > repository, but then I thought: wouldn't it be simpler just to use the > appDelegate for that purpose? It's a singleton already and available to all > classes via [[UIApplication sharedApplication] delegate]. All I need to do is > add my @properties to it and I'm done. > Are there any drawbacks to this? > -Carl >
Overloading the AppDelegate like that isn’t really a great practice. It’s often done because it’s easy and because it’s a single call away, but AppDelegate already has its definition and responsibilities and it’s very little work to sort out your own top-level object, suitably named, to just deal with your app’s logic. And when you get to the point you find you suddenly need two of them, because say you’re switching an old app context for a new one or doing some kind of data upgrade, you’ve already got what you need mostly where you need it. And it’s amazing how often that happens. My advice, leave AppDelegate to be do its job being the generic app delegate, often with only about 2 methods fleshed out, and put your business logic in your own object. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
