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

I am trying to add 21 developer fields in a session using session.CreateField.  

It always crashes on the line adding the 17th developer field. I have tried a few different things, even swapping order, but same error occurs (runtime system error "Failed invoking <symbol>").  Is there a limit of 16 on the number of developer fields I can add?  Is there any way around this?

I am using SDK 2.4

Top Replies

All Replies

  • 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.

  • 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.

  • -

    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 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.

  • 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.

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

    Again, this constant can vary by device. We could definitely document 16, but a device could be released tomorrow that would set the value to 2 or 24. I'm not against documenting limits if there are barriers in place to prevent them from being changed, but I don't like making documentation that can be made invalid because someone on another team makes a one-line code change in a file that isn't associated with ConnectIQ.

    We could say something like the limit is typically 16, but it may vary by device and is subject to change; I'm not sure how helpful that is though.

    I see some variance in the wild with my 735xt

    It is possible. I only evaluated the number of RECORD fields allowed. It is possible that you can have more than 16 fields if some of them are SESSION or LAP fields.