Re: Memory Warnings

Once your application is in the background it becomes fair game for being terminated. So even if you're using a very reasonable mount of RAM, if you're in the background you can expect that if some other application needs the memory your application will be terminated. -- David Duncan @ My iPho

Re: Memory Warnings

On 8 Oct 2014, at 13:42, Quincey Morris wrote: > (reposted after editing for length) > > On Oct 7, 2014, at 22:12 , Gerriet M. Denkmann wrote: > >> Is there a way for the app to find out how much memory it is currently using? > > Here’s my take on this, which may be way off base: > > There

Re: Memory Warnings

(reposted after editing for length) On Oct 7, 2014, at 22:12 , Gerriet M. Denkmann wrote: > Is there a way for the app to find out how much memory it is currently using? Here’s my take on this, which may be way off base: There’s really no practical way to answer such questions any more. The wa

Memory Warnings

I have an app which sometimes receives: applicationDidReceiveMemoryWarning:. Is there some rule, how much Ram use is ok? Like: not more than x KB, or: not more than y % of total Ram? Is there a way for the app to find out how much memory it is currently using? Is there a way for the app to fin

Re: How are views supposed to reload after being nillified by memory warnings?

Well, at any rate, I have no such subview property. I've also found that among my series of modal presentations, there's a view that's displayed modally, whose user interaction works just fine, but whose viewWillAppear and viewWillDisappear methods are never called. As far as I know, it could be

Re: How are views supposed to reload after being nillified by memory warnings?

On Mar 5, 2012, at 3:40 PM, G S wrote: > No. But if you've presented a modal view controller, your entire view > hierarchy (self.view) has been ripped out of the window, and if a memory > warning arrives, then self.view will be set to nil. What happens next depends > on if you implemented -view

Re: How are views supposed to reload after being nillified by memory warnings?

> > No. But if you've presented a modal view controller, your entire view > hierarchy (self.view) has been ripped out of the window, and if a memory > warning arrives, then self.view will be set to nil. What happens next > depends on if you implemented -viewDidUnload properly or if your view > refe

Re: How are views supposed to reload after being nillified by memory warnings?

On Mar 3, 2012, at 8:57 AM, Matt Neuburg wrote: > On Fri, 02 Mar 2012 10:17:43 -0800, David Duncan > said: >> On Mar 2, 2012, at 1:28 AM, G S wrote: >> >> In the vast majority of cases where I've seen this behavior, it is because >> in your delegate handler for the UIImagePickerController, you

Re: How are views supposed to reload after being nillified by memory warnings?

Thanks for the feedback, Roland. On Sun, Mar 4, 2012 at 6:07 PM, Roland King wrote: > 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 > This would require excessive knowledge of the delegate contro

Re: How are views supposed to reload after being nillified by memory warnings?

#x27;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) t

Re: How are views supposed to reload after being nillified by memory warnings?

hat 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

Re: How are views supposed to reload after being nillified by memory warnings?

On Fri, 02 Mar 2012 10:17:43 -0800, David Duncan said: >On Mar 2, 2012, at 1:28 AM, G S 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 yo

Re: How are views supposed to reload after being nillified by memory warnings?

o picker often results in memory warnings (based on various > forum posts I've seen). It's after the dismissal of the picker's owning > controller that the white screen is revealed. In the vast majority of cases where I've seen this behavior, it is because in your delegate

Re: How are views supposed to reload after being nillified by memory warnings?

is getting > blown away by a memory warning, and how did that new content get there? > It's the photo-picker (actually a view that presents the photo picker and then lets the user add a caption). It's presented with presentModalViewController and dismissed by the delegate, as is ty

Re: How are views supposed to reload after being nillified by memory warnings?

so keep debugging then. How do you know the white view is screen-sized and has no superview? Actually a UIView which you can see and yet has no superview is probably just the UIWindow itself. How about the view which has just been loaded? Does it have a superview? Probably won't at that poin

Re: How are views supposed to reload after being nillified by memory warnings?

OK, after our controller's view gets blown away on the memory warning, it does appear to be reloaded from the nib when it's time for redisplay. At least the IBOutlet members are non-nil in viewDidLoad (I nilled them on viewDidUnload). So it appears that the controller's view is reloaded from the

Re: How are views supposed to reload after being nillified by memory warnings?

well in viewDidLoad take a look at view and the view hierarchy, where is it, what size is it, what alpha is it etc etc. On Mar 1, 2012, at 5:38 AM, G S wrote: > Thanks guys. > > The problem happens with no override of loadView. I only overrode it to > verify that it was being called after the

Re: How are views supposed to reload after being nillified by memory warnings?

Well, I've verified that the view controller has the correct name of the nib when it tries to reload the view after a memory warning. So this seems like a pretty big Cocoa bug, which unfortunately only one (remote) person on our team can reproduce reliably. I know Instagram encountered this same

Re: How are views supposed to reload after being nillified by memory warnings?

Thanks guys. The problem happens with no override of loadView. I only overrode it to verify that it was being called after the memory warning, and to verify that nibName was set. In viewDidLoad, I just instantiate a data collection and progress indicator. _

Re: How are views supposed to reload after being nillified by memory warnings?

On Feb 28, 2012, at 10:36 PM, G S wrote: > So I did override loadView, simply to write to a log and then call [super > loadView]. In the log, I verified that the controller's loadView method IS > being called after the overlapping view is dismissed. I also verified that > the object's nibName pr

Re: How are views supposed to reload after being nillified by memory warnings?

> Date: Tue, 28 Feb 2012 22:36:38 -0800 > From: G S > To: cocoa-dev > > > So I did override loadView, simply to write to a log and then call [super > loadView]. If you override loadView you must *not* call super. To put it another way, don't implement loadView unless you mean it (i.e. you in

Re: How are views supposed to reload after being nillified by memory warnings?

The Apple doc says, "If the view controller has an associated nib file, this method loads the view from the nib file. A view controller has an associated nib file if the nibName

How are views supposed to reload after being nillified by memory warnings?

Hi all. View controllers that are buried in the navigation stack (or otherwise have their views obscured) set their views to nil when they receive a memory warning. This makes sense temporarily, because the views aren't visible. But when the overlapping views are dismissed, how is the nillified

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

Le 25 févr. 09 à 18:37, mmalc Crawford a écrit : mmalc OK, thank you Frédéric ___ Cocoa-dev mailin

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or mode

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

Le 25 févr. 09 à 00:44, Jonathan Hess a écrit : On Feb 20, 2009, at 1:05 AM, Alexander Spohr wrote: Am 20.02.2009 um 04:18 schrieb mmalc Crawford: On Feb 19, 2009, at 12:34 PM, mmalc Crawford wrote: See also updated:

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Feb 20, 2009, at 1:05 AM, Alexander Spohr wrote: Am 20.02.2009 um 04:18 schrieb mmalc Crawford: On Feb 19, 2009, at 12:34 PM, mmalc Crawford wrote: See also updated: The Doc states: Y

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Feb 20, 2009, at 1:05 AM, Alexander Spohr wrote: You should therefore also set outlet variables to nil in dealloc: - (void)dealloc { // release outlets and set outlet variables to nil [anOutlet release], anOutlet = nil; [super dealloc]; } why not just use [sel

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

Am 20.02.2009 um 04:18 schrieb mmalc Crawford: On Feb 19, 2009, at 12:34 PM, mmalc Crawford wrote: See also updated: The Doc states: You should therefore also set outlet variables to nil in

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Feb 19, 2009, at 12:34 PM, mmalc Crawford wrote: See also updated: Just to try to forestall what will probably otherwise be a flood of feedback; yes, there's a typo: [super release]; shou

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Feb 19, 2009, at 2:01 PM, mmalc Crawford wrote: On Feb 19, 2009, at 1:57 PM, James Montgomerie wrote: I feel like I may have opened a can of worms here. I think Ricky just closed it -- thanks. And your post afforded a good opportunity to point to the updated documentation, so thanks for

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Feb 19, 2009, at 3:57 PM, James Montgomerie wrote: I feel like I may have opened a can of worms here. Nope; my fault. All this time I had misread the whole point of the threads. My app has never received low-memory warnings. So my observations in turn have nothing to do with it

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Feb 19, 2009, at 1:57 PM, James Montgomerie wrote: I feel like I may have opened a can of worms here. I think Ricky just closed it -- thanks. mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or mo

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

can you free up in response to a memory warning. If you don't follow this pattern, then you won't be freeing up as much as you could to. If your app isn't getting memory warnings, you won't encounter this at all. OK, things have finally clicked :) Yes, I have never

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On 19 Feb 2009, at 21:41, Ricky Sharp wrote: On Feb 19, 2009, at 2:18 PM, James Montgomerie wrote: Returning to this months-old thread... Apologies for the length of the mail, I thought it best to summarise what went before. I now have shipping iPhone OS apps and during all my tests and

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

ou don't follow this pattern, then you won't be freeing up as much as you could to. If your app isn't getting memory warnings, you won't encounter this at all. mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) P

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Feb 19, 2009, at 2:18 PM, James Montgomerie wrote: Returning to this months-old thread... Apologies for the length of the mail, I thought it best to summarise what went before. I now have shipping iPhone OS apps and during all my tests and analyzing things in Instruments (connected to

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Feb 19, 2009, at 12:18 PM, James Montgomerie wrote: Is the reason that the setView: approach is preferred that, despite what the docs and comments in the files say, the superclass' didReceiveMemoryWarning might /not/ actually release the view, even if it doesn't have a superview It's

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

thread, the "setView: approach" is, by the way: On Nov 18, 2008, at 1:19 PM, Greg Titus wrote: The way to handle this is to _not_ respond to memory warnings in subclasses (at least not for the purposes of view outlet handling - there may be other non-view memory you want to free

Re: UIViewController memory warnings | didReceiveMemoryWarning | setView | releasing outlets | releasing properties

On Nov 29, 2008, at 2:58 PM, Glenn Bloom wrote: // Implement loadView if you want to create a view hierarchy programmatically - (void)loadView { /* snip */ NSMutableString * stringCompleteMutable = [NSMutableString stringWithString:string00Local]; // local variable set with a construct

RE: UIViewController memory warnings | didReceiveMemoryWarning |

UIViewController memory warnings on the iPhone, I've found various useful threads online, and in particular, was very glad to follow the numerous recent posts in this forum with the subject 'Outlets / IBOutlet declarations'. In response, I've written a test app to confirm what

Re: UIViewController memory warnings | didReceiveMemoryWarning | setView | releasing outlets | releasing properties

On Nov 29, 2008, at 9:45 AM, Glenn Bloom wrote: Ashley, Can't thank you enough. I just posted the following, hoping to pre- empt other folks from wasting time correcting me on various points you addressed - and I hope, refocusing things on my major questions. I have of course been throug

Re: UIViewController memory warnings | didReceiveMemoryWarning | setView | releasing outlets | releasing properties

On Nov 28, 2008, at 11:44 PM, Glenn Bloom wrote: In the course of trying to understand UIViewController memory warnings on the iPhone, I've found various useful threads online, and in particular, was very glad to follow the numerous recent posts in this forum with the subject &#x

UIViewController memory warnings | didReceiveMemoryWarning | setView | releasing outlets | releasing properties

In the course of trying to understand UIViewController memory warnings on the iPhone, I've found various useful threads online, and in particular, was very glad to follow the numerous recent posts in this forum with the subject 'Outlets / IBOutlet declarations'. In response, I&#x

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Nov 22, 2008, at 8:29 AM, mmalcolm crawford wrote: Let me check on this one. It seems that, for various reasons, the setView: approach is still preferred. mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

Am 22.11.2008 um 01:53 schrieb mmalcolm crawford: - (void)dealloc { // release outlets and set variables to nil [anOutlet release], anOutlet = nil; [super release]; } [super dealloc] ? ;) atze ___ Cocoa-dev mailing list (Cocoa-de

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On 22 Nov 2008, at 16:29, mmalcolm crawford wrote: On Nov 22, 2008, at 8:16 AM, mmalcolm crawford wrote: [...] Sorry, pressed Deliver on the wrong message by mistake. Let me check on this one. Oops, sorry, looks like we're mailing around each other now... Jamie. ___

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

But I'm assuming that self.anOutlet will be valid if and only if self.view is already valid (in which case the call to self.view.superview should be safe, no?). Under this assumption, if self.anOutlet is nil, the && be short- circuited and self.view never called; if it is valid, it's safe to

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Nov 22, 2008, at 8:16 AM, mmalcolm crawford wrote: [...] Sorry, pressed Deliver on the wrong message by mistake. Let me check on this one. mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moder

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Nov 22, 2008, at 7:58 AM, James Montgomerie wrote: if(self.anOutlet && !self.view.superview) { On Nov 19, 2008, at 12:59 AM, mmalcolm crawford wrote: You could invoke 'view': - (void)didReceiveMemoryWarning { if ([self.view superview] == nil) { // set outlets to nil

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On 22 Nov 2008, at 00:53, mmalcolm crawford wrote: Context: UIViewController provides a method, didReceiveMemoryWarning, which is invoked on view controllers when the amount of memory available to the application is severely constrained. The goal of the method is to allow view controller

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Nov 21, 2008, at 5:21 PM, Ricky Sharp wrote: But, that's only if dealloc releases objects directly and doesn't use accessors or use the workaround shown below. Yes, although following "best practice" is assumed... :-) I'm now really curious as to why UIViewController uses an accessor

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Nov 21, 2008, at 6:53 PM, mmalcolm crawford wrote: This leaves us for now with two solutions: (a) Greg's (override setView:) which is more future-proof but is in many respects academically unsatisfying. - (void)setView:(UIView *)aView; { if (!aView) { // set outlets to nil, e

Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

Context: UIViewController provides a method, didReceiveMemoryWarning, which is invoked on view controllers when the amount of memory available to the application is severely constrained. The goal of the method is to allow view controllers to dispose of resources that are currently not ne

Re: memory warnings

I'm sure what you say is true. If you try to allocate right up to the limit, yes, you will eventually hit failures. But knowing your heap is, say, 90% full is still pretty useful information. You can jettison stuff and try to reduce your footprint well before you reach "the wall." Jens Alfke w

Re: memory warnings

On 12 Mar '08, at 11:00 AM, John Stiles wrote: You can dive into BSD to get some values which might help you. I'm not an expert on this, but I've listened in on email threads where OS X kernel engineers were giving answers. Trying to preflight memory allocations is, basically, not feasibl

Re: memory warnings

Thanks, ill look into this. Its much better than nothing. AC On 12-Mar-08, at 2:00 PM, John Stiles wrote: You can dive into BSD to get some values which might help you. vm_statisticsvmstats; mach_msg_type_number_t count; kern_return_t result = host_statistics(mach_host_se

Re: memory warnings

You can dive into BSD to get some values which might help you. vm_statisticsvmstats; mach_msg_type_number_t count; kern_return_t result = host_statistics(mach_host_self(), HOST_VM_INFO, (host_info_t) &vmstats, &count); uint64 freeMem= uint64(vmstats.free_count +

Re: memory warnings

On Mar 12, 2008, at 11:40 AM, Alexander Cohen wrote: Is there any way to be notified when my app is running low on memory? Not really. My app is very memory intensive and needs to have a lot of images in memory at the same time, id like to be able to clear some cache if memory gets too l

memory warnings

Is there any way to be notified when my app is running low on memory? My app is very memory intensive and needs to have a lot of images in memory at the same time, id like to be able to clear some cache if memory gets too low. thx AC ___ Cocoa-d