How to Limit Instances of Datafield on a Layout?

I don't have an answer to your question about how to distinguish between two identical data fields on a screen - but that's not necessary (at least in my experience with Edge devices):

Two identical data fields on a screen behave in exactly the same way (so there is no point in having two on one screen).

Example: If you tap one to change a display (if the data field offers this option), both data fields respond to this tap in the same way.

Both data fields behave in exactly the same way. In fact, only one data field is used - it is simply displayed twice.

While I think it's impossible to differentiate between 2 fields of the same size and obscurity flag, the behavior you describe is not necessarily a feature of the CIQ platform. I think * it is probably just as much determined by the way your DataField is programmed.

*) I don't have experience with user interaction (aka touch) with datafields.

BTW I wasted some time in the past trying to crack this thing (with not much success) and you can try out this DF Detector DataField: https://apps.garmin.com/apps/1535a238-cbac-463b-bde2-373403502a6f also on GitHub: https://github.com/flocsy/DFDetector

flocsy🤠 said:

I think * it is probably just as much determined by the way your DataField is programmed.

When the program does any stuff coded in onCompute it has effect on all datafields (of the same datafield) on the same screen - even the sizes are different.

When you do stuff in onUpdate for different datafield sizes, you can get different displays of the datafield at the same time on one screen.

But 2 identical datafields (same width, same heigth) always react as one in the same way. (What‘s logical, because you cannot distinguish in onUpdate.)

PS: I have your datafield for field-distinguishing. But as you stated - it does not help - especially with Edge devices.

Thanks both -- the DF Detector was really useful in identifying potential problems with watches returning similar or same obscurity flags and sizes, ... and I was OK with the duplication on Edge where two large fields are still rectangular.  My edge-case is where a semi-circular field upper on a watch I would like to process differently to a lower semi-circular layout.

I could detect two onUpdate() being called with at the same moment and tell one not to update member variables (obscurity) for the onConpute to handle but it was unreliable.  I'll have to give some credit to user common sense (ahahahaahha)

assuming you have control of the api server end, just cache the response for x minutes based on a common url pattern that both fields would have.   that way the user can run it in as many fields as they want, but each one will get the same response from your server, one will just get the cached value from the previous call.

crispgarmin said:

I could detect two onUpdate() being called with at the same moment and tell one not to update member variables (obscurity) for the onConpute to handle but it was unreliable.  I'll have to give some credit to user common sense (ahahahaahha)

My hot take is that if the user is allowed to do something like add the same CIQ data field multiple times, then they can't be blamed for doing so, especially if the action is not a bug or quirk in the system.

Iow, if your data field is added multiple times by a user, and it behaves in some way that the user doesn't expect, respectfully speaking, it's not their fault if the data field acts in some way that looks wrong to them. I wouldn't characterize any reaction from the user in this case as a failure of common sense.

In general, if some app works unexpectedly in some edge case that's rare, yet "legal", that's not the user's fault. If they don't understand why it's working unexpectedly, it's not a failure of common sense.

Respectfully, I think it's up to us as app devs to either:

- somehow prevent said edge cases (not possible here)

or

- address the edge cases as best as we can

As others have implied and as the CIQ team has explicitly noted, this is exactly why we are not supposed to calculations in onUpdate - that's what compute() is for.

Seems like you're trying to jam a square peg into a round hole and implying that the user is wrong if they notice that it's not quite working.

I don't think you explained exactly how or why your web request is supposed to be different for each instance of the data field, but it sounds kind of fragile.

crispgarmin said:

i could initialise the web request in onUpdate and not onCompute but I’d not know which request of multiple came back for which dc layout

Do you have control over the server? Can you add context to the request which will be returned in the response?

Why is it better if you make the request in onCompute vs onUpdate?

Sorry that I'm obviously missing a bunch of things here.

It's easy: you send the dc size and obscurity flag to the server? Send them back in the response, and cache the response in a map indexed by the DC size and obscurity flag (I just make a number of them: 10000 * width + 10 * height + obscurityFlag), then each field in it's onUpdate can use the relevant values from the cache