Re: How are views supposed to reload after being nillified by memory warnings?
Re: How are views supposed to reload after being nillified by memory warnings?
- Subject: Re: How are views supposed to reload after being nillified by memory warnings?
- From: Roland King <email@hidden>
- Date: Mon, 05 Mar 2012 10:07:11 +0800
Are you allowed to push a view controller onto a navigation controller which is hidden by something modal and has had its top level VCs view removed? If I was doing that and getting what you're getting I would suspect that and change it so that either
1 the new view controller is pushed by the viewDidDisappear of the dismissed modal one or
2 knowing the view is just about to be rebuilt, override the memory warning handling not to dump the views, at least to that first level.
I would certainly have tried those as a first debugging step.
On 5 Mar, 2012, at 9:39, G S <email@hidden> wrote:
>>
>> In the vast majority of cases where I've seen this behavior, it is because
>> in your delegate handler for the UIImagePickerController, you assign the
>> returned image directly to a UIImageView that you have in your view
>> hierarchy. If you've recently gotten a memory warning, then this image view
>> is either nil, or will be released very soon, and you will end up with a
>> view that has no image.
>>
>
> Thanks for that observation, David. But the entire screen is white;
> there's not even the status bar visible. Our app doesn't have any
> full-screen UIImageView. The only one involved in this process is confined
> to part of the screen.
>
> I wonder if there's a bug somewhere that's revealed by our particular
> scenario, which consists of these steps:
>
> 1. We're on the root view of our tab (the root view of the navigation
> controller that lives on this tab). It shows a UIListView of items.
>
> 2. The user opts to create a new item, so we display a modal item-creation
> screen that subsequently brings up (and handles the dismissal of) the photo
> picker. While this is up, memory warnings often occur.
>
> 3. After the user completes the item-creation process, our modal
> item-creation controller calls its delegate (the original list screen) to
> say it's done.
>
> 4. The delegate creates an item-detail view for the new item, and pushes it
> onto the navigation stack (behind the modal view). It then dismisses the
> modal view, which should reveal the newly created detail screen. This
> works fine, unless a memory warning happened; in that case only a white
> screen is revealed and the app essentially hangs because the user can't
> interact with it.
>
> What we know from logging is that (in the memory-warning case)
>
> 1. The detail screen's view is loaded from the XIB, but its viewWillAppear
> method is never called.
> 2. The tab's root view (the list) is unloaded, and its viewWillAppear
> method is never called.
>
> But our modal view's viewWillDisappear method IS called. So no view is
> told that it's about to appear when the modal one disappears.
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden