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

Reply via email to