Looking for #WPDev opinions

October 2, 2014

In October, I’m interested in getting thoughts and opinions from the Windows platform development community in my ~annual pulse of the Windows developer community. This year’s survey focuses in on asking less about what you’re doing, and more on why you’re doing what you’re doing. This information will be used by my team to adjust where we spend our focus in the next 3-18 months.

To participate, head over and complete the survey here.

Every year, my team looks to gather information from our mobile developer community about what is working and what isn’t for you. We use this information in a few ways:

  1. Provides longitudinal progress and quantitative measurement (obvious item)
  2. Informs what is top of mind for developers, and where the team should spend our dev readiness and marketing dollars to provide additional guidance/code samples/etc
  3. Informs our conversations with engineering on what we need to try to solve in the platform

As part of my job, I do a lot of research, both at small scale (i.e., focus groups, call downs, design reviews, etc.) and at large scale (e.g., our VisionMobile partnership). This is one of those surveys that have a direct impact on what is built for you, and what comes out of Redmond starting next month (rather than engineering investments that can take many months/quarters to get out into the market).

Last year, we received almost 400 responses. If you can help us get over 500 responses, I can commit to publishing out a survey here by the end of the 2014.

Looking back at the Spring 2013 survey

Last year (2013), I ran a version of a survey in two places: first in one of our Spring 2013 newsletters (and via Twitter), as then as a survey sent out to Build 2013 attendees (I was recruiting for a few research groups we ran on-site).

The goal for the Spring 2013 survey was different than this month’s survey. The 2013 survey had a much stronger drive to asking questions around publication bridges and barriers, and personal drivers to why folks were building mobile apps. Most of this information was used to help inform some of our work that landed at Build 2014 (the keynote story, the Build floor, the //publish/ event structure, etc.). So if you participated in the 2014 survey – we appreciate your assistance in helping us craft our story! Smile I also learned a lot about how to better phrase and ask about development practices based on this survey.

One of the largest reasons I didn’t do a report out on this data was because there are a number of holes in the way I asked questions. I used this learning in a number of studies we ran last year…which is a long way of saying I know there are problems with some of the data groupings below (and here’s where I point out that my background is in computer science, and not in research). As you’ll notice as you take this month’s survey, it’s gotten a lot better. Smile


Looking at the devs responding, the responses primarily came from developers publishing into to the Store, but there were also a number of hobbyists and moonlighters building for the platform.

This also showed up in he monetization strategies used by those who have published up to the store – 48% of the responses showed no in-store monetization intended from the apps.


Returning to my point about key learnings since fielding this DIY survey, the ‘no monetization’ option is easy to misread. What is missing from this question is the reflection that a number of publishers don’t monetize their apps directly – the group that we refer to as ‘brand extenders’. For the brand extender, mobile is not their primary monetization channel (but it may be a important part). In surveys following this one, the ‘I don’t monetize my app in the store’ option has grown into a few different options.

And you also told us that you felt pretty strongly around the languages that you used – the majority of folks use (and love XAML + C#), with a smattering of WinJS usage. This has been an important data point that we’ve used to guide our readiness investments and tone over the past year.


As you can see above, there was definitely an HTML contingent, but the representation was much smaller than the .NET faithful. Similarly, I believe the .NET usage also played as a factor into why Windows Phone was selected as a platform, with many folks saying that the primary driver in selecting Windows Phone as a target platform tended to group around the docs and platform familiarity.


The platform selection piece jives pretty well with the developer segmentation work that VisionMobile published last year, and also tends to play into the strengths of the platform – after all, Microsoft has always been a developer-centric company – from tooling to docs, Microsoft has set the bar for dev productivity for some time. What was nice to see with this survey is the growth of the user segment citing revenue as a selection driver, as well as rising satisfaction levels with the revenue they are making on the platform.

Lastly, I had a few questions for those who hadn’t yet published into the Store yet; and while skill development was very strong with the survey responses, intent to monetize was much stronger this year than in the prior year. In prior years, data tended to weigh much stronger towards skill development and personal apps (not for publishing).


And unpublished developers reported that there weren’t many blockers for getting their apps into the store – most reported that the app is still in development and on the way. In the two prior years, the largest blocker tended to be not having a good idea or inability to run the emulator.



At any rate, I’m looking forward to hearing more from the community this month with the survey. As I’ve said on Twitter, feel free to be verbose. I read everything you send and share it up and around the group.

So…one last appeal…go fill it out! Smile

Best regards,

As I started working with SQLite as a place to store my data, I began thinking about my app’s changing data scheme and I wondered: ‘how do I handle change management in my local database?’ This blog entry outlines my approach to solving this issue, which basically boils down to tracking the data scheme version in the database and doing a wholesale drop and recreate when the schema changes.

Why drop and recreate?

For my app, I use SQLite for data caching of server-side information – providing performance and offline capabilities for the user. Prior to using SQLite, I had been using in-memory serialization to store the object collections in isolated storage, which had a number of performance issues (memory and CPU).

For non-cached user information (account information, preferences, etc.), I don’t use SQLite – I store those items in the isolated storage property bag. As I take my app to the Windows Runtime platform, I’ll bring this information into the roaming data area (for preference information) and credentials locker (for account information).

For the cached app data, I’m now storing this as a SQLite database. My issue is that each version sees continued improvement around the richness of the data (adding review information from a variety of sites, news entries, etc.) – which means scheme modifications. Many of the websites describing using SQLite talk about how to create the database, but leave it to the user to figure out database updates. I played around DDL tracking with complicated UPDATE scripts and decided this was taking way too long for basically volatile cache data…and I went with a simpler approach – ship the app with a current snapshot of the full cache (~7mb) and simply do a drop and recreate each time the schema changes.

Tracking Database schema state

To track the state of the database, I created a class called DBMetadata that I can use for a variety of things in my app, including the schema version (what we’re explaining here), and things like the last time I retrieved a particular dataset (to help balance data pulls that don’t need to be run every time the app runs). The class looks like the following:

public class DbMetadata {

  [PrimaryKey, AutoIncrement]
  public int Id { get; set; }

  public string SettingName { get; set; }

  public int SettingValueMajor { get; set; }

  public int SettingValueMinor { get; set; }

  public string SettingInt { get; set; }

  public string SettingString { get; set; }

  public DateTime SettingDateTime { get; set; }



To track the database schema version, I use constants in my LocalData class like the following:

const string DBMETA_SCHEMA_VERSION_NAME = "DbSchemaVersion";


With this code in place, I have the following two methods in my LocalData class to interact and check if the database is running the most current:

private async static Task<bool> ValidateIsLatestDbVersion() {

  try {

    int _table = await LocalData.DbConnection.ExecuteScalarAsync<Int32>("SELECT count(*) FROM sqlite_master WHERE type='table' AND name='Metadata';");

    if (_table == 0) return false; 

    if ((await LocalData.DbConnection.Table<DbMetadata>().Where(t => t.SettingName == DBMETA_SCHEMA_VERSION_NAME).CountAsync()) > 0) {
      var _ret = await LocalData.DbConnection.Table<DbMetadata>().Where(t => t.SettingName == DBMETA_SCHEMA_VERSION_NAME).FirstAsync();

      if (_ret != null && _ret.SettingValueMajor > DBMETA_SCHEMA_VERSION_MAJOR) {
        return true;
      } else if (_ret.SettingValueMajor == DBMETA_SCHEMA_VERSION_MAJOR && _ret.SettingValueMinor >= DBMETA_SCHEMA_VERSION_MINOR) {
        return true;
  } catch (Exception _e) {

  return false;

private async static Task<bool> MarkDbVersion() {

  try {
    if ((await LocalData.DbConnection.Table<DbMetadata>().Where(t => t.SettingName == DBMETA_SCHEMA_VERSION_NAME).CountAsync()) > 0) {
      var _ret = await LocalData.DbConnection.Table<DbMetadata>().Where(t => t.SettingName == DBMETA_SCHEMA_VERSION_NAME).FirstAsync();
      _ret.SettingValueMajor = DBMETA_SCHEMA_VERSION_MAJOR;
      _ret.SettingValueMinor = DBMETA_SCHEMA_VERSION_MINOR;
      await LocalData.DbConnection.UpdateAsync(_ret);
    } else {
      await LocalData.DbConnection.InsertAsync(new DbMetadata() { SettingName = DBMETA_SCHEMA_VERSION_NAME, SettingValueMajor = DBMETA_SCHEMA_VERSION_MAJOR, SettingValueMinor = DBMETA_SCHEMA_VERSION_MINOR });
    return true;
  } catch (Exception _e) {
    return false;


With the above in place, it’s pretty easy to now handle the check and drop, as needed.


So now with the plumbing in place, it’s time to put in place the business logic that does the database creation. I do this when I open the database for the first time in my Windows Phone app.

private async static Task OpenLegoDB() {

  string DBPATH = System.IO.Path.Combine(ApplicationData.Current.LocalFolder.Path, DBNAME_LEGO_SETS);
  try {
    await ApplicationData.Current.LocalFolder.GetFileAsync(DBNAME_LEGO_SETS);
    _legoDbConnection = new SQLiteAsyncConnection(DBPATH);

    //Check the schema version, and replace the database if it's an old one
    if (!await ValidateIsLatestDbVersion()) {
      _legoDbConnection = null;
      await LocalData.DeleteLegoDB();

  } catch (FileNotFoundException) {
  } catch (SQLiteException) {
    _legoDbConnection = null;
  if (_legoDbConnection == null) {
    await LocalData.CreateLegoDB();
    _legoDbConnection = new SQLiteAsyncConnection(DBPATH);

private async static Task DeleteLegoDB() {
  string DBPATH = System.IO.Path.Combine(ApplicationData.Current.LocalFolder.Path, DBNAME_LEGO_SETS);
  try {
    var _file = await ApplicationData.Current.LocalFolder.GetFileAsync(DBNAME_LEGO_SETS);

    await _file.DeleteAsync();
  } catch (FileNotFoundException) {


private async static Task CreateLegoDB() {
  try {

    string DBPATH = System.IO.Path.Combine(ApplicationData.Current.LocalFolder.Path, DBNAME_LEGO_SETS);

    _legoDbConnection = new SQLiteAsyncConnection(DBPATH);
    await _legoDbConnection.CreateTableAsync<LegoTheme>();
    await _legoDbConnection.CreateTableAsync<LegoSubtheme>();
    await _legoDbConnection.CreateTableAsync<LegoSet>();

    await _legoDbConnection.CreateTableAsync<DbMetadata>();
    await LocalData.MarkDbVersion();

    StorageFile dbFile = null;
    try {
      dbFile = await StorageFile.GetFileFromPathAsync(DBPATH);
    } catch (FileNotFoundException) {
      if (dbFile == null) {
        // Copy file from installation folder to local folder.
        IsolatedStorageFile iso = IsolatedStorageFile.GetUserStoreForApplication();

        // Create a stream for the file in the installation folder.
        using (Stream input = System.Windows.Application.GetResourceStream(new Uri("Assets\\LegoSets.Snapshot.sqlite", UriKind.Relative)).Stream) {
          // Create a stream for the new file in the local folder.
          using (IsolatedStorageFileStream output = iso.CreateFile(DBPATH)) {
            // Initialize the buffer.
            byte[] readBuffer = new byte[4096];
            int bytesRead = -1;

            // Copy the file from the installation folder to the local folder. 
            while ((bytesRead = input.Read(readBuffer, 0, readBuffer.Length)) > 0) {
              output.Write(readBuffer, 0, bytesRead);

  } catch (Exception _e) {


There’s a bunch of cool stuff happening in the code above (the delete step alone took me a few hours on StackOverflow to get right). But the basic logic here is as follows:

  1. Open the database file
  2. If the file is there, check the version number
    1. Validate that the settings table exists (that we have a version number to check Smile)
    2. If the database is the same or newer version, then all is good!
    3. If the database has an old version, delete the file and clear the variable
  3. If we have an open database file, proceed; if we don’t, then create a new one
    1. If we’re running in DEBUG, then create the file and the tables from scratch
    2. If we’re not running in DEBUG, then use the snapshot that shipped with the app

Note that the above applies to an app written for Windows Phone Silverlight. When I do bring this over to the Windows Runtime platform (targeting Windows client, as well as phone), I will likely add some #IF checks to handle where the files are located and the like. But that’s for a future consideration (I have a tablet version of my code, but put it on hold while I get the SQLite and Amazon integration done).

Hope that helps

That about does it for how I manage my SQLite database in my app; I hope this helps!

There are a variety of other things that I’ve adopted over time based on this strategy that may be worth noting (e.g., breaking my SQLite DB into a few different databases to enable part of the cache to be cleared without clearing all of a user’s past traffic). Also, I’m in the process of wiring this up with the Bing Translator, which also warrants a blog post in the coming months.

While I was reinstalling my laptop this week, I ran into some friction getting my Brick Manager development environment going again. My issue turned out to be pretty simple, and I thought I would share out how to solve the issue to help out others that follow on behind me(because I couldn’t find anything on the interwebz).

After syncing my solution down to my newly configured dev machine, there was a System.IO.FileNotFoundException thrown by the  public static Result Open(string, out Sqlite3DatabaseHandle, int, IntPtr) method within the SQLite.cs; in particular, the exception was thrown by the Sqlite3.sqlite3_open_v2() call.

SQLite exc blog post - 01

Exception details:

  • Type: System.IO.FileNotFoundException
  • Message: The specified module could not be found.
  • HRESULT: 0x8007007E


SQLite exc blog post - 03At the root of the exception was a missing SQLite extension for Visual Studio. I had the SQLite-net and SQLite-net-wp8 NuGet packages, but Visual Studio didn’t automatically link into the SQLite for Windows Phone extension (even though it was installed).

To re-add this to your VS solution, do the following steps:

  1. Open up the project’s references by secondary-clicking on the ‘References’ node in the solution explorer and selecting ‘Add Reference…’
  2. In the Reference Manager, select ‘Windows Phone SDK 8.0’
  3. Select ‘Extensions’
  4. Check the box for ‘SQLite for Windows Phone’ if it isn’t already selected. If it isn’t in the list, then you will need to install the extension (but I will assume you already know how to do that Smile)

SQLite exc blog post - 02

Once I selected the box, everything was once again copasetic and all was good in the universe once more.

Hope this helps!

This blog post starts to cover a number of interesting Windows platform development challenges that I ran into as I built out my Brick Manager app. While the code was initially written for Windows Phone, it also applies to building Windows Store apps. Given that I started the app out as a learning experiment a bit over a year ago, it’s funny that it’s taken me a year to get the first one of these out. Feel free to share your feedback below. – CRS

At the heart of my Brick Manager app is communication with the BrickSet web services. As I started using the service, I wanted to take advantage of HttpClient and the async keyword, but I ran into two challenges up front: (1) Huw uses ASMX for his web service (good luck finding a blog or StackOverflow article discussing how to wire up against one of those) and (2) the site only returns XML (while most Windows/HttpClient blogs only talk about wiring up JSON).

The logic of the XML communications eventually settled on the following pattern:

  1. Instantiate HttpClient to use for the web service communication
  2. Instantiate a CancellationToken to allow me to set a time-out
  3. Parse the result into an XElement data structure, and pass that back to the caller
  4. From the caller, pass the returned XElement into the appropriate parser

I eventually compartmentalized my service calls into a static class, which centralized all of the web service call logic into one place (which not only deduped the code, but also improved stability and perf).

For the web service communication (steps 1-3 above), this is a cleaned up version of my GetBrickSetData method:

private static async Task<XElement> GetBrickSetData(string url) {
  using (HttpClient _client = new HttpClient()) {
    using (var _cts = new CancellationTokenSource(TIMEOUT_DEFAULT)) {
      try {
        var _result = await _client.GetAsync(url, _cts.Token);
        var _data = XElement.Parse(await _result.Content.ReadAsStringAsync());
        return _data;
      } catch (OperationCanceledException _e) {
        // Code to handle timed out exception
      } catch (System.Net.Http.HttpRequestException _e) {
        if (_e.Message.ToLower().Contains("Response status code") && _e.Message.ToLower().Contains("404")) {
          // Code to handle timed out exception
    return null;

One item that is worth calling out is the CancellationToken. I mentioned this as step 2 above, but this was a later addition to my code logic, which I added when BrickSet was undergoing a DoS attack. During that time, the app experience looked to users like it was in a perpetual unresponsive state. Adding the CancellationToken enables me to take the default 60 second timeout to something closer to 3 seconds, but the addition did require me to tease apart the typical HttpClient.GetStringAsync() call you see in code samples everywhere into the two calls above.

Once I get the data back from the above, I then have to parse apart the huge clump of XML For me, I found it easiest to use LINQ to XML to parse the data apart. In the code below, which is pulled from my method that parses the BrickSet set themes, I grab the namespace from the XML and then iterate through each elements in the “themes” node.

public static async Task<IEnumerable<Theme>> GetThemes() {
  string _url = String.Format(BRICKSET_ASMX + "/getThemes?apiKey={0}", BRICKSET_API_KEY);

  XElement _themeData = await GetBrickSetData(_url);

  //parse the results
  XNamespace _ns = _themeData.Attribute("xmlns").Value;
  var _themes = (from themes in _themeData.Elements(_ns + "themes")
                 select new Theme {
                 ThemeName = (string)themes.Element(_ns + "theme").Value,
                 Sets = int.Parse(themes.Element(_ns + "setCount").Value)
  return _themes;

In the end, [I believe that] I landed on a pretty elegant solution, but it can be a real pain to get it right. Not only do you need to really know the XML structure coming off the server, but you need to be able to handle the parsing in a bullet-proof fashion – one parsing error and the code goes bananas.

Parsing errors to keep your eye out for:

  • XML elements that need more robust parsing (e.g., turning 0 | 1 into a Boolean)
  • XML elements that are occasionally null
  • XML elements that are child nodes (and aren’t always present)
  • Optional XML elements that may or may not be there (e.g., when you’re not passing a user ID)

My code (above) gives some decent starting pointers for basic XML parsing, and I’ll dig into my travels through LINQ-to-XML-land in a future blog post.

I hope this helps!

This is a blog post that has been sitting on my laptop, all written and ready for posting, for just about two months now. I worked on the post when Jeff posted his social extension for 4th and Mayor…but shelved it when the topic died down. When talking with my colleague, Larry Lieberman, about the topic, he convinced me to dust it off and post it…and also convinced me to make an appearance on Inside Windows Phone. I hope it better explains what the team shipped with 8.1.  – CRS

With the new Windows Phone 8.1 release, a whole new class of social extensibility points are now available for developers. These new extensions begin to open up a new area of the phone to developers that were pretty closely held – the People and Photo hubs. While these new APIs add a number of highly requested social capabilities to the platform, the new extensions also seem to be a source of confusion.

As the team released the Windows Phone 8.1 preview and devs started digging into the new APIs, I started getting a number of questions on the topic (on social, in my inbox, and on the phone), and I started digging into the topic with the teams that built the features (admittedly, the topic was new to me and missing from all of my ‘what’s new in phone’ discussions so far). In my honest opinion, I found the new social capabilities in 8.1 pretty amazing.

As I haven’t seen much on the topic, I thought it was worth writing up a semi-quick blog post on the topic to explain what I found and to provide some pointers to related reference material. There’s just so much more richness to the subject than 140 characters can do it justice. Smile By the end of the post, my hope is that the new extensions points are much clearer: not only what they are (and what they aren’t), but how you can get started taking advantage of them today.

Why social?

Windows Phone has always been, at the heart, a social phone. This value proposition was the one that resonated most to me, and is central to my ‘why I love my phone’ pitch. Using the People Hub and pinned groups, my phone connects me to the people that matter most in my life (via a couple live tiles), as well as to my broader social graph. At a glance, I can get everything that matters to me in one place, regardless of its source (Facebook, Twitter, LinkedIn, email, or SMS).

wp_ss_20140701_0001The People Hub is magic. As a father of three and Seattle transplant (with all of my family back east), it makes it easy for me to share the day-to-day with my personal networks. Last month, that update was to share news of our girls taking their first steps. And I believe it goes without saying that I’m busy – and the People Hub enables me to get the low-down on my social graph without having to actually go a number of dedicated apps. Again – magic.

There were a couple limitations with this approach, however. While folks generally love the integrated experience, but wanted additional/deeper network-specific features in the native People Hub experience (e.g., to like a photo). And for our international customers, the deeply OS-integrated approach meant that the Windows Phone engineering team was then the only group that extend the integration to additional key social networks around the world.

What can be extended?

To open up the Windows Phone social hubs (the People Hub and the Photos Hub), the team built out a social extension framework to enable Windows Phone to light up anyone’s social graph. imageOver time, this approach should not only make it easy for social networks to extend the hubs, but also to bring flexibility that enables social networks to light up specialized integrations to our users.

With 8.1, there are three integration points that are opened up for app developers publishing into the Store:

  • Social broadcasting: Apps can extend the ‘Me’ card to enable the user to choice and launch an app to checks in or post a social update. As I understand it, the documentation on these is still in the works, but Jeff Wilcox publicly shared out the source code for his Social Extension for 4th & Mayor app.
  • Contact cards: Apps can still integrate with the contact cards to add and extend contacts in the phone’s address book. What is new in 8.1 is the ability to bind to the contact card using a ‘contact binding’ to place an app tile into the new ‘Connect’ pivot to contextually extend the contact. By implementing a contact binding, you provide the phone user with a way to display relevant information about that user (e.g., service username, user/gamer/karma score, relevant pictures, latest update) and provide a way to deep link into your app to immediately interact with that user.
  • Photo Hub: For services that host user photos online, you can also now integrate your app into the Photos Hub, surfacing your app as a tile on the album pivot, enabling your users to jump right into their pictures on your service. This means being able to launch off from one place, the Photos Hub, into each and every connected photo sharing service, without having to navigate in and out of each and every app, looking for that one family picture that you want to show someone.

wp_ss_20140701_0002With the new social extensions, there’s a lot that you, as an app developer, can do to enrich the social lives of your users by surfacing relevant service information in-context. And the result is win-win: for you, you get discovered and launched more often; for your user, the functionality and experience they want is always at their fingertips. Smile


And that’s not all…

Beyond these sweet new social extensions that you can use in your app, it’s worth calling out that you also have the Action Center, contextual awareness via Cortana, and all the yummy goodness of WNS and the new tile templates…with each of these topics totally worthy of a blog post unto itself.

As a developer, it’s really hard not to get excited about all of the new tools that Windows Phone 8.1 adds to an app developer’s toolkit. And as a social network user, it’s even harder to not get excited about all the innovative social experiences that developers can build using them…right there in that magical place called the People Hub.

wp_ss_20140418_0001One of the common questions I’ve been getting over the past week from folks has been how to take advantage of this semi-obscure ‘Project my Screen’ entry that was added to the settings collection with Windows Phone 8.1.

This entry is enabled in one of two ways: by using Miracast capabilities delivered in 8.1, and by using the Project my Screen app on a PC and connecting your phone to your PC using a USB cable (sorry – no WiFi yet).

I believe the ‘Project my Screen’ application has been one of the more eagerly awaited features by developers and technical enthusiasts alike. Since we launched Windows Phone 7.0, I’ve received at least a 2-3 mails/questions a month on how they can do demos like Microsoft presenters. With this enabled, anyone can fire up their phone and project a demo of their app or their phone. So, let me lay out how you can demo your app and phone. Smile

Project my Screen requirements
The application is a desktop/x86 application (not a Windows Store app), and should run on Windows 7 and later. And, talking to the team, there is currently no plan to expand this to a Store app, nor is there a plan to enable this to connect to a television or non-PCs. A lot of this stems from the core purpose of this viewing application is to enable demos. The use case for televisions and other device types will come along with Miracast support (I don’t have any details on this, but I will post more on this as I get more information).

How to install it
To make use of the Project my Screen app, you need to do the following:

  1. Download and install the Project My Screen app from the Microsoft Download Center
  2. Start up the application using the ‘Project my Screen’ shortcut on the desktop or program list. This will start up a full-screen – click <ESC> to get that puppy to window down
  3. Connect your phone to your computer using a data-transfer quality USB cable
  4. You should get a prompt for permission to allow screen projection, click ‘yes’
  5. At this point, your phone screen should show up (similar to below)

4-18-2014 2-09-47 PM


Command cheat sheet

There is a limited number of commands available in the application to control the demo experience. The table below summarizes the commands available to you (you can get this list in app by hitting F1):

Action/Command Key
View the help screen <F1>
Quit to windowed mode <ESC>
Toggle background image on/off B
Toggle the expanded screen mode E
Toggle full-screen mode F or <Alt>+<Enter>
Toggle the phone shell image P
Toggle visibility of ‘touch dots’ T
Display the current [desktop] frame rate R
Force orientation to landscape left Left arrow key
Force orientation to landscape right Right arrow key
Force orientation to portrait up Up arrow key
Force orientation to portrait down Down arrow key
Reset orientation to match phone <spacebar>

…if your screen won’t project…

4-18-2014 2-27-16 PM

If you don’t get a prompt on your phone and the Project my Screen app remains blank/black, you may have some old phone drivers hanging around. To get rid of them, head over to your machine’s device manager (my preferred way of getting there on Windows 8.1 is to secondary-mouse-click on the Start button and select ‘Device Manager’ from the pop-up menu).

Once in the Windows Device Manager, you’ll want to remove + uninstall the drivers related to your device. When removing these drivers, it’s important that you get them all – not only the actual device itself, but the related USB device drivers.

To do this, do the following steps, keeping the plugged in:

  1. Right-click on each driver you want to delete and select ‘uninstall’
  2. A dialog will pop up asking you to confirm uninstallation. If you also have the option to delete/remove the drivers, select that
  3. Once they’ve all been uninstalled, unplug and replug in your phone back in and Windows should take care of the driver magic
  4. You should also now get the screen projection prompt shown above

4-18-2014 2-29-46 PM


Happy projecting!

VS Issue: Designer failing

October 27, 2013

Update: I believe I solved this issue, and this post has been refined to point to the actual issue (and not the way I treated the symptoms of the bad cache).


I was running into an issue while developing in my Windows Phone app in Visual Studio. After banging my head against the wall for several hours looking for a ‘real problem’, it turned out to be an issue in my view model.

My Issue

For any XAML pages in my project where I used the Telerik controls in my project, I received a design-time error whenever Visual Studio attempted to render the page. Funny enough, the error was different depending on which instance of Visual Studio I opened/ran the project in:

  • Visual Studio 2013: ObjectDisposedException: Cannot access a disposed object (NativeObject)
  • Visual Studio 2012: Error HRESULT E_FAIL has been returned from a call to a COM component

NativeObj Exc

This error drove me nuts for a variety of reasons:

  • The same XAML worked in other projects (e.g., Telerik sample code)
  • Creating a blank/new XAML page worked until I added any of the Telerik controls
  • Reinstalling/readding the Telerik controls didn’t do anything.
  • The stacktrace was absolutely meaningless

Funny enough, the error keeps coming back – and I’m guessing it seems to be related to having the Telerik controls open in two projects at the same time in VS2013. It looks like VS2013 changed the way it handles errors in the XAML files – I say this because the sample data XML file that I was using in VS2012 had no issues, but it reported issues in VS2013.

My Initial Solution – Cleaning the Cache

After playing with a large number of things, I tried doing an aggressive cleaning of everything related to the project:

  1. I did a ‘clean’ for every project in the solution
  2. I removed every \bin and \obj folder in the solution
  3. I cleared out the Visual Studio designer temp files
  4. I cleaned up Windows temporary files

After doing the four things above, I returned back to my project, did one more Clean (just because you always double-tap Smile) and then did a Build on my WP project. I then reopened the XAML file, and everything worked once more! Yay! However, opening it up in VS2013 caused everything to get hosed again. So, I did more digging and eventually found my issue was in how I interacted with Isolated Storage in my view model.

My Solution – Fixing my ViewModel


At the heart of the issue, I was using isolated storage settings in my view model (for storing username and a userhash), which I was then taking advantage of in my sample data xml file. And that sample data XML file was being used to render design time data in XAML via data binding. VS2013 seems to look for and throw an error in the sample data XML that VS2012 wasn’t throwing, and this is what was causing an issue above.

I added the below check around the assignment/reading of the IsolatedStorageSettings object to verify that it should go over to the isolated storage area before actually doing so:

if (!System.ComponentModel.DesignerProperties.IsInDesignTool) {
  settings.TryGetValue<string>("username", out m_username);

Using the above check prior to doing a TryGetValue, everything now works appropriately, treating not just the symptoms, but the root cause.

Hope this helps!

Last week, I had the pleasure of visiting AppCampus in Helsinki. While there, I spent time with each of the teams in residence reviewing their apps and their app strategy, and I even did a short talk to the group that starts from the subject of app decay and what developers should consider to avoid decay and be successful. It was a great having the opportunity to engage with so many new app devs and to see the fresh ideas that folks are bringing to life for the mobile app market; but I also noted a continuing trend where app devs focus on birthing their apps while neglecting their upbringing. Smile

Since I joined the team, the topic of ‘success’ for the average/breadth mobile developer has been a top of mind item for me. And while there are a number of factors that contribute to the success of one’s app, perhaps the success factor that is most overlooked by developers is focusing on a meaningful user engagement.

As I talk to app developers about their apps, most talk about building a functional app that accomplishes some purpose and potentially then talk about the user experience and adding polish that presents their functionality in some compelling fashion. Some will then talk about app discovery and download numbers. But very tend to think about their go to market strategy for their app, let alone talk about.

And so that is the topic I engaged the AppCampus teams on:

  • The need to understand the user
    (who are they? what do they care about? why are they in your app, anyway?)
  • The need to understand how your user wants to be engaged
    (what will bring them back? what will they find valuable?)
  • The need for you and your users to discover one another
    (what’s your launch strategy? where are your advocates? how will you grow?)

Developers continue to be caught in the age-old trap of believing that they are their customer and that they should develop their app for their tastes and scope the features and user experience to their preferences. And so they build an app to their own needs (and perhaps ask their wife to give them usability feedback), they release it to the store, and then wonder why they get only about 200 or so downloads.

If you really want to succeed, you need to think ahead and have a go to market strategy. To do otherwise, in the words of a dev I met a couple months ago, ‘is like buying an electric guitar and expecting to have a hit single.’

I’ll drill into these topics more in a series blog posts on factors that contribute to an app developer’s success. But, in the meantime, feel free to enjoy my slides on the topic; I admit that they may be a bit limited in their usefulness without the talk track, but I’ll flesh that out in the coming weeks as your interest and my time allows.

A couple weeks ago, as part of a fairly sizable ‘August update’ blog post, the Windows Phone team announced that they expanded developer unlocks to enable hobbyist developers to unlock their personal device to test their code on a real device.

After a number of questions on the topic via email and Twitter, I thought it was worth posting a blog entry detailing the device unlock expansion to help folks understand what happened (and what didn’t happen). Given the number of things announced in one blog post, it seems a number of people connected things together that weren’t intended to be.

Quick context: developer unlocked phones

With the launch of Windows Phone 7 (and the accompanying Marketplace), developing for Windows Phone has required this thing called a ‘Developer Unlock’ to deploy an app to a phone. Once unlocked, a developer with a current/paid membership on the Windows Phone App Hub/Dev Center could use their Microsoft Account ID to unlock 3 of phones, and side-load up to 10 applications. The intent here is to enable apps to be tested and run on the device prior to submitting them up to the Store.

It’s important to note that a developer unlocked phone is different than what some folks call a carrier unlocked or network unlocked phone. A developer unlocked phone can side-load apps, but it’s still bound by all other MO and OEM restrictions that are placed upon it.

So what changed this month?

Starting this month, anyone can developer unlock their phone. This means two things for a developer:

  1. They don’t need to pay for a Windows Phone Dev Center account in order to debug and run a personal app on their personal phone
  2. While SLAT is still required for to run the WP emulator, devs can now debug their app using their personal Windows Phone. While you’ll still need an x64 processor and Windows 8 (any edition) to run the WPSDK, folks just starting out with WP should no longer be blocked by the HyperV-based emulator (which requires Windows 8 Pro (or above) and a SLAT-capable processor) if they have a device to run the app on.

And those two things are pretty awesome!

But there is fine print, and here it are the limits with this when using a Microsoft Account that is not paid/registered on the Windows Phone Dev Center:

  • Number of devices: Up to 1 phone can be dev unlocked
  • Number of apps: Up to 2 apps can be side-loaded

While the above could be thought of as limiting, I believe the expansion was made for the hobbyist developer, providing enough capability to get these folks started with experimenting with app development on the Windows Phone development platform. Should they need the ability to side-load + use more than 2 apps at once, then they are likely ready to graduate past the hobbyist status and get a Dev Center account.

What’s the experience for the hobbyist?

The overall experience of developer unlocking a phone doesn’t change for the developer beyond two aspects:

  • The hobbyist is subject to the limits above
  • Registering a second device happens silently

So what does that second point mean? When a paid/registered developer uses the Windows Phone Developer Registration Tool to dev unlock a phone after they’ve reached their limit, the tool provides an error message telling them that they’ve exceeded their limit. For the hobbyist developer, no such message is displayed. Instead, the system will automatically replace their old phone with the new one the developer is unlocking, and the prior phone will automatically and silently relock.

I call this behavior out because it caught me by surprise the first time I saw it, having been used to the prior error message. However, in a one-device system, this behavior actually makes a ton of sense, because it means that the hobbyist developer doesn’t need to track down the prior phone and do a unregister/relock prior to being able to use a unlock a new device (e.g., she sold the phone or has simply moved on from the cool 920 to the awe-inspiring 1020 Smile).

So that’s the low-down on that ‘developer unlock for everyone’ capability. This capability has been a long-time coming, and I’m very happy to see the Windows Phone folks finally get that one out to the hobbyist community.

Today is an exciting day at Build – the Windows 8.1 Preview is available for download! If you’re like me, you can’t wait to update your machine to take advantage of everything delivered in the new release. http://www.preview.windows.com/

Among the enhancements and changes in Windows 8.1, it looks like the team made some changes that affect Hyper-V, creating a compatibility issue with the Windows Phone emulator (XDE) included in the Windows Phone SDK 8.0. Thankfully, this is quickly fixed with Visual Studio 2012 Update 3.

When you start up the Windows Phone 8.0 emulator on your newly updated machine, you’ll likely be greeted with the following dialog box from the Windows Program Compatibility Assistant, informing you that the emulator has compatibility issues:


To resolve the issue, you need to install the Visual Studio 2012 Update 3 (hereafter simply referred to as VSU3 for the sake of brevity). Among all the goodness in the update that RTM’d today, VSU3 includes an update that enables the XDE to install and work on Windows 8.1. And, in case you’re curious, you should be able to install VSU3 either before you install the Windows 8.1 Preview or after…as long as you install it before you use the emulator again, you’re all good.

To install VSU3, you can either download it from the Microsoft Download Center page, or you install it from within the Visual Studio 2012 environment. To install VSU3 from within VS2012, follow the following steps:

  1. From within Visual Studio 2012, select the ‘Extensions and Updates…’ option from the ‘Tools’ menu
  2. Within ‘Extensions and Updates’, you want to navigate into the ‘Updates’ section and select ‘Product Updates’, which should provide you with the option to update Visual Studio to VSU3
  3. Click ‘Update’ and let the update roll

6-23-2013 10-47-26 AMRegardless of the update path you take, you can kick off the upgrade and grab a coffee (or, in my case, a Slurpee) and let it run for awhile. After it completes, we’re once again on the happy path and the emulator launches just fine!

I hope this blog post helps you out,

[Edit Jul-1-2013: I modified this post to remove some dialogs that I encountered when I was installing VSU3 RC2 and also to add in how to install the update from within Visual Studio; thanks to those who provided these suggestions!]