-
Say hello to WP Dev Fusion!
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!
in
-
Fast App Resume and Caliburn Micro
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 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. </ul> 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; }; } }</pre> 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: <pre class="brush: csharp;"><Tasks> <DefaultTask Name="_default" NavigationPage="Views/MainPage.xaml" /> </Tasks></pre> 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: <pre class="brush: csharp;"><Tasks> <DefaultTask Name="_default" NavigationPage="Views/MainPage.xaml" ActivationPolicy="Resume" /> </Tasks>
- The NavigationMode parameter that we got in the Navigated event is equal to Reset.
</pre>
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! <div id="scid:fb3a1972-4489-4e52-abe7-25a00bb07fdf:d525092e-8b71-412e-895d-f28bda6b0c8e" class="wlWriterEditableSmartContent" style="float: none; padding-bottom: 0px; padding-top: 0px; padding-left: 0px; margin: 0px; display: inline; padding-right: 0px"> <p> <a href="http://wp.qmatteoq.com/wp-content/uploads/2013/12/Caliburn.FastAppResume.zip" target="_blank">Download the sample project</a> </p> </div>
in
- Fast Application Resume is enabled.
-
Windows Phone and Windows Store apps developers unification
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!
in
subscribe via RSS