need a better uniqueIdentifier value

The serialnumber is not exposed as that could be user identifiable info and will not be exposed under GDPR.

I'm afraid you will need to build something for yourself:

- DeviceSettings.partnumber will give you a unique string per device (see devices.xml for the lookup to see which partnr matches which device)

- In the app settings you could provide two string values (email and password for instance). email could be the user's paypal email address and password could be a value that you send out based on the user's paypal address + the device the user uses.

Be sure to create a privacy policy in which you explain on how you're processing and potentially storing info (for gdpr compliance you might also need to foresee a service where the user can delete him from your database)

yeah, i'm looking at the data under User Profile and grabbing some of that data and hashing it.  of course that's even more along the lines of user identifiable.  i'm thinking serial # + developer ID might be the best solution (found an old post where uniqueidentifer is serial # + developer ID + app ID), but i'm guessing i'm an edge case so probably won't be a top priority for the garmin folks.

It seems very unlikely that we'd provide something beyond the uniqueIdentifier value that is already there. 

yeah, i kinda figured.  i can see use cases for both ways, but i figured what i was looking for was an edge case.  i modified my second app to use the email address which i already have in my license structure.  it just requires a bit of friction on the users end to input it.  

My approach to this is to retrieve a UUID from my web service and save in Storage on the app's initial startup. I use the PHP md5 function.

<?php
 header('Content-Type: application/json');
 		$settings = new stdClass();
		$settings->GUID = md5(mt_rand());
		print json_encode($settings);
?>

No user interaction required.

On larger systems, I have used the BlueTooth MAC address but even that is hidden from us. (Privacy gone mad!)

That gets the client a unique identifier, but that isn't sufficient to solve the problem. He still needs to identify that unique identifier as belonging to a licensed user. At some point it seems the user has to do something to establish this link.

That said, I'm not sure I understand what benefit the above code has over just letting the client app send the uniqueIdentifier value to the server. It actually seems worse since the value that you're using could get lost if the device needs to be wiped/reset, whereas the uniqueIdentifier will remain the same for the same device/app/developer.

Yes, you're right, it solves a diffrent poblem.

i guess Former Member has to provide the same login process for the second app as he has for the first as I don't think there's a way for an app to share data wth another app on a watch.

Hi Scott, I discovered this old post.

How did you solve this issue?

Thanks, Stefano

BTW: App Wind Field is GREAT!

thanks! and sorry for the late response, was off doing the Enve Grodeo and just got back home.  

all of my apps connect to my webserver, so windfield takes the UUID, generates a much shorter code from that which i use for registration.  after that, i then have your email in my database

secondary apps (i now have 5?  6?) are then registered on my site via the email address.  I just make sure you are a subscriber and then those apps get activated.

i share data across apps the same way.   first app connects, i store the data for when the next app requests it.