Sunday, February 3, 2013

Why do Windows Phone Apps for SharePoint need access to Location Services?

I recently did some programming with the SharePoint SDK for Windows Phone. (See my last post for details on how to set up your development environment.) When running the Store Test Kit I noticed that my app needed the Location Capability (ID_CAP_LOCATION).


This was strange and I decided to investigate.

Windows Phone App Certification Requirements when using Location Services

Why do I even care? Two reasons:
  1. It might push away users if they get the feeling my app wants to spy on them.
  2. Apps using Location Services have to follow certain rules. If they don't they can't enter the Store.
When an app uses the user's location you have to include or link to a privacy policy in your app explaining how you are going to use the collected data. You can find the certification requirements over here. Reading them carefully can save you some time as I had to learn the hard way.

Fair enough, but I wasn't using any actual location data. Apart from that the requirement leaves some room for interpretation (emphasis mine):
§2.7 The following requirements apply to apps that receive the location of a user's mobile device
What if I am using location-related classes but never use them? I have the feeling nobody won't care about that. So I decided to include a privacy policy (as demanded by §2.7.2) to be sure:
§2.7.2 The privacy policy of your app must inform users about how location data from the Location Service API is used and disclosed and the controls that users have over the use and sharing of location data. This can be hosted within or directly linked from the app. The privacy policy must be accessible from your app at any time.

How does Capability Detection by the Store Test Kit work?

Open the Store Test Kit via Project context menu.

Why does my app suddenly uses Location Services? How does the Store Test Kit determine that my app has to include the capability ID_CAP_LOCATION?

You can look up what APIs require which app capability in Rules.xml, a file included in the Windows Phone SDK. On my machine it can be found in C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Tools\Marketplace.

Here is the relevant part of Rules.xml showing what needs ID_CAP_LOCATION:


<Capability ID="ID_CAP_LOCATION" Type="Security">
 <Assembly Name="System.Device, Version=2.0.5.0, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e">
  <Namespace Name="System.Device.Location">
   <Class Name="GeoCoordinateWatcher" />
   <Class Name="GeoPosition" />
   <Class Name="GeoPositionChangedEventArgs" />
   <Class Name="GeoPositionStatusChangedEventArgs" />
  </Namespace>
 </Assembly>
 
 <Assembly Name="Microsoft.Phone, Version=7.0.0.0, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e">
  <Namespace Name="Microsoft.Phone.Controls">
     <Class Name="WebBrowser">
      <Method Name="set_IsGeolocationEnabled"/>
     </Class>
  </Namespace>
   </Assembly>
</Capability>

Why does the SharePoint SDK for Windows Phone use Location Services?

To determine where the SharePoint SDK uses location-related functionality I had a look into the assemblies included in the SDK - and found something in Microsoft.SharePoint.Phone.Application.

Normally I use ILSpy to look at the implementation of framework assemblies, but ILSpy unfortunately doesn't support full text search as of this writing. So I tried the free JustDecompile by Telerik and this worked nicely.

Searching for GeoCoordinateWatcher lead to the class ModifyItemViewModelBase.


It seems like location services are used in relation with the Geolocation field type which is new to SharePoint 2013. A method named OnGeolocationStatusChanged creates instances of GeolocationFieldViewModel which in turn stores geo coordinates.

I could not find where OnGeolocationStatusChanged is used in any of the SDK assemblies. It's public and virtual so maybe it's just there to use for us. Seems the documentation is a bit scarce here as well.

What does this mean for me as app developer using the SharePoint SDK?

Seems like I have to accept the fact that access to location services is baked into the SharePoint SDK libraries. And that I have to explain this to the wary folks visiting my app in the Store.