iOS: Using AppDelegate as an app-wide singleton

[Carl Hoefs]

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


___

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

Re: iOS: Using AppDelegate as an app-wide singleton

[Alex Zavatone]

I'm more of a fan of special case singletons, or else you essentially create 
one big global al over again.

Also, the AppDelegate class has certain responsibilities.  For organizational 
purposes, I feel most comfortable in creating a singleton for the purpose of 
the task at hand.  

On Dec 1, 2015, at 3:58 PM, Carl Hoefs 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
> 
> 
> ___
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.com


___

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

Re: iOS: Using AppDelegate as an app-wide singleton

[Rick Mann]

> 
> 
>> On Dec 1, 2015, at 4:55 PM, Quincey Morris 
>>  wrote:
>> 
>> On Dec 1, 2015, at 12:58 , Carl Hoefs > > wrote:
>> 
>>> available to all classes via [[UIApplication sharedApplication] delegate].
>> 
>>> Are there any drawbacks to this?

I've found it's best to remove as much of your app-specific singleton behavior 
out of the app delegate as possible, with an eye toward porting the iOS app to 
OS X or vice-versa. 

This is not to say you should actually port it. But by moving those things out 
of the app delegate, it makes that sort of thing much easier should you choose 
to.

You may also want to break up that singleton into more than one, depending on 
the functional areas it serves. For example, I no longer put my Core Data stack 
in app delegate, instead putting it in a CDManager of some sort. This, along 
with my model classes, ends up being a fairly portable chunk of code I can 
share among apps. But I may have a different singleton for collecting other 
app-wide functionality that's specific to my app, again, trying to keep it out 
of the AppDelegate.


-- 
Rick Mann
rm...@latencyzero.com



___

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

Re: iOS: Using AppDelegate as an app-wide singleton

[Carl Hoefs]

The following seems to be working out for me.

#import "AppCommon.h"
@implementation AppCommon
+ (AppCommon *)shared
{
static AppCommon *shared = nil;
static dispatch_once_t token;
dispatch_once(, ^{
shared = [[self alloc] init];
});
return shared;
}

-Carl


> On Dec 1, 2015, at 4:55 PM, Quincey Morris 
>  wrote:
> 
> On Dec 1, 2015, at 12:58 , Carl Hoefs  > wrote:
> 
>> available to all classes via [[UIApplication sharedApplication] delegate].
> 
>> Are there any drawbacks to this?
> 
> I don’t find this practice very objectionable, but the drawback is that 
> '[[UIApplication sharedApplication] delegate]’ has the wrong class, so you 
> usually end up writing some sort of global function to get it pre-cast.
> 
> In that case, you may as well use a different object, make it a local static 
> variable in a class implementation, and write a static method 
> (“[MyContextCache sharedContextCache]”) to get it. Don’t forget to use 
> dispatch_once to create the singleton. You may not have any thread safety 
> concerns right now, but you might easily do so later.
> 
> 

___

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

Re: iOS: Using AppDelegate as an app-wide singleton

[Roland King]

> On 2 Dec 2015, at 04:58, Carl Hoefs  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

Re: iOS: Using AppDelegate as an app-wide singleton

[Quincey Morris]

On Dec 1, 2015, at 12:58 , Carl Hoefs  wrote:

> available to all classes via [[UIApplication sharedApplication] delegate].

> Are there any drawbacks to this?

I don’t find this practice very objectionable, but the drawback is that 
'[[UIApplication sharedApplication] delegate]’ has the wrong class, so you 
usually end up writing some sort of global function to get it pre-cast.

In that case, you may as well use a different object, make it a local static 
variable in a class implementation, and write a static method (“[MyContextCache 
sharedContextCache]”) to get it. Don’t forget to use dispatch_once to create 
the singleton. You may not have any thread safety concerns right now, but you 
might easily do so later.


___

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

Re: iOS: Using AppDelegate as an app-wide singleton

[Quincey Morris]

On Dec 1, 2015, at 16:20 , Carl Hoefs  wrote:

> The following seems to be working out for me.
> 
> #import "AppCommon.h"
> @implementation AppCommon
> + (AppCommon *)shared
> {
> static AppCommon *shared = nil;
> static dispatch_once_t token;
> dispatch_once(, ^{
> shared = [[self alloc] init];
> });
> return shared;
> }

Looks functionally perfect. 

PSA #1: I would encourage you avoid naming the method ‘shared’, indeed to avoid 
naming anything with a brief name that doesn’t say what it is. Even the 
argument that it’s easier to type isn’t good any more, since Xcode is going to 
autocomplete almost every name for you.

PSA #2: I can’t help mentioning that you can write all of this in Swift as so:

class AppCommon {
static let shared = AppCommon ()
}

Sometimes, Swift really is Obj-C-but-better. ;)

___

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

Re: iOS: Using AppDelegate as an app-wide singleton

[Alex Zavatone]

What does Apple do on this?

I think their standard is to use shared in the name.


On Dec 1, 2015, at 7:33 PM, Quincey Morris 
 wrote:

> On Dec 1, 2015, at 16:20 , Carl Hoefs  wrote:
> 
>> The following seems to be working out for me.
>> 
>> #import "AppCommon.h"
>> @implementation AppCommon
>> + (AppCommon *)shared
>> {
>>static AppCommon *shared = nil;
>>static dispatch_once_t token;
>>dispatch_once(, ^{
>>shared = [[self alloc] init];
>>});
>>return shared;
>> }
> 
> Looks functionally perfect. 
> 
> PSA #1: I would encourage you avoid naming the method ‘shared’, indeed to 
> avoid naming anything with a brief name that doesn’t say what it is. Even the 
> argument that it’s easier to type isn’t good any more, since Xcode is going 
> to autocomplete almost every name for you.
> 
> PSA #2: I can’t help mentioning that you can write all of this in Swift as so:
> 
>   class AppCommon {
>   static let shared = AppCommon ()
>   }
> 
> Sometimes, Swift really is Obj-C-but-better. ;)
> 
> ___
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.com


___

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

Re: iOS: Using AppDelegate as an app-wide singleton

[Quincey Morris]

On Dec 1, 2015, at 21:38 , Alex Zavatone  wrote:
> 
> On Dec 2, 2015, at 12:24 AM, Luther Baker wrote:
> 
>> Alex, the API uses lots of different words to grab a-hold of the so-called 
>> "standard", "default" or "shared" static instance. Unfortunately, I'm not 
>> aware of any docs that specify when to use which adjective or if any one 
>> particular adjective should be used when creating a real Singleton ... since 
>> none of these are!
> 
> I just remember looking into Apple's implemented conventions on this last 
> week in iOS and didn't have time to fully look this up.  It's just what I 
> noticed they were doing in a few areas that escape me at the moment.  
> 
> Except for the application delegate, which does use sharedApplication as its 
> accessor.

On the naming question, my earlier objection was not about “shared”, but about 
the name not saying a shared *what*.

Regarding standard vs default vs shared, I suspect there’s no real Apple policy 
involved, but I believe that generally they mean what they say. 
‘standardUserDefaults’ is the standard (i.e. ordinary, regular) user defaults 
object, but an app can certainly create non-standard ones. 
‘defaultNotificationCenter’ is the notification center that apps use — mostly — 
in default of anything more particular, such as a distributed notification 
center, so again there can be others. ‘shared…’ is the term that means there’s 
only one the application should use. In that case, there’s no real presumption 
that another object of the class can’t be created, just that you’re not 
supposed to try.

___

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

Re: iOS: Using AppDelegate as an app-wide singleton

[Luther Baker]

The conversation here is pretty loose ... and so everyone might be right in
what they are intending to convey... ;-) but I thought I'd just put in a
vote to stop using the term "Singleton" for this access pattern. It isn't a
Singleton (unless there is historical signficance that grandfathers this
incorrect term in) and I think that using the term loosely in this case
actually weakens the power of a pattern vocabulary a bit.

Unless you're doing something we can't see (which is possible), it is
unlikely you are actually creating a Singleton. It is more likely that you
are creating class methods that in some/many/most/all cases - are accessing
private static instances. Similar in form to ...

[NSUserDefaults standardUserDefaults]
[NSNotificationCenter defaultCenter]

Neither NSApplication, NSUserDefaults nor NSNotificationCenter technically
adhere to the Singleton pattern -- although everyone labels this technique
as such.

https://en.wikipedia.org/wiki/Singleton_pattern

Alex, the API uses lots of different words to grab a-hold of the so-called
"standard", "default" or "shared" static instance. Unfortunately, I'm not
aware of any docs that specify when to use which adjective or if any one
particular adjective should be used when creating a real Singleton ...
since none of these are!

That said, the names all seem contextually valid ... and yet completely
ignore the idea of reflecting their identical access pattern.

Maybe someone can chime in with some historical context. There are better
ways to implement/approximate real Singletons ... they just aren't obvious
(and may not be necessary)  aand, this line of conversation is
probably getting dry by now ;-) Happy to hear someone chime in on this
perspective!

Cheers,
-Luther



On Tue, Dec 1, 2015 at 9:15 PM, Alex Zavatone  wrote:

> What does Apple do on this?
>
> I think their standard is to use shared in the name.
>
>
> On Dec 1, 2015, at 7:33 PM, Quincey Morris <
> quinceymor...@rivergatesoftware.com> wrote:
>
> > On Dec 1, 2015, at 16:20 , Carl Hoefs 
> wrote:
> >
> >> The following seems to be working out for me.
> >>
> >> #import "AppCommon.h"
> >> @implementation AppCommon
> >> + (AppCommon *)shared
> >> {
> >>static AppCommon *shared = nil;
> >>static dispatch_once_t token;
> >>dispatch_once(, ^{
> >>shared = [[self alloc] init];
> >>});
> >>return shared;
> >> }
> >
> > Looks functionally perfect.
> >
> > PSA #1: I would encourage you avoid naming the method ‘shared’, indeed
> to avoid naming anything with a brief name that doesn’t say what it is.
> Even the argument that it’s easier to type isn’t good any more, since Xcode
> is going to autocomplete almost every name for you.
> >
> > PSA #2: I can’t help mentioning that you can write all of this in Swift
> as so:
> >
> >   class AppCommon {
> >   static let shared = AppCommon ()
> >   }
> >
> > Sometimes, Swift really is Obj-C-but-better. ;)
> >
> > ___
> >
> > 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/zav%40mac.com
> >
> > This email sent to z...@mac.com
>
>
> ___
>
> 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/lutherbaker%40gmail.com
>
> This email sent to lutherba...@gmail.com
>
___

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

Re: iOS: Using AppDelegate as an app-wide singleton

[Alex Zavatone]

On Dec 2, 2015, at 12:24 AM, Luther Baker wrote:

> The conversation here is pretty loose ... and so everyone might be right in 
> what they are intending to convey... ;-) but I thought I'd just put in a vote 
> to stop using the term "Singleton" for this access pattern. It isn't a 
> Singleton (unless there is historical signficance that grandfathers this 
> incorrect term in) and I think that using the term loosely in this case 
> actually weakens the power of a pattern vocabulary a bit.
> 
> Unless you're doing something we can't see (which is possible), it is 
> unlikely you are actually creating a Singleton. It is more likely that you 
> are creating class methods that in some/many/most/all cases - are accessing 
> private static instances. Similar in form to ...
> 
> [NSUserDefaults standardUserDefaults]
> [NSNotificationCenter defaultCenter]
> 
> Neither NSApplication, NSUserDefaults nor NSNotificationCenter technically 
> adhere to the Singleton pattern -- although everyone labels this technique as 
> such.
> 
> https://en.wikipedia.org/wiki/Singleton_pattern

Yeah, but are the "effectively singletons"?
> 
> Alex, the API uses lots of different words to grab a-hold of the so-called 
> "standard", "default" or "shared" static instance. Unfortunately, I'm not 
> aware of any docs that specify when to use which adjective or if any one 
> particular adjective should be used when creating a real Singleton ... since 
> none of these are!

I just remember looking into Apple's implemented conventions on this last week 
in iOS and didn't have time to fully look this up.  It's just what I noticed 
they were doing in a few areas that escape me at the moment.  

Except for the application delegate, which does use sharedApplication as its 
accessor.

Cheers.
___

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