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
