Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Eric grover strategies for sharing code with windows 8 and windows phone 8 apps


Published on

Strategies for sharing code with windows 8 and windows phone 8 apps

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Eric grover strategies for sharing code with windows 8 and windows phone 8 apps

  1. 1. Strategies For Sharing Code With Windows Store & Windows Phone Apps Presented by Eric Grover Senior Consultant with
  2. 2. Why Build for Windows 8? • Up to 80% revenue sharing. • 200 markets worldwide. • 100 million Windows 8 licenses sold in the first 6 months. 250 million apps downloaded. • Use your existing development skills.
  3. 3. Why Build for Windows Phone 8? • 128 markets worldwide. • Has replaced BlackBerry as #3 consumer phone OS. • Is quickly becoming the Enterprise replacement for B-Berry / BES. • Crossed double digit market share in Europe (passing the fruity phone in several markets). • Use your existing development skills. • Room in the app store for high quality apps.
  4. 4. What Do They Share?
  5. 5. Design Differences • Different form factors. • Different controls. Win8 - Gridview (horizontal), WinPhone LongListSelector (vertical). • Different back buttons (hardware vs. software) • Different application button bars. • Different live tiles.
  6. 6. Where Do We Start? • We need a pattern that allows us to separate the UI layer from the application state/logic and from the data layer.
  7. 7. Model-View-View Model Pattern • The M-V-VM pattern is based on a variation of the MVC pattern which promotes a separation of concerns between UI and application logic layers. • Two-way data binding allows the use of the Observer pattern to decouple Views from the state and operations of the application.
  8. 8. Where Should We Put Shared Code? • We need a place to put our shared View Models and Models so that it can be referenced by either platform.
  9. 9. Portable Class Libraries (PCL) The Portable Class Library project supports a subset of assemblies from the .NET Framework, Silverlight, .NET for Windows Store apps, Windows Phone, and Xbox 360, and now Xamarin iOS/Android! Windows Store Views, and platform specific code Models View Models Windows Phone 8 Views, and platform specific code Xamarin iOS or Android Views, and platform specific code
  10. 10. Portable Class Libraries (PCL) What kind of code goes into a PCL? • Models • Core View Models • Data Layer / Service Consumption • Other Generic Logic
  11. 11. Portable Class Libraries (PCL)
  12. 12. What About Other Types Of Code? • Not everything can be moved back into the PCL. • Some code, like converters, has to stay in our UI projects.
  13. 13. Linked Files Linked files are shortcuts added to one project that points to a file in another project. What types of files should I consider linking? • Converters • Common platform implementation • Assets
  14. 14. Linked Files
  15. 15. What About Code That is Slightly Different? • Sometimes, there are only slight differences between platforms and their API (i.e. IValueConverter).
  16. 16. Compiler Directives Compiler directives tell the compiler which block of code to run based on the platform being compiled for. • • #if NETFX_CORE/WINDOWS_PHONE Allows you to use linked files when there are minor differences because of platform divergence.
  17. 17. Compiler Directives
  18. 18. PCL vs. Linked Files PCL Linked Files Pros: Pros: • Cleaner, simpler code. • Full API access. Cons: Cons: • Limited API access. • Can’t reference non- • More complex (messy) PCL assemblies. code.
  19. 19. Copy & Paste (no, really) • XAML snippets • Styles
  20. 20. What If I Need To Call Platform Specific API Or Non PCL assembly in My View Model / Commands? • Sometimes Your View Model will need to trigger navigation, read or write from local storage, or pin a tile to the start screen.
  21. 21. OOP Patterns • Use base classes with virtual methods that are overridden with platform specific API calls in derived classes. • Use interfaces to de-couple derived classes so that more code can reside in PCL.
  22. 22. Platform Adapter • A Platform Adapter is an abstract class for which each platform project implements a specific set or interfaces for their platform. • Code in the PCL can then be written to invoke platform specific tasks (such as navigation, file I/O, etc.) agnostic to the implementation for each platform.
  23. 23. Platform Adapter
  24. 24. What about Localization? • Windows Phone 8 and Windows Store apps use different approaches, making resource re-use challenging.
  25. 25. Localization • Windows Phone 8 apps use .resx files, localization through data binding. <TextBlock Text="{Binding Loc.AppTitle, Source={StaticResource Localization}}"/>
  26. 26. Localization • Windows Store apps use .resw files, localization through x:UId. <TextBlock x:Uid="TextBlock1" Text="DesignTimeText"/>
  27. 27. Localization • Storing localization string in PCL is possible, but you must: • Hack your PCL project file to add the <Supported Cultures> element. • Move all of your .resx files from your Phone project into the PCL. • Keep stub .resw files in your Windows 8 project with at least one string in each file. • Not use the new x:Uid attribute in Windows Store apps. You must use the legacy data binding approach instead.
  28. 28. Localization
  29. 29. Summary • • PCLs let us share: • Models • Business Logic • Web Services • Helpers • Core View Models • Core Commands Linked Files • Converters • Some Controls • Common API implementation • Static assets
  30. 30. Questions?