Is there a better way to obtain the actual device name?

I think I can build the string files and folders from devices.xml and a batch script, then use monkey.jungle to hide the excrescence of files from my project and share it accordingly. 

Horrid, but might work. 

Ok, the monkey.jungle might be worse than the unpleasantness of files.

A question from elsewhere, can we rely on the part numbers in devices.xml being:

a) complete?

b) up to date?

c) accurate?

I think you said somewhere about the auto-migration that new APAC could be added between SDK releases. I presume they all have different part numbers and so, also presumably, are not in devices.xml until the SDK is updated?

Where is "elsewhere"?

To answer your question, I just got an email today about a new device, so what's in 3.1.8 is no longer complete or up to date.

"Elsewhere" is in a separate directory so that I don't need to scroll down pages of crud to find source!

9635560 said:

I think I can build the string files and folders from devices.xml and a batch script, then use monkey.jungle to hide the excrescence of files from my project and share it accordingly. 

This seems like a painful bit of ongoing maintenance.

You suggest we shouldn't ask why, but it seems pretty relevant. Why would you need to retrieve the device *name* on the device?

If you *really* do have to have the device name, do you need it immediately on device, or would it be okay to fetch it at a later time? You could pretty easily create web service that looks up a part number and returns the device name from devices.xml. Then the maintenance doesn't require re-building the app at every release so you can have up-to-date device names.

Otherwise your options are limited. If you don't need to support devices that are older than ConnectIQ 2.3.0, you could use a JSON resource file that maps the supported part numbers to device names. I'm guessing this will take a decent hunk of memory, so it isn't a great option. If you need to cut the memory usage down, you could split the JSON file up by putting devices with part numbers 006-B1XXX-00 into one file, and 006-B2XXX-00 into another...

If you have to support older devices, then the only remaining option is to use a String resource or to hard-code the device lookup in the app source.

Travis.ConnectIQ said:

You suggest we shouldn't ask why, but it seems pretty relevant.

There is a third-party web-service I need to tie into. They log stats by device.

Travis.ConnectIQ said:

You could pretty easily create web service that looks up a part number and returns the device name from devices.xml

Well, they could, and I have certainly suggested that as a possibility, but...

jim_m_58 said:

To answer your question, I just got an email today about a new device, so what's in 3.1.8 is no longer complete or up to date.

... we have no guarantees that what is in devices.xml is either complete or accurate.

Admittedly, the numbers of extremely new devices whose part numbers aren't in the current devices.xml is likely to be small, but there, I have to fall back on this is a third-party service whom I can only influence by making suggestions and hoping!

9635560 said:

There is a third-party web-service I need to tie into. They log stats by device.

Can't they track by part number?  That seems the logical way to do it, and then that webservice can maintain the translation.

As far as 

9635560 said:

Admittedly, the numbers of extremely new devices whose part numbers aren't in the current devices.xml is likely to be small

You're new.  It will be very common.  You can safely say that new devices are in the works all the time, and the SDK can get out of sync.

That's another reason for auto-migration.

Is this the k-pay stuff? Is that "elsewhere"?

if you are sending this data to a 3rd party site, you may want to also check on the GDPR stuff and the privacy policy in the store.  Collecting the device type would be considered "user data".

Privacy Policy

If your app collects user data, you must provide a link to your app’s privacy policy.