locked
Universal apps, shared settings and user identification on both platforms at the same time RRS feed

  • Question

  • Currently we are porting our web-based application to a portable app using C#, XAML and the managed Azure Mobile Services. Everything is fine so far except for the following glitches we detected during development:

    1. There is no unique identifier available that would allow us to pin-point a user based on the installation of either the Windows Phone 8.1 app or the Windows 8.1 app. To get only the user-name of we need to enable enterprise capabilities, which we really don't need in our app.
    2. The roamed settings between Windows Phone 8.1 and Windows 8.1 are only updated on the Windows 8.1 side. If we delete roamed settings on the Windows 8.1 side, the installed app on Windows Phone 8.1 (even after an app re-start) is not able to recognize the changes. The settings seem to be unchanged. We tried that with the Windows Phone 8.1 app installed on a device with a valid MS-Account and installed on the emulator with the same Microsoft account.

    This is what we could observe so far. Here the main questions: How can we identify a universal app user on both platforms with a unique id only valid for a specific user, without generating a GUID or similar that will be lost and could be tampered and without the need to save it to isolated storage or within app-settings?

    How can we ensure a reliable sync of roamed settings between the two apps within the same app-family?

    Thursday, May 22, 2014 5:05 PM

Answers

  • Hi Rob - that's exactly what we are doing and I am talking aboutusecase. I need to cover the case to sync data between Win8.1 and WP8.1, even when the user is using two separate social providers (that's only one use-case). Here is what I will implement now. It's a scribble but maybe that can show much better what I am going to do.

    Ilija

    Saturday, May 24, 2014 1:47 AM

All replies

  • 1) Normally you'd have the user log in to the Mobile Service and can then identify the user by those credentials. See Tutorial: Get started with authentication and Tutorial: Authenticate with Live Connect single sign-on . Anything else can be spoofed at some level.

    2) The settings should roam correctly, but it won't be immediate and roaming can be disabled by the user. Make sure it's enabled, that the apps have the same Package Family name. See How to roam data between a Windows Store app and a Windows Phone Store app . Often you'll use a different name for the beta version of your Windows Phone app, and that won't be part of the same roaming system.

    --Rob

    Thursday, May 22, 2014 11:13 PM
    Moderator
  • Thank you for your answers Rob.

    1) We are familiar with Live Connect Authentication 

    2) We did that already

    Both apps have the same package-family name, all of that is already setup and working. Sorry that I did not point that out earlier.

    I assume that we have to provide a code to the users of our universal app, to truly sync data between those two apps (independent of roaming user-settings) for each and every user. Why? Because users today want to choose their favorite social-login provider like Twitter, FB etc. . And this is where all of this becomes tricky with a lot of overhead on the backend.

    If there was a possibility (at least for universal apps, or apps within the same package-family) to generate a unique-id per user, which would not solve all of the possible scenarios,  but would be really helpful, instead of binding to the users hardware-based ASWHID that is different on Windows Phone 8.1 and Windows 8.1 (which it has to be, because it depends on the users hardware settings). And the ASWHID requires also a lot of work on the backend to track changes within the users hardware-configuration. Good for hardware-based licensing, but not more.

    A third possibility would be to have the power to implement your own roaming-backplane to save and update the roaming settings, within the bounds of the system.

    Ilija

    Friday, May 23, 2014 12:30 AM
  • Because users today want to choose their favorite social-login provider like Twitter, FB etc.

    This sounds like a perfect use case to authorize on the Azure Mobile Service. You can fairly easily hook it up to a variety of social login providers and let the user choose.

    --Rob

    Saturday, May 24, 2014 1:05 AM
    Moderator
  • Hi Rob - that's exactly what we are doing and I am talking aboutusecase. I need to cover the case to sync data between Win8.1 and WP8.1, even when the user is using two separate social providers (that's only one use-case). Here is what I will implement now. It's a scribble but maybe that can show much better what I am going to do.

    Ilija

    Saturday, May 24, 2014 1:47 AM