I'd like to use UserExtendedProperties.GetValue to associate a user with a high score table in a game I'm working on. Reading Microsoft's own API description I cannot work out whether this applies to a user (blah#live.com) or a physical device. Does anyone know?
Chris
UserExtendedProperties.GetValue("ANID") is an anonymous ID based on the user's Live ID. So, the same Live ID logged in from multiple WP7 devices will have the same ANID.
Related
I have implemented a login feature in my app where a user can pay for subscription and have that subscription tied to their in-app login account by using the setObfuscatedAccoundId() method. However, in a scenario where the current user(user_A) makes a purchase, logs out of the app and a different user_B logs in, user_B is unable to purchase the same subscription as it has already been bought by user_A (as they share the same underlying Google Play account) even though I DON'T want these in-app accounts to be related at all. Currently, what happens is user_B gets a responses that states "You already own this item". So that makes me wonder:
Can we actually possibly use a single/the same underlying Play Store account to purchase the same subscription while logging in to an app with different user accounts?
Also, what would be an ideal design approach for a problem like this considering the limitation?
I am still a beginner at this and would really appreciate your inputs!
I'm beginner at this like you and may I was wrong but I think you can not do that because the subscriptions are saved in your google account and you can not buy same subscription you owned already.
As per Google Assistant documentation for Smart Home, the agentUserId used in action.devices.QUERY is defined to 'Reflects the unique (and immutable) user ID on the agent's platform. The string is opaque to Google, so if there's an immutable form vs a mutable form on the agent side, use the immutable form (e.g. an account number rather than email)'
However there can be cases where the same device (with same agent user id) is attached to multiple Google Assistant accounts and in such cases a DISCONNECT request may result is ceasing report state for all accounts. The solution will be to add some unique ID corresponding to the Google Assistant account, however such information is not available in any request.
Has anyone seen similar issue and is my understanding incorrect?
The agentUserId is meant to be the user account on the smart home platform. SHP user '1234' may have a vacuum and two lights, but could be linked to multiple Google accounts.
During the account linking process, you would be expected to give a refresh and access tokens to allow for Google to have authorized control over these devices. If you assign unique access tokens for each Google account that signs in, you'd be able to determine which Google account the request is coming from.
At that point, once the user disconnects, you can use the access token in the request header to associate that with a specific Google account and only disable reporting for that account while not affecting other accounts.
So, yes the solution is to have a unique ID connecting to the account. While this is not passed in the agent ID, there is already a mechanism to make this association through the authorization system.
Alternatively, you could append a key in the agentUserId, ie. '1234-user#gmail.com'. However, this may have unintended impacts in the Home Graph. In a multi-user home, you may end up seeing the devices duplicated because Google doesn't have the right information to deduplicate.
I have a problem with getting User ID but I mean programmatically. Is any chance to get User's Live ID or something like that ? Because I want use trial experience with expiration time but is only one way how to do this. Storing all user's ID's and after installation check their identity. I don't want to use advertisement ID because it is not working in every case. Not every user is using this kind of ID.
So any ideas ?
You won't get any personal information without asking the user.
But the windows store features a trial mode with expiration. Check out the topic on MSDN.
Otherwise there is an overview on Idendity on Windows and you can use WebAuthenticationBroker on the Phone.
I was thinking of a way to some how connect my phone user base to my site user base. Right now if an item gets added to the site via the phone the userId is generic and the site displays it as SmartPhoneUser. I was thinking it might be cool to display the unique phone id by using the UserExtenedProperties, however, after reading Nick Harris's blog about it I'm thinking it may not be a good idea as I don't want users to think I'm up to anything nefarious.
So I'm wondering if there are any suggestions out there on how to accomplish this task. Right now my site uses the JanRain module that allows multiple logins from other sites (Facebook, Yahoo, Google etc.). I'm letting users log in to their own accounts and using the information from those sites to populate my user table. I'm not sure if WP7 has something similar I can use.
Any thoughts on how I can accomplish what I want to do without using the ExtendedProperties?
We can accomplish something similar by creating a unique guid/DateTimeStamp KEY the first time the app launches and stored it in Isolated storage.
Reusing the same KEY by reading it from Isolated Storage should work.
[N.B. : Anybody with other ideas please do suggest/comment/contribute. Tx.]
For storing WP7-app-data it would be great if it was possible to use the current users live account. Is this possible somehow? I guess not. The alternative is for me to setup my own server to store the data, which means I also will have to implement account-management and require the user to create a new login and password for my particular app/site. This is not very practical as the user already has a live account on the phone. A compromise would be if I could use the logged in live-account on the phone as some kind of token to validate that the logged in user is who he/she pretends to be, and then store the data on my website. Comments?
This is not possible for security reasons and I wouldn't expect it to change in the foreseeable future.
Allowing applications access to a users live account and be able to interact with content there would raise all sorts of possible issues, particularly around security.
On the phone the users data is sacrosanct and you (your app) cannot interact with it without the user knowing.