Universal apps are a great way to share code between your Windows and Windows Phone versions of your app.
Most devs have figured out how to share modules which are exactly the same, but sharing modules which are only almost the same is a bit less obvious.
The Shared project isn’t a normal, stand-alone project: it gets merged into the platform specific projects at build time, so you can treat the full project as all of the files from the platform specific project plus all of the files from the shared project. We can use this split in several ways to target specific code to specific targets.
Ok. This one’s obvious. For small differences conditional compilation works well, and this is demonstrated in Visual Studio’s templates:
For larger differences conditional compilation can quickly become cumbersome, and conditional compilation isn’t possible at all in XAML, only in code.
Partial Classes are a C# and VB.Net feature which allows a class to be implemented in multiple files by prepending the “partial” keyword before the class definition. The final class is the combination of the classes, fields, and properties defined in all versions. XAML apps use this feature to share the code-behind class (e.g. MainPage.xaml.cs) and the generated XAML classes (e.g. MainPage.g.cs and MainPage.g.i.cs ).
The app can split a class amongst files in the platform specific project and the shared project by marking each part as a partial class. When building and running both parts will be available in the class.
A common scenario would be to have mostly shared backing code but UI tuned differently for phones and for larger screens. The app could have different versions of MainPage.xaml with platform-specific layouts in the platform-specific projects and the MainPage.xaml.cs file with the bulk of the code in the Shared project. A button handler for a phone specific feature might be implemented in a partial MainPage class in the WindowsPhone project and stubbed out in a partial MainPage class in the Windows project.
XAML doesn’t support conditional compiling or partial classes, so it is more difficult to split out large layout differences without using separate files. However, styles, colors, and templates can be placed in an external ResourceDictionary. Depending on the app the primary XAML file could be platform specific for gross layout and include a shared styles dictionary for ItemTemplates, or the app could share a primary XAML file and include platform specific resource dictionaries to include platform specific colors (the app may use its own branded colors on Windows but the user’s theme colors on Windows Phone).
Here’s a quick example with a platform specific XAML file which uses a ListView in the phone and a GridView on Windows. The ItemTemplate comes from the same DataTemplate in the shared project. The highlight on the template uses the standard PhoneAccentBrush on the phone. Since PhoneAccentBrush doesn’t exist on Windows the app defines its own in the Windows project’s PlatformDictionary.xaml to draw Purple.
Both platforms share the same implementation of MainPage.cs to generate the same sample data. Button_Click handlers are in platform specific MainPage_Platform.cs files.
I hope this blog entry gives you some ideas about ways to share common code across your Universal apps!
Don’t forget to follow the Windows Store Developer Solutions team on Twitter @wsdevsol. Comments are welcome, both below and on twitter.