One of the design goals for the Visual Studio App Center SDK is to simplify things for developers, making it easy for them to use App Center in their mobile (and desktop) apps. Because of this, the SDK does a lot of work for developers, especially at startup whenever the app lets the SDK know which App Center services are in play. 

When the SDK starts up and the app registers the App Center services it wants to use the SDK automatically initializes each service in the app, but also initializes the service on the App Center backend as well. In general, this means sending information about the app and device to App Center for processing – whatever that may be. 

When we added support for setting user identity (either using the App Center Auth service or the App Center SDK), this creates some potential complications for developers to consider as they build their apps. 

No matter how your app sets user identity, it’s possible for the app to be in multiple states as far as App Center is concerned. For example, assuming you’re using the App Center Analytics, Diagnostics, and Push services in your app – before you identify the app user (using the Auth service or set using the App Center SDK), the following happens: 

• The app sends analytics data to App Center for processing 
• If the app crashes, the SDK sends diagnostics data to App Center for processing 
• The SDK registers the device to receive notifications (first it gets a push token from the platform notification service, then sends it to App Center so it can send to the device later) 

This data sits in App Center without being associated with any user. 

When an app user logs into the app or logs into the app’s backend and the app sets the user identity through the App Center SDK, App Center ensures that all future data sent to App Center is now associated with the provided user identity. 

At this point, there are two sets of data in App Center, the early, anonymous data, and the data associated with user. 

Now, when you’re using App Center Push, and an app is shared by multiple users on the same device (shared devices) things can get a little wonky. 

When the app launches with Push enabled, the SDK registers the device for Push or refreshes an existing device registration. When the user logs into the app, App Center updates the device registration to associate the user with the device. When a different user uses the same device, any push notifications sent to the previous user will be sent to that device until sometime after the new user logs into the app on the device. When the new user logs in, the SDK updates the device registration with the new user identity. Since it may take a little bit of time for the backend update to complete, there may be some overlap after the new user logs in. 

To mitigate potential issues related to this: 

• Never send confidential information to a user using any push notification service. Architect your app so it sends a simple notification to the app/device/user letting the app know there’s new data. When the app reads the notification, it uses existing logic in the app to connect to the backend server and request the updated data. If the data is associated with a specific user, force the user to login to access the data. With this approach and the appropriate access control mechanisms in place, users can’t see another user’s notification data. 

• Ensure shared device app users know to logout of the application when they’re finished with the device. Or, even better, automatically log users out of the app when they’ve been inactive for some time. 

As you can see, the user identity capabilities of App Center enhance how you interact with your app users and allow you to more easily troubleshoot issues when they arise (by targeting data for the specific user). We’ll continue to add capabilities to App Center to enhance what you can do for your app users, if you have suggestions for future features, be sure to give them to us through the App Center GitHub repository.