Successful Architecture for Windows Store Apps by @johanlindfors #devsum13

Goal: Simplify development and maintenance
Mission: Share code and UI
Tactic: Separate UI from application logic
Obstacle: Abstract platform specifics

Johan started off by telling us that the hints and tips he was going to focus on for his session, were not valid for single use/campaign apps. Instead, he was going to drop some valuable tips for how to write apps apps that are intended to live for a long while.

I'm very fond of Portable Class Libraries, says Johan. I try to put as much logic as possible in a shared Portable Class Library, so that I can share that across my Windows Phone and Windows 8 apps. By abstractive native implementations behind generic interfaces in my PCL, I can easily inject the specific behavior in runtime, while maintaining nice code reuse.

Git works very well against TFS in the cloud, by the way.

If you're using shared code via file links and there are type incompatibilities (Visibility is different between Windows Phone and Windows 8), you can use ifdefs in your shared code:
#if WINDOWS_PHONE
#else
#end if

If you want to share .xaml, but there are platform specifics (PerformanceProgressBar (WP7) vs ProgressBar (WP8)), you can wrap your control inside a ContentControl and bind via a ResourceDictionary where you include different resource dictionaries for different platforms.

If you share resources files in PCLs, you'll need to add an InternalsVisibleTo in your AssemblyInfo.cs for each client. [[ see-also: InternalsVisibleTo Helper for ReSharper ]] 

If you have save commands in your action bars, first call Focus on your view and then do the update call through the dispatcher thread to ensure that the data binding gets run before you save.

Check out Coding4Fun for nice additions.

As far as PCL is concerned, I almost always add a reference to Microsoft.Threading.Tasks, which allows me to use async for Windows 7.5 too.

By using a messenger system, we can communicate between pages.

Tip: In Windows Phone, wrap XNA's MessageBoxGuide.BeginShowMessageBox. Through it, you can set the strings you want to present on the buttons and it is invoked asynchronously.

A way to keep generic code in a shared library, but offer native implementations, is to have basic ViewModels in your PCL and then inherit them in your native client. This way, you can have your Visibility properties in your native client that wraps a simple boolean in your PCL, for example.


Use an IoC container. This will force you to reconsider your architecture and help you on your way to code reuse.

Comments

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Unit testing your Azure functions - part 2: Queues and Blobs

Testing WCF services with user credentials and binary endpoints