compiler limit exceeded while assembling user class; 255 fields allowed connect iq 258 used

peterdedecker said:

It would've been great if:

  - you could create settings without string resources and use hard coded strings instead....

FlowState said:

- These string resources didn't impact the runtime memory usage of your app

Either/or.

Seems like the goal of requiring string resources for settings is to try to "encourage" CIQ devs to localize their settings strings (same idea behind the FIT contributor metadata, where labels and units have to be string resources.) Or maybe just to give devs that option, if they want/need it.

It would be no problem if CIQ would provide a separate resource section for settings-specific strings, so their IDs wouldn't waste app memory when you load at least one resource at runtime.

Thanks! Creating a hierarchie could bring some order as well. Good workaround

Thing is, a change like this wouldn't be quick, and would mean changes to device FW (the VM), which might not make it into older FW,

As it looks like you are only a few over 255, have you looked as using the exact same stings for things in settings and used at run time?  If you have a string for "Lap Time" in settings and another string "Lap Time" for runtime, you can use the same sting for both and eliminate one. 

I have a couple apps where the stings I use at runtime are the exact same ones I use in settings.  I was no where close to the 255, but wanted to see how easy this could be done.

Let's say you have 7 strings for something like the day of the week.  Just have a single string like "Sun,Mon,Tue,Wed,Thu,Fri,Sat", and do a simple parse in your app, maybe saving it as an array of strings, one string per day for faster access later on..

hi,

what you could do also to save strings in settings:

I had for example

 - Pressure Format =>settings list)

-----HPA

-----InHg

-----mmHG

so here 4 strings

I did

- Pressure Format (1=HPA, 2=InHg, 3=mmHg) => numeric box

so here 1 string but less frindly user

jim_m_58 said:

Thing is, a change like this wouldn't be quick, and would mean changes to device FW (the VM), which might not make it into older FW,

Which change are you referring to specifically?

- allowing more strings in CIQ? (When I said that, I didn't think it would actually happen - maybe I should've made that clear)

- allowing settings-specific strings to live in a dedicated section that isn't available to the app at runtime?

- allowing settings to use hardcoded strings?

It seems that the latter 2 ideas are actually the rare kind of proposed design change which could be implemented without changing the firmware at all; ideally, the compiler/linker and CIQ store would have to change, but not the firmware.

But let's be real, we all know none of those things are going to happen.

The the first two, yes, FW changes.  The 3rd one, maybe.

more stings means adding a second byte to the id.  it's 255 now as that's the max in 8 bits.

Separating things could also break existing apps that use the same stings in settings and at run time.  There is nothing that prevents that today.  You may not do common stings, but I do..

Cutting back the number of stings by 3 to get back to 255 is the quickest solution right now.

jim_m_58 said:

more stings means adding a second byte to the id.  it's 255 now as that's the max in 8 bits.

Yes, you explained that several times. We all understand that the largest number that can be represented by a byte / 8 bits is 255.

Like I said, that wasn't really a serious suggestion. In that case, I literally meant "it would have been great if more resources were allowed", not "I think more resources should be allowed". Again, I sincerely regret not making that abundantly clear.

jim_m_58 said:

The the first two, yes, FW changes. 

I don't see how the 2nd suggestion (allow some string resources to be in a separate section) necessarily requires a firmware change. If the compiler/linker is changed to create a new section for string resources which aren't needed at runtime, this section could go somewhere that the firmware would never see (e.g. a separate file, which is still uploaded to the store).

jim_m_58 said:

Separating things could also break existing apps that use the same stings in settings and at run time.  There is nothing that prevents that today.  You may not do common stings, but I do..

That's why it's also been suggested that this separation would be *opt-in*.

FlowState said:

- allowing settings-specific strings to live in a dedicated section that isn't available to the app at runtime?

Key word: allowing (not mandating)

It's been discussed at length more than once in the past, but the idea is that the developer would opt-in to placing string resources in some sort of dedicated section that wouldn't be available to the app at runtime. This could also be use for other things, like string resources that are only used for FIT labels and units.

Conceptually, I don't see why this kind of thing requires a firmware change.

Simple analogy / example:

- A change is made to the Connect IQ infrastructure which allows devs to include store description, changelog, listing image and screenshots as part of the IQ package, so that devs can automate/script the app update process if they choose. The compiler/linker has to change, the store has to change, but firmware doesn't have to change, because the firmware would never see any of that additional data.