Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

How to handle memory warnings on the javascript side

I've been tracing through the iOS code to see what happens when a memory warning is received (in response to a call to didReceiveMemoryWarning or a UIApplicationDidReceiveMemoryWarningNotification notification).

It seems to merrily throw away a bunch of resources which should be re-creatable, which makes sense since that's the sort of thing one is supposed to do in this situation.

However, in an app that I'm taking a look at for a client, what this results in is a blank view with just a solid background colour. I've seen this issue reported elsewhere so I guess I'm not alone.

I'm a cocoa guy, not a appcelerator guy, so my question is - is the javascript side of things supposed to listen for an event or handle this situation in some way? Does it need to do something to kick off the process of re-building the purged resources and/or re-showing the current view?

Memory warnings are something that the app is pretty much guaranteed to receive at some point or other. They aren't supposed to be fatal events - the whole point is that they are supposed to give your app time to clear up its caches, tighten its belt, and carry on.

So either I'm missing something that the app is supposed to be doing, or this is a really really fundamental bug…

— asked December 13th 2011 by Sam Deane
  • ios
  • javascript
  • memory warning
0 Comments

2 Answers

  • Accepted Answer

    I am generally an appcelerator girl, and not a cocoa girl (so to say), but I have an exactly same request. Many times I am facing situations, when it would be essential to receive memory warning (if for nothing else, then at least to let the user know that we cant continue/open the document/load the image and such). I really hope it will be implemented before i have to go and throw my own custom event from some place in code…

    It does apply both to Cocoa and Java, where the memory situation is even worse, and all I can do is guess and pray….

    Sam, being a Cocoa guy, do you know any good place in code to throw such an event? Let's throw it! Joking apart, you can just go and modify anything in /Library/Application Support/Titanium/mobilesdk/osx/<your sdk>/iphone/Classes directory (as long as you know what you are doing, or just willing to try), and the next clean and next build will include the modification into your project.

    Throwing an event in the framework is quite easy, search for the line that say "fireEvent", and you'll see a lot of them like this:

    [proxy fireEvent:@"touchstart" withObject:[proxy createEventObject:nil] propagate:YES];

    That is the event you can just catch from Javascript.

    — answered December 21st 2011 by Ganna Kozynenko
    permalink
    1 Comment
    • When I was rummaging through the SDK code I seem to remember that there were a few places where memory warnings were handed, so off the top of my head I can't remember where the best place to throw the event would be. You could always register for the UIApplicationDidReceiveMemoryWarningNotification and throw it from the notification handler - but I guess you might need some context.

      On the plus side, I think that the 1.8 release candidate does a better job of handling memory warnings.

      Fortunately I'm not working on that project any more, so I don't need to use appcelerator! Honestly, I'd really advise against it for any serious app that you want to build.

      — commented December 21st 2011 by Sam Deane
  • You can judge the device memory how much consuming your code it..

     Titanium.API.info ('Available memory:' + Titanium.Platform.availableMemory)
    
    — answered December 14th 2011 by sachin thakur
    permalink
    1 Comment
    • I can judge the memory usage in Instruments thanks, but that's not what I asked.

      — commented December 14th 2011 by Sam Deane
The ownership of individual contributions to this community generated content is retained by the authors of their contributions.
All trademarks remain the property of the respective owner.