Building a Modern Windows App
•
1 j'aime•868 vues
This session will walk you through how to build a modern Windows app with C# and XAML that runs on both Windows 8 and Windows Phone 8. We will go over some of the decisions and trade-offs that need to be made to write the same code for multiple platforms as well as techniques to enable as much code reuse as possible. We will look at these techniques in action within the context of a simple application by looking under the hood at the code.
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Building a Modern Windows App
Similaire à Building a Modern Windows App (20)
Dernier
Dernier (20)
Building a Modern Windows App
- 1. Building a Modern Windows App Brent Edwards Principal Lead Consultant BrentE@magenic.com @brentledwards brentedwards.net https://github.com/brentedwards
- 2. November 17-21 Royal Pacific Resort at Universal Orlando, FL More info: http://modernappslive.com Register and save money: http://bit.ly/LSPK27REG
- 3. What We Will Cover • MVVM • Universal Apps • Dealing with Code Differences • Navigation • Application Settings • Secondary Tiles • Contracts • Unit Testing
- 5. Charmed Framework • Open source, Windows-based MVVM support library – Windows 8.1 – Windows Phone 8.1 – Updated to Universal Apps • https://github.com/brentedwards/Charmed
- 9. Why is MVVM Cool? • Separates Presentation from Functionality • Promotes Testability • Works great with Data Binding • Easy collaboration with Designers • Makes it easy to change out the View layer!
- 10. Universal Apps Sharing the love
- 11. Universal Apps • What are they? – One codebase to rule them all (on Windows, anyway) Source: https://dev.windows.com/en-us/develop/building-universal-Windows-apps
- 12. Universal Apps • Project type that came with Visual Studio 2013 Update 2
- 13. Universal Apps • Introduces concept of Universal Shared Project type – Essentially a code placeholder project • Does not compile on its own
- 14. Universal Shared Projects • Put common code in universal shared project – Platform-specific code in platform-specific projects • What is common? – Models – ViewModels – Converters – Services • What about views? – That depends…
- 15. Universal Shared Projects • A helpful Visual Studio extension – Shared Project Reference Manager • http://visualstudiogallery.msdn.microsoft.com/315c13a7-2787-4f57-bdf7-adae6ed54450
- 16. Dealing With Code Differences
- 17. Dealing With Code Differences • What is different? – Not a lot anymore! – Mostly platform features • Windows Charms • Sharing • Settings
- 18. Dealing With Code Differences • How can I deal with platform differences? – 3 techniques • Compiler Directives • Abstraction • Compiler Directives + Abstraction
- 19. Compiler Directives • Usage – Windows • #if WINDOWS_APP • NOTE: Was previously NETFX_CORE. Now both platforms define this. – Windows Phone • #if WINDOWS_PHONE_APP • NOTE: Was previously WINDOWS_PHONE • Pro – Easy • Con – Can be messy
- 20. Abstraction • Usage – Abstract platform-specific functionality into abstract class or interface • Pro – Clean • Con – Can be complex
- 21. Compiler Directives + Abstraction • Usage – Move compiler directives behind abstraction layer • Pro – Can keep the mess out of view models • Con – Still can be messy
- 22. Navigation
- 23. Navigation • Much simpler with Universal Apps! – Approach is now unified • View-driven with 1 optional parameter – Parameter can be anything • 2 Problems 1. Logic for navigation is generally in ViewModel • ViewModels have to know about Views?!?! 2. Not easily mocked in unit testing
- 24. Navigation • Solution – Provide abstraction layer for view model driven navigation
- 27. Application Settings • Store application settings – Locally • On device only, no sharing – Azure • Called Roaming Settings • Roamed settings can be shared with different platforms – In each store, assign same Package Family Name (PFN) to each app • http://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn630421.aspx • Problem – Not easily mocked in unit tests
- 28. Application Settings • Solution – Provide abstraction layer
- 30. Secondary Tiles
- 31. Secondary Tiles • Again, Universal Apps FTW! – Unified approach (from code perspective) • Main Difference – Windows requires user approval to pin/unpin tile – Windows Phone does not • Does that matter? – No! Same code, platforms just act differently • Problem – Not easily mocked in unit tests (sound familiar?)
- 32. Secondary Tiles • Solution – Provide abstraction layer
- 35. Contracts • What are they? – Agreements between one or more apps • Provide consistency across all apps
- 36. Examples of Contracts • Search • Share • Settings • Play To • File Picker • Cached File Updater
- 37. Contracts • Contracts You SHOULD Leverage – Search – Share – Settings • You HAVE to use this one with Internet access • Why? – Always available via Charms menu
- 38. Charms Menu
- 39. Share • Share content from your app • Can be context specific • Content can be shared in many formats – Different apps support different formats – Support as many formats as possible – Fire and forget
- 40. Share [Demo]
- 41. Settings • Change settings in your app • Any app-wide settings should go here • Users will be conditioned to use this
- 42. Settings • Things to consider – What app-wide settings will you need? – How can they be simplified? – How will changing them affect the UI? • Changes should be reflected immediately – Will you use the Internet? • If so, you MUST provide a privacy policy
- 43. Settings [Demo]
- 44. Unit testing
- 45. Unit Testing • Almost the same as .NET • Runs right alongside .NET tests in MSTest • Biggest Difference? – No Reflection.Emit namespace • Which means? – No mocking frameworks! – Have to hand roll all mocks
- 47. What We Covered • MVVM • Universal Apps • Dealing with Code Differences • Navigation • Application Settings • Secondary Tiles • Contracts • Unit Testing
- 48. Questions? Please rate session at http://spkr8.com/t/37441!