Actually, now that I think of it, an even simpler, more sweeping solution is to make the split view controller your own UISplitViewController subclass, and implement didReceiveMemoryWarning to return immediately:
- (void) didReceiveMemoryWarning { return; } Now the detail view will never be unloaded and the problem won't arise. I did sort of suggest this the last time we discussed this topic; I just didn't spell it all the way out. m. On Wed, 16 Feb 2011 13:42:28 -0800, Matt Neuburg <m...@tidbits.com> said: >>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