3

I'm at a point in the development of my little app where I'm implementing didReceiveMemoryWarning and such, but I feel like I don't have a good grasp on the best way to test what I'm implementing.

First off, apparently in the simulator, didReceiveMemoryWarning isn't triggered for apps that aren't in the foreground until that app is brought back into the foreground, according to this question - actually, that matches my own experience, but I was prone to ignore it because it doesn't really make sense. (Why would I want to delay clearing up my memory until I'm coming back into the foreground and probably about to need that data again?) Does this match the behavior of actual hardware? If so, does it make sense to cleanup tasks in applicationWillEnterBackground in addition to didReceiveMemoryWarning?

Second, generally, what is a good strategy for triggering the "Simulate Memory Warning" menu item in the simulator in such a way as to trigger memory warnings in a manner that they're likely to happen on the actual hardware?

Community
  • 1
  • 1
Garrett Albright
  • 2,844
  • 3
  • 26
  • 45
  • 1
    Wow. That source code is one of the rare species that aren't cluttered with terrible stylistic errors that make me vomit. This code is nice and consistent. I especially like that you're using the pointer qualifier the right way. Thanks for this piece of diamond. (Oh, an +1 here.) –  Dec 31 '12 at 14:54
  • Thanks for the code review. As I say in the readme, good code style is important to me, but I can't find much info on what the best practices are with regards to Cocoa/Obj-C. It's good to know that I've stumbled upon them regardless. – Garrett Albright Jan 01 '13 at 02:56
  • If I can give you an advice: the sanest C coding style I've known is the [Linux kernel style](http://www.kernel.org/doc/Documentation/CodingStyle), it's worth reading it and adhering to it. –  Jan 01 '13 at 07:23

2 Answers2

3

Q1: Does this match the behavior of actual hardware?

  • A: Yes, the simulator and the actual device behave the same in this regard (e.g. if your app is suspended and is not running a background task, it does not receive applicationDidReceiveMemoryWarning).

Q2: Does it make sense to cleanup tasks in applicationWillEnterBackground?

  • A1: Only insofar as that your app must prepare itself for a complete restart. If your app remains suspended and the user does a lot of things with other apps, your app may become fully unloaded - even though the app may still be visible in the task switcher, when the user activates it the next time, your app delegate will receive application:didFinishLaunchingWithOptions: (not applicationWillEnterForeground:).
  • A2: I wouldn't bother with cleaning up memory, but you should make sure that by the time applicationWillEnterBackground has finished, any user preferences and other stuff are saved so that the app knows where to take up again when it is activated the next time.

Q3: What is a good strategy for triggering the "Simulate Memory Warning" menu item?

  • A1: I doubt whether a general strategy can be formulated since every app is different.
  • A2: To use a specific case: In my app, I don't use the app delegate's applicationDidReceiveMemoryWarning to relieve memory pressure, instead I rely on the fact that when a memory warning is sent, iOS also invokes viewDidUnload on certain view controllers that are not in use. Therefore I generally use the memory warning simulation to test whether my view controllers' viewDidLoad and viewDidUnload are balanced correctly.
  • A3: Concrete example: My app uses tabs, so a favorite scenario of mine is to 1) display the tab with the view controller (VC) under test; 2) navigate to a different tab; 3) simulate the memory warning (iOS invokes viewDidUnload in the VC under test); 4) navigate back the original tab (iOS invokes viewDidLoad in the VC under test).
  • A4: If you want to use a similar approach, then you have to figure out for your app which views might be unloaded by iOS. In my (limited) experience these tend to be views that are unrelated, such as views on different tabs.
herzbube
  • 13,158
  • 9
  • 45
  • 87
  • As Mike M pointed out in the comments to his answer, `viewDidUnload` is deprecated in iOS 6. Without thorough investigation, I guess the correct thing to do will be to replace `viewDidUnload` with an override to `didReceiveMemoryWarning` and do the view unloading yourself. – herzbube Dec 31 '12 at 18:13
  • Thanks for sharing your "concrete example" - that sort of thing was what I was looking for. I would love to hear others from other devs if they'd care to share. With regards to my app, probably the biggest memory suck is an array of 250 or so objects which is created by merging a plist's contents with user preferences; I think this will be the lowest-hanging fruit to purge when memory is low. Not difficult to rebuild when needed, but time-consuming. – Garrett Albright Jan 01 '13 at 03:06
1

Here's my answer to your second question - it also kind of answers your first question:

I've used the "Simulate Memory Warning" feature to effectively reproduce issues where a child view controller consumes enough memory such that its parent must free up resources.

For example, consider a child view controller that displays the camera/photo library (i.e., UIImagePickerController)). This uses a significant amount of memory. If the picker controller consumes more memory than is available, the parent's view controller will be unloaded, and once the parent view controller is shown again (when the child is popped), the parent's viewDidLoad will be called again. This means that any variables set in viewDidLoad will be set again, potentially with memory leaks or bad pointers.

The "Simulate Memory Warning" helps to find these problems. You can go into the child view controller, select "Simulate Memory Warning", then pop the view controller and check for problems.

Note that the "didReceiveMemoryWarning" is more relevant (imho) to let you know it happened than actually trying to release memory at that point.

Mike M
  • 4,358
  • 1
  • 28
  • 48
  • Reading your answer I became nervous and tried the following: In the root controller of a navigation controller I am pushing a child controller onto the navigation controller's stack. While the child controller displays its view I trigger the memory warning in the simulator. However, the `viewDidUnload` method in the root controller is never called. Phew, I'm relieved because that's what I expected. So could you please elaborate on the parent/child relationship between the two controllers in your scenario? E.g. is there a navigation controller involved? – herzbube Dec 31 '12 at 16:31
  • @herzbube - hmn, it seems that the behavior in the 6.0 simulator is different than earlier versions. In the 5.x simulator unload is called, 6.x does not. – Mike M Dec 31 '12 at 17:44
  • Apparently viewDidUnload was deprecated in 6.0 – Mike M Dec 31 '12 at 17:46
  • 1
    from the doc: "On iOS 6, views are never purged and these methods (unload) are never called. If your view controller needs to perform specific tasks when memory is low, it should override the didReceiveMemoryWarning method." So forget everything I said :-P – Mike M Dec 31 '12 at 17:48
  • Uh oh, thanks for this info, I didn't know about the deprecation. It looks as if I will have to rewrite quite a few things in my app. By the way: I did my tests with the 5.1 simulator, so the `viewDidUnload` deprecation should not have been in effect yet. In my answer I have mentioned a tabbed UI scenario (Q3/A3) where the call to `viewDidUnload` works for me. – herzbube Dec 31 '12 at 18:04