Number of devices in export greater than number of devices in manifest.

TL;DR I don't object to criticizing anything about Garmin, I object to this inexplicable obsession with finding the device ID or equivalent data inside of simulator.json, because it just isn't necessary.

Alan.raceQs said:

Please understand that I wasn't criticizing the design of Garmin's simulator.json. I recognize it's not intended as a developer tool and is appropriately placed within each device's directory.

I was simply investigating the possibility of using the image filename as a deviceID substitute, and I've since verified its reliability in the current iteration of the file

Right, I'm just saying that I disagree that any of this should be a problem ("challenge"). I don't care if you criticize Garmin's design, I just disagree that the design itself presents any kind of meaningful roadblock to accomplishing what you're seemingly trying to do. And I disagree that it would make sense for all the files in each device directory to have the device id in them. Indeed, as some of them are binaries (svg and png), they *can't* all have the id in them.

Again:

- the device directory name is literally the same as the device id

- compiler.json (with the device ID) is right there next to simulator.json

Example of very two simple approaches to slurping the data which allows you to write compiler.json and simulator.json info to separate arrays of objects (if that's indeed what you want to do):

Approach 1:

- For each device directory d:

-- open compiler.json

-- write information that you care about to some compiler-specific object, including deviceId (from compiler.json)

-- open simulator.json

-- write information that you care about to some simulator-specific object

-- also write deviceId: {d} to the simulator-specific object

Approach 2:

- For each device directory:

-- open compiler.json

-- write information that you care about to some compiler-specific object, including deviceId (from compiler.json)

-- save deviceId from compiler.json to a temporary variable d

-- open simulator.json

-- write information that you care about to some simulator-specific object

-- also write deviceId: {d} to the simulator-specific object

"I'm currently facing a challenge with simulator.json. Unlike compiler.json, it lacks the deviceID, making it difficult to identify devices when slurping them into an array of objects."

This shouldn't be a "challenge" or "difficult" unless you are stubbornly and unnecessarily married to one specific problem-solving approach which doesn't happen to fit the data as it exists.

"The closest identifier I've found is the image filename ("image": "fenix7.png"), which seems a bit dodgy."

There's no need to use the image filename and I happen to think this is the worst possible approach, but you do you.

I'm genuinely trying to help, but you're not listening. Honestly, this happens almost every time. I guess it's my fault for not learning from experience.

Alan.raceQs said:

I was simply investigating the possibility of using the image filename as a deviceID substitute, and I've since verified its reliability in the current iteration of the file

Well, as with several things in the original post, this is just plain wrong. Here's several examples which break the rule you've imagined.

I can already anticipate your response:

"That's ok, I don't plan on supporting those devices."

This response would miss the point completely, of course.

To be clear, the point is:

- deviceId in compiler.json is 100% certain to be the device ID, and can be correlated with any of the files in the same directory. In other words, you can read the deviceId from compiler.json and be sure that all the files in the same directory pertain to the same device ID

- the directory name is almost 100% certain to be the device ID

- the image filename has been demonstrated to not always be the same as the device ID, and therefore has 0 utility in determining the device ID. Furthermore it's not necessary at all since you have two other ways of determining the device ID above. Even if the image filename was currently the same as the device ID in all cases, why would you assume this would be true in the future?

So again, instead of sticking with the current broken problem-solving approach and grasping at solutions which would allow you to cling to that approach (except those solutions don't work either), simply change your approach to work with the data that you have.

Here's a simple script which might help you get started:

- for each device directory, combines compiler.json and simulator.json into a temporary json file (by combining the top-level keys)

- slurps all the temporary json files into an array of objects and saves that as a single file (devices.json)

Note that:

- each object in the array corresponds to a single device

- each object has all the information from compiler.json, including deviceId

- each object has all the information from simulator.json

Copy this script to ConnectIQ/Devices, give it executable permissions, and run it

https://pastebin.com/Rsf10rBp

Alan.raceQs said:

I encountered an unexpected result in my latest release: the build generated output for 166 devices, despite my manifest specifying only 90. Curious, I delved into the reason behind this discrepancy.

This might be well-known to experienced developers, but it was a new and interesting discovery for me, and I wanted to share my results.

Also, none of this should be a surprise to you.

- You have been here (in the dev forums) for at least 8 years (hardly a noob dev), and you have an app in the store that was released in 2019

- It was already explained to you that devices have multiple part numbers:

https://forums.garmin.com/developer/connect-iq/f/discussion/162892/missing-device-part-numbers