datafield: DF Detector

# DF Detector

This datafield is an example for CIQ developers to demonstrate how a datafield can be added multiple times to a layout.

## Description

This datafield is an example for CIQ developers to demonstrate how a datafield can be added to multiple fields in a layout and sometimes be identified. It uses the width, height, obscurityFlags. When you place it to a position that "translates" to a single possibility per layout (3C.2 or 4.2|6.3 or even 5.1|6.1|6.3 on layout 5) then you could use the settings to configure what to display in those "good" positions.

Add this datafield to any activity, multiple times. As you add it to multiple fields (places in the layout) you'll see the detected layout, field position.

If you like the app you can thank me by sending a beer: https://paypal.me/GavrielF or buymeacoffee.com/flocsy or at least write a positive review with 5 stars StarStarStarStarStar.


## Legend

- [0] | green | field+ layout+ | 3C.2 | exact field and layout detected
- [1] | aqua | field+ layout- | 4.2|6.3 | field identified inside the layout (it is alone) but could be in multiple layouts
- [2] | pink | field? layout- | 5.1|6.1|6.3 | in some layout(s) field can be identified (5.1) but in some layout(s) the field is unknown (6.1 or 6.3) (matches multiple fields in the same layout)
- [3] | red | field- layout? | 6.1|6.2 | unknown field, there are multiple matching fields in each layout
- [4] | black | unknown hash! | unknown | unknown field hash (need to add the device or fix the dimensions of the field in the source code)
NOTE: if you see [4] black background with "unknown" label then please take a screenshot and send it to the Support Forum indicating the device you have.
Unknown field hash means that there is a bug in the SDK's simulator.json and Garmin need to fix it.

- layout names: 1, 2, 3A, 3B
- field names: layout.position: 1.0, 2.0, 2.1, 3A.2. i.e: 4C.2 means: the 2nd field in the "4 Fields C" layout. Fields are 0 indexed.

'+' means: known, detected, identified (i.e: field+ 1.0 - layout 1, field 0)
'-' means: unknown, can't be distinguished (i.e: layout-: 4.2|6.3 - either layout 4 or 6)
'?' means: depending on the context (field vs layout) can be known or unknown.
i.e: field? 5.1|6.1|6.3 means in some layouts it's identified (5.1) but in others it can be more than one field (6.1 or 6.3)

obscurity flags: 'b': bottom, 'r': right, 't': top, 'l': left. i.e: 260x129@rtl means the field size is 260x129 and it's obscured on 3 sides: right, top and left


## Screenshots

  • I downloaded the datafield to my Edge1040.

    Ok, DATAFIELD_HASH_2_FIELD_NAME seems to be null because EDGE1040 is not listet under source_devices. (and on EDGE there are of course no obscurities...)

    I will dig deeper into the code to see, why there is no fieldIdx displayed.

    Anyway - thanks for the datafield and its code!

  • no obscurity on square/rectangle devices, so the same thing will probably be the case on the Venu sq and Venu 2 sq.

  • Thinking about this theme:

    It would be great, if we could find out, which given datafield coordinate corresponds to which screen coordinate. Then it would be easy to handle multiple datafields of the same app.
    But I think, such an information is not available (yet).

  • This is kind of intended for rectangle devices, but you're right that I can improve this by having a different message like "unsupported" or "rectangle" to differentiate this from when a certain layout is missing from simulator.json like here: forums.garmin.com/.../bug-some-layouts-are-missing-from-simulator-json-for-fr965

    I removed fieldIdx because it makes no sense in real devices, the numbers were jumping to as high as 40-50 and changing all the time. It's not ideal but this is documented so that's what it is:

    // Note that compute() and onUpdate() are asynchronous, and there is no
    // guarantee that compute() will be called before onUpdate().
  • It has never been available, and I doubt it will be.  What people do is offer is clones of their DF can then can show different things on the same screen, and different things in different activities.

  • 1. if IS available for positions where you see white background. In those places we recognize both the field inside the layout and the layout. In these places you'll see the label like "4B:2" This means that looking into the simulator.json you can also know the position of the field.

    2. You already can add the same DF to multiple positions. This example is exactly to demonstate that :) I agree it's not ideal, but for fields that are white or even grey it works. You could create an DF where in the settings you set what data to display in which field. For example your DF has HR and MaxHR. You could configure it so that in 4F:1 it displays the HR and in 4F:2 it displays the Max HR. The only problem is that it's not very intuitive how to recognize (name) the positions. But it could work either by displaying the "id" like now it displays the label. It could work similar to when you connect multiple monitors to a computer and then in the display settings it shows which monitor is called "1" and which is "2". Even if it's "the other way around" as "2" is on the left side and "1" is on the right. But still it's a perfect identification.

    So there can be different ways to do this. The problem is that even if I would auto-generate the settings for each device so it has the correct labels that can appear in that device it would make no sense or it would make it a too long list. So what I would try is something like this. Create a dictionary in the view and put some data in there. Something like:

    var hash2config as Dictionary<Number, Dictionary<String, String>>;

    in onUpdate you get the hash for the current field, and if it's found in hash2config, then use it, if not then create and add it. Inside you could have your own dataformat instead of the inner Dictionary, and there you could have things like:
    id or name (could be just an index (but notfieldIdx!!!) that every time you add a new value to hash2config would be incremeted. This id could be displayed on the device in the label, and in the settings you would be able to configure what you wanted to see there.

    So let's say you added the DF in 2 places: first: 3B:2 and then: 3B:0 and in hash2config you'll have something like:
    {
       26008707 /*260x87@lrt:0 3B:0*/ => {"id":2, ...},
       26008713 /*260x87@blr:0 3B:2*/ => {"id":1, ...}
    }

    In the settings you could have something like:
    field #1: dropdown to chose from the possible values: [HR, Max HR, Min HR]
    field #2: dropdown to chose from the possible values: [HR, Max HR, Min HR]
    ...
    field #8: ...

    Note that there are some problematic layouts. For example in fenix6 there are these:

    12906401 /*129x64@l:2*/ => "5:2|6:1|6:3"

    This is OK if you are on layout "5 Fields", but you can't use it if it's on "6 Fields" because then you won't be able to differentiate between position 1 and 3. That's the reason that these 3 places are colored orange (it should be red for "6 Fields" and white for "5 Fields", but since we can't recognize the layout we can't decide)
  • Actually I just checked some of the edge devices (all are rectangle) and there are some fields that can be recognized, so I'll generate the hashes for them as well. The only backside is that some will have instead of "rectangle" a label like "6:4|6:5|7:3|7:4|7:5|7:6|8:2|8:3|8:4|8:5|8:6|8:7|9:1|9:2|9:3|9:4|9:5|9:6|9:7|9:8|10:2|10:3|10:4|10:5|10:6|10:7|10:8|10:9"

  • Neat. But if only you could reliably detect if the DF is the 1st, 2nd etc added to the same activity, it could be more useful.

  • Looks like you missed the point. The goal was to demonstrate that depending on the display shape, the layout and the field position inside the layout it might or might not be possible to detect it's position. It is not up to me or my code, this is what can be deduced based on the data available from CIQ. If this DF can't differentiate between 2 field positions, then currently it's impossible.