Download to read offline
Uploaded byJiri Danihelka
UWP apps development - Part 1
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.
More Related Content
Similar to UWP apps development - Part 1
More from Jiri Danihelka
UWP apps development - Part 1
- 1.
- 2. What is auniversal 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 itmean to be universal? The consumer promise • Similar theme • Common experience • Shared authentication • Shared data/profile • Single app purchase • Single IAP purchase
- 4.
- 5. What does itmean 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 itmean 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 Linkedfiles 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 Linkedfiles 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 manageplatform-specific visibility
- 13. Reality check • Don’texpect to save time writing XAML • Do expect to save time writing implementation code
- 14. Module recap • Codesharing strategies • Platform-specific code • Sharing XAML
- 15. Module Agenda • Platformcapabilities • 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 theuser…? The emulator is sufficient for flow verification. Follow standard approaches with controls
- 19. What if thedevice 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 acommon visual vocabulary TT
- 23. Which design assetsto 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