Looking at Windows Phone 8 from a developer's perspective

Microsoft has finally started to talk about the highly anticipated major update to Windows Phone, codenamed Apollo. With it we get a glimpse into the brand new Windows Phone 8.0, we've had a chance to assess some of the features that are inbound with this update and for the developers out there, it's time to start getting excited about a few of the features we're going to highlight.

Native C++ development

App-to-app communication APIs

NFC & Bluetooth stacks

In-app purchasing and the Wallet

Some of the biggest news of course is the shift in the base of the system to the new 'WinPRT' (Windows Phone RunTime), a subset of Windows Phone 8 (WinRT) with a few COM and Win32 APIs available for good measure. That means that a fair amount of code written for WinRT will be directly portable to this new WinPRT based framework.

Read on past the break for our take on exactly how Microsoft has opened up a new world of development possibilities...

Native C++ development

Now I may not be particularly versed in the language of C++, but this is huge news for developers who are bringing their apps over to the Windows Phone platform. Briefly from a consumer perspective I'm excited by the prospective that the major app successes we're missing from Windows Phone will now find it easier than ever to join the party.

As for game developers, those who know their way around C++ will find their new games performing better, and perhaps this will even pave the way for popular engines such as Unreal to come to the platform, particularly as DirectX and native audio feature sets have also been announced. [Edit: Of course already engines such as the Havok physics platform have been announced for Windows Phone 8.]

Of course, XNA is not dead for those of you who prefer it. If managed code is your preference then your XNA games will continue to work with Windows Phone 8, but we're now in the realms of backwards compatibility, so perhaps the writing is on the wall.

Finally, support for mixed mode development is still available, so just as in Windows Phone 7.1 with XNA and Silverlight apps, Windows Phone 8.0 developers can combine C++ elements with managed C# code to mix the great UI controls of Windows Phone with more advanced C++ routines when needed.

App-to-app communication APIs

As a developer this is perhaps the most exciting feature to have learned about, via sources outside the Windows Phone Summit interestingly enough. The premise is simple, apps will be able to register either a URI scheme which they accept, or register as being handlers for a specific file extension. The user would then be able to choose which app opens the file/URI, Windows (and Android in the mobile world) has used this approach for a while and it is a superb decision by the Windows Phone team.

Why is this so exciting? Well take for example the YouTube integration in the WPCentral app, I'm mimicking how the official YouTube app plays content, but I'd much rather be able to launch into a protocol that say, SuperTube could pick up. SuperTube would then be able to identify the command sent to it and take over video playing responsibilities, good for the SuperTube developers for advertising, good for me to know the app has improved, and great for consumers getting the best experience.

As an example of how the protocol might work, here's a quick diagram showing a theoretical future version of WPCentral allowing other apps and websites to link straight to articles, reviews or podcasts.

Particularly smart website owners would even be able to test for the Windows Phone browser's user agent and automatically try to open relevant links or articles using the app's protocol, now wouldn't that be something?

Now one caveat to consider, we understand that Microsoft has reserved a myriad of Protocols and file names for the operating system, so it's likely that files: mp3, jpg, pdf, xaml and protocols such as http and Mailto would not be available for developers. Don't expect to be replacing the default media player, marketplace, web browser or mail client with a third party offering, that's still under Microsoft's control.

Bluetooth stack

Near field communication is awesome (if a little terrifying privacy wise) but let's talk about a few options now available to developers. It's not perfectly clear from the information we have whether the NFC stack will be available to third parties, but we know for certain that the Bluetooth stack is. We also know that NFC can be used to pair Bluetooth devices, allowing phones to tap together to create a connection for sharing.

With the Bluetooth stack provided in Windows Phone 8.0, any developer can hook into the phone's connection capabilities, either to connect to any Bluetooth enabled device, or to another instance of their app.

The option to pair to a device means we might start seeing Windows Phone apps sold with Bluetooth accessories, as simple as a pedometer of some kind for fitness buffs, or as interesting as a PayPal-style card reader. Of course connecting two apps would make it very easy to play multiplayer games with anyone in the proximity, or easily connect with people nearby in a regular app (think connecting with new people at a gig with Pepper). The best part is you don't need an existing pairing to connect with another instance of your own app, so setting up a quick game with a nearby stranger on the bus will be perfectly possible and safe.

Rumored lock screen access

Taking the "glance and go" mantra one step further, Windows Phone 8.0 looks to offer app developers a little control over the lock screen, and more than you might imagine. As a developer you can affect the lock screen in one of two ways, either by using a lock screen notification, or by changing the wallpaper.

Lock screen notifications are similar to those you'll find on your current Windows Phone device for your e-mail accounts or messaging app. They are incredibly simple to implement if you've already got a live tile, requiring about 2 new entries into the WMAppManifest.xml file. The reason they are so simple is that they read the count value from your app's main live tile, along with a newly specified 24x24 PNG icon. That's great so long as you use the default count type (that's the little black circle with a white number for those who haven't tried it out yet), but if you're using a custom counter type like one of the options in our app, you'll need to work out a different way to use that counter. In fact, it looks like the only way to have a custom counter style as well as a lock screen counter would be to create a sub tile using your custom counter type, and have the user un-pin the main tile (disclaimer: I haven't tested this theory yet!).

Lock screen wallpaper access is still a little mysterious as I write this. A simple implementation idea would be to have an app which could download different wallpapers for you to use, similar to the idea in existing apps, just with direct access to actually setting the wallpaper. A possibly more interesting (but very intrusive) idea would be to use the wallpaper as a giant notification screen. Assuming that the wallpaper could be changed from a Background task, wallpapers could be updated every hour or so directly from your favourite image (or news!) source.

In-app purchasing & Wallet

Monetisation (that's the British spelling) is a big part of attracting developers to a platform, but it's also a delicate balancing act. So far one of the most popular models to adapt involves the trial/free model, allowing users to "unlock" an app for a set fee. Microsoft is following the lead of other popular mobile operating systems in providing developers the tools for users to buy new features or products for your app.

Now this can be as simple as unlocking your app to a full version, or as a whole product list, updateable online without updating the app.

Note that you won't be uploading your 'products' to the Microsoft dev center here, they will need to be hosted on your own server, but a catalogue linking to the products available on the dev center. What's equally interesting here is the concept of receipts, meaning that user's will receive a full proof of purchase, protecting their product purchase in the future.

So what is a product in this sense? Microsoft have 2 types defined, a Consumable and a Durable. A consumable is demonstrated by the as akin to 'gold coins' in a game, something the user will purchase, utilise, and then may want to purchase again. On the other hand a durable works more like a license, where users will make a one time purchase available in an app indefinitely, for example a new game level or app feature.

This gives developers the chance to offer one form of an app at a certain price, and then expand the app further through additional charges, an incredibly important tool when certain new features can take a lot of effort to implement.

In terms of wallet access to developers, it looks like functionality exists to add and remove cards to the wallet, as well as list wallet information. How is this useful? Think of the loyalty app concept, apps will now be able to directly add a copy of a loyalty card to to the phone's wallet, making it available through NFC for a seamless experience.

Other changes

Finally there are a few more controls presumably entering the SDK (coming late summer) that will make a big difference to the apps you develop.

Those apps which centre around or integrate map controls will see the maps in Windows Phone switch to the Nokia maps system. As part of this switch new directions and map tasking APIs are being introduced, including access to Nokia's 3D mapping packages.

As a last point of discussion, the new resolutions Windows Phone 8 will offer mean that as developers we can no longer be lazy about the XAML we produce. User interfaces will be expected to scale well to the new 720p resolutions, and Microsoft is recommending that you start using images for the new resolution to be scaled down rather than letting your old ones be scaled up. If you want to get a jump on making sure your app will adapt to different resolutions, my advice to developers would be to make every single screen in your current app work in landscape mode. That will give you the chance to get out of any bad habits you may have picked up in setting fixed pixel locations, instead focussing on alignments and margins.

Well, hopefully that's enough expansion for one article, expect to see more information about changes in Windows Phone 8.0 if more comes to light, and remember this is not a full list of everything that's changed, only some of the features we think are either promising a great deal of potential, or that are just plain exciting. There are plenty more to discuss and we'll be doing that in the next few days.

As always we'd love to hear your thoughts on all the information above, whether you're already developing apps, thinking of starting your first Windows Phone project, or just love reading about the new apps which may be hitting your device, let us know in the comments below.

I skipped it intentionally because I didn't have a lot of information about it when writing this article. I'm also a little cautious about it's capabilities as we've yet to see it work reliably. Don't worry though, I'm still secretly excited to try it out!

Like a reply box r something for this app cuz I have a hard time tryn to find my comments after so many people put there's . Just an idea if not the app is still my number one over all others on my home screen and all I'm on it everytime a toast pops up lol

I really appreciate the developer information. Your article was well written and I appreciate the examples.
One thing ... actually 2 things, I know that you can develop HTML5 apps and get them in the Win8 store but can you develop HTML5 apps and have them in the WP8 store?
Also, I read that XNA apps will not be allowed in the Win8 store so I figure, what the heck. Might as well go towards HTML5, especially if they will make it into the WP8 store.
Love the work you did on the WPCentral App. Besides my games, it is by far my most used app.

But you can use HTML inside of your apps. Similar to the way many devs do on Iphone. Have a web browser control in your app and host the JS and html in your library. Now that IE10 supports touch properly this will be a very viable option I would hope!

As long as I get control over it, I'm happy. Just because I downloaded the news app from CBC to read it when I'm free doesn't mean I want to know if Stephen Harper is having a headache on my lock screen.

lol, I wouldn't want that either. and yeah, on the w8 preview you can select which apps to show notification counters for and the order the icons display (so its always visually consistent). I think it'll be the same with wp8.

The only time I really miss it is when I literally miss a toast notification and the app isn't pinned to my start screen, or worse, doesn't have a live tile. It's not that big of an issue really since if it is really that important, it'll be on my start screen - but there are occasions and WP seems to have more of these occasions that either iOS or Android.

Yay Native C++! Goodbye crappy C#. I'm so excited for this. Will definitely keep WP as my first platform of choice to develop for now when I begin development. I loathe and despise managed code, .net and xaml. Pure C++ is what this platform needed badly.

Yes game development is my main goal but maybe apps as well. Jay: I just hate .net since rather than learning to program you mostly have to spend alot of time learning the framework. C++ let's you focus more on the programming.

Everything has a framework. You can't just start cranking out C++ until you learn how to display data, accept input etc. C# makes everything easier so I'm not sure why that would be a bad thing. If you really wanted to you could crank out C++ and C# without knowing OO, without any special structure or complexity to it at all. I coded in C++ for 3 years, switched to C# when it was released and never looked back. Each to their own I guess.

I don't know how to explain exactly. Its just that I tried C# but eventually went back to C++. I guess everyone has their own preferences. And since MS looks like it's offering both, its great. More programmers means more apps. :-)

Can you elaborate on what C++ code will have access to. For example if you are not building a game how would you build a UI? XAML like in Windows 8? Also can you build non-UI libraries in C++ and expose them to C# and vice versa like you can with WinRT components in Windows 8?

Also I realize that this is not a developer website but it would be cool to have more detailed article about the new screen resolutions especially since one of them has different aspect ratio.

If im not mistaken, XAML is available whatever language you choose. You can also definately use non-ui libraries in C++ and I think you should be able to expose them to C#.
As for the screen resolutions, according to Joe developers will not need to do anything to support all the new resolutions. They will be hardware scaled. You may WANT to change them (Up the res of your assets), but you don't need to.

I did not hear anything like this about the exposing C++ libraries and C++ and XAML. Is this real information or assumption based on Win8 dev story.

About the screen resolutions I understood the same thing you said but the article implies that we won't be able to be lazy anymore. If you and I understood correctly then we will be able to be lazy just like we currently are.

regarding C++ libraries, nothing was said in the article or by Joe, im just going from my limited experience with Windows RT development and what that can do.
As for the screen resolutions, some of the article is what Jay believes will be the case, no-one is wrong yet :) We will have to see when the SDK is out or we get more information

The only information we have on screen resolutions is that there will be three of them:

WVGA at 480x800 (15:9)

WXGA at 768x1280 (15:9)

720P at 720x1280 (16:9)

A recommendation (if using XAML) is to use Grids wherever possible as they will automatically stretch and re-flow controls for you, rather than forcing you to consider it. When you make the Grid set the first RowDefinition Height value to be "Auto", then use "*" after that. Set ColumnDefinition Width values to "*" as well, this should let things scale.

i wonder if that will matter? I wonder if WP8 will be clever enought o say, well his app width is 480 and height is 800, im going to use scaling on this. Although your approach is pretty sensible anyway ;)

I've been trying to do this but at one point I wanted a negative margine (to hide some UI elements I needed to slide with animantion later). The grid is practically the only control that supports proportions and it only supports it for Width and Height, not for things like margins. Of course I may be wrong on this since currently I don't have much experience with XAML-based development.

Also note that Joe mentioned something about hardware support for auto scaling. Maybe old apps that are supposed to support only the 480x800 resolution will auto scale even concrete pixel values.

I've seen dramatic performances differences between using stackpanels and grids for complex layouts, particularlly stackpanels inside a grid. Changing to a full grid implmenation really sped up the app.

One thing people have got to see the writing on the wall here by now is the fact that this is the stepping stone to the next version. They're laying the ground work for W/WP9 which will be entirely unified and will no doubt be a truly cross-platform OS. Today-- a lot of code sharing. Tomorrow-- total code sharing. Microsoft has always been good at this sort of thing. They know how to woo developers, and it shows... 50,000 apps faster than iOS and Android and 100,000 apps faster than Android? Nobody can say people aren't interested with a straight face anymore.

The amazing thing about the speed to 100K compared to ios/android is the small marketshare.
IOS went to 100K faster because some fart noise app made a ton of money and everybody jumped in to cash in (most didn't of course).
There will always be differences between WP and windows, just because of the different form factors (charms barely make since on a tablet, make no sense on a phone), but if developers can write once and only adjust the UI layout for different screen sizes, that will save so much work. (even if you don't use margins and fixed pixel layouts, you need to take advantage of the larger screen)

I guess we need to wait for the SDK to know for sure, but I want to see how we can structure/code an app that targets WP7/WP8/Win8. I would love to be able to reuse the code for the Model and ViewModel across all three without a ton of #if/#endif for different namespaces. If we could reuse those peices and just build different views in xaml that would be amazing.

Woohoo Jan nice article! I'm on fire with excitement about Windows Phone 8 and Windows 8 tablets (Surface anyone?). Does Microsoft have their mojo back or what? I'm praying they come out with their own phone after seeing what they did with the Surface tablet. Not that the Lumia 900 wasn't a nice phone, it was. But I don't think anyone saw this type of premium design coming from Microsoft, except maybe die hard fans of the Zune HD which really was a very nice device. Keep it up Jay, rock the Windows Phone World baby!

I hope some of these rumored additions are true. The app-to-app communication in windows 8 includes more than the protocol activation you mention here. that feature is very similar to the ios/android implementations (where you register your url/intent with the system)
What I like in windows 8 is the pre-defined protocols (sharing for example). It just works and looks better