Why do you need to do any explicit cleanup on app termination? App memory
disappears (poof!) so it's not like you're leaking anything. Is your class
holding onto some state that must be written out to disk, for example?
On Jun 1, 2011, at 3:54 AM, Dan Hopwood wrote:
> Thanks Steve. For completeness - what's the proper way to perform the
> cleanup? Should another static method be created that releases the singleton
> instance when the app is closed? i.e.
>
> + (void)releaseSharedInterface
> {
> [sharedInstance release];
> sharedInsance = nil;
> }
>
> D
>
>
> On 1 June 2011 09:54, Dan Hopwood <d...@biasdevelopment.com> wrote:
> Great, thanks a lot Steve - very helpful.
>
> D
>
>
>
> On 31 May 2011 18:44, Steve Christensen <puns...@mac.com> wrote:
> How about providing a singleton class method? Then you just include
> WebServiceInterface.h where needed. No need to have a global variable.
>
> @implementation WebServiceInterface
>
> ...
>
> + (WebServiceInterface*) sharedInterface
> {
> static WebServiceInterface* sharedInstance = nil;
>
> if (sharedInstance == nil)
> sharedInstance = [[WebServiceInterface alloc] init];
>
> return sharedInstance;
> }
>
> ...
>
> @end
>
>
> foo = [[WebServiceInterface sharedInterface] someMethod];
>
>
> On May 31, 2011, at 3:25 AM, Dan Hopwood wrote:
>
>> Thanks for all your answers, they make complete sense.
>>
>> I have one more related question. I have developed a custom, stateful
>> WebServiceInterface object, which manages all connection requests made to an
>> XML-RPC server. Being stateful, I initialise this object when the app
>> launches and at the moment I store a pointer to it in a header file, which I
>> include in all view controllers. This allows me to make a request for data
>> from anywhere. In a similar way, I feel that storing a global pointer is not
>> best practise and can't help but think there is a more elegant way of doing
>> this. One option I have considered if storing/initialising the object in the
>> app delegate and then creating a utility method in the delegate that wraps
>> the object call. Is this the best solution or is there a design pattern I am
>> unaware of?
>>
>> Many thanks!
>>
>>
>> On 28 May 2011 19:15, Conrad Shultz <con...@synthetiqsolutions.com> wrote:
>> On May 28, 2011, at 6:11, Dan Hopwood <d...@biasdevelopment.com> wrote:
>>
>> > Thanks for your response Steve. I have considered using the
>> > nsnotification service but what if you need to not only let another
>> > object know when an event has occurred but you also need to send that
>> > object some data? For example a user selects an option in a table -
>> > the selection must be conveyed in some way to the vc I'm pushing on
>> > the nav controller stack so that it's view is dynamic depending on the
>> > selection. As far as I'm aware that is not possible using
>> > notifications.
>>
>> That's very doable with notifications. See the "object" and "userInfo"
>> methods in NSNotification and corresponding methods in NSNotificationCenter.
>>
>> > In general I create a new vc/nib for *every* screen I have in the app.
>> > Let's take a navigation app as an example. Are you saying that the
>> > hierarchy should be:
>> >
>> > -> 'root view controller' (has overall control, contains navigation
>> > logic and sends data between the containing view controllers)
>> > ->-> 'nav controller'
>> > ->-> 'all view controllers to be pushed/popped'
>> >
>> > ...where the nav controller and its view controllers are stored and
>> > initialised inside the 'root view controller'?
>>
>> Well, I'd say the view controllers aren't "stored" inside the root view
>> controller; they are pushed onto the navigation stack as and when needed.
>> Unless you are doing some caching, I wouldn't store the view controllers
>> outside the navigation stack. (If you do implement caching, make sure you
>> respond to memory warnings by flushing the cache!)
>>
>> In a navigation based application I feel that your architecture is
>> simplified by design. Since only one view controller (notwithstanding modal
>> view controllers) is on screen at any time, and they are all arranged
>> hierarchically, parents should configure their children before pushing them
>> onto the stack. When children need to communicate back to their parents (for
>> example, if you push an editor view controller from a summary view
>> controller, which needs to be updated when the editor view controller makes
>> changes), you can use KVO or notifications, but if the communication is by
>> design of interest only to the parent and child view controllers, just make
>> the parent the delegate of the child. So if the child, say, had a list of
>> favorite URLs for the user to select, it could call something like [delegate
>> didSelectFavorite:url] which would cause the parent to be updated (and
>> change appearance when the child is popped off the stack).
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
