Memory and crashes

Try it when you have say 3 k memory left and call JSOn that returns 4k

Try it when you have say 3 k memory left and call JSOn that returns 4k

Sounds like you know what the issue is. :) If this wasn't a device crash, it would be a "IQ!" crash of your widget. Don't know if CIQ can catch this, but a "IQ!" crash would be better, but would still happen.

Something you're doing takes a bunch of memory (images and fonts?)

You could always check available memory, and if it's less than needed for the second makeJsonRequests()'s data, don't make the request. Or make images/fonts smaller, so they won't take as much memory, and you'll always have enough.

Are you loading all your images all the time? You might save some memory if you only load the ones needed.

I dont know what the issue is. I'm guessing.

Yes I've reduced the images/fonts and hoping that will address issue. It doesn't crash but reboots.

I load all images as I need them all

Thanks Rupert--I'll try loading up the memory and then make a request. Based on what you're describing, it sounds like it's not necessarily the second request, but just low memory and a JSON request with a large enough response. I'll keep at it and see what I can figure out.

I'm still not able to reproduce this exact issue, even under low memory conditions, but I did uncover what looks like a problem with makeJsonRequest() when memory is low. It's not crashing or rebooting the device, but the app basically stops executing (it's not clear whether the request is firing or if the response is returned--all I can say for sure is that the callback never gets invoked). Brian is taking a deeper look at it to identify the problem.

Aside from this, I also see Out Of Memory errors, which is an expected an correct response. During a brief discussion last week, some of the team thought that the issue Rupert is seeing may have already been addressed in 1.1.4. It may be that what I'm seeing is related to Rupert's issue, but I can't say for certain. We'll keep poking at it until we find something, and I'll post back here.

I'm still not able to reproduce this exact issue, even under low memory conditions, but I did uncover what looks like a problem with makeJsonRequest() when memory is low. It's not crashing or rebooting the device, but the app basically stops executing (it's not clear whether the request is firing or if the response is returned--all I can say for sure is that the callback never gets invoked). Brian is taking a deeper look at it to identify the problem.

Aside from this, I also see Out Of Memory errors, which is an expected an correct response. During a brief discussion last week, some of the team thought that the issue Rupert is seeing may have already been addressed in 1.1.4. It may be that what I'm seeing is related to Rupert's issue, but I can't say for certain. We'll keep poking at it until we find something, and I'll post back here.

Thank you for continuing to look at this. 1.1.4 has indeed impoved the JSON request massively so thanks guys! The other really interesting issue with the JSON calls is the fact that it runs SOOOO fast when the connect app on the iphone is active compared to running but no active.

KEEP UP THE GOOD WORK!

From Brian:

It looks like this is an out of memory error in the JSON callback. A fix was brought into 1.2.0 that properly triggers these errors from the callback, but it is not being handled on 1.1.4. The app is crashing, but not actually triggering the crash sequence.

I'm not sure what the plan will be to bring this fix into 1.1.x, but we've already got a fix in place for the 1.2.0 release.

I've had other people comment on the speed of JSON requests on iOS when GCM is open, so that's already been reported for investigation. :)

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;
}

}

function onMenuItem(item) {
if (item == :DSFO_Timer) {
// var stats = Sys.getSystemStats();
// var freeMemory = stats.freeMemory.toString();
// var totalMemory = stats.totalMemory.toString();
// var usedMemory = stats.usedMemory.toString();
// Sys.println("TIMER Free: " + freeMemory + " used:" + usedMemory + " total:" + totalMemory);
Ui.popView(Ui.SLIDE_IMMEDIATE);
Ui.pushView( new Rez.Menus.M_Timer(), new TimerDG(_DS, _DSF), Ui.SLIDE_LEFT );
} else if (item == :DSFO_Pace) {
Ui.popView(Ui.SLIDE_IMMEDIATE);
Ui.pushView( new Rez.Menus.M_Pace(), new TimerDG(_DS, _DSF), Ui.SLIDE_LEFT );

}
}
}


most likely I'm doing something wrong. The above "works" on the simulator, but when I load it into my F3, it goes bonkers. (as well as I don't see there to be improvements in memory)

Speaking of 1.1.4, has that VM and the changes rolled out to any device FW yet? Will some devices skip 1.1.4 and move right to the 1.2.0 VM?

None of the devices have publicly-released firmware that includes 1.1.4 just yet, but there are internal, development firmware builds that include 1.1.4. I expect to see public firmware updates to all devices soon. There are no devices that are currently available which will skip 1.1.4 and go directly to 1.2.0.