>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
