Monthly Archives: September 2012

More Windows Phone 8 sillyness.

I’ve been watching the Windows Phone 8 conversation with great interest. I say conversation, but it has been kind of one sided. That said, Todd Brix who posted the most recent post (12 Sept) on the WP development blog has chimed in on the comments following the post. Here is a copy of what he commented:

I wanted to respond to those of you who are frustrated about the fact that we haven’t publicly released the Windows Phone 8 SDK. This year we’ve taken the approach of unveiling the new features of the OS as close to device availability as possible.  Unfortunately we can’t release the SDK without revealing all of the new features and capabilities.  I recognize this is a departure from how we’ve operated in years past and some of you are questioning our thinking.  That’s ok – let me give you a little more to consider.

Windows Phone 8 was designed to run the apps written with the Windows Phone 7 SDK which is available today.  Right now and for most devs the high-volume app development opportunity remains on the Windows Phone 7 SDK because these apps will run on phones available later this year, regardless of what OS version is on the phone.  If you want to help make sure your Windows Phone 7 app runs well on Windows Phone 8, when it is released, you’ll want to take a look at the Sept 12th post from Andrew Whitechapel . And while I know you want to test your app in our new emulator, the reality is that you will also want to do final testing with Windows Phone 8 devices which are not yet in market.

There are also devs who want to jump on new Windows Phone 8 technologies before anyone has bought a device, which is fantastic.  This is why we’re doing the early Preview Program. For those who don’t get the Windows Phone 8 SDK via the program, we will get the final SDK out in time for you to capitalize on the wave of new devices.

Thanks for your interest in Windows Phone!

Todd makes several good points in his comment:

  1. The biggest opportunity right now for Windows Phone developers is the 7.x generation of devices.
  2. They can’t release the Windows Phone 8 SDK without developers figuring out what the platform has on offer.

Unfortunately, the comment still completely misses the point. Firstly, even if I am going to target Windows Phone 7.x generation devices, I still want to work within the latest version of Microsoft’s IDE. Developers don’t just write Windows Phone applications, they build the backends which support those applications and when your vendor doesn’t continually bring their SDKs up to a level where you can use a single IDE they are effectively introducing a productivity burden. I want an updated SDK which allows me to use Visual Studio 2012, I’m actually less concerned about the Windows Phone 8 specifics right now.

The other point, which has been raised by others is that by sharing the SDK with some developers, they are effectively sharing the SDK with all developers. We are already hearing rumours about WP8 devices being found in the wild. It is possible that these are just unfounded rumours, but it definitely appears like they have RTM’d the operating system. Sorry guys – you can’t contain this stuff it will leak out. Developers will be pissed if they are the last to know – it is a great way to completely screw an product eco-system and fill it with ill-will.

So where are we after my previous post? Nowhere. I had hoped that Microsoft would quickly switch strategies and open up access to the SDK as soon as it was ready (so no super secret preview program). That is looking less and less likely now. Not only that, but it appears that Microsoft is suggesting that we should be happy and target the mobile platform with the most opportunity (see highlighted second in Todd’s comment). Fair enough – here are some statistics for you to consider (according to the Mobile Mix report):

  • 46% Android
  • 34% iPhone
  • 15% BlackBerry
  • 4% Windows
  • 1% Symbian

Time to leap to action! Go and download the Android SDK and the iOS SDK.

Windows Phone 8 SDK? Srsly?

The Windows Phone 8 SDK Preview program is now open. Except you can’t download the bits, and it isn’t the least bit open. If you are a software developer that has been loyal to the Microsoft platform for years (or decades) you have the right to be pissed.

Many developers have been eagerly waiting for the release of an updated SDK for Windows Phone. Microsoft didn’t see fit to release an update with Visual Studio 2012 so that developers could use the latest IDE to target Windows Phone 7.x, and so an updated SDK was really overdue.

Unfortunately on the 5th of September Microsoft announced that they would only be opening up the Windows Phone 8 SDK in preview mode to a select few, basically cutting off those who had been waiting for an update in the SDK to start work on their projects (whether they are Windows Phone 7.x or Windows Phone 8.x). The overwhelming reaction of developers commenting on that post and today’s update was clear (epic fail).

In order to get access to the SDK you need the following:

  1. Publisher Name
  2. Dev Center Publisher GUID
  3. Registered Country
  4. Application Name
  5. Application GUID

As an MVP I’m used to filling in forms on the Microsoft Connect, but normally it is just basic demographic and organisation information. This is a whole new level and it basically excludes a lot of really passionate developers from getting access. The form of course is not the only blocker, Microsoft then needs to “select you” because it’s not just a case of filling in the form and automatically getting access to the bits.

The Windows Phone 8 SDK preview is not open, its closed. Period.

Sure the marketing folks in charge of this decision are quickly reconsidering their options. Firstly – the requirement to go through this process will detract from developer adoption of their platform. Right now they are getting a strong reaction from a small number of developers passionate enough give a crap.

I’m already feeling cheated having paid good money (USD$99) to get access to the Windows Phone Dev Center, only to have Microsoft completely drop the ball on SDK updates after the RTM of Visual Studio 2012.

Right now Microsoft has sub-10% market share in the mobile operating system space. This strategy of locking loyal developers out of the platform updates (combined with not releasing updates to existing tools) is completely wrong-headed.

Version Numbers

Identifying when, how and whom produced a product is important. It is important with physical goods, hence why we have barcodes, expiry dates, model and serial numbers. The same is also true for software. Embedding a version number in files that ship with a product allow support team members to determine what version of the source code went into produce that version of the product and therefore more easily debug its observed behaviour.

Later this week I was working with a fellow team member on automatically applying version numbers to our product each time that it built (continuously integrated). On the surface it is quite a simple task except when you start to consider the sheer number of places that version numbers should be applied within a relatively complex build process. Here are some common examples:

  • .NET assemblies
  • NuGet packages
  • WiX installers
  • Documentation files

Each one of these target locations requires a different approach for finding and updating version numbers and it end up getting pretty complicated. But before you start you might want to give some consideration to what your version number actually looks like, and what it means.

I take a lot of inspiration from SemVer.org but it doesn’t really work for all technologies. For example, strongly named assemblies in .NET have four elements (major.minor.build.revision) whereas SemVer defines three elements (major.minor.patch). SemVer also defines trailing elements followed by a dash (for example 1.0.9-rc1) which won’t work for the strong name in a .NET assembly. Of course we can use other informational versioning techniques to pass along SemVer like version information.

If we look at SemVer and apply the first part (major.minor.patch) to version numbers within the package then we could probably adopt a manual version increment technique and just take a centrally defined version number (say in version.xml in the root of the solution) and stamp it in various files during the build process.

Anyway – version numbers, they are important!