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

4. Tailoring the experience

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