>On Sun, 16 Jan 2011 18:35:45 -0500, Phillip Mills <phillip.mil...@acm.org> 
>said:
>>I see a problem with the following scenario:
>>1) Start with the template project for a split view
>>2) Add a function where a modal view can be shown over it using a style of 
>>UIModalPresentationFullScreen
>>3) Run in portrait mode
>>4) While the modal view is being shown, trigger a memory warning
>>5) Dismiss the modal view
>>
>>The result is that the 'Events' button that brings up the popover root 
>>controller is no longer displayed.  The view has been reloaded, but the 
>>callback that sets up the 'Events' button hasn't been activated.

I've just been looking into this (sorry it took so long for me to get around to 
it) and it's exactly as you said. The sequence of events is very 
straightforward:

* The detail view is initially loaded as the app starts up. viewDidLoad is 
called if you've implemented it. This is your chance to configure the toolbar

* 
splitViewController:willHideViewController:withBarButtonItem:forPopoverController:
 is called, and it inserts the popover-summoning button into the UIToolbar

* The modal view covers the screen

* The memory warning takes place

* The detail view is not visible, so it is unloaded and the reference to it is 
nillified, and viewDidUnload is called

* The modal view is dismissed

* The detail view is reloaded. So, the view including the UIToolbar is brought 
in from the nib, and viewDidLoad is called if you've implemented it. This is 
your chance to configure the toolbar again

* That's all - 
splitViewController:willHideViewController:withBarButtonItem:forPopoverController:
 is, as you say, *not* called again - and therefore the popover-summoning 
button is never added to the toolbar that just got loaded fresh (and empty) 
from the nib.

The same thing, by the way, is true of the text in the middle of the detail 
view. This is supposed to say "row 4" or whatever row of the master view you 
tapped on, but if the detail view is unloaded and reloaded, that info is not 
restored.

So, I think what you've discovered is well worth pointing out, but one could 
argue that it isn't a bug. It would be wrong to call willHideViewController 
again, surely. It's just that, if you add something to the app that allows view 
unloading to take place, you have to cover your bases. A solution might be 
something like this:

- (void)viewDidUnload {
    [super viewDidUnload];
    self.toolbarItems = self.toolbar.items; // property with retain policy
}

- (void)viewDidLoad {
    [super viewDidLoad];
    if (self.toolbarItems) {
        self.toolbar.items = self.toolbarItems;
        self.toolbarItems = nil;
    }
}

m.

--
matt neuburg, phd = m...@tidbits.com, <http://www.apeth.net/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
http://www.apeth.net/matt/default.html#applescriptthings_______________________________________________

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

Reply via email to