Is there any boiler plate code to creating a 4 fields B layout for the Fenix 7?

FlowState said:

I seem to recall a post which mentioned that obscurity flags can't distinguish between all possible field placements.

Correct, if you have a 7 field layout you may have two obscurity 1 and obscurity 4 fields. But there are ways of handling (such as static variables in your custom classes) that if you’re deciding what to show. in the field. You can either duplicate what’s in the field with same obscurity or show something different.  I have some data fields that rotate the value and label shown every few seconds or so.  

I think with layouts many of us get stuck down a rabbit hole sometimes with the layout mechanisms we first come up with.  Such as your compact layout parameter approach. Great for memory, rubbish for maintenance.  I think if I took my approach and translated the layout definitions into jsonData with a custom class to do what text area does, it would likely combine the low maintenance of my approach with low memory overhead of your approach.  An idea I might explore when I get some time between projects.

Ultra said:

Yes it’s possible, because you’re using 1 datafield in all 4 positions. The datafield decides what it is drawing  based on where it is in the layout. It absolutely is possible to do the above in a 4B layout with a single datafield.

That's true. I did qualify my statement to say that it isn't possible if you want to have 4 independently running instances of the same data field app (with their own independent settings and memory), but I absolutely realize that's not what you meant.

As I mentioned, I'm a bit curious why more devs haven't adopted this solution (it has come up in the past.) Usually when a CIQ data field app implements/supports a multiple field layout, the user is asked to select a single field layout and the app draws all the fields itself.

I'm curious how this actually works though.

1) I assume that there's only one running instance of the data field app. (If this assumption is incorrect and there's actually 4 instances, I would be shocked, since that would be an easy way of getting around the 2 app limit.)

2) I assume onLayout gets called 4 times (once for each position the app is added to the layout.)

My questions are:

3) Does onUpdate() actually get called 4 times per second?

4) If the answer to 3) is yes, how do you correlate the call to onUpdate() with the appropriate layout position? If the answer is no, how do you display different information for the fields?

EDIT nvm, I re-read your posts and I see that you handle everything by setting the appropriate layout in onLayout. derp

I guess onUpdate() is called 4 times per second then?

Ultra said:

I think with layouts many of us get stuck down a rabbit hole sometimes with the layout mechanisms we first come up with.  Such as your compact layout parameter approach. Great for memory, rubbish for maintenance.  

Yes I agree it's terrible for maintenance, to the point where I would never share the code as-is, and it's also a huge pain to add support for new devices with new screen dimensions.

However, my solution also allows for 6 field layouts on devices which don't support 6 fields natively, for example.

In a perfect world I would auto-generate the code from something that's a bit more maintainable.

It looks like different people are "communicating" in this thread about different things.

As for the original question: it looks like all you need is to create your datafield that displays ONLY your custom data, then chose the layout you like, add your custom data DF to the position you like, and add the rest of the built-in fields you mention in the question to where you like to see them 

As for another topic that some commenters touched: if you want to build a FULL screen datafield with layout mimicking one of the official layouts of your device, there are 2 wats you can do that:

1. You can find the official Garmin device style documentation that has a nice picture of each layout with the dimensions of each field

2. If you're interested to generate this for multiple devices you'd like to support it is easier IMHO to generate the layouts (either as layout.xml-s or some constants that are used to programmatically draw the screen) then you can write a script in the language you prefer to parse the simulator.json file in the device directories in the SDK. In the json you'll find all the existing layouts with the dimensions and position of the fields.

As for detecting in which position your datafield is positioned in a layout, and which layout that can be... This is tricky. I have a python script that parses the above mentioned json and generates monkey c code that uses some of the information and as a "side effect' prints if any of the devices has a layout that has a field that would have the same dimension and obscurity flags (the only useful information a DF is able to query as far as I know) as any other fields of any other layout of the same device and thus they "collide" - meaning that if a DF detects that dimension and obscurity flags út wouldn't be able to tell in which of the 2 possible field positions / layouts it actually is placed.

An easy and sad example: any if the rectangular devices will have all the fields with the same obscurity flags, thus the only way to guess is from the field dimension, which in cycling computers almost gives you no information.

However in case of round devices the situation is much better. There are only a handful of layouts on a handful of devices that have fields that can't be differentiated. So in theory one could try to use this to differentiate the fields (for example in theory it would be possible on most of the round devices layouts to add your DF to any spot on the layout and display the label or sequence number of the field on the given layout and in many cases even know which layout it is.

However I think that while one could make an interesting example DF to demonstrate the above I would not use it in a 'production' DF.

If someone is interested the you can try this script here:

github.com/.../monkey-generator

I created a demo datafield. You can install it on any device (preferably with round display, if you want to see it really in action)

https://forums.garmin.com/developer/connect-iq/f/showcase/359783/datafield-df-detector