Re: Object scope - or where to put objects that should always be accessible
Re: Object scope - or where to put objects that should always be accessible
- Subject: Re: Object scope - or where to put objects that should always be accessible
- From: Nathan Day <email@hidden>
- Date: Wed, 27 Oct 2004 13:01:43 +1000
By the sound of it you want something like NSNotificationCenter, where you have a defaultNotificationCenter method just do something like this
- (+)defaultDataBaseThingy
{
static DefaultDataBaseThingyClass * defaultDataBaseThingy = nil;
if( defaultDataBaseThingy == nil )
{
defaultDataBaseThingy = [[self alloc] init];
}
return defaultDataBaseThingy;
}
This object will not have it's dealloc method called when your application is terminated, it's difficult to guarantee that the dealloc method is called for all object in objects-c, for example objects retained by the shared NSApplication instance will not have there dealloc method called, so you should use you the NSApplicationWillTerminateNotification to do anything like close connections when you application quits.
On Wednesday, October 27, 2004, at 07:16AM, Ole Voss <email@hidden> wrote:
>
>
I'm getting into Cocoa development and have a bit of a problem with the
>
object-structure. I see that objects are being instantiated by the nib (for
>
instance) but where do I put objects that I want to be globally accessible.
>
>
For example: I would like my program to establish a database connection
>
during its startup and keep this database object available throughout the
>
applications life. When the application terminates, the object should close
>
the database connection. Where do I instantiate this object? Should it be in
>
the 'main' Routine or is there a special place where I should put it.
>
>
Also, what about the other Objects that are brought to life by the nib
>
loader for instance. Are these objects accessible to all other objects?
>
>
It there any good place to read about object scope and all these things?
>
>
Please point me in the right direction. I don't want to bother anybody with
>
simple stuff ;-)
>
>
>
Regards,
>
>
Ole.
>
>
_______________________________________________
>
Do not post admin requests to the list. They will be ignored.
>
Cocoa-dev mailing list (email@hidden)
>
Help/Unsubscribe/Update your Subscription:
>
>
This email sent to email@hidden
>
>
Nathan Day
email@hidden
http://homepage.mac.com/nathan_day/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden