Memory and crashes

Some of the things I do to reduce memory are:

• Eliminate bitmaps or reduce the number of colors in them. Usually, drawing simple shapes uses less memory than bitmaps
  
• If you have a menu or series of confirmations that is several layers deep, you can pop the shallower layers when you go to the deeper layers to save a couple of K
  
• Sprinkle Sys.println(Sys.getSystemStats().usedMemory) throughout the code to figure out where the biggest memory users are and work from there
  

How does one go pop the shallower views? Can give an example? My menu system sometimes takes up to 7-8k due to 4-5 levels deep.

221

Make sure you have created a CIQ_LOG.txt in \garmin\apps\logs on your device to catch VM stuff, and look for an err_log.txt in the root and post it here or send it to the CIQ folks.

You can also put Sys.println() calls in your code to show available memory, and it will be written to a pre-created <appname>.text in logs, and see what memory you're really using.

By "crash" do you mean the "IQ!" screen, or do you mean a reboot of the watch? If it's a "IQ!" screen, there will be stuff in the ciq_log.txt file that should point you to what happened in your code.

One thing I've seen when doing a makeJsonRequest(), is that the site might return JSON data of a different form, based on an error, so you need to handle the difference in onRecieve(). Otherwaise that will give you a "IQ!" screen.

For example, in my Weather stuff, if the weather station I'm asking data for hasn't been reporting, the response for my request is in a different format.

How does one go pop the shallower views? Can give an example? My menu system sometimes takes up to 7-8k due to 4-5 levels deep.

If you uncomment the popView line below, it saves about 1.7 K in a quick test on the simulator.

The drawback is that after the number picker is done, it returns to the main view rather than where you were in the menu.

class PickerMemoryMenuDelegate extends Ui.MenuInputDelegate {

function onMenuItem(item) {
if (item == :item_1) {
var picker = new NumPicker();
var delegate = new NumPickerDelegate();
//Ui.popView(Ui.SLIDE_IMMEDIATE);
Ui.pushView(picker, delegate, Ui.SLIDE_DOWN);
} else if (item == :item_2) {
Sys.println("item 2");
}
return true;
}

}

thanks MoxyRoger!! That's great info. I'll give it a try and see if I can live with going back to the main view. (But I think that instead of going entirely to the main view (or do u mean main menu?) it would just go down one less level )

Level 1- level 2 - level 3 - level 4 - (Popview here) - level 5
Upon exiting level 5, I would return to level 3 correct?

Works fine until I make the second JSON call, running on 920 with latest firmware.

Garmin can you please help!?

Here is the error log

www.boiledsweets.com/tmp/err_log.txt

The call I'm making is

Comm.makeJsonRequest("api.openweathermap.org/.../daily", {"lat"=>latLon[0].toFloat(), "lon"=>latLon[1].toFloat(),"cnt"=>"6", "APPID"=>"33b43a459f4002b3693aaec3420776ac"}, {}, method(:onReceiveForecastDaily));

It works fine in the simulator. The onReceiveForecastDaily function never gets called. The previous JSON call to get the current weather works. Free memory is about 10k at the time of calling. It causes a reboot of the device.

THis is in the CIQ_LOG.TXT

@PC = 0x300005C0
@PC = 0x30000671
@PC = 0x100006AC
TVM ERROR:
Out Of Memory Error
Failed invoking <symbol>

THANK YOU!

Thanks for the report, Rupert. That crash you're seeing is due to a bad memory handle, but we'll need to investigate a little more before we can zero in on the problem. I'll create a ticket and report back here once I know more.

Seems to happen when I make a secord JSON call. Perhaps I've run out of memory for the returned data? Dunno.

What I'd like to know is can I set the previous data passed in to my callback function to null to force the garbage collector to fire sooner?!

What I'd like to know is can I set the previous data passed in to my callback function to null to force the garbage collector to fire sooner?!

Yes, ConnectIQ uses reference counting and not garbage collection. As soon as you eliminate your last reference to an object (which can be done by setting the variable assigned to it to null), the data will be freed.

Rupert: I'm not able to reproduce this crash. I basically took the weather sample and plugged in your makeJasonRequest() as an additional request, and use an onReceivedForecastDaily() callback that prints the response code and the data. In all, I have three consecutive requests, the last of which is yours, and my app is not crashing (plus, I'm getting an OK response with data from all three requests).

Are you able to provide more of your code or perhaps send me the source so I can try to reproduce the issue? It's not specifically due to multiple JSON requests, though it could still somehow be related.