UWP apps development - Part 1
Download as PPTX, PDF0 likes25 views
A universal app allows building an app that targets both Windows and Windows Phone using shared code and resources. The document discusses different strategies for sharing code and resources between platforms, including linked files, shared projects, and portable class libraries. It also covers approaches for handling platform-specific capabilities and views in a universal app.
UWP apps development - Part 1
- 1. UniversalApps Development Part 1/3 Jiri Danihelka
- 2. What is a universal app? • You can build an app that targets Windows and Windows Phone • It is not (currently): – A single binary – A non-Windows binary (Xamarin) application • Targeting iOS • Targeting Android – An HTML/JavaScript (Cordova) application
- 3. What does it mean to be universal? The consumer promise • Similar theme • Common experience • Shared authentication • Shared data/profile • Single app purchase • Single IAP purchase
- 5. What does it mean to be universal? The Windows Store perspective • Shared package full name • Single app purchase • Single IAP purchase • Roaming data • Shared notification channel
- 6. What does it mean to be universal? The Visual Studio perspective • Shared project-type – A new feature or bug in one project, everything is updated • Still possible to tailor • Reusing code is meaningful because of unified APIs
- 7. Solution 'App1' App1_Phone81 App1_Windows81 Class1.cs Page1.xaml Asset1.png Class1.cs Page1.xaml Asset1.png App.xaml App.xaml Solution 'App1' App1_Phone81 App1_Windows81 MyData.cs MyData.cs MyWebservice MyData.cs Linked files for sharing source code Solution 'App1' App1_Phone81 App1_Windows81 Class1.cs Page1.xaml Asset1.png References App1_Shared References App1_Shared App1_Shared App.xaml Shared Projects for sharing source code Solution 'App1' App1_Phone81 App1_Windows81 Class1.cs Page1.xaml Asset1.png References App1_PCL References App1_PCL App1_PCL App.xaml App.xaml .NET PCLs for sharing binaries Types of sharing Linked files in a super-crazy way
- 8. Solution 'App1' App1_Phone81 App1_Windows81 Class1.cs Page1.xaml Asset1.png Class1.cs Page1.xaml Asset1.png App.xaml App.xaml Solution 'App1' App1_Phone81 App1_Windows81 MyData.cs MyData.cs MyWebservice MyData.cs Linked files for sharing source code Solution 'App1' App1_Phone81 App1_Windows81 Class1.cs Page1.xaml Asset1.png References App1_Shared References App1_Shared App1_Shared App.xaml Shared Projects for sharing source code Solution 'App1' App1_Phone81 App1_Windows81 Class1.cs Page1.xaml Asset1.png References App1_PCL References App1_PCL App1_PCL App.xaml App.xaml .NET PCLs for sharing binaries Types of sharing Linked files in a super-crazy way
- 9. Consider… • Linked files – It’s all manual • Shared projects – Basically MSBuild • Portable class libraries – Lowest common denominator
- 10. Rules of thumb • Compilation directives – Can make code difficult to read – Solves small, quick-hit platform problems • Partial classes – Makes it easy to isolate platform code – Difficult to see the entirety of your code • Base classes – Familiar concept to most programmers – Partial and abstract methods are options
- 11. Three XAML strategies Solution 'App1' App1_Phone81 App1_Windows81 LoginPage.xaml References App1_Shared References App1_Shared App1_Shared Solving styles Faking themes Adaptive nirvana Most reuse, least likely Solution 'App1' App1_Phone81 App1_Windows81 References App1_Shared References App1_Shared MainPage.xaml MainPage.xaml Device-specific Least friction, most likely LoginPage.xaml App1_Shared MainPage.xaml Solution 'App1' App1_Phone81 App1_Windows81 LoginPage.xaml References App1_Shared References App1_Shared App1_Shared MainPage.xaml Dictionary.xaml Dictionary.xaml
- 12. Strategies to manage platform-specific visibility
- 13. Reality check • Don’t expect to save time writing XAML • Do expect to save time writing implementation code
- 14. Module recap • Code sharing strategies • Platform-specific code • Sharing XAML
- 15. Module Agenda • Platform capabilities • Device variability • Design considerations
- 16. Windows • Print contract • New window • Search Box • App Bar Phone • Call dialog • Back button • Status Bar • Pivot control Platform-specific capabilities
- 17. Accessibility • UI automation – Accessibility checker • Assistive technologies – On screen keyboard, only Keyboard – Voice recognition, varying input – Screen readers, varying output • Theme Resources – High contrast – Variable Fonts • Media captioning • Customizing controls – Automation peers (IValueProvider) – Accessibility names / Label(Name) / View(Raw) / LiveRegion
- 18. What if the user…? The emulator is sufficient for flow verification. Follow standard approaches with controls
- 19. What if the device is…? 40” 30” 24” 18” 14” 10” 8” 6” 4” The emulator is insufficient for asset verification. Avoid adding additional scaling to your own assets. Don’t overthink it. If it looks good, you’re done. It’s up to you to set the expected size of assets.
- 22. Designing with a common visual vocabulary TT
- 23. Which design assets to share Windows • Assets • Scaled Images • Dictionaries • Templates.xaml • FontSizes.xaml • Controls.xaml • Platform.xaml • Views • Main.xaml • Detail.xaml • Settings.xaml Phone • Assets • Scaled Images • Dictionaries • Templates.xaml • FontSizes.xaml • Controls.xaml • Platform.xaml • Views • Main.xaml • Detail.xaml • Settings.xaml Shared • Images • Simple Images • Dictionaries • Brushes.xaml • FontFamilies.xaml • Views • Login.xaml • WidePage.xaml • NarrowPage.xaml