This is a post from MSDN for the new Universal apps for Windows 8.1 and Windows Phone 8.1. Get the latest resources from http://dev.windows.com
You can build an app for Windows and Windows Phone 8.1 at the same time, and share code, user controls, styles, strings and other assets between them. This reduces the expense associated with building and maintaining an app for each type of device.
If you already have a Windows Store app, you can easily add support for a Windows Phone Store app. Similarly, if you start by creating a Windows Phone app, you can easily add support for a Windows Store app.
Develop an app that targets Windows and Windows Phone 8.1
To get started, pick a Universal project template in the New Project dialog box.
This image shows the universal project templates that are currently available for C#. Visual C++ has a similar set of Universal App templates..
When you select a template and create a solution, three projects appear in Solution Explorer: a Windows Phone project, a project, and a Shared project.
This image shows a solution that appears when you choose a Blank App project template.
- The Windows Store project contains XAML pages and code that target Windows.
- The Windows Phone project contains XAML pages and code that target Windows Phone 8.1.
- The Shared project is a container for code that runs on both platforms. The contents of the Shared project are automatically included in both the Windows Phone and the Windows Store projects. There is no build output from the Shared project itself.
When you build the solution, Microsoft Visual Studio builds a Windows Phone Store app and a Windows Store app. When you run the solution, for example by pressing F5, the project that is set as the startup project is the one that runs. To set either the phone or Windows project as startup project, right click on the project node in Solution Explorer and choose Set as Startup Project. The project that you choose shows in bold in Solution Explorer. In the previous image, App1.Windows (Windows 8.1) is the startup project.
When the Windows project is the startup project, the Debug target dropdown displays options for the Windows Simulator or Local Machine. When the Phone project is the startup project, the dropdown displays options for Device as well as various phone emulators. In a C++ phone project, you must manually set the build configuration to the ARM platform in order to see the Device option and deploy the app to a physical device. The Win32 configuration is used for the phone emulators only. Set the platform by navigating to Project | Properties | Configuration Manager | Platform.
Get started writing a converged app
Consider starting with the template named Hub App (Universal Apps) instead of a Blank App. The Hub App template creates an app that has three pages. (Hub is the equivalent of Panorama in previous versions of Windows Phone.) You can find the Hub App template under the Universal Apps category. To read more about the Hub App project template, see Visual Studio templates.
This image shows the Hub App project template selected in the New Project dialog box.
Write cross-platform code in the Shared project
In the Shared project, you typically write code that runs on both platforms. You can also use the #ifdef directive to isolate sections of code that are platform-specific. The constants WINDOWS_APP and WINDOWS_PHONE_APP are conveniently predefined for you. (In C++ use this directive:
You can use drag-and-drop to move files from one of the platform-specific projects to the Shared project or vice versa to change the scope of the code.
Platform context in the code editor
When you’re writing code in the Shared project, the Visual Studio code editor uses a context that targets one platform or the other. In C#, the Intellisense that you see as you write code is specific to the context of the code editor – that is, specific to Windows or to Windows Phone 8.1. In C++, the context (and not the startup project) determines whether the code inside the
#if WINAPI_FAMILY==WINAPI_FAMILY_PHONE_APP directive is greyed out or not.
If you use an API in shared code that’s not supported on both platforms, an error message will identify this API when you build the project. You can confirm that you’re using cross-platform APIs, however, without building the project. Switch the editor context in the drop-down list to the other platform to see squiggly lines under APIs that are not supported on that platform. Then isolate those APIs by using the #ifdef directive.
This image shows the context chooser drop-down list in the Visual Studio code editor.
Add support for a Windows or Windows Phone 8.1
If you’ve published a Windows Store app already, it’s very easy to reuse some of the code and publish a version of your app for Windows Phone 8.1. Similarly, if you started by creating a Windows Phone 8.1 app, you can modify your solution to build for Windows desktops and tablets as well. To add support for one type of device or another, open the shortcut menu for the project and choose either the Add Windows Phone 8.1 or Add Windows 8.1
Depending on which type of app your adding support for, Visual Studio adds Windows Phone 8.1 or Windows Store project to your solution. Visual Studio also adds a Shared project as well. This image shows a project after a Windows Phone project has been added.
Move files into the Shared project
You can move any code that you want to share between apps to the Shared project. For example, if you created your app by using a Visual Studio template, consider moving the Common, DataModel and Strings folder into the Shared project. You can even move App.xaml into the Shared project. More on that later in this topic. This image shows a solution after files and folders have been moved into the Shared project.
You’ll probably receive some compiler errors in the code that you’ve shared. In many cases, you can resolve the errors adding assembly references to the new app project. (In C++, if both projects depend on a LIB or DLL, you have to specify it separately in each project.) For example, if code refers to the
JsonConvert type in the Newtonsoft.json assembly, that code might have compiled before you moved it into the Shared folder because your Windows Store app contained a reference to the that assembly. Now that you’ve moved that code into the Shared project, you’ll have to also add the Newtonsoft.json assembly to the Windows Phone project. This image shows assemblies added to both projects.
If your shared code uses API’s that are specific to Windows, use the #ifdef directive to isolate that section of code. You can isolate sections of Windows-specific code by using the WINDOWS_APP constant. Apply the WINDOWS_PHONE_APP constant to isolate sections of code specific to Windows Phone 8.1. The next section shows an example of how to apply these constants, and the analgous constants used in C++
Note Moving files from one project to another does not physically move them in the file system. In a C++ project, this means that if you drag files to another project, you might have to adjust header file paths in your #include directives.
Share the App.xaml
In a brand new Universal app, Visual Studio places App.xaml into the Shared project. You can do this with your converted solution, but you’ll have to set the Build Action property of the page to ApplicationDefinition.
- In Solution Explorer, in the Shared project, select the App.xaml file.
- Select View > Properties Window.
- In the Properties window, in Build Action drop-down list, select ApplicationDefinition.
You’ll also have to decide how you want to handle code that opens the first page of your app. For example, the App.xaml page of a solution might start a page named HubPage as shown below:
throw new Exception(“Failed to create initial page”);
For this code to compile, both projects must contain a page named HubPage. If you would rather use a page by a different name, you’ll have to add #ifdef directives as shown below:
throw new Exception("Failed to create initial page");
Finally, ensure that any styles defined in your App.xaml file use resources that are available in both types of apps. Otherwise, move those style definitions into the Windows Store or Windows Phone project