universal apps for windows 8.1 and windows phone 8 · universal apps. how universal are they? x x...
Post on 29-Jul-2020
2 Views
Preview:
TRANSCRIPT
Philip Japikse (@skimedic)
skimedic@outlook.com
www.skimedic.com/blog
Microsoft MVP, ASPInsider, MCSD, MCDBA, CSM, CSP
Principal Consultant/Architect, Strategic Data Systems
UNIVERSAL APPS FOR WINDOWS 8.1 AND
WINDOWS PHONE 8.1
Principal Consultant/Architect, Strategic Data Systems
http://www.sds-consulting.com
Microsoft MVP, ASPInsider, MCSD, MCDBA, CSM, CSP
Founder, Agile Conferences, Inc.
President, Cincinnati .NET User’s Group
Co-host, Hallway Conversations
www.hallwayconversations.com
Phil.About()
Application Development and Application Renovations
Architecture, Development, and Architectural Design Reviews
.NET, Java, SharePoint
Agility - Agile Coaching and Transformations
Cloud Enablement
Mobile – iOS, Android, Windows
Training - Agile, .NET
Our place or yours!
Contact me at phil@sds-consulting.com
Strategic Data Systems – What we do:
Some of our Customers (That I can Share)
UNIVERSAL APPS
HOW UNIVERSAL ARE THEY?
X X
Coming
Soon
CONVERGENCE IS A JOURNEY
Windows Phone 7.5 Windows Phone 8.0
Convergence Begins with IE
• WP 7.5 shipped with IE9
• Same IE codebase as Windows
• Same JavaScript engine as
Windows
Converged Core OS
• Common NT kernel, file system
and core networking
• Kernel mode driver f/work
• Secure boot & BitLocker
Developer Platform
• Partial API convergence
(focus on sensors & IAP)
• Native Code (C++) and DirectX
• IE10
Converged Dev Platform
• More skillset reuse
• More code reuse
• More seamless app experiences
Aligning the Stores
• Shared dev registration
• Shared entitlement
Common Core Platform
• Proximity & Location frameworks
• Security & identity
• Task scheduler
The Windows Runtime (WinRT)
is the shared runtime and API
space used by store apps across
the Windows platform (phone and
client)
Dramatic convergence in 8.1 Goal is 100% convergence for dev scenarios
In 8.0, we had ~30% API convergence
With 8.1, we move well past 90%+
convergence
API CONVERGENCE ACROSS WINDOWS PLATFORMS
CommonWinRT APIs
Phone-specificWinRT APIs
Windows-specificWinRT APIs
CONVERGED CONTROLS
80% exact same XAML 20% custom
Common SignatureOptimized
DatePicker
TimePicker
CommandBar
AppBar
Button
CheckBo
x
RadioButton ProgressBar
Slider
ToggleSwitchHub
Pivot
ListView
GridView
WINDOWS DEVELOPER PLATFORM 8.1
| |
Legend
NATIVE APP DEVELOPMENT IN WINDOWS PHONE 8.1
CameraCaptureTask
Camera Lenses
Lockscreen background image
Runs under lock
Background audio agent
Alarms/Reminders
SocialRT (SL 8.1 only)
VoIP
Continuous background location
tracking (SL 8.0 only)
Wallet agents
System ServiceModel (WCF/SOAP)
FEATURES ONLY AVAILABLE ON SILVERLIGHT (WP)
CREATING A UNIVERSAL APP
CONVERTING EXISTING PROJECT TO UNIVERSAL APP
THE BETTER OPTION
Creating a Universal App
CODE SHARING STRATEGIES
THREE MAIN MECHANISMS
Shared Project Files
The best option – essentially build “magic”
Portable Class Libraries (Not covered today)
Successfully used for a long time
Must consider lowest common denominator
Linked Projects (Not covered today)
Maybe, for simple projects
SHARED PROJECTS
Project contents get pulled into each platform specific project
Use the same namespaces across all three
Use partial classes and methods across all three
Shared Project Reference Manager
http://bit.ly/sharedprojectmanager
Dropdown select the context for the
code between
WindowsPhone
Windows
SETTING THE CONTEXT IN SHARED PROJECT
CODE WINDOW CHANGES
Windows Windows Phone
PLATFORM ISOLATION
HANDLING PLATFORM ISOLATION IN SHARED CODE
90% != 100%
Three main mechanisms:
Compiler Directives
Can make code difficult to read
Good for small problems
Inheritance
Complicates code, reduces flexibility
Partial classes/methods
Easy platform isolation
Splits code into multiple locations
COMPILER DIRECTIVES#if WINDOWS_PHONE_APP // Windows Phone Specific Code #else// Windows Specific Code #endif
#if WINDOWS_APP // Windows Specific Code #else// Windows Phone Specific Code #endif
Two built in:
WINDOWS_APP
WINDOWS_PHONE_APP
INHERITANCE
//In shared project public class ViewModelBase{
public virtual string AppTitle { get; set; } }
//In platform specific project public class InheritedViewModel: ViewModelBase{
public override string AppTitle{
get { return “My Phone Project”; }
} }
Define base class in shared
project
Override in platform specific
projects
PARTIAL CLASSES//In shared project public partial class MainPageViewModel: ViewModelBase{
public MainPageViewModel() {
SetAppTitle(); } partial void SetAppTitle(); public string AppTitle{
get { return _appTitle; } set { _appTitle = value; }
} } //in Windows Phone project public partial class MainPageViewModel{
partial void SetAppTitle() {
_appTitle = "Group Bill Splitter (WP8.1)"; }
}
Define partial class in each project
Leverage partial methods
Must return void
If not implemented, they are
removed from the IL
Great for project files like
App.xaml.cs
Code Sharing and Platform Isolation
REPLACING MAIN PAGE WITH BASIC PAGE
WHY ADD XAML BASIC PAGE?
Updates the layout of your application
Adds framework classes (including)
Navigation
RelayCommands
SuspensionManager
Observable Dictionary
For more information see ReadMe.txt (also added to the project)
ADDING THE BASIC PAGE
Delete MainPage.xaml
From Windows and Windows Phone project
Add BasicBage to one project
Name it MainPage.xaml
Common directory gets created
Move Common directory to shared project
Add BasicPage to other project
Name it MainPage.xaml
Adding Basic Page
SHARING XAML
SHARING XAML IS MUCH HARDER
Each device has a different scale and usability modes
Apps need to be responsive
XAML doesn’t support compiler directives
Options:
Keep pages entirely native
Keep XAML files in platform specific projects
Share XAML.cs files
Use user controls
Create styles for platform specific projects
Clipboard inherit
<Application x:Class="GroupBillSplitter.App"xmlns="http://schemas.microsoft.com/winfx/2006/xaml/pre
sentation"xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"xmlns:converters="using:GroupBillSplitter.Converters"><Application.Resources>
<ResourceDictionary><ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="ms-appx:///Platform.xaml"/>
</ResourceDictionary.MergedDictionaries><Style x:Key="TextBoxStyle1"
TargetType="TextBox"BasedOn="{StaticResource TextBoxStyle}"><Setter Property="Foreground"
Value="Black"/><Setter Property="Background"
Value="White"/></Style>
</ResourceDictionary></Application.Resources>
</Application>
Create resource dictionary in each
platform specific project
Create platform specific styles
across platforms
PhoneAccentBrush
Merge them in App.Xaml
PLATFORM SPECIFIC STYLES<!-- Windows Phone --><ResourceDictionary …>
<Style x:Key="TextBlockGridStyle“TargetType="TextBlock"BasedOn="{StaticResource BodyTextBlockStyle}"><Setter Property="FontFamily"Value="Global User Interface"/><Setter Property="HorizontalAlignment“Value="Right"/><Setter Property="Margin"Value="0,0,10,0" /><Setter Property="VerticalAlignment"Value="Top" />
</Style>…</ResourceDictionary>
<!-- Windows 8 --><ResourceDictionary … >
<!– Built in Phone style --><SolidColorBrush x:Key="PhoneAccentBrush“
Color="CadetBlue"/>
<!-- Windows 8 --><Style x:Key="TextBlockGridStyle"
TargetType="TextBlock"BasedOn="{StaticResource SubheaderTextBlockStyle}"><Setter Property="FontFamily"Value="Global User Interface"/><Setter Property="HorizontalAlignment"Value="Right"/><Setter Property="Margin"Value="0,5,10,5" /><Setter Property="VerticalAlignment"Value="Top" />
</Style></ResourceDictionary>
Sharing XAML
STORE CONVERGENCE
TWO STORES, ONE APP
Reserving an app name in one store creates an app identity
It can then be reserved in the other store with the same identity
Buy the app once, it’s available on both platforms
In App Purchases are valid across stores
Microsoft Azure Mobile Services shared across platforms
Keyed off app identity
Store Convergence
Questions?Questions?
phil@sds-consulting.com
www.sds-consulting.com
skimedic@outlook.com
www.skimedic.com/blog
www.twitter.com/skimedic
www.hallwayconversations.com
www.about.me/skimedic
Contact Me
top related