EN
Dieser Inhalt ist in Ihrer Sprache leider nicht verfügbar. Im Folgenden finden Sie die englische Version.

Maximize code reuse between Windows Phone 8 and Windows 8

Applies to: Windows Phone 8 and Windows Phone Silverlight 8.1 | Windows 8

In this section, we will help you make the right choices to maximize code reuse in your apps. As a developer, you want to streamline your development and make maintaining your apps as efficient as possible. By working smarter, you give yourself more time to develop more apps and fill the marketplace with your creations. When building an app for Windows Phone 8 and Windows 8, you should look for opportunities to share code, designs, and assets as much as possible so that you maximize the return on your investment. This section describes the sharing techniques that you can use when building you app for both platforms.

The following table shows some of the techniques you can use to share code between your Windows Phone 8 and Windows 8 apps. Each is described in detail in the topics to which they are linked. The table calls out whether a technique applies to managed code, C# or VB, or native (C++) code. You can choose any of these techniques, or a combination of them.

Sharing technique

When to use

Separate UI and app logic using the Model-View-ViewModel pattern

This guidance is applicable to many app types, but particularly to apps that have a XAML UI. Separation allows you to write the app logic and to concentrate on user experience design separately. An added benefit is that your app logic is more likely to be common for your app on both platforms, and therefore is a great candidate for code sharing using the rest of the techniques described here. Model-View-ViewModel (MVVM) is a great way to achieve this separation.

Share functionality using Portable Class Libraries

Windows Phone 8 and Windows 8 share the same .NET Framework engine. In a XAML app, most of your app logic will be written in managed code. If you are using the MVVM design pattern, you have the potential to share your viewmodel and potentially your model. Note that Portable Class Libraries are a .NET Framework concept and don’t support C++.

Share code with Add as Link

Use this technique for code that is non-portable and therefore can’t be implemented in a Portable Class Library. For example, Windows Phone 8 and Windows 8 can use the common Windows Runtime API surface to harness the power of each platform for networking, proximity, in-app purchase, and many other features. Portable Class Libraries don’t support Windows Runtime API. Instead, you can abstract this non-portable code, which is common to both platforms, into a class that can be shared using Add as Link in Visual Studio. In C++ projects files are added to projects as linked files by default.

Share using Windows Runtime Components

In addition to consuming the common Windows Runtime API available on both platforms, you can write your own Windows Runtime Component to make your functionality available in all supported languages. This can be written in C++ and consumed by C# or VB. This is a very useful technique for language interoperability or for when you want to write compute-intensive code in C++ and use it in all languages.

Sharing XAML UI

The UI in Windows Phone 8 and Windows 8 is written in XAML. However, the XAML implementations are not portable between the platforms. But you can isolate some of your custom basic UI building blocks into UserControls and share those classes as linked files that will be compiled for each platform. This technique is limited and should be used only for simple, reusable parts of your UI. The core of your UI should be built and tailored separately for each platform.

Conditional compilation with preprocessor directives

If you have functionality that’s implemented differently for Windows Phone 8 and Windows 8, you can use conditional compilation to compile the code suitably for each platform. You can’t use conditional compilation in a Portable Class Library. How much you adopt this technique will depend on your app complexity, but it can lead to more difficult code maintenance if used extensively.

Anzeigen:
© 2014 Microsoft