Connect IQ 1.2.4 SDK Available!

Connect IQ developers web page out of date

The page at http://developer.garmin.com/connect-iq/overview/ still says 1.2.2, so is lagging a whole 2 subversions behind!

Rupert,

Regarding the 0.5KB, there was a bug in our Windows SDK that was under-reporting memory used versus on-device. The point in the release notes "Better alignment of reported memory estimates between OS X and Windows" also affected devices (all three are better aligned). That issue has been addressed in the 1.2.4 SDK.

I was working on an app. I want to use the back - lap button to navigate in the app. Things run smooth in ConnectIQ SDK 1.2. However, in CIQ SDK 1.2.2 and 1.2.4 after I click the back/lap button at first codes run fine but then the app exits. Here is the part I handle the key function:
else if(evt.getKey() == Ui.KEY_ESC)
{Sys.println("Ui.KEY_ESC");
if(hPos==3){hPos=0;}
else{hPos=hPos+1;}
}

The code runs fine, screen updates as it should be, but the app exits.
I thought this was an issue with the simulator running on Linux and continued using CIQ 1.2 but, it is doing this on Fenix 3 (FW6.80, CIQ 1.2.2) too.

I also tried to create a new app and also back/lap key exits in it too. So I think ESC key exits all the apps now. So is this a permanent change with the SDK as ESC key will only be used to exit the app, or an issue? Or am I just missing something?

In the past it worked just fine as I used it in my own game too (https://apps.garmin.com/en-US/apps/52fda9b1-190a-4055-8328-7f7877f2f339). But now couldn't run the game with latest SDK as it throws errors with image files...

Are you returning true from the input handler when you handle the escape key press?

Travis

Are you returning true from the input handler when you handle the escape key press?

Travis

Thanks. I really missed that. Solved. ;)

Devices have a limit to the number of objects they can allocate. A “Too Many Objects” error is issued when this limit is reached; the number has been increased to better reflect device capability.

Increased? Great! Why then previously working app fails with "Too Many Objects Error"? Dictionary supported up to 30+ entries, now it's less than 26.
Still don't get why there are limits if free memory is available. :mad:

Got rid of dictionary anyway. Hardcoded keys as const indices of array. Didn't change the memory usage too much, -0.5kb.

Dictionary supported up to 30+ entries, now it's less than 26.

There is something else going on in your app. I wrote the following test code and ran it on 1.2.3 and 1.2.4. In both instances, the program inserted 1746 entries into the map before running out of memory (yes, it didn't run out of objects, it ran out of memory). If you enable the commented out code in onTimer() and use a string as the value in the map, with 1.2.3 you get 230 entries in the map before running out of objects. With 1.2.4 you run out of memory after 443.

class MyView extends Ui.View {

hidden var mpMap;
hidden var mpVal;
hidden var mpTimer;

function initialize() {
View.initialize();

mpMap = {};
mpVal = 0;
}

function onShow() {
mpTimer = new Timer.Timer();
mpTimer.start(self.method(:onTimer), 50, true);
}

function onHide() {
mpTimer.stop();
mpTimer = null;
}

function onTimer() {
mpMap[mpVal] = mpVal; //.toString();
mpVal += 1;

var stats = Sys.getSystemStats();
Sys.println(stats.usedMemory);

Sys.println(mpVal);
}

function onUpdate(dc) {
}
}


Still don't get why there are limits if free memory is available.

These kinds of limits turn up all over in computers science. This is really no different from the number of inodes on a file system limited. Most commonly these limitations exist for efficiency reasons. Sometimes they are there to simplify the implementation. I have no idea what case this is, but so far I've seen no evidence that 1.2.4 and the dictionary type are having problems with this. Perhaps you could provide a test case to demonstrate?

Perhaps you could provide a test case to demonstrate?

I've got what's the issue in my case. It seems like I have a memory consumption spike during some heavy calculations (sunrise/sunset), outside of actual dictionary usage. That's why reducing the size of dictionary helped with "too many objects" error. I've noticed that when I declared huuuge dictionary inside the function (stack), no error occur, however, when I declare it inside the WatchFace class, I'm hitting some limit. Moreover, I've tried to reduce dictionary items count by grouping them into sub-dictionaries, and it didn't help, hence the actual array size matter, not just items count.

However, I built my app without any changes when I was using dictionary without any changes on new 1.2.4 simulator and it throws "too many objects" error like crazy.

I've got what's the issue in my case.

Sorry, I don't understand. If you have a simple program that demonstrates the problem when built with the 1.2.4 SDK and not with the 1.2.3 SDK, you should post it for Garmin (and other interested parties) to investigate.

It seems like I have a memory consumption spike during some heavy calculations (sunrise/sunset), outside of actual dictionary usage.

But you're not complaining about memory consumption, you're complaining that the object count is being exceeded. These are different, but related, problems. Either way, if you have a complex calculation, you can reduce used resources by re-using temporaries or assigning them to null when they're no longer needed.

That's why reducing the size of dictionary helped with "too many objects" error.

It just so happens that it helped, but that doesn't indicate that dictionary is the problem. I'm willing to bet if you started trimming other data the problem would go away as well.

Think of it this way; an operating system update is installed and suddenly you get warnings that your hard disk is running out of space. You can definitely free up some space and eliminate the warnings by deleting operating system files (del /s /q c:\windows\system32), but that doesn't mean that the files in the system32 folder were the cause of the problem.

when I declare it inside the WatchFace class, I'm hitting some limit.

It sounds like this should be a starting point for your test case then.

I built my app without any changes when I was using dictionary without any changes on new 1.2.4 simulator and it throws "too many objects" error like crazy.

I'm not saying that there isn't a difference in behavior between 1.2.3 and 1.2.4. The documentation says there are changes. I'm simply trying to convince you to generate a test case to demonstrate the problem so that we can better understand it. Right now you're saying that it is caused by Dictionary, but my testing shows that you should have less problems with resource usage and Dictionary on 1.2.4.

I'm not saying that there isn't a difference in behavior between 1.2.3 and 1.2.4. The documentation says there are changes. I'm simply trying to convince you to generate a test case to demonstrate the problem so that we can better understand it. Right now you're saying that it is caused by Dictionary, but my testing shows that you should have less problems with resource usage and Dictionary on 1.2.4.

No need to convince, I perfectly understand it would be helpful. :) Unfortunately I have no time now to generate standalone example that reproduces my problem. It appears in working app with resources and bunch of other code that takes 50.5KB of memory. The key thing I've noticed though, I can create big dictionary(~40 items) inside the stack. However, when I put the dictionary into my WatchFace object (child), which already has bunch of other stuff (resources, variables), it eventually throws "too many objects" error. I suppose there is an object size limit in the heap.
I will try to research it deeper in my app or maybe even share the code.