What is the limiting number of developer fields that can be added under session?

Sorry Jim, I don't understand this.  I have a 520 plus, but am adding CIQ dev fields programatically.  I find if I try to add 17 I get a runtime error, but with 16 I do not.  

Perhaps we are at cross-purposes?  I am talking about developer fields in a watch-face app, not CIQ data fields.

Ok, I was talking about data fields.  Seems you're talking about user/developer (fitContrib) data in a single data field/device app.

I'm pretty sure you can see when you hit the limit in the sim, and as Travis said, there's no hard and fast limit and it can vary based on other factors.

That is the problem - it doesn't give me any idea.  Here is error message.  Occurs on the line creating the 17th developer field:

Error: System Error
Details: Failed invoking <symbol>
Stack:
- startLog() at E:\Aeromotive\Velosense\ConnectIQ\Eclipse\VeloView\source\velo_view_fit_file.mc:52 0x10003182
- startStopLog() at E:\Aeromotive\Velosense\ConnectIQ\Eclipse\VeloView\source\velo_view_fit_file.mc:80 0x10003292
- onKey() at E:\Aeromotive\Velosense\ConnectIQ\Eclipse\VeloView\source\velo_view_delegate.mc:49 0x10002984
- handleEvent() at T:\mbsimulator\submodules\technology\monkeybrains\virtual-machine\api\WatchUi.mb:1056 0x300023a4 

Looks like you're seeing line numbers in your code.

If you need a bit more info, add some println calls.

bgarrood said:

Error: System Error
Details: Failed invoking <symbol>
Stack:
- startLog() at E:\Aeromotive\Velosense\ConnectIQ\Eclipse\VeloView\source\velo_view_fit_file.mc:52 0x10003182
- startStopLog() at E:\Aeromotive\Velosense\ConnectIQ\Eclipse\VeloView\source\velo_view_fit_file.mc:80 0x10003292
- onKey() at E:\Aeromotive\Velosense\ConnectIQ\Eclipse\VeloView\source\velo_view_delegate.mc:49 0x10002984
- handleEvent() at T:\mbsimulator\submodules\technology\monkeybrains\virtual-machine\api\WatchUi.mb:1056 0x300023a4 

There are going to be limitations in various bits of code (there are multiple pieces in play here). I looked at the associated code and don't see any explicit limits (nothing says if (field_count > 16) fail(); like you're hoping), but there are implicit limits... in the FIT format, in the memory reserved for this in the virtual-machine, in the memory available on the device, ... We need to figure out exactly what is failing and then work from there.

Without some information about what is happening at velo_view_fit_file.mc:52 (is this a call to createField?) it is going to be difficult to tell. Since there are ~16 calls to createField at play here, it seems like the best course of action would be to get information about the parameters to those various calls so that we can reproduce your exact problem here (16 uint8 fields might work, but 2 32-byte string fields might fail).

If we can get that information (a test app that reproduces the problem would be nice, especially if it shows the problem in the simulator), we might be able to actually make some progress instead of just guessing at the problem that you're actually experiencing.

And if I recall, there's also a limit on total data.

So if for example you have 16 fields with a Number and it works, things could beak if you switched to 16 Stings where each string was 100 characters long.

bgarrood-

It turns out I don't need a test app to reproduce. There is a constant in the device firmware the controls the maximum number of developer data fields that can be active at once for the entire activity profile. This is the limit that jim_m_58 mentioned in his first response, and it is set to 16 for every device that I checked. There is nothing that you can do to get more fields.

That said, I think that we can handle this situation a bit better. Having a limit that is shared between apps could be very frustrating for an app developer, especially when running up against that limit produces an unrecoverable error. I think it would be much cleaner for us to throw an exception if the underlying system is not able to allocate a shared resource.

That doesn't necessarily help you get more data fields, but it would make it possible for you to handle the error vs just crashing the app.

Travis.ConnectIQ said:

There is a constant in the device firmware the controls the maximum number of developer data fields that can be active at once for the entire activity profile.

I think this would be one of the constants I think should be in docs, but no matter.

In the absence of that number, I see some variance in the wild with my 735xt. Pretty sure I've had multiple fields running on the device totalling some way above that - I think around 22 - although there was a mix of SESSION, RECORD and LAP fields if that makes any difference.