Original URL: https://www.theregister.com/2012/11/05/windows_phone_8_sdk/
Windows Phone 8: Exceptional tools, but where are the devs?
Microsoft's vast scary world of versions and APIs
Posted in Software, 5th November 2012 16:16 GMT
Analysis The Windows Phone 8 SDK emerged at the Microsoft’s BUILD conference in Seattle last month. After so much hope, hype and promise, what’s new for developers?
A lot, as you would expect given that this version of Windows Phone is built on the same core as Windows 8, whereas the 7.x line is built on Windows CE. At the same time, Microsoft has yet to do the obvious thing: unify the Windows 8 “don’t-call-it-Metro” runtime with what is provided for Windows Phone 8, though it is closer than it was before.
The reason seems to be compatibility. There are about 120,000 Windows Phone 7.x apps in Windows Phone Store, according to Microsoft. It would be a disaster if Windows Phone 8 was incapable of running those existing apps. Microsoft also had to keep the Silverlight-based XAML - Microsoft’s XML-based language for defining a user interface – rather than replacing it with the native code XAML used by Windows 8, although the Silverlight name is no longer spoken.
Windows Phone 8 also still supports XNA, a means of developing games with .NET code, although this is no longer the recommended path for games development, and Visual Studio will not let you create an XNA project targeting Windows Phone 8. Developers like XNA, so why not? The reasons may be to do with Microsoft’s internal politics rather than technology. The Windows team is focussed on native code and DirectX more than .NET.
There is a fudge though. The new SDK fully supports creating an XNA project targeting Windows Phone 7.1, which will run fine on Windows Phone 8. There are even ways, through .NET Reflection, to get to Phone 8 specific APIs in such a project.
If Windows Phone is tied to Silverlight-style XAML, and Windows 8 to native XAML, how will convergence ever come to the two platforms? Microsoft will not say, but here is a clue. It would be good, I observed to Microsoft’s Larry Lieberman, who was running the Windows Phone track at BUILD, if you could run Windows Phone apps on Windows RT and devices like Surface RT. “We could not do everything at once. You are not the first person to make that suggestion,” Lieberman said.
It seems plausible, therefore, that at some future date the Phone 8 XAML stack might come to Windows 8 to run Phone apps. Perhaps the reverse may come as well, so that Windows Phone can support both stacks.
Native code project options include Windows Runtime extensions
Despite these issues, there is already some degree of convergence. The Phone 8 platform includes the Windows Phone Runtime that is accessed using .NET metadata as in the Windows Runtime. You can also create new Windows Phone Runtime components using Visual C++. This is significant, since this lets you extend .NET code with native code. COM interop and Platform Invoke, which you may use in desktop Windows, do not work on Windows Phone.
In Windows Phone 7.x, of course, you could not use native code at all unless you were Microsoft, or an operator or manufacturer. Now there is a range of native code application types, including Direct3D, Direct3D with XAML, and static or dynamically linked libraries.
There is no support in Windows Phone 8 for WinJS, the projection of the Windows Runtime to JavaScript used for HTML apps in Windows 8. However there is a new HTML5 app type, which uses embedded Internet Explorer 10 in a XAML page. There is some access to Phone APIs through the InvokeScript JavaScript method.
Windows Phone 7 included a version of the Compact Framework for its .NET runtime. In Windows Phone 8, this is replaced by a new version of the CoreCLR, which was first developed for Silverlight on the desktop. This version includes the asynchronous programming model introduced in C# 5.0. Microsoft also claims that startup times are up to twice as fast for .NET apps.
Confused? You will be: let's talk on-demand compilation in the cloud
Another new feature is cloud-based compilation. The story here is that .NET apps are delivered as MSIL (Microsoft Intermediate Language) and compiled to native code at runtime. This cannot be done earlier due to hardware-specific considerations, but the process of compilation at every startup is demanding for the phone. In Windows Phone 8, apps are pre-compiled in the cloud to a format called MDIL that program manager Brandon Bray described as “90 per cent compiled”, speeding up performance.
With much in common between Windows 8 and Windows Phone 8, how can developers share code? The primary technique is a feature of Visual Studio 2012 called Portable Class Libraries. This is non-visual code in which Visual Studio will enforce compatibility with the platforms you specify.
The idea is to share the non-visual code between the platforms you select, and write a platform-specific user interface. Of course “portable” in Microsoft’s world means portable between variants of Windows rather than true cross-platform.
Developing for Windows Phone 8 requires Visual Studio 2012, though there is a free Express version for getting started, and Windows 8. One reason why Windows 8 is required is that the phone emulator runs on the Hyper-V virtualisation engine, which is not present in Windows 7.
You can target Windows Phone 7.x as well as 8. The emulator is comprehensive and lets you vary screen size and memory, and emulate location data and accelerometer movement. A Simulation Dashboard lets you test with a variety of scenarios such as low-signal strength.
The Hyper-V emulator for Windows Phone 8
Deployment is normally through Microsoft’s store, but there is also provision for enterprises to install apps directly, such as via email or a microSD card. This is enabled by registering for an enterprise mobile code signing certificate and getting an Application Enrolment Token that enrols phones for use with company apps.
There are also a range of new features available to apps. These include lock screen notifications, a rich new map control and navigation API, speech API, wallet API for mobile payments including Near-Field Communications (NFC) where available, camera add-ins called Lens apps, and new photo and video capture APIs. The web browser control is now based on Internet Explorer 10.
In networking, there are APIs for Bluetooth, proximity including NFC, IPv6 support, and native Winsock support for those familiar with Windows sockets programming. In-app purchases are supported. A new storage API is a subset of that in the Windows Runtime and includes SD card access.
Native code support in Windows Phone 8 has enabled better support from third-party libraries, and Tony Garcia from Unity took the stage at BUILD to show off use of this popular game development framework on Windows Phone 8.
This is a big release, with much that is significant. Visual Studio is well liked by developers, and if it were competing on ease of development alone, Microsoft would be prospering in mobile. As it is though, it struggles, because of two well-entrenched competitors in the form of Apple iOS and Google Android. Development company Thoughtworks said this in its Technology Radar, a survey of software development trends:
Despite a promising start to Windows Phone, a well thought-out user interface, and probably the best development experience of any mobile platform, we have seen several stumbles in the execution of the platform strategy by Microsoft and its partners. This makes us less optimistic about the future of the platform than we were in the last radar.
This was in relation to Windows Phone 7. If the platform was already good for developers, Windows Phone 8 is exceptional. Whether that is enough to win customers from other platforms remains an open question. ®