Building apps with common code for windows 8 and windows phone 8 (WP8)

Editor's Notes

• #4: UI Consistency
• #5: UI Consistency
• #7: The set of Windows Runtime API not supported on Windows Phone 8. The API surface area of Windows Runtime is very large, with over 11,000 members. We’ve adopted a subset for Windows Phone 8 that allows you to build compelling phone scenarios. Area 1 in the diagram above represents the APIs that are not available on Windows Phone 8.The set of Windows Runtime API adopted for Windows Phone 8. This is represented by area 2 in the above diagram and consists of approximately 2,800 members. For some types, we have not implemented certain members. For others we have added additional members to support phone-only features. In both cases, these differences are noted in the API reference documentation.We’ve added key APIs needed to build great apps for the phone. These are represented by area 3 in the diagram and total about 600 members. For example, we have brand-new APIs for speech synthesis and recognition, VOIP, and other features. Creating these as Windows Runtime style APIs means you can use them regardless of the programming language you use for your app.
• #13: Code that is written in WinRT API. Windows Phone 8 has adopted a subset of Windows Runtime App logic common to both apps, but not portable. In Windows Phone 8 and Windows 8, a lot of infrastructure code, or code that interacts with the operating system or external data sources, can be written using Windows Runtime API. Because Windows Phone 8 has adopted a subset of Windows Runtime, it’s possible to write code that uses this functionality once, and then share it across your apps. For example, both platforms have the same Windows Runtime API for networking, sensors, location, in-app purchase, and proximity. There’s significant overlap in these API on both platforms. This code can’t be placed in a Portable Class Library because it’s not portable. The .NET Framework portable libraries don’t support Windows Runtime. Instead, you can isolate the use of these APIs to classes in your app and share as linked code files in both your Windows Phone 8 and Windows Store app. If you’re using the free, Express versions of Visual Studio, you won’t be able to create Portable Class Libraries. In this case, you should use this code sharing technique to share your app logic. For example, apps that have been built using the Model-View-ViewModel (MVVM) pattern could share the model and viewmodel of you app.User controls with no platform dependencies. Windows Phone 8 and Windows 8 both enable you to create rich user experiences using XAML. They implement this layer differently and have also defined the API in different namespaces. However, this divergence is not insurmountable. In fact, a lot of the functionality, types, and members are named the same between the platforms, and behave the same way. Although the overriding guidance is to build the best user experience as possible for each platform, there may be cases when you can extract elements of your UI that are common to both, write it once, and share with both apps. It isn’t possible to conditionally compile XAML, so the UI that’s defined in a shared user control must be platform independent. You can use conditional compilation in your code-behind class of the user control, so this offers some flexibility.
• #15: Doesn’t use Windows Runtime APIs Windows Runtime APIs aren’t portable and can’t be used in a Portable Class Library. There is overlap in the Windows Runtime APIs that are supported on Windows Phone 8 and Windows 8. However, binary compatibility is not supported. Your code has to be compiled for each platform and therefore isn’t suitable for a Portable Class Library. Here too you should abstract the use of Windows Runtime APIs into classes or objects that aren’t shared in a Portable Class Library.Isn't relevant to UI constructs - Although XAML for both platforms looks the same (even same names) this code isn’t portable