Don’t get fooled by the version number: Windows Phone 8.1 isn’t just a minor update, but it’s a totally new version of our favorite operating system, both for users but, most of all, for developers. At a first glance, you may think that it’s the usual Windows Phone you already know, with its tiles and the familiar user interface. However, under the hood, there’s a huge number of new features that turns greatly improve the platform’s quality and experience.This new version was awaited since a long time and, finally, yesterday Microsoft has revelead it during the BUILD’s keynote, the most important Microsoft conference that is running in these days in San Francisco.

Since, if you’re reading this post, you’re probably a developer, let’s start by talking about all the new features that you probably care most about. Be prepared, because this is probably one of the longest posts I’ve ever wrote Smile

Welcome Windows Phone Store apps!

If you’ve ever tried to develop an application that targets both Windows Phone and Windows 8 you would have discovered that sharing code between the two platforms is not that easy: despite the fact that, under the hood, you can find the same framework, which is the Windows Runtime, there are a lot of features that are implemented using different classes and methods (like tiles, push notifications or the XAML controls). Windows Phone 8.1 changes everything, by sharing almost all the APIs and features that have been introduced in Windows 8. For this reason the new SDK has added a new kind of applications called Windows Phone Store apps: basically they are the same as Windows Store apps, but for Windows Phone, since they share almost all of the features and APIs. If we have already developed one or more Windows Store apps you’ll find yourself at home: application lifecycle, background tasks, XAML controls, etc. are exactly the same you can find in Windows 8.1. Also the package delivered by Visual Studio isn’t a XAP anymore, but it’s an AppX package, which contains a new manifest file called Package.appxmanifest.

For this reason Visual Studio now offers also a new template to create Universal Windows apps, which makes the life easier to developers that are willing to create an application that targets both Windows 8.1 and Windows Phone. This template includes two different projects for the two platforms, plus a new shared project: all the code we include will be automatically shared with the other projects, using the linked files approach. This means that the files that are part of the shared project are physically stored just in one location, but they are added as link to the other projects. This approach was already available in the past and it was, indeed, one of the strategies to share as much code as possible between a Windows Store app and a Windows Phone app: the difference is that, if in the past you were forced to use a lot of tricks and workarounds (like conditional compilation symbols) due to the many differences between the two frameworks, now everything is much easier, since the two runtimes are basically the same. This way you’ll be able to write your application’s logic just once and you’ll have just to take care to create two different user interfaces, due to the user experience’s differences between the tablet / pc world and the smartphone one (if this doesn’t mean that you won’t be able to reuse the same XAML code at all).

Another cool announcement related to Universal Windows apps is that, in the future, they’ll be able to run also on XBox One, bringing full convergence across all the screens: tablets, smartphones, computers and TVs.

The Windows Phone Store apps are completely based on the Windows Runtime, XAML included: we don’t have to deal anymore with the managed XAML available in Windows Phone 8, which was still based on Silverlight, but now we can work with native XAML, which offers much better performances. However, there’s a downside: due to the many differences, you won’t be able to automatically upgrade your existing Windows Phone applications to the new framework in the same way like, for example, you do now when you want to migrate a Windows Phone 7 app to Windows Phone 8. There are many reasons, like:

  • The Windows Phone Store apps only support the new Windows Runtime APIs: as a consequence, all the old Silverlight APIs (like background tasks, tiles management, network interaction, ecc.) are no longer working.
  • The new native XAML is based on a set of namespaces and controls which is different from the Silverlight ones: many controls, like Panorama or LongListSelector, are not available anymore and they need to be replaced.
  • The application lifecycle and the navigation framework offered by the Windows Phone apps are very different from the Silverlight ones.
  • Since the Windows Phone Store apps are no longer based on the .NET framework, all the third party libraries that still relies on it won’t work anymore. We’ll need to use specific versions of the libraries that can target the Windows Runtime (however, most of the libraries that are available for the Windows Store apps will work just fine).

If you’re already a Windows Phone developer, don’t panic! Microsoft didn’t leave you behind, but they’ve also updated the Silverlight runtime with the new 8.1 APIs and features, by introducing the Windows Phone Silverlight 8.1 apps. This means that you’ll be able to right click on an existing Windows Phone 8.0 project and choose the option Upgrade to Windows Phone 8.1: this way, you’ll be able to use almost all the new APIs (including the Windows Runtime’s specific ones, like the new background tasks or contracts) without losing the compatibility with your existing codebase. Of course, this approach has some downsides: it will be harder to share code with a Windows Store app (since the XAML, the application lifecycle, the navigation framework, etc. will continue to be different) and you’ll lose most of the performance improvements offered by the new runtime.

It should be clear, now, that Windows Phone 8.1 is totally compatible with Windows Phone 7.1 / 8.0 applications: you’ll need to update your application to 8.1 only if you’re planning to make use of some of the new features. Of course, the new 8.1 apps can be launched only on 8.1 devices: if you want to keep the compatibility with Windows Phone 8.0 and, at the same time, use the new 8.1 features you’ll have to maintain and publish two different projects. However this time, unlike it happened with Windows Phone 8.0, it’s just a temporary requirement: since Windows Phone 8.1 is going to be available as a free update to every Windows Phone 8 device on the market, in the long term you won’t be needed anymore to keep two versions of the same project, since eventually every user will be able to use just the 8.1 version.

In the end, the Windows Runtime has added a new important feature: WinJS support. Exactly like you can do nowadays with Windows Store apps, you have the chance to develop native applications (and not just simple web applications that are rendered using a WebBrowser control) using HTML and Javascript thanks to a library called WinJS, which grants access to all the Windows Runtime APIs and features using Javascript as a programming language, in replacement of C#, VB.NET or C++, and HTML as a design language, in replacement of XAML. At the same time, Microsoft has announced that WinJS is being released as an open source and cross platform library on GitHub.

Which framework should I choose?

Probably now, after reading about the coexistence of two frameworks, you were wondering which one you should choose to develop a Windows Phone 8.1 application. The first thing to consider is if you’re planning to develop a new app or to upgrade an existing one: if it’s the first case, the Windows Phone Store apps are, for sure, the most interesting path to take. If you’ve never developed a Windows Store app there will be a starting learning curve, since you’ll have to know and master all the differences with the old approach when you have to deal with lifecycle, navigation, background activities, etc. However, in the end you’re going to develop an application that can be easily ported to Windows 8.1 and that can take advantage of the new performance improvements introduced by the Windows Runtime.

On the other hand, if you already have an existing application and you just want to make use of some of the new Windows Phone 8.1 feature, the simplest path to take is to keep using the Silverlight framework: this way you’ll be able anyway to make use of the new features without having to rewrite the application from scratch. Then, in the future, when Windows Phone apps will take off and the number of supported libraries will increase, you may evaluate to migrate your existing application to the new runtime.

However, there’s another series of things that are important to keep in mind when you have to make this choice: there is a list of features that, for timing and resources issues, the team wasn’t able to make available in both frameworks. For this reason, if you choose to develop a Windows Phone app, you won’t be allowed to:

  • Use the APIs to interact with the clipboard
  • Define your app as a lock screen provider, so that it can change the lockscreen’s wallpaper
  • Define your app as a ringtone provider
  • Use Alarm and Reminders
  • Develop a Lens App (which are photographic apps that can be integrated with the native camera app)
  • Keep an app running under the lock screen
  • Use the Continuous Background Tracking APIs, that can be used to continuosly track the user’s position even when the app is not in foreground
  • Use VoIP APIs
  • Use the CameraCaptureTask, which is the chooser that can be used to take a picture with the native camera app and import into your application

On the other side, if you develop a 8.1 application using the Silverlight framework you won’t be able to:

  • Use the old APIs to manage background audio. You will have to migrate to the new Windows Runtime APIs or keep your application as a Windows Phone 8.0 app
  • Make use of the new XAML framework, which is able to fully support devices with different screen sizes
  • Use the new XAML controls, like Hub or GridView
  • Use the new APIs to edit videos
  • Use the new Visual Studio tools for profiling and coded UI tests

It should be clear now that the framework’s choice can’t be based just on the type of application (new or existing one) but also on the features you want to use: if, for example, you’re developing a Lens App or an images catalogue app which acts as a lock screen provider, you’ll be forced to develop a Windows Phone Silverlight 8.1 app.

New Stores shared experience

Thanks to the Universal Windows apps ,both Windows 8 and Windows Phone stores introduce a new shared experience for our apps: we’ll be able to publish the two versions of our app on both stores but, since they’ll share the same application identifier, the user will be able to buy it just once and install it on all his devices. In addition, you’ll be able to share settings and in-app purchases between your Windows Phone and Windows Store app.

New development tools and emulator

The Windows Phone 8.1 SDK is completely aligned with the latest Microsoft development technologies: the SDK, in fact, is based on Visual Studio 2013 which, for the occasion, has been updated to the Update 2 RC release. There are also many improvements with the emulator: the first thing to mention is that now it’s able not just to simulate different resolutions, but also different screen sizes. This scenario is becoming more and more important every day, since in the mobile market you can find devices with very different screen sizes: from small devices, like the Lumia 620 (3.8 inches) to phablets, like the Lumia 1520 (6 inches). Now, in the debug dropdown menu, other than the usual indicator about the supported resolution (like WXGA, WVGA, 1080p, etc.) you’ll find also the screen size, as you can see in the following image.

image6_thumb3

The second news is connected to the touch screen simulation: finally we’re able to simulate multi touch gestures (like pinch to zoom) also using the mouse, while previously the only way to do that was using a touch screen device.

The third and last new feature is connected to the additional tools that are bundled with the emulator: Windows Phone 8.0 introduced some nice tools to simulate geo location or accelerometer. Windows Phone 8.1 has added to the list:

  • A tool to simulate the type and the network speed (Wi-Fi, 2G, 3G, etc.)
  • A tool to simulate push notifications: we won’t have anymore to send real push notifications from a server application to test if our Windows Phone app correctly manages them
  • A tool to simulate the SD card: we can set up a folder and make the emulator thinks that it’s a removable card, so that we can test the new APIs to read and write data from a SD card
  • A tool to create emulator’s snapshot: the Windows Phone emulator automatically resets itself when it’s closed, including all the data we’ve created (installed apps, storage, etc.). With this new feature we’ll be able to create checkpoints of a specific status and restore them in a second time.

image1_thumb2

 

Another news connected to Visual Studio is a new manifest file, which is now included in the project’s root and it’s called Package.appxmanifest: it’s very similar to the Windows Store apps one and, other that supporting features that should already be familiar to Windows Phone developers, like assets and capabilities managements, we can find new sections like Declarations, which can be used to set up the contracts and the various extensibility points of the application. Another new important feature that we can find in the manifest file is the ability, for the user, to install our application on a SD card: as developers, we are able to disable or enable this feature.

image4_thumb3

The new Windows Phone 8.1 features for developers

It would be almost impossible to deeply analyze all the new Windows Phone 8.1 features, since the list is too big. In this post I will just highlight the most important ones.

Application lifecycle and navigation framework

The Windows Phone Store apps’ lifecycle is the same supported by the Windows Store apps and it has many differences with the old one offered by the Silverlight framework. Under the hood, the architecture is very similar: the application, when it’s suspended, gets “frozen”, which means that every thread and operation is aborted; this way, the application will keep using just memory, but all the other resources (hardware sensors, CPU, etc.) will be released. Without a warning, the operating a system is able to kill a suspended application, in case the left memory is not enough to allow the user to open new applications: as developers, we are required to manage this scenario (which in Windows Phone 8.0 was called tombstoning) to properly save and load the application’s state, so that the user can act like if the application has never been terminated. The main difference with the old approach is that now applications are always suspended: if the user presses the Back button in the first page of the app, it won’t be closed anymore but just suspended, like if he has pressed the Start button. This means that the system, regardless of the way the user will open back the application (using the task switcher, tapping on the tile in the Start screen, etc.), will always resume the previous instance (unless he has explicitly closed the application tapping on the X icon that is displayed in the task switcher).

image8

The other big difference with the previous runtime is the navigation framework: as a standard behavior, the Back button doesn’t automatically redirect anymore the user to the previous page of the app, but to the previous app in the operating system’s stack. If we want to keep the previous navigation approach we need to intercept the Back button and redirect the user to the previous page: by default, the new Visual Studio templates include some code snippets that will take care of this scenario for you. Another new feature connected to the navigation framework is that the NavigationService class is now gone and it has been replaced by the Frame one, which represents the page’s container of the application and, thus, it offers all the methods to move the user from one page to the other. One of the biggest advantages of this class is that it’s not connected anymore the old Silverlight approach, which was based on Uris and, as a consequence, it allowed us to carry only textual parameters from one page to the other: now we are able to exchange also complex objects.

Another new important feature is that Windows Phone now fully support the contracts approach, which are a way to extend our applications and integrate them in the operating system. One of the most useful contracts is called sharing and it allows developers to create apps that are able to share a content to another app (in this case, we talk about sharing source apps) or to receive a shared content from another app (in this case, we talk about sharing target apps). The contracts approach introduce a new behavior in the application lifecycle: the app can be opened not just by the user, but also from another app; exactly like we do in Windows Store apps, the App.xaml.cs file is able to manage all the entry points of our application

image9

If you decide to keep using the Silverlight framework, no one of the just explained features will apply to you: the Back button will continue to redirect the user to the previous page within your app and, if it’s pressed in the main page, it will close it. The only difference is that, now, Fast App Resume is enabled by default: the suspended instance of your application will be always resumed, regardless of the entry point.

The new XAML features

The new XAML runtime includes a lot of new controls and features, which are aligned to the Windows Store app ones: for this reason, the Windows Phone Toolkit is not needed anymore for Windows Phone apps, since all the controls are now included in the Windows Runtime. We can split the controls in three different categories:

  • Common: these are the controls that have the same visual layout and behavior on both platforms, like Button, TextBlock and TextBox
  • Optimized: these are the controls which have the same behavior, but a different visual layout to match the platform’s guidelines. The DatePicker controls is a sample of this category: the behavior is the same on both platorms (it can be used to choose a date), but on Windows 8 it’s rendered as a series of dropdown menus, while on Windows Phone 8.1 it’s displayed in a new page.
  • Signature: these are the unique controls that are available only on one platform or that are available on both, but with a completely different layout and behavior. The Pivot control is part of the first category, since it’s available just in Windows Phone. The AppBar control, instead, is part of the second one: it’s available on both platforms, but with a completely different implementation.

The biggest advantage of this approach is that we’ll be able to reuse the same XAML on both platforms: by using UserControls we’ll be able to share not just the logic, but also part of the user interface between the Windows Phone and the Windows Store app.

The new XAML runtime includes also many new changes when you have to deal with signature controls:

  • The Panorama control has been removed and replaced by the Hub one
  • The application bar is now implemented using the AppBar control, which supports two kind of commands: PrimaryCommands and SecondaryCommands. In Windows Store apps the difference between the two categories is referred to the position of the commands (on the left or on the right of the screen); in Windows Phone apps, instead, we can distinguish between icons (the PrimaryCommands controls replace the old ApplicationBarIconButton ones) and menu items, which are displayed only when the application bar is expanded (in this case the SecondaryCommands controls replace the old ApplicationBarMenuItem ones). Another important news, especially if you work with the MVVM pattern, is that now the AppBar control fully supports binding, both to define properties and commands.
  • Windows Phone 8.0 introduced a new control called LongListSelector to manage grouped data collections (like the hub People, for example, groups the list of contacts by the first letter of the name). However, it wasn’t really simple to use: one of the biggest limitations was the requirement to create a new class to manage the grouping, instead of allowing us to work directly with the original data collection. Now the LongListSelector has been removed and replaced by two controls that should already be familiar by the Windows Store apps developers: GridView and ListView. These controls, other than being optimized to manage large collections of data, help us to simplify the code needed to manage grouping. In addition, they support the semantic zoom concept, which has been added in Windows 8 and can be used to quickly see all the available groups and jump from one to the other.

image2_thumb5

The other big news connected to the XAML runtime is the new layout management: Windows Phone Store apps don’t have anymore a fixed layout that is automatically scaled according to the phone’s resolution, but they uses a fluid layout, that is able to adapt to any resolution and any screen size, exactly like the Windows Store apps do to properly support at the same time small tablets and big monitors.

All the new XAML features mentioned in this section are available just for the Windows Phone Store apps: the Silverlight apps keep using the old XAML frameworks and, as a consequence, you won’t find the new controls.

Dealing with local data: the storage APIs

Windows Phone 8.0 did a first attempt to unify the storage APIs with the Windows Runtime ones, by introducing classes like LocalStorage, StorageFolder and StorageFile. Windows Phone 8.1 completes this unification, by supporting all the features and APIs that were still missing in Windows Phone 8.0. The most important features are:

  • A new way to manage settings
  • A new storage called TemporaryStorage, which can be used for caching purposes: the storage’s content, in fact, is automatically erased by the operating system
  • A new storage called RoamingStorage, which has a limited size (100 KB) but which content is automatically synced with all the other devices that are have been configured with the same Microsoft Account (regardless if they’re Windows Phone devices or Windows 8 tablets or computers).

Another important new feature is the capability to access to all the data that is stored in the multimedia library of the user: thanks to the KnownFolders class (which offers different storage’s types, like PicturesLibrary, MusicLibrary and VideosLibrary) you’ll be able to access (both for reading and writing purposes) to all the user’s pictures, videos and audio tracks. The same limitation has been removed also when you want to deal with the SD card that is supported by some devices: now you’ll be able to read and write data on the external memory. In the end, in Windows Phone 8.1 we are able to better manage and import file from other applications or from the phone, by using the FileOpenPicker and FileSavePicker classes.

image7

 

Geolocalization and geofencing

The biggest new feature introduced in Windows Phone 8.1 connected to the geo location services is geofencing support, which was already introduced in Windows 8.1: with the new APIs you’ll be able to define an area on the map and, when the user walks into it, your app will be notified, even if it’s not running thanks to a new kind of background task. There are a lot of scenarios that can make use of this new feature: let’s think about an application connected to a commercial activity, that can notify to the user all the promotions that are running in the shop he has just walked in.

The new geolocation APIs offers also a complete unification with the Windows 8.1 ones: the only exception is with the maps controls which has two different implementations at the moment. In Windows 8.1, in fact, you still have the Bing Maps control, while in Windows Phone you can use the Here Maps one, which uses the Nokia services.

Tile, notifications and notification center

Windows Phone 8.1 introduces big news in the tiles management: instead of the original 3 templates available in Windows Phone 8.0, now you have access to the full catalog of 40 templates that are available in the Windows Runtime and that are shared with Windows 8.1. The new templates are much more flexible than the old ones: now you can manage multiple images, text lines or badges. The tile architecture is the same we’ve learned with Windows Phone 8.0: every tile is represented by a XML layout, which contains all the properties that define the visual layout of the tile. The difference is that, now, the templates are shared with the Windows Store apps and automatically adapted to the platform: in case there are some properties that can’t be rendered on one of the two platforms, they will simply be ignored. The same applies for toast notifications: the code to define a toast is exactly the same, but the visual layout they will look very different between Windows Phone 8.1 and Windows 8.1.

An important difference to highlight between the old and the new approach is that the XML layout is used for any scenario: in Windows Phone 8.0 XML was required just for push notifications, while in a background agent or within the app you were able to use classes like ShellTile and ShellToast. In Windows Phone 8.1, instead, tiles and toasts are are always represented using XML data: you’ll need to manipulate the XML document to set the different tile properties, like in the following example.

private void OnSendNotificationClicked(object sender, RoutedEventArgs e)
{
    XmlDocument xml = TileUpdateManager.GetTemplateContent(TileTemplateType.TileWideText01);
    XmlNodeList nodes = xml.GetElementsByTagName("text");
    nodes[0].InnerText = "This is the text";

    TileNotification notification = new TileNotification(xml);
    TileUpdateManager.CreateTileUpdaterForApplication().Update(notification);
}

In case you prefer to use a more traditional approach, based on classes and objects, you can find on NuGet a library provided by Microsoft called  NotificationsExtensions. By using it, you’ll be able to change the previous code like the following one:

private void OnSendNotificationClicked(object sender, RoutedEventArgs e)
{
    ITileWideText01 tile = TileContentFactory.CreateTileWideText01();
    tile.TextBody1.Text = "Line 1";
    tile.TextHeading.Text = "Title";

    TileNotification tileNotification = tile.CreateNotification();
    TileUpdateManager.CreateTileUpdaterForApplication().Update(tileNotification);
}

image3_thumb2

This new approach improves a lot the tile and toast management for developers, especially when you have to deal with push notifications. We’ll be able, in fact, to send from a server application (like a cloud service) the same exact notification to Windows Phone and Windows Store apps and they’ll both be able to receive it with success. As a consequence, you probably have already guessed another new important feature introduced in Windows Phone 8.1: push notifications are now sent using the WNS (Windows Notification Service, which is the service used for Windows Store apps) instead of the old MPNS (Microsoft Push Notification Service). The architecture is the same: the application subscribes to receive notifications and receives from the WNS a URL that univocally identifies the channel; server side, when you want to send a notification to the device, you simply send a HTTP request using a POST command do the URL that identifies the channel: the body of the request is the XML data that represents the notifications. This way, you’ll be able to unify the push notifications management in your backend service: we’ll be able to send the exactly same notification to both platforms.

If you already have an existing app which uses push notifications, don’t worry: MPNS is here to stay and you’ll be able to keep using it. However, if you want, you’ll be able to use the new tiles management and the Windows Notification Service also from a Windows Phone Silverlight 8.1 app.

For sure, the biggest new feature (especially from the user point of view) connected to notifications is the action center: by swiping from the top to the bottom of the screen we’ll be able to access to this new screen, which stores all the toast notifications that all your apps have received. The action center fills one of the biggest Windows Phone 8.0 limitations: if the user received a notification while he was distracted and the app wasn’t set up to display notifications on the lock screen or on the tile, the user didn’t have any chance to retrieve it. Now, instead, all the notifications are automatically stored in this new view, grouped by application. As developers, this new feature is completely transparent: automatically, all the toast notifications that are sent to our application will be automatically kept in the action center. However, we have the chance to interact with it thanks to some properties that are exposed by the ToastNotification class (which identifies, as you can imagine, a toast notification): for example, we can define after how much time the notification should disappear from the action center (by using the ExprationTime property) or we can send to the application “ghost notifications” (by setting to true the SuppressPopup property), that are not displayed to the user in the regular way but they are simply stored in the action center. We can also remove notifications generated by our application, by using the ToastNotifcationHistory class.

QuickAction_Default_16X9

Background operations

Windows Phone 7.5 introduced background agents, which are separated projects that contains some code that can be executed periodically from the operating system even when the application is not running. Windows Phone 8.1 improves this area by following, again, the Windows Runtime approach: we’ll keep working with separated projects called background tasks, which offers much more flexibility than the old background agents. Background tasks, in fact, are based on triggers: if background tasks were limited to be executed according to specific time conditions (for example, every 30 minutes), background tasks, instead, can be automatically activated due to a system status change (SystemTrigger, like Internet connection available or not available); when the user walks into a specific are (LocationTrigger, they are connected to the new geofencing APIs); when the app receives a push notification (PushNotificationTrigger); when the device connects or disconnects with another device using Bluetooth (BluetoothSignalStrengthTrigger). If you just need to recreate the old background agent experience don’t worry, you have also some triggers for that, like TimeTrigger (which can be used to peridocailly run the background task, the minimum intervalis 15 minutes) and MaintenanceTrigger (which replaces the ResourceIntensiveTask and can be used to perform long running operations that should be execute only when the phone is charging).

Thanks to Visual Studio improvements, it’s now easier also to test background tasks: in the Debug toolbar now we have a useful dropdown menu that can be used to trigger a background task’s execution anytime we need.

image5_thumb2

There are also some regardless other background scenarios, which, again, have been aligned to the Windows Runtime APIs:

  • Background transfers are now achieved using the BackgroundDownloader and BackgroundUploader classes, which are more flexible
  • You can develop multimedia applications that can reproduce audio in background using a new set of APIs, which area great improvement compared to the old ones

New APIs to interact with other devices

Windows Phone 8.0 added a new set of APIs called Proximity APIs, which can be used to interact with other devices using technologies like NFC and Bluetooth. Windows Phone 8.1 adds a bunch of new features in this category, by introducing support to two new technologies:

  • Bluetooth Low Energy (BLE), which is a new Bluetooth standard that is widely used by many new devices on the market like smart watches, fitness bracelets, medical equipment, etc. Windows Phone 8.0 Update 3 introduced the support to these kind of devices, but just from a user point of view: the phone was able to connect to some of these devices and interact with them. Now, instead, we are able to interact with these devices also from third party applications
  • Wi-Fi Direct, which is a technology that can be used to establish a direct connection between two devices using Wi-Fi

Multimedia

Windows Phone 8.1 introduces a new set of APIs called Media Foundation APIs, which were already part of the full Windows Runtime in Windows 8: you’ll b able to developer advanced applications that are able to manipulate audio and video and to play multimedia content. There’s also a new set of APIs inside the Windows.Media.Editing namespace, which can be used to perform video editing operations: we’ll be able to developer apps that will allow the user to trim, add effects or manipulate videos that have been recorded with the phone.

Inside this category we can find also some new classes that can be used to record the user’s activity on the screen: we’ll be able, for example, to include a recording feature inside our game, so that the user can share his best match with his friends or on social networks.

The new consumer features

Windows Phone 8.1 isn’t just a big update for developers, but also for users: other than being able of make use of all the new features that the application will be able to implement, users will find many new features integrated in the operating system. Here are the most important ones:

  • A new feature called Cortana, which acts both as a vocal assistant (she’s able to interact with the user by voice) and as personal assistant (she’s able to remind you important things, scan your mail to plan your travels, etc.). Plus, third party applications will be able to integrate with it, so that Cortana can search data directly in your application.
  • New start screen customization: now you can set a background image, which is applied to all the transparent tiles with a parallax effect; in addition, you can reduce the tile size, so that you can display a third column even on devices without a big screen.
  • The action center, other than being a container for all the toast notifications received by the applications, gives quick access to the network settings: you’ll be able to quickly enable or disable Wi-Fi, Bluetooth, etc.
  • Complete backup of the phone, including the tile layout on the Start Screen.
  • The Store app has been completely redesigned, to give more visibility to the best applications.
  • Now you can force the Store to check updates for the installed apps or, like in Windows 8, you can enable auto update, so that apps are automatically updated without manual confirm from the user.
  • New Calendar app, with new options (like weather forecast) and a new weekly view.
  • New Camera app, with support for burst mode (the camera takes many photos at once, so that you can choose the best one and discard the others).
  • Internet Explorer 11, which improves support for the latest web standards (HTML5, WebGL, etc.); automatic bookmarks sync with your  Windows 8 pc or tablet; integrated password and download manager; Reading mode, which is able to adapt a page’s layout so that it’s easier to read.
  • New enterprise features: VPN support, better devices management, new policies to decide which apps can be installed from the store, encrypted mails support, Wi-Fi enterprise support, etc.
  • New swipe keyboard, that can be used to insert texts without releasing your finger from the touch screen
  • New Sense applications: Battery Power Sense, to keep track of the battery usage made by every single app; Wi-Fi Sense, to share your Wi-Fi connections with another device; Storage Sense, to keep track of the storage occupied by every app.
  • You can project your phone’s screen on another screen, like a monitor or a TV, both with a wired connection (using the USB cable) and with a wireless one, using Miracast

Wrapping up

As you can see, Windows Phone 8.1 is more than just a simple update: it’s a new starting point, that adds a new and important piece of the puzzle of the Microsoft ecosystem. If you already are a Windows Phone developer, this new release will give you the chance to push your application even further: thanks to the new features, you’ll be able to easily port your application to Windows 8.1, giving you more chances to make money and to increase your number of users.

On the other side, if you already are a Windows Store app developer, you’ll find yourself at home: one of the biggest complaints in the past was that, even if Windows Phone 8 and Windows 8 apps shared many similarities (like the application lifecycle, the user interface approach, etc.) most of them were implemented with totally different APIs. Now, instead, this problem has been fixed and there are only a few scenarios where you won’t find APIs convergence (and, in most of the cases, this happens just because there are some scenarios which don’t make sense both on tablets and smartphones).

And now, let’s share some release dates:

  • During the BUILD’s keynote Microsoft announced also a new update for Windows 8.1, which brings some features that will improve the desktop experience. The update is already available for MSDN subscribers and it will be released on 8th April via Windows Update to every Windows 8.1 device.
  • MIcrosoft will release a Windows Phone 8.1 Preview for existing phones via the Preview for Developers Program during April.
  • Starting from May / June, vendors and operators will start to release Windows Phone 8.1 as an OTA (Over The Air) update to every existing device
  • Later this month Microsoft will also open the Store to accept the submission of Windows Phone 8.1 apps

And here are some links that can be helpful:

We have just scratched the surface! In the upcoming months we’ll have the chance to cover more deeply all the new features and to learn how to implement them in our applications!

Tagged with:  

I’m happy to announce that, last week, Syncfusion, a popular company among developers for their great suites of controls, has released my new book titled Windows Phone 8 Development Succinctly. It’s a digital free e-book and, in 243 pages, it covers most of the important concepts to develop a Windows Phone application, from the basic ones (like the XAML, the application lifecycle, etc.) to the most advanced ones (like background tasks, geolocalization and speech APIs).

Here is a quick recap of the chapters:

  1. Introduction
  2. The User Interface: Basic XAML Concepts
  3. Core Concepts
  4. Data Access: Storage
  5. Data Access: Network
  6. Integrating with the Hardware
  7. Integrating with the Operating System
  8. Multimedia Applications
  9. Live Apps: Tiles, Notifications, and Multitasking
  10. Distributing the Application: Localization, the Windows Phone Store, and In-App Purchases

The book is distributed by Syncfusion for free, you just have to register and then you’ll be able to download it both in PDF and Kindle format. I hope that the book can be a great resource both for new developers, that want to start learning the basic Windows Phone concepts, and for already skilled developers, that can use the book as a reference for all the APIs and features offered by the platform.

So don’t waste anymore time and head to http://www.syncfusion.com/resources/techportal/ebooks/windowsphone8 to register and download your free copy!

 

Tagged with:  

A few days ago Microsoft has finally released a new set of emulators that are aligned with the latest Windows Phone update, GDR3, which is available to developers since a while and that it’s going to be released soon for all the consumers. One of the most important additions is a new emulator image for the new resolution introduced with GDR3, which is 1080p (1080×1920). But there’s an important thing to highlight: resolution and screen size are two different parameters! If a device is using the 1080p resolution, it doesn’t mean that it has a big screen. Take, as example, the Lumia 1320: it features the same resolution of other devices on the market (720p), like the HTC 8X, but it offers a much bigger screen (6 inches).

This means that knowing the device’s resolution isn’t enough: if you want to adapt your application to devices with big screens (by showing, for example, more information), you need to know the real size of the screen. All the emulators included in the SDK simulates a standard device: you can notice, in fact, that the 1080p emulator offers the standard interface with two columns of tiles, while devices like the Lumia 1520 and Lumia 1320 offers three columns of tiles.

And what if you want to optimize your app for bigger screens and you don’t have a real device to play with? Rudy Huyn, the developer behind many famous apps like 6tag or 6sec, has created a simple class that can be used to “fake” the big screen, so that you can test your apps using one of the standard emulators.

Here are two articles that you’ll find useful to adapt your applications:

Happy coding!

Tagged with:  

For me the first day of the year is always a special day: not only because it’s a day full of hope for the things that are going to come during the year, but also because it’s the day in which, since 2011, my MVP status expires. If you’re not familiar with the MVP, it’s an award gifted by Microsoft to the community leaders for their passion and enthusiasm in sharing their knowledge about Microsoft technologies (in my case, about Windows Phone development). It’s not a “one time” award: you have to earn it every year and to prove that you still deserve it. For me, this time of the year is 1st January: and I’m really happy to say that Microsoft has confirmed his trust in me and renewed my award also for 2014!

2013 has been a crazy year for me as an MVP: 2 summits, the release of my first book, the Windows Phone Week organization, the Italian webinar series with Nokia and much much more. There are so many people to thank for this great year! The first one is, for sure, my wife Angela, that keeps supporting me, even when my activities steal some of the time that we can spend together. Then, in random order:

  • Lorenzo Barbieri, which is not only a friend but he’s also the best supporter (together with the DPE department) of the Windows Phone activities that we organize with the community.
  • Daniele Pagani, Luca De Bernardi and Frangino Lucarini, which are part of the Italian Nokia team that are doing an amazing job in supporting the Italian Windows Phone developers and our activities as Nokia Champions.
  • Desiree Lockwood, the referral for our activities as Windows Phone Development MVPs. She’s an amazing person and she’s doing a terrific job. Without her, the Windows Phone Week (and many other activities) would have been just a crazy idea.
  • The Windows Phone Development’s MVP family (with a special mention to Joost Van Schaik): they’re the living proof that being part of the MVP family doesn’t mean just connecting with great professionals, but also that you can find and meet great friends, even if they live far away from you.
  • Ugo Lattanzi: if today I have the pleasure to be part of the MVP family it’s totally his fault Smile He’s the one that, 5 years ago, made me discover the community world and conviced me to open a blog and to do my first speech about Windows Phone. Everything started right there Smile
  • Roberto Freato and the DotNetLombardia crew, which accepted me as part of the community and involved (and keep involving me) in all their activities.
  • Funambol and my team: I’ve joined the company more than 1 year ago and it has been one of the best things that happened in my life. I met many special people and friends and I love the way the company keeps supporting my community activites. I’m really proud to be part of it!

But, of course, my biggest thank goes to all the developers and communities out there, which keeps supporting and believing in me. I’m looking forward to keep working with you in 2014!

Tagged with:  

For sure one of the best 2013 moments for me was the Windows Phone Week organization: born as a crazy idea from three friends, it quickly turned out into an international initiative that brought more than 20 events all around the world. Seeing the enthusiasm and the passion of all the Windows Phone developers out there was really great and insipiring.  All of us instantly understood that this couldn’t be a “one time experience”: we had to find a way to keep supporting all the Windows Phone developers to find great content and to meet each other and, at the same time, to grow and to learn from our mistakes.

So.. say hello to WP Dev Fusion! My MVP friend Peter Nowak, from Germany, had a great idea: Windows Phone Week was great, but what about all the people that weren’t able to join a local event? Why we don’t find a way to support and get in touch with everyone? So WP Dev Fusion was born, as the natural successor of the Windows Phone Week.

What is WP Dev Fusion? It’s a new community initiative, with the goal to continue the good work made with the Windows Phone Week and to expand it, so that we can reach developers from all around the world. WP Dev Fusion will continue to have a traditional offline soul: you will see, for sure, new events and initiative organized in various places all around the world with the WP Dev Fusion brand, thanks to Microsoft and Nokia support. But we will have also an online soul: other than just spreading the latest and most important news about Windows Phone development with our social channels, we’ll regularly organize virtual conferences, that can be followed online from the comfort of your home. This way, we’ll deliver the best content with the support of the best speakers directly to your home!

And which is the best way to launch a new community initiative? To organize a conference, of course! So let me introduce you to the first WP Dev Fusion virtual conference, that will be hosted on 22nd January 2013, starting from 6 PM (CET timezone): after a brief introduction, a group of Windows Phone Development MVPs will introduce you to many development topics, like maps, speech API, App Studio, etc. I’ll have the chance to speak too about local data access in Windows Phone applications. Like in a traditional conference, you’ll have the chance to ask questions and to give feedback. At the end of the day, we’ll host also a “Ask The Expert” session, so that you’ll be able to ask any question you may have about developing apps for Windows Phone.

So, what are you waiting for? Go to the official website to register and to read the complete agenda: registration is needed to understand how many people will join and to prepare the needed infrastructure. You’ll be contacted with all the needed information to get access to the conference before 22nd January.

See you online!

Tagged with:  

If you’re a Windows Phone user, you’ll probably know that Microsoft offers two Facebook applications: an official one and a beta one. The second one is simply a “test field” for all the new features that, from time to time, are added to the application by the team: after a reasonable time, the features are considered stable and are “promoted” and added also to the official application. Some months ago Microsoft has added to the beta application a really interesting feature for developers: a way to use it as a “bridge” to integrate Facebook into our applications. This feature still relies on the existing Facebook SDK for .NET (a library available on NuGet to easily integrate Facebook in our applications) but, instead of asking to devs to create their own login page in their apps, everything is made by the Facebook app. Here is the flow if you start using this new feature:

  1. Our application starts the login procedure.
  2. The Facebook app is opened: the user will have to eventually login and to confirm the permissions.
  3. The user is returned to our application but, this time, we will receive the Access Token that is needed by the Facebook SDK to perform any operation (like posting a message or getting information about the logged user).

The biggest pro of this approach is that we need to write less code and that, in most of the cases, the user will just have to grant the permissions to the app: since the user, probably, regularly uses the Facebook app, he’s already logged in, so he won’t have to insert his credentials every time. And if he doesn’t have the app? No problem: since the method is based on the protocol sharing feature that has been added in Windows Phone 8, the user will simply be asked if he wants to download the app from the Store.

Since a few days ago, this feature was available just for testing scenarios: most of the people use the official version, not the beta one. Plus, since the beta application is hidden in the Store (you can reach it just with the deep link), in case the user doesn’t have it the user will still be prompted to search for the app on the Store, but he won’t be able to find it. However, now the official application has been updated with all the latest beta improvements, including the authentication support, so there’s no reason why you shouldn’t use it!

This feature was detailed in a blog post made by the team, which I used as a “training ground” to write this post. The official post is really good, but it can be hard to understand if you aren’t an experienced Windows Phone developer, since it assumes that the reader already knows many concepts like Uri associations, the UriMapper class, etc.

So, let’s see how to do it in a more detailed way.

Publish your app

Probably you’re wondering why publishing your app, which should be the last step, is reported at the beginning of this post. To properly set up the authentication process, you’ll need to include in your application your real Application Id. The problem is that, when you create a new application with Visual Studio, a random id is generated and assigned to the app: when the app is submitted on the store, the real application id is generated and included in the manifest. The first step is to ask to the Dev Center to generate an application id for us: to do it, you just have to start the submission process and to upload the XAP file (in Step 2). Then, simply abort the process by returning in the main page of your dashboard: you’ll find your app in the In-progress submissions list. Click on it and switch to the Details section: you’ll find the App ID section already populated with the real application id. Copy it: we’re going to use it later. Important! When your app is finished and you’re ready to publish it, you’ll have to resume this pending submission and not to start a new one: otherwise, the application will get a new application id, breaking the Facebook authentication process we’re going to set up in the next steps.

Register the application on Facebook

The second step is to register the application on Facebook: every application that needs to interact with the Facebook APIs has to be registered in the Facebook developer’s portal. This way, you’ll get some information that will be important to use the Facebook SDK (like the App Id assigned by Facebook). To do this, go to https://developers.facebook.com, click on the Apps link in the upper menu and choose Create new app. To interact with the Windows Phone application there are only two fields that are required:

  • The name of the application, which has to be set in the Display Name field.
  • How the application integrates with Facebook: choose Windows App from the list and, in the Windows Phone Store ID [BETA] section, paste the Application Id you previously copied from the Dev Center (you’ll have to remove the hypens so if, for example, your id is b94ca943-21f1-4ef7-9895-b44a32dc1230, you’ll have to past b94ca94321f14ef79895b44a32dc1230 as value).

image

Register the protocol in the manifest

Protocol sharing is one of the new features introduced in Windows Phone 8 that allows an app to register a specific protocol (like foo:/), so that other apps can interact with your application by using that protocol. This technique is used to properly manage the Facebook login: the Facebook application, after the login, will call back your application using a specific Uri. This way, you’ll be able to intercept the call and to get the result of the login process. To register a protocol, you have to edit the manifest file: you’ll have to do it manually, since this scenario is not supported by the visual editor. Just right click on the manifest file (the one called WMAppManifest.xml inside the Properties folder) and choose View code: you’ll get access to the XML version of the manifest.

Under the section called Tokens you’ll have to add a new section called Extensions in the following way:

<Extensions>
  <Protocol Name="msft-b94ca94321f14ef79895b44a32dc1230" NavUriFragment="encodedLaunchUri=%s" TaskID="_default" />
</Extensions>

The only thing you’ll need to change is the value in the Name attribute, which should be msft- followed by the same application id you’ve retrieved from the Dev Center and that you’ve pasted in the Facebook Developers Center (as you can notice, also in this case you’ll have to remove the hyphens).

Start coding

Now you’re ready to write some code and to effectively start the login process. The first step is to install two libraries from NuGet, which will provide the needed APIs to interact with Facebook: the first one is the Facebook for .NET SDK (which we already mentioned), while the second one is the Facebook Client for .NET SDK (which adds a set of libraries that are specific for Windows Phone and Windows Store apps). Please note that, to find the second package in NuGet, you have to extend the search also to pre-release packages.

The second step, which is not required but it will make things easier, is to use a class developed by Microsoft as a sample called SessionStorage: it’s a simple class that acts as a wrapper of the IsolatedStorageSettings class, but that is able to encrypt the data. This way, we’re going to save in safety the access token returned by Facebook. To create this helper simply creates a new class, called it SessionStorage and paste the following code:

public class SessionStorage
{
    /// <summary>
    /// Key used to store access token in app settings
    /// </summary>
    private const string AccessTokenSettingsKeyName = "fb_access_token";

    /// <summary>
    /// Key used to store access token expiry in app settings
    /// </summary>
    private const string AccessTokenExpirySettingsKeyName = "fb_access_token_expiry";

    /// <summary>
    /// Key used to state in app settings
    /// </summary>
    private const string StateSettingsKeyName = "fb_login_state";

    /// <summary>
    /// Tries to retrieve a session
    /// </summary>
    /// <returns>
    /// A valid login response with access token and expiry, or null (including if token already expired)
    /// </returns>
    public static FacebookSession Load()
    {
        // read access token
        string accessTokenValue = LoadEncryptedSettingValue(AccessTokenSettingsKeyName);

        // read expiry
        DateTime expiryValue = DateTime.MinValue;
        string expiryTicks = LoadEncryptedSettingValue(AccessTokenExpirySettingsKeyName);
        if (!string.IsNullOrWhiteSpace(expiryTicks))
        {
            long expiryTicksValue = 0;
            if (long.TryParse(expiryTicks, out expiryTicksValue))
            {
                expiryValue = new DateTime(expiryTicksValue);
            }
        }

        // read state
        string stateValue = LoadEncryptedSettingValue(StateSettingsKeyName);

        // return true only if both values retrieved and token not stale
        if (!string.IsNullOrWhiteSpace(accessTokenValue) && expiryValue > DateTime.UtcNow)
        {
            return new FacebookSession()
            {
                AccessToken = accessTokenValue,
                Expires = expiryValue,
                State = stateValue
            };
        }
        else
        {
            return null;
        }
    }

    /// <summary>
    /// Saves an access token an access token and its expiry
    /// </summary>
    /// <param name="session">A valid login response with access token and expiry</param>
    public static void Save(FacebookSession session)
    {
        SaveEncryptedSettingValue(AccessTokenSettingsKeyName, session.AccessToken);
        SaveEncryptedSettingValue(AccessTokenExpirySettingsKeyName, session.Expires.Ticks.ToString());
        SaveEncryptedSettingValue(StateSettingsKeyName, session.State);
    }

    /// <summary>
    /// Removes saved values for access token and expiry
    /// </summary>
    public static void Remove()
    {
        RemoveEncryptedSettingValue(AccessTokenSettingsKeyName);
        RemoveEncryptedSettingValue(AccessTokenExpirySettingsKeyName);
        RemoveEncryptedSettingValue(StateSettingsKeyName);
    }

    /// <summary>
    /// Removes an encrypted setting value
    /// </summary>
    /// <param name="key">Key to remove</param>
    private static void RemoveEncryptedSettingValue(string key)
    {
        if (IsolatedStorageSettings.ApplicationSettings.Contains(key))
        {
            IsolatedStorageSettings.ApplicationSettings.Remove(key);
            IsolatedStorageSettings.ApplicationSettings.Save();
        }
    }

    /// <summary>
    /// Loads an encrypted setting value for a given key
    /// </summary>
    /// <param name="key">The key to load</param>
    /// <returns>
    /// The value of the key
    /// </returns>
    /// <exception cref="KeyNotFoundException">The given key was not found</exception>
    private static string LoadEncryptedSettingValue(string key)
    {
        string value = null;
        if (IsolatedStorageSettings.ApplicationSettings.Contains(key))
        {
            var protectedBytes = IsolatedStorageSettings.ApplicationSettings[key] as byte[];
            if (protectedBytes != null)
            {
                byte[] valueBytes = ProtectedData.Unprotect(protectedBytes, null);
                value = Encoding.UTF8.GetString(valueBytes, 0, valueBytes.Length);
            }
        }

        return value;
    }

    /// <summary>
    /// Saves a setting value against a given key, encrypted
    /// </summary>
    /// <param name="key">The key to save against</param>
    /// <param name="value">The value to save against</param>
    /// <exception cref="System.ArgumentOutOfRangeException">The key or value provided is unexpected</exception>
    private static void SaveEncryptedSettingValue(string key, string value)
    {
        if (!string.IsNullOrWhiteSpace(key) && !string.IsNullOrWhiteSpace(value))
        {
            byte[] valueBytes = Encoding.UTF8.GetBytes(value);

            // Encrypt the value by using the Protect() method.
            byte[] protectedBytes = ProtectedData.Protect(valueBytes, null);
            if (IsolatedStorageSettings.ApplicationSettings.Contains(key))
            {
                IsolatedStorageSettings.ApplicationSettings[key] = protectedBytes;
            }
            else
            {
                IsolatedStorageSettings.ApplicationSettings.Add(key, protectedBytes);
            }

            IsolatedStorageSettings.ApplicationSettings.Save();
        }
        else
        {
            throw new ArgumentOutOfRangeException();
        }
    }
}

Now it’s time to start the real login procedure, which is done using the FacebookSessionClient class: to create a new instance you’ll have to pass as parameter the Facebook application id, which you can find on the Facebook Developers portal page (see the following screenshot).

image

Here is a full login sample:

private void OnLoginClicked(object sender, GestureEventArgs e)
{
    FacebookSessionClient fb = new FacebookSessionClient("563659977051507");
    fb.LoginWithApp("basic_info,publish_actions,read_stream", "custom_state_string");
}

To effectively perform the login you have to use the LoginWithApp method, which requires two parameters:

  • The first one is the list of permissions you want to use. You can find all the available ones here; the previous code is used to grant access to the user profile, to his timeline and to allow the app to post on behalf of the user.
  • The second parameter is a custom string that is returned to the application once the login procedure is completed: we’re going to use it to implement our own logic when the user is redirected back to our application (for example, to perform an action or to redirect the user to a specific page).

As we’ve previously described, this new login method is based on the Windows Phone 8 protocol sharing feature: this means that, when the Facebook app has completed the login, it calls back our application with a special Uri. We need to intercept it and to retrieve the query string parameters, that are needed to understand if the operation completed with success or not. The best way to achieve this task is to use a UriMapper class: you should be already familiar with this approach if you’ve already worked with scenarios like protocol sharing or speech APIs. Basically, this class acts as a middle man between every navigation: every time the user moves from a page to another, this class intercepts the navigation and he’s able to analyze the calling Uri and, eventually, to change it or to redirect the user to another page. This behavior is extended also to navigation from and towards the Start screen or another application: when the Facebook application has completed the login, the UriMapper will intercept it and will be able to extract the parameters we need.

To create the UriMapper, simply just add a new empty class to your project: you’ll have to inherit from the UriMapperBase class, which will force you to implement the MapUri() method. Here is the full code:

public class FacebookUriMapper: UriMapperBase
{
    private bool facebookLoginHandled;

    public override Uri MapUri(Uri uri)
    {
        if (AppAuthenticationHelper.IsFacebookLoginResponse(uri))
        {
            FacebookSession session = new FacebookSession();
            try
            {
                session.ParseQueryString(HttpUtility.UrlDecode(uri.ToString()));

                // Handle success case
                // do something with the custom state parameter
                if (session.State != "custom_state_string")
                {
                    MessageBox.Show("Unexpected state: " + session.State);
                }
                else
                {
                    // save the token and continue (token is retrieved and used when the app
                    // is launched)
                    SessionStorage.Save(session);
                }
            }
            catch (Facebook.FacebookOAuthException exc)
            {
                if (!this.facebookLoginHandled)
                {
                    // Handle error case
                    MessageBox.Show("Not signed in: " + exc.Message);
                    this.facebookLoginHandled = true;
                }
            }
            return new Uri("/MainPage.xaml", UriKind.Relative);
        }
        // by default, navigate to the requested uri
        return uri;
    }
}

This code checks if the Uri used to open the app the one used by the Facebook app: in this case, we’re going to create a Facebook session by using the information we’ve got in return in the Uri. If it’s a valid Facebook session (do you remember the custom string we’ve passed to the LoginWithApp() method?), we use the SessionStorage class we’ve created before to store the session data.

The last step to enable the UriMapper is to register in the in the application’s frame: open the App.xaml.cs file and look for a method called InitializePhoneApplication() (which, by default, is hidden in a collapsed region called Phone application initialization). Right after the RootFrame object has been initalized simply create a new instance of your UriMapper class and assign it to the UriMapper property, like in the following sample:

RootFrame = new PhoneApplicationFrame();
RootFrame.Navigated += CompleteInitializePhoneApplication;
RootFrame.UriMapper = new FacebookUriMapper();

Interacting with Facebook: getting data

Now you have a valid Facebook access token, which you can use to perform one of the operations offered by the FacebookClient class provided by the Facebook C# SDK. This class acts as a wrapper of the Facebook REST APIs and offers many methods to interact with Facebook by wrapping the standard HTTP commands (for example, GET to retrieve data or POST to submit changes).

The following sample shows how to retrieve the logged user’s name:

private async void OnShowNameClicked(object sender, GestureEventArgs e)
{
    FacebookSession session = SessionStorage.Load();
    FacebookClient client = new FacebookClient(session.AccessToken);

    dynamic result = await client.GetTaskAsync("me");
    string name = result.name;
    MessageBox.Show(name);
}

The first step is to load the session we’ve previously stored after the login process by using the Load() method of the SessionStorage class. Now that we have a FacebookSession object we can use it to get the information we need: specifically, we need the value of the AccessToken property, which has to be passed as parameter when you create a new instance of the FacebookClient class.

Since, to retrieve information from Facebook, we have to issue a GET operation, we need to use the GetTaskAsync() asynchronous method, which is based on the Facebook’s Open Graph APIs. As parameter it needs the Open Graph’s path: me is the path used to get information about the logged user.

The method returns a dictionary, which is a collection of data identified by a key: in this case, every key identifies one of the user’s information (for example, the key called name contains the user’s name). In the sample code you can see a different way to manage this scenario: by using the dynamic keyword, we are able to work with the value returned by the GetTaskAsync() method like if it’s a dynamic object (in a similar way when you work with dynamic languages like Javascript). This way, we are able to simply get the name of the user by asking for the value of the name property of the result. We could have used another property like surname or birthday to get other information about the user: you can see the full list here.

Integrating with Facebook: posting data

Another common scenario when you want to integrate Facebook in your application is posting messages. Here is a sample code to post a message on the user’s timeline:

private async void OnPostMessageClicked(object sender, GestureEventArgs e)
{
    FacebookSession session = SessionStorage.Load();
    FacebookClient client = new FacebookClient(session.AccessToken);

    var parameters = new Dictionary<string, object>();
    parameters.Add("message", "First test post using Facebook login");

    await client.PostTaskAsync("me/feed", parameters);
}

The first part of the code is the same we’ve seen before: by using the SessionStorage class we retrieve the access token to create a new instance of the FacebookClient class.

The biggest difference between this code and the previous one is that, in case of posting, we need to interact with the Open Graph APIs passing a parameter: we do it by creating a new set of parameters (which is a Dictionary<string, object> collection) and by adding a parameter called message. The value of the parameter is simply the text of the message we want to post.

In the end, we use the PostTaskAsync() method, since in this case we’re going to execute a POST request: other than the specifying the Open Graph APIs path (in this case, me/feed) we need to pass the input parameters we’ve just defined.

Wrapping up

There are many other operations that you can do with the Facebook C# SDK: you can find many samples here, just keep in mind that these samples are based on the old Facebook .NET SDK version, which was based on the callback approach for asynchronous method instead of the async / await one.

The biggest pro of this approach is that it saves you a lot of time working with Facebook login, which is probably the most complex scenario to implement when you have to deal with Facebook integration. In addition, it will offer a better experience to the user: since most of the time he’s already using the Facebook app, he won’t have to insert his credentials every time. The only downside, instead, is that it relies on a third party application: in case the user doesn’t have the official Facebook app (because, for example, he prefers to use another app or the mobile website) he will have to download it before using the Facebook integration in your app. This requirement may lead the user to change his mind and stop using your application.

Tagged with:  

Fast App Resume is one of the new features introduced in Windows Phone 8 that allows developers to introduce a smoother experience in their applications. The standard navigation experience is that, when a user suspends the application, he’s able to resume it only by pressing the Back button or by using the task switcher. If he launches the same application using the main tile or the icon in the application list, the suspended process is terminated and a new instance of the app is executed. The result is that, whatever the user was doing, he will have to start from scratch.

Fast App Resume introduces a more user friendly experience: the user is able to definitely quit from the application only by pressing the Back button in the main page. In every other case (including tapping the main tile or the icon in the application list) the previous instance is resumed. This way the user doesn’t have to remember that, to resume the work he was previously doing, he has to use the task switcher: regardless of the way he is going to open the app, he’ll be able to keep using the app from where he left. Anyway, Fast App Resume is a double edged sword: not always the user has the need to resume his work, but he just need to start from beginning.  Think about, for example, a Twitter client: most of the time, when the user opens the app he wants to see his timeline and not to keep reading the tweet he was looking at the last time he used the app (that could have happened many hours before). So, my suggestion is: use Fast App Resume carefully!

After this brief introduction, let’s get back to the core of the post: implementing Fast App Resume means editing the manifest and apply some changes to the navigation events of the Windows Phone’s main frame (which class is called PhoneApplicationFrame and takes care of managing all the rendering of the pages and the navigation system). From a developer’s point of view, the operation needs to be done in the App.xaml.cs class: when the PhoneApplicationFrame object is created, you have to subscribe to the Navigated and Navigating events and apply some code, that we’ll see later.

The problem when you work with Caliburn Micro is that all the application’s setup is made by the boostrapper class: initialization is removed from the App.xaml.cs class, so you don’t have a way anymore to make the needed changes. A good alternative is to use the boostrapper class, since it replaces the App one: the problem is that, by default, you don’t have a way to access to the PhoneApplicationFrame class in the bootstrapper.

But there’s a workaround Smile The boostrapper class, by default, initializes the PhoneApplicationFrame under the hood, but it offers a method that can be used to customize the process. It’s useful in case you want to override, for example, the default frame with another one (like the TransitionFrame included in the Windows Phone Toolkit that offers built-in support to transitions). The name of the method is CreatePhoneApplicationFrame and should return a PhoneApplicationFrame object (which is the basic class that every frame class inherits from). In our case, we can use it just to define a private instance of the PhoneApplicationFrame class, that we’re going to use to subscribe to the Navigated and Navigating events.

Here is the code:

public class AppBootstrapper : PhoneBootstrapperBase
 {
     private PhoneContainer container;
     private PhoneApplicationFrame rootFrame;

     public AppBootstrapper()
     {
         Start();
     }

     protected override PhoneApplicationFrame CreatePhoneApplicationFrame()
     {
         rootFrame = new PhoneApplicationFrame();
         return rootFrame;
     }
}

We’re basically doing the same things that the boostrapper does under the hood: the difference is that, this time, since we have an explicit reference to the PhoneApplicationFrame object, we can use it in our code.

What we’re going to use it for? To properly support Fast App Resume we need to intercept two navigation events: Navigated (that is triggered every time the user has navigated to another page) and Navigating (which, instead, is triggered just before the navigation is performed). It’s important to keep in mind, at this point, that navigating to another page doesn’t necessarily mean navigating from an application’s page to another page. It can be also a suspension (navigation from a page to the start screen) or a restore or launch (navigation from the start screen to a page).

The first step to continue our implementation is to change the Configure() method of the boostrapper and add two event handlers, to subscribe to the two events, like in the following sample:

protected override void Configure()
{
    container = new PhoneContainer();
    if (!Execute.InDesignMode)
        container.RegisterPhoneServices(RootFrame);

    container.PerRequest<MainPageViewModel>();

    AddCustomConventions();

    rootFrame.Navigated += rootFrame_Navigated;
    rootFrame.Navigating += rootFrame_Navigating;
}

void rootFrame_Navigating(object sender, NavigatingCancelEventArgs e)
{
    throw new NotImplementedException();
}

void rootFrame_Navigated(object sender, NavigationEventArgs e)
{
    throw new NotImplementedException();
}

To better understand the code we’re going to write, let’s explains how Fast App Resume works from a developer point of view: usually, when you tap on the main tile, you launch a new instance of the app with, as navigation uri, the main page of the application. The same happens when Fast App Resume is enabled: the difference is that, this time, the previous instance of the app will be resumed, with the last page visited by the user already at the top of the navigation stack. The problem is that, since the main tile triggers a navigation to the main page, the user won’t see the last opened page, but the main one. Other than being an incorrect behavior, it will cause also a navigation issue: if the user presses Back on the main page, he will be redirected to the last opened page, instead of closing the app. So, the goal for the developer that correctly wants to support Fast App Resume is to detect this scenario and to cancel the navigation towards the main page: this way, the user will correctly stay on the last opened page.

To achieve this goal we’re going to use the Navigated and Navigating events we’ve previously defined.

We need to use the Navigated event to understand the navigation’s type that has been triggered: this event returns a parameter called NavigationMode, which explains which type of navigation has been issued, like Back, Forward, New, etc. One of the possible values is Reset: this is the one we’re looking for, since it’s triggered when the user has opened the application using the main tile or the icon in the application list but Fast App Resume is enabled. We need to store this information for a later use: it’s required because the Navigated event is the only one that can give us this information, but, since the navigation has already been completed at this time, we can’t cancel it. So we’re going to define a global property in the boostrapper, which type is bool, and we’re going to set it to true in case the NavigationMode property is equal to Reset. In an application that supports Fast App Resume, we’re going to get this information when app is resumed and initial navigation to the last opened page is triggered.

public class AppBootstrapper : PhoneBootstrapperBase
  {
      private PhoneContainer container;
      private PhoneApplicationFrame rootFrame;
      private bool reset;

      public AppBootstrapper()
      {
          Start();
      }

      protected override PhoneApplicationFrame CreatePhoneApplicationFrame()
      {
          rootFrame = new PhoneApplicationFrame();
          return rootFrame;
      }

      protected override void Configure()
      {
          container = new PhoneContainer();
          if (!Execute.InDesignMode)
              container.RegisterPhoneServices(RootFrame);

          container.PerRequest<MainPageViewModel>();
          container.PerRequest<Page2ViewModel>();

          AddCustomConventions();

          rootFrame.Navigated += rootFrame_Navigated;
          rootFrame.Navigating += rootFrame_Navigating;
      }

      void rootFrame_Navigating(object sender, NavigatingCancelEventArgs e)
      {
         throw new NotImplementedException();
      }

      void rootFrame_Navigated(object sender, NavigationEventArgs e)
      {
          reset = e.NavigationMode == NavigationMode.Reset;
      }
}

Now that we have this information, we are ready to cancel the navigation to the main page in case the user opens the app from the main tile and a previous instance of the app is already available in memory. To satisfy this requirement, we’re going to use the Navigating event, that we’re going to use to intercept the navigation to the main page of the app before it’s completed. This second navigation is triggered immediately after the first one to the last opened page is completed (the one we intercepted with the Navigated event). We need to cancel this second navigation if the following conditions are satisfied:

  • Fast Application Resume is enabled.
  • The NavigationMode parameter that we got in the Navigated event is equal to Reset.
  • The Uri of the page where the user is navigating to is the main page.

Here is how these conditions are translated into code:

void rootFrame_Navigating(object sender, NavigatingCancelEventArgs e)
{
    if (reset && e.IsCancelable && e.Uri.OriginalString == "/Views/MainPage.xaml")
    {
        e.Cancel = true;
        reset = false;
    }
}

We check the value of the boolean property we’ve defined before (called reset) and we check the navigation uri (stored in the NavigatingCancelEventArgs parameter). Of course, you’ll have to adapt your code according to the position and the name of the main page of your application: usually, it’s the same that is set in the manifest file, in the field called Navigating page. If these conditions are satisfied, we’re going to set the Cancel property of the method’s parameter to true: this way, the navigation to the main page will be canceled and the user will stay on the last visited page.

Here is the full code of the bootsrapper to properly support Fast App Resume:

public class AppBootstrapper : PhoneBootstrapperBase
{
    private PhoneContainer container;
    private PhoneApplicationFrame rootFrame;
    private bool reset;

    public AppBootstrapper()
    {
        Start();
    }

    protected override PhoneApplicationFrame CreatePhoneApplicationFrame()
    {
        rootFrame = new PhoneApplicationFrame();
        return rootFrame;
    }

    protected override void Configure()
    {
        container = new PhoneContainer();
        if (!Execute.InDesignMode)
            container.RegisterPhoneServices(RootFrame);

        container.PerRequest<MainPageViewModel>();
        container.PerRequest<Page2ViewModel>();

        AddCustomConventions();

        rootFrame.Navigated += rootFrame_Navigated;
        rootFrame.Navigating += rootFrame_Navigating;
    }

    void rootFrame_Navigating(object sender, NavigatingCancelEventArgs e)
    {
        if (reset && e.IsCancelable && e.Uri.OriginalString == "/Views/MainPage.xaml")
        {
            e.Cancel = true;
            reset = false;
        }
    }

    void rootFrame_Navigated(object sender, NavigationEventArgs e)
    {
        reset = e.NavigationMode == NavigationMode.Reset;
    }

    protected override object GetInstance(Type service, string key)
    {
        var instance = container.GetInstance(service, key);
        if (instance != null)
            return instance;

        throw new InvalidOperationException("Could not locate any instances.");
    }

    protected override IEnumerable<object> GetAllInstances(Type service)
    {
        return container.GetAllInstances(service);
    }

    protected override void BuildUp(object instance)
    {
        container.BuildUp(instance);
    }

    private static void AddCustomConventions()
    {
        ConventionManager.AddElementConvention<Pivot>(Pivot.ItemsSourceProperty, "SelectedItem", "SelectionChanged")
            .ApplyBinding =
            (viewModelType, path, property, element, convention) =>
            {
                if (ConventionManager
                    .GetElementConvention(typeof (ItemsControl))
                    .ApplyBinding(viewModelType, path, property, element, convention))
                {
                    ConventionManager
                        .ConfigureSelectedItem(element, Pivot.SelectedItemProperty, viewModelType, path);
                    ConventionManager
                        .ApplyHeaderTemplate(element, Pivot.HeaderTemplateProperty, null, viewModelType);
                    return true;
                }

                return false;
            };

        ConventionManager.AddElementConvention<Panorama>(Panorama.ItemsSourceProperty, "SelectedItem",
            "SelectionChanged").ApplyBinding =
            (viewModelType, path, property, element, convention) =>
            {
                if (ConventionManager
                    .GetElementConvention(typeof (ItemsControl))
                    .ApplyBinding(viewModelType, path, property, element, convention))
                {
                    ConventionManager
                        .ConfigureSelectedItem(element, Panorama.SelectedItemProperty, viewModelType, path);
                    ConventionManager
                        .ApplyHeaderTemplate(element, Panorama.HeaderTemplateProperty, null, viewModelType);
                    return true;
                }

                return false;
            };
    }
}

Before testing our work, there’s one important thing to do: enable Fast App Resume in the manifest. Unfortunately, this option isn’t supported by the visual editor, but you’ll have to manually edit the XML file: right click on the WMAppManifest.xml file in the Properties folder of your project and choose View code. You’ll find the following section:

<Tasks>
  <DefaultTask Name="_default" NavigationPage="Views/MainPage.xaml" />
</Tasks>

To enable Fast App Resume you’ll have to add a new attribute to the DefaultTask node called ActivationPolicy and set it to Resume, like in the following sample:

<Tasks>
  <DefaultTask Name="_default" NavigationPage="Views/MainPage.xaml" ActivationPolicy="Resume" />
</Tasks>

That’s all! If you want to do some experiments with Fast App Resume, you can use the sample attached project, which simply contains two pages: the first page contains a button to navigate to the second one, which instead is empty. This project has enabled Fast App Resume, so you’ll notice that, if you navigate to the second page and you suspend the app by pressing the Start button, then you open it again using the main tile or the icon in the application list, you’ll notice that the previous instance of the app will be correctly resumed and you’ll land to the second page, instead of the main one.

Happy coding!

Tagged with:  

Yesterday Microsoft announced the first step towards the long rumored Store unification between Windows Phone and Windows 8: a unique registration process. What does it mean? Until today, being a Windows Phone developer was different than being a Windows Store apps developer: they were two separate subscriptions, each with their own registration process and payment.

Starting from today, instead, the process has been unified: a single registration portal, a single registration process and, most of all, a single registration fee! Microsoft is doing an amazing job to attract developers to its new platforms: first they’ve dropped the registration price (from 99 $ to 15 $), now they’ve merged the registration process and they’ve lowered it by 70% of the original price. The new developer fee to pay, in fact, is 19 $, which will allow you to publish applications both for Windows Phone and Windows 8.

For the moment, Microsoft has unified just the registration process: since we’re talking about two different Stores (you can’t install a Windows Phone app on Windows 8 and vice versa), you will still have to use two different dashboards to publish and manage your applications on the store. So, if you’re a Windows Phone developer, your starting point will continue to be http://dev.windowsphone.com

And what about already existing developers? The good news is that, for free, you’ll gain access to both stores: so, if you were a Windows Phone developer, now you’ll be able to submit apps also on the Windows 8 store; if you were a Windows Store apps developer, you’ll be able to port and publish your apps also on the Windows Phone Store. And if you were already both? Microsoft got you cover, by giving you a free token to renew your subscription when your account will expire (the account that expires for latest will count).

This news, combined with the announcements by Nokia that is going to release its first Windows RT tablet, will help more developers to support both platforms, by giving them the tools to publish them both for smartphones and PCs / tablets. As I’ve already made in the previous post about the Nokia World, I suggest you take a look at this series of webcasts about sharing code between Windows Phone and Windows Store applications.

Keep up the good work!

Tagged with:  

Yesterday Nokia has showed off to the world, during Nokia World, many great news about Windows Phone and the Lumia series. In fact, Nokia has announced 2 new phones which falls into the “phablet” category (they both share a 6” screen), a tablet (based on Windows 8.1 RT) and many important apps that are coming in the next weeks, like Instagram, Vine and Flipboard.

They all are really good news for developers, since I’m sure that they will push even further the Windows Phone ecosystem and more phones around the world means more opportunities for devs Smile

To get all the information about the new products and apps, I suggest you to visit the official Nokia blog called Nokia Conversation, which covers in details all the news. In this post, I would like to focus on what’s interesting for developers regarding the new announcements.

Lumia 1320 and Lumia 1520

The new members of the Lumia family are part of the so called “phablet” category: they are phones, but with a very big screen (6 inches). The Lumia 1520 is a high end phone, which features the new resolution introduced with GDR3, which is 1080p (1080×1920), together with a quad core processor (another new feature for a Windows Phone device) and a 20 MPixel camera. The Lumia 1320, on the other side, is a mid end phone, with lower tech specs but with a much cheaper price. It features a 720p resolution (720×1280), which is not new for Windows Phone (it’s one of the new resolutions introduced in Windows Phone 8), but it’s new for Nokia, since previously all the other phones used only the WVGA (480×800) and WXGA (768×1280) resolutions.

And here comes the first news for developers: 1080p and 720p resolutions are very different from the other ones, since they offer a 16:9 aspect ratio, instead of the usual 15:9. This means basically two things:

  • If you’ve used a rigid layout in your application (using, for example, fixed margins and sizes), there’s a good chance that your app will not look very good on one of these devices. The solution is to use a fluid layout, which is able to adapt to the screen size. For example, when you create a Grid, try not to use fixed sizes for columns and rows. There’s a good article in the MSDN documentation about this topic.
  • Windows Phone 7 apps don’t support the new resolutions: if for WXGA phones is not a problem (aspect ratio is the same, so layout is simply adapted but not distorted), it’s not the same for 720p and 1080p. Since aspect ratio is different, there’s the chance that the layout will look bad: for this reason, Windows Phone 7 apps that are executed on a 720p or 1080p device will look “cut” at the top, since a black bar will be added to keep the 15:6 aspect ratio. The only solution to fix it is to upgrade your project to Windows Phone 8: only this way you’ll be able to fully support the new devices.

If, in the past, developers didn’t care too much about 720p, since only a few models with low market share supported it, now it’s definitely time to change and fully embrace it: otherwise, people that will buy the Lumia 1320 or the Lumia 1520 won’t be able to experience your apps with full quality.

Nokia has scheduled one webinar in two different dates and times (6 November and 7 November) on how to adapt your application to fully support the new resolutions. Don’t miss it!

Plus, if you remember my previous post, you should know that Microsoft is going to release soon a SDK update which features a new GDR3 emulator with the 1080p resolution. However, since aspect ratio is the same, you can start right now to test your apps for the new Lumia devices with the 720p one. If your app looks good a on a 720p phone, it will look good also on a 1080p one (unless you’ve used low quality images, in this cases they can look bad on a high resolution screen).

image_thumb[5]

Lumia 2520

Nokia has announced also his first tablet, a Windows 8.1 RT device with a look and feel very similar to the Lumia smartphones. It’s a quad core ARM device with a 1080p resolution which, as every other Windows RT device, is optimized for the new Windows Store apps introduced in Windows 8: desktop apps won’t run, except for the ones provided by Microsoft (like the Office suite).

From a developer point of view, it’s a new opportunity: if you’ve already have a Windows Phone app that could make sense on a larger screen, you can start thinking about a porting for Windows 8. There’s some work to do, but there are many shared classes between the Windows Runtime for Windows 8 and the Windows Runtime for Windows Phone, like storage APIs, sensors APIs, geolocalization APIs, etc. I suggest you to start looking at this series of webinars published on Channel 9 made by Ben Riga: they will introduce you to concepts like Model-View-ViewModel (which we covered deeply in this blog too) and Portable Class Libraries, which are two of the tools that will help you to reuse your Windows Phone code for a Windows 8 app.

image_thumb[11]

Nokia Developer Offers

The most interesting news for developers is, probably, the launch of a new program called Nokia Developer Offers, which gave to developers, for free, a set of very useful tool and resources:

  • A token to subscribe to the Store or to renew an existing subscription
  • A license for BugSense Performance Monitoring Solution, which is an analytics platform
  • A 1 year license for Telerik controls for Windows Phone
  • A 1 year license for Infragistics controls for Windows Phone

However, there are a couple of requirement to be able to join the program and get all these goodies for free:

  • You have to be subscribed to DVLUP, so if DVLUP is not available in your country yet, I’m sorry but you’ll have to wait
  • If you’re a new developer, you should have published at least 2 application on any mobile platform: not just Windows Phone or Asha, but also Android, iOS, etc.
  • If you already had a Nokia Developer Premium account in the past, you should have released at least one app after you’ve subscribed.

The Nokia team will take a few days to verify that you’re eligible. Once you’re in, it’s important to know that, in the future, you could get access to new benefits (for example, discounts on the XP points required to get rewards on DVLUP): to continue to be part of the program, you’ll have to publish at least a new app or an update to an existing app within 6 months from your subscription.

If everything I told you sounds good, go to the official website and apply!

Tagged with:  

Yesterday Microsoft has announced two big news for all the Windows Phone users and developers. Let’s start to dig them!

GDR3 announcement

Microsoft has officialy revelead the third Windows Phone 8 update, called Update 3 (or GDR3). Like GDR2, the focus of this update are consumers, since it adds a coulpe of much requested features like:

  • A new driving mode, that is automatically enabled when you’re driving and that automatically turns off all the notifications so that you can’t be distracted.
  • A new option in Settings to lock screen rotation.
  • Custom ringtones support for all the notification types, like mails and text messages.
  • Improved task switcher, with an option to close suspended apps.
  • Now, during the first wizard, you’ll be able to restore a backup also using a Wi-Fi connection.

Anyway, the most important new feature, which is interesting also for developers, is the support for a new resolution, which is 1080p (1080×1920). Devices with this resolution will be able to display a new column of tiles in the main screen (while, even if some rumors stated the opposite, phones with lower resolution will keep the current layout with two columns). From a developer point of view, 1080p and 720p (which is one of the already supported resolutions) are the same: they have the same aspect ratio (16:9), which is different from the aspect ratio of the other two resolution (15:9). What does it mean? That it’s important to test your app with this new resolution if you want to deliver to your users the best experience: since the aspect ratio is different, some images and look could look different. In some cases, you’ll need to load specific images for the new resolution and to use a fluid layout, which is able to automatically adapt to the screen’s size. If you want to learn more about this topic, you can take a look at this article from the official MSDN documentation.

This new resolution will also make you reconsider the choice to not update your applications to Windows Phone 8: since 1080p has a different aspect ratio, 7.8 applications will look “cut”, with an empty space at the top of the screen. So, if you want that your app looks best on every device, you’ll have to upgrade it to Windows Phone 8, which is able to support all the resolutions.

You’ll be able to test your app against the new resolution very soon: Microsoft is going to release a SDK update, that will introduce new emulators aligned with GDR3. From a developer point of view, there are also other other changes, that are detailed in the MSDN documentation:

  • The memory cap for background audio agents has been raised from 20 to 25 MB on devices with 1 GB of RAM or more.
  • The memory cap for apps has been raised to 570 MB on devices with 2 GB of RAM.
  • There’s a new Uri scheme (ms-settings-screenrotation: ) to quickly access to the Screen Rotation setting.
  • Icon and tile of your application are now used also in the updated Task switcher view.
  • You can set a custom sound for toast notifications, using reflection.
  • The Internet Explorer’s viewport has been updated: this can impact applications that use WebBrowser control or mobile websites.

If you need to check if the current phone is running GDR3 or not, you’ll need to use the Environment.OSVersion.Version property: a GDR3 device will return 8.0.10492.

Preview Program for Developers

But what if you want to test your apps on a real GDR3 device? Here comes the most interesting news for developers: Microsoft has opened a Preview Program for Developers, which allows to get early access to new Windows Phone updates, without having to wait for carrier’s approval. This way, developers can get their apps ready when the new update will be publicly distributed to every user. To be part of the program you’ll just need:

  • A developer unlocked device. Phones can be unlocked using the Windows Phone Developer Registration tool that comes with the SDK. If you’re a registered developer, you’ll be able to unlock up to 3 phones; otherwise, you can unlock just one phone.
  • A paid developer account, which allows you to publish your apps on the Store, or a free App Studio account.

Once you have met this requirement, you can go to this page, where you can review the requirements and the program’s conditions: you’ll find a link that will redirect you to an application in the Store. You’ll simply have to download it, run it and, after accepting terms and conditions, enable the preview program. From now on, when you look for new updates in the Settings hub, you’ll directly contact Microsoft’s servers to get the latest version of the OS: if you do it right now, the GDR3 download and installation process will start. Cool, isn’t it?

In the end, here are some important things to know about the program:

  • The GDR3 version that is distributed with the Preview program is final, but it’s just the OS update offered by Microsoft. Diver and firmware updates from the phone’s vendor will be provided with the official GDR3 release.
  • GDR3 can be installed on any phone, but it should already have installed GDR2. The minimum required OS version is 8.0.10322.71.
  • There’s no turning back: after you’ve installed GDR3, you’ll be able to install future updates but not to go back to the previous state.
  • The update is incremental, so you won’t lose any data.
Tagged with:  
Animated Social Media Icons Powered by Acurax Wordpress Development Company