We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Building Universal Apps for Windows Phone and Windows 8.1

00:00

Formal Metadata

Title
Building Universal Apps for Windows Phone and Windows 8.1
Title of Series
Number of Parts
170
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
With Windows Phone 8.1, convergence with the Windows programming frameworks means that it is easy to build universal apps that run on both Windows tablets and PCs, and on Windows Phone. In this session, we will take a look at the new features in Visual Studio 2013 and the Windows Phone 8.1 SDK that help you build universal apps, and dive into the architecture of a ‘real-world’ universal app, looking at questions such as when to use shared code in the Shared folder, when and how to use Portable Class Libraries, how to share XAML and what you should do to create tailored UI that differs between a Phone screen and a Tablet/PC screen.
3
Thumbnail
59:06
71
112
127
130
Windows PhoneBuildingCodeMobile appCompilation albumSocial classInjektivitätState of matterLatent heatMaizeWeightState of matterComputing platformInterface (computing)CodeInjektivitätOnline helpMobile appTablet computerWindowTemplate (C++)Level (video gaming)Multiplication signQuicksortTouch typingPoint (geometry)Social classAreaPartial derivativeCompilation albumScripting languageReal numberShared memoryMoment (mathematics)PurchasingProjective planeBitData storage deviceBuildingUniverse (mathematics)SpacetimeRight angleCircleGame controllerNumberDifferent (Kate Ryan album)Design by contractLibrary (computing)Set (mathematics)VirtualizationSpeciesImplementationComputer configurationSampling (statistics)Disk read-and-write headRun time (program lifecycle phase)Programming languageCross-platformStrategy gameDiagramCondition numberProcess (computing)MappingObject (grammar)Java appletVideoconferencingTrailHydraulic jumpCivil engineeringPortable communications deviceVisualization (computer graphics)Block diagramRevision controlDemo (music)Computer animation
View (database)SummierbarkeitSoftware testingLie groupWeb pageBitBitPattern languageSampling (statistics)View (database)CausalityVirtual machineQuicksortRevision controlGroup actionPresentation of a groupUnit testingPlanningLie groupSource codeComputer animation
Electric currentAverageLanding pageWeb pageWindowUniverse (mathematics)PlastikkarteMobile appLine (geometry)Moment (mathematics)Multiplication signCellular automatonPoint (geometry)System callUltraviolet photoelectron spectroscopyComputer animation
Directed graphSoftware testingForm (programming)BitBefehlsprozessorView (database)Annulus (mathematics)SpacetimePhysical systemLatent heatDefault (computer science)WindowComputer fileIndependent set (graph theory)InformationoutputComputer wormVacuumProgrammable read-only memorySign (mathematics)Software bugComa BerenicesSimultaneous localization and mappingWeightWeb pageExecution unitComputing platformMobile appSynchronizationOvalStack (abstract data type)Parameter (computer programming)Frame problemMIDIStatisticsSource codePartial derivativeLogicEquivalence relationRankingContent (media)BuildingConfiguration spaceRootAlpha (investment)Asynchronous Transfer ModeData modelInclusion mapRight angleMobile appWindowView (database)Computer programmingProjective planeBitArithmetic progressionStructural loadCartesian coordinate systemOptical disc drivePoint (geometry)Landing pageStandard deviationService (economics)Social classPattern languageComputer architectureFlow separationEndliche ModelltheorieIdeal (ethics)Visualization (computer graphics)Universe (mathematics)Data conversionFunction (mathematics)Web pageData storage deviceLogicGoodness of fitUnit testingTouchscreenGroup actionDisk read-and-write headMultiplication signUtility softwareMedical imagingBuildingShift operatorRow (database)GradientTime zoneBootstrap aggregatingMass2 (number)Hash functionShared memoryComputer animation
Stack (abstract data type)InformationWeb pageParameter (computer programming)QuantumSpacetimeLatent heatoutputTemplate (C++)WindowSoftware bugProgrammable read-only memoryTunisSoftware testingOrientation (vector space)Keyboard shortcutDigital photographySource codeVisual systemData typeStylus (computing)Category of beingClique-widthOpen setRootComputer iconNormed vector spaceView (database)Markup languageInstallable File SystemContent (media)Hacker (term)Gamma functionDivision (mathematics)Limit of a functionAdditionPivot elementEmailInclusion mapConfiguration spaceBuildingBefehlsprozessorBitComputer-generated imageryPartial derivativeSynchronizationTerm (mathematics)Coma BerenicesExecution unitFile formatCompact spaceHost Identity ProtocolLocal ringExpressionWechselseitige InformationVertical directionBitWeb pageGoodness of fitView (database)Pivot elementWindowParsingGame controllerContent (media)Multiplication signProjective planeCausalityMultilaterationException handlingComputing platformKey (cryptography)EmailPattern languageNormal (geometry)Mobile appLatent heatInformation1 (number)Digital photographyMoment (mathematics)Tablet computerSystem callGradientRule of inferencePlastikkarteRight angleLanding pagePlanningProcess (computing)Computer clusterPresentation of a groupSheaf (mathematics)Disk read-and-write headSign (mathematics)DialectData miningComputer animation
Software testingLeakAsynchronous Transfer ModeBound stateData typeComa BerenicesComputer-generated imageryOvalWindowError messageSpacetimeMobile appExecution unitBitGroup actionSystem callEmpennageTelephone number mappingMobile appCodeWindowStructural loadComputer fileExpected valueOpen setBitDifferent (Kate Ryan album)AreaRun time (program lifecycle phase)Radical (chemistry)Moment (mathematics)Exception handlingMatching (graph theory)Machine codeOrder (biology)Greatest elementPoint (geometry)Computer animation
Windows PhoneComputer-generated imageryShared memoryCodeComputer fileView (database)Data modelLogicType theoryComputer configurationLibrary (computing)Social classPortable communications deviceComponent-based software engineeringRun time (program lifecycle phase)Point (geometry)Mobile appUniverse (mathematics)WindowData storage deviceCodeFunction (mathematics)Key (cryptography)Flow separationPower (physics)Demo (music)View (database)Shared memoryLanding pageComputer fileLogicProjective planeWeb pageOpen setLink (knot theory)Goodness of fitGreatest elementComputer configurationData modelComputing platformLine (geometry)Endliche ModelltheoriePlastikkarteMedical imagingMiniDiscComputer animation
BitComputer configurationCodeType theoryPortable communications deviceLibrary (computing)Social classComputer fileShared memoryComponent-based software engineeringRun time (program lifecycle phase)View (database)Source codeMobile appFunction (mathematics)Computer-generated imageryUsabilityJava appletScripting languageProjective planeLibrary (computing)Set (mathematics)UsabilityBuildingBitFunction (mathematics)Visualization (computer graphics)WindowDifferent (Kate Ryan album)Link (knot theory)Connectivity (graph theory)Disk read-and-write headCartesian coordinate systemUniverse (mathematics)NumberRun time (program lifecycle phase)Computer configurationExtension (kinesiology)CASE <Informatik>Computing platformFilter <Stochastik>CodeSocial classPortable communications deviceCategory of beingMultiplication signFraction (mathematics)Point (geometry)Selectivity (electronic)ArmFlow separationSign (mathematics)PlotterForm (programming)Process (computing)MassComputer animation
Maxima and minimaOvalComputer fileError messageSpacetimeSoftware testingWindowView (database)Social classWindows PhoneService (economics)Computer-generated imageryInterface (computing)Gamma functionSynchronizationInstance (computer science)Fluid staticsData typeData dictionaryFrame problemMenu (computing)Arc (geometry)Execution unitParameter (computer programming)Exception handlingData modelScalable Coherent InterfaceHydraulic jumpModal logicGeometrySoftware bugWeightInclusion mapInformationLemma (mathematics)Task (computing)Message passingElectronic visual displayState of matterMultiplication signReal numberService (economics)ArmRight angleView (database)Interface (computing)Structural loadCategory of beingEndliche ModelltheoriePoint (geometry)Cartesian coordinate systemLibrary (computing)InjektivitätRun time (program lifecycle phase)ImplementationUnit testingObject (grammar)Power (physics)WindowQuicksortMathematicsBitProjective planeGame theorySoftware testingSocial classCodeEvent horizonNumberWeb pagePlastikkarteKeyboard shortcutIterationSet (mathematics)LogicInstance (computer science)RoboticsOrder (biology)Mobile appPattern languageNavigationComputer animation
CodeWindows PhoneComputer fileComputer networkInternationalization and localizationComputer-generated imageryType theoryOpen setThumbnailView (database)Conditional probabilityComputing platformSocial classInheritance (object-oriented programming)CompileroutputLine (geometry)Social classProjective planeSingle-precision floating-point formatCodeMobile appCycle (graph theory)BitCategory of beingGroup actionAdditionDifferent (Kate Ryan album)Digital photographyCondition numberWindowSystem callMachine codeSemiconductor memoryPrandtl numberDirected graphControl flowMoment (mathematics)Computer fileStatement (computer science)Hash functionPoint (geometry)Gastropod shellComputing platformOperational amplifier1 (number)Disk read-and-write headMassComputer hardwareData storage deviceShared memoryFilter <Stochastik>Interactive televisionAsynchronous Transfer ModeExtension (kinesiology)MultiplicationDesign by contractProcess (computing)CircleInheritance (object-oriented programming)Partial derivativeCartesian coordinate systemVideo gameOpen setCompilerView (database)Run time (program lifecycle phase)File formatLibrary (computing)Analytic continuationPortable communications deviceComputer animation
Computing platformAbstractionSocial classLatent heatCodeFunction (mathematics)Source codePartial derivativeMechanism designLogicSynchronizationRootInheritance (object-oriented programming)BitComputing platformDisk read-and-write headDifferent (Kate Ryan album)Latent heatGoodness of fitAbstractionPhysicalismSocial classMultiplicationDemo (music)Partial derivativeSource codeCompilation albumWindowCASE <Informatik>Projective planeLine (geometry)MereologyIterationCompilerSpacetimeFlow separationComputer fileIndependence (probability theory)Greatest elementCodeComputer animation
Windows PhoneTask (computing)OvalString (computer science)WindowComputer-generated imagerySoftware testingExecution unitComputing platformInformation managementBefehlsprozessorSummierbarkeitHTTP cookieSynchronizationRouter (computing)Asynchronous Transfer ModeError messageDiscrete element methodEuler anglesInclusion mapRAIDArc (geometry)AreaFrame problemContext awarenessCache (computing)MathematicsInfinityPhysical lawElectronic meeting systemContent (media)RootElectric currentStatisticsWeb pageLarge eddy simulationProgrammable read-only memoryCharacteristic polynomialSocial classData modelComputer fileCompilerVarianceEndliche ModelltheorieProcess (computing)Computer fileOpen setCompilation albumAnalytic continuationHeegaard splittingLine (geometry)CodeMobile appWindowIterationEvent horizonArc (geometry)LogicSingle-precision floating-point formatLatent heatGastropod shellBitDisk read-and-write headData storage deviceBoilerplate (text)Content (media)Computing platformCategory of beingAdditionComputer hardwareHash functionNavigationProper mapView (database)Key (cryptography)HookingMereologyPlastikkarteExterior algebraMoment (mathematics)Condition numberTemplate (C++)Sampling (statistics)Standard deviationWeb pageShared memoryCuboidFrame problemGame theoryDigital photographyPoint (geometry)System callComputer animation
CodeDemo (music)DivisorGUI widgetComponent-based software engineeringWeb pageComplete metric spaceState of matterSocial classExecution unitData dictionarySource codeMaxima and minimaKeyboard shortcutShared memoryStatisticsDrill commandsWeb pageMobile appData managementComputing platformView (database)BitTemplate (C++)Visualization (computer graphics)WindowState of matterDifferent (Kate Ryan album)VolumenvisualisierungLatent heatData dictionaryGraph coloringBlock (periodic table)Run time (program lifecycle phase)Revision controlSystem callDisk read-and-write headIdentity managementShared memoryElectronic mailing listRight angleGame controllerSampling (statistics)OvalFunctional (mathematics)Machine visionInformationSpacetimeAudiovisualisierungStatement (computer science)CodeLie groupAreaComputer animation
Clique-widthMultiplicationWeb pageKeyboard shortcutImage warpingMathematicsData typeComputer-generated imageryString (computer science)Analog-to-digital converterLatent heatState of matterNormal (geometry)WindowData dictionaryRight angleOpen setAudiovisualisierungAdditionPlastikkarteWeb pageSampling (statistics)Physical systemComputer animation
Visual systemSummierbarkeitExecution unitMIDIInstallable File SystemWindowManufacturing execution systemFrame problemSoftware testingSynchronizationCodeAudiovisualisierungData managementWeb pageDifferent (Kate Ryan album)State of matterPlastikkarteWindow1 (number)MathematicsPlanningMachine visionBitRow (database)Line (geometry)QuicksortAlgorithmMarginal distributionGroup actionTablet computerFrustrationContent (media)Point (geometry)Discrete element methodStructural loadClique-widthRotationComputer animation
Demo (music)Local ringMobile appStandard deviationSynchronizationHeat transferComputer networkEvent horizonBenachrichtigungsdienstClient (computing)Electric currentData storage deviceInflection pointMathematicsOvalPartial derivativeAndroid (robot)CodeSample (statistics)Windows PhoneGUI widgetInformationVideoconferencingComputer fileIdentity managementSoftware development kitWindowCompilation albumSocial classInjektivitätState of matterRevision controlTablet computerShared memoryState of matterMobile appCausalityPoint (geometry)Demo (music)Link (knot theory)Partial derivativeSocial classString (computer science)Point cloudData dictionaryWindowData managementPhysical lawAreaOperational amplifierSet (mathematics)Multiplication signEvent horizonDirected graphDevice driverRow (database)TouchscreenComputing platformAudiovisualisierungComputer fileFamilyCodeData storage deviceLatent heatHand fanService (economics)BitLevel (video gaming)View (database)Connected spaceGame controllerLocal ringClient (computing)CASE <Informatik>SynchronizationSoftware developerHookingCondition numberOnline chatSampling (statistics)FreewareComputer animation
Computer animation
Transcript: English(auto-generated)
OK, let's get started. All right, thanks very much for coming along to this talk. If any of you were in my previous talk before lunch, that was a kind of a high-level overview of Windows Phone 8.1, new stuff that's in it. So in this session, I'm going to dive deeper
into building a universal app. And it's going to be more of a real-world example in the kind of challenges that you'll meet and the opportunities that are there for you. So I'm going to do a worked example of something that's not too complicated, obviously, but work through creating a universal app from an existing Windows 8 one. So I'm Andy Wigley. I work as a technical evangelist
in Microsoft in the UK. And I've been incredibly busy with Windows Phone 8.1 right from Christmas time until the present day. But particularly last month, we recorded the Jumpstart videos, which are on Channel 9 and also on a Microsoft Virtual Academy course. So if you've got two and a half days to spare,
you could sit down and watch all of those videos, which takes you right from the beginnings, right through all of the new APIs, showing you how to code them all up. So topics for this one, we're going to just have a quick recap of what a universal app actually is, why we got this opportunity, what's changed in Windows Phone 8.1 that allows
us to create these kind of apps. But then we're going to actually build one. We're going to take one and create one. Look at the sharing strategies for how much can you share and what you do when there's a little bit of a you want to do some platform-dependent stuff. And that comes down to a number of different topics.
We've got this new thing called a shared project, which is a way of sharing stuff. It's a bit like Adders Link, if you've ever used that, but with new tooling around it. Or you can use portable class libraries. I'm going to touch on that one as to which of those are the most appropriate option in certain circumstances. And then where we have got shared code, well, what are the techniques we can use here?
What if you need to have a slight difference between the way the code runs on the tablet compared to how it's running on the phone? So how do we handle that? And there's a couple of techniques there around conditional compilation, partial classes, and using dependency injection to implement platform-specific versions of an interface or an implementation of an interface,
those kind of techniques. Then we'll look at how much or how you can share XAML between a tablet and a phone app, and when it's appropriate again to do so, and when you might not. And then I'm just going to touch briefly at the end on state sharing, so. Right, so what are universal apps?
So with Windows Phone 8.1, the new API, the big deal, the big deliverable with this release is the convergence of the Windows Store apps platform and Windows Phone apps platform. So at this start at the moment,
people who were here before lunch have already seen this. I apologize if this is not new, but the big circle, for those of you who are in here for the first time, is that it represents the Windows Runtime API set on big Windows, on Windows PCs, tablets. And then the little red one there was the Windows Runtime implementation on Windows Phone 8.0,
so the one that is out on phones at the moment. And there were a few APIs that were common, in-app purchase, a bit of Windows.storage, some sensors stuff, but really not a lot of convergence there. But when we get to Windows Phone 8.1, we're looking at a picture more like that. Still not 100% because a phone is different from a tablet.
There's some usage scenarios that don't make sense. I mean, there's a few things like the settings contract on the tablet. We don't have that on the phone. And there's a few other little bits and pieces, a few controls that are tablet only or phone only, but we are talking about a very small amount. The vast majority of the APIs are common.
Over 90% of the APIs are common now between Windows Phone and Windows tablet. And this is what allows us to take advantage of this to build universal apps where we're sharing a very high percentage of our code, and indeed, as Aml. So this is a kind of a block diagram showing you the different ways you can build apps for Windows Phone 8.1.
You can use HTML and JavaScript and our WinJS library to call down to WinRT. So you can create native apps entirely in HTML and JavaScript. So that's really cool if that's your preferred platform. Then in the XAML, Windows runtime XAML space, we've got, you can code in C++
or you can code in C sharp VB. And then also on Windows Phone, we've got Silverlight XAML, the way we've been building apps up till now. So when we're talking about universal apps, we're talking about that area. So there are, you can create a shared app where you can share code
between a Windows Phone Silverlight app and a Windows Store app. But there's a lot of mismatch. There's a lot of clunky edges that don't quite fit there. And if you're trying to do that, you're certainly gonna share hardly any XAML. All you can do is copy and paste like data templates, for example, and that sort of stuff. And your code, well, you know, actually with a Windows Phone Silverlight 8.1 app,
you've got all of the Windows Runtime API. So you can share a lot of your code there. But the real, the templates, everything we've got is all in that area. And so this is where the universal apps is where we're using Windows Runtime XAML or HTML. And we've got templates in Visual Studio that help you create apps that are gonna run on both.
So these are apps on the converged Windows 8.1 and Windows Phone 8.1 platforms. We've got Windows Runtime XAML in different programming languages and HTML with JavaScript. So how do you, you can create new projects with the universal, and I did one before lunch
where I just created it. There's a template in there. And it spits out a solution with a Windows Phone head and a Windows head in it. And then a common area, this shared project. And actually I had a question after that talk saying, do you have to create universal? What if I only wanna create a phone app? And actually I'd just kind of forgotten to say that, but absolutely, you can start with one.
You can just create a phone app and then later on add the Windows head to it. Or you can start with a Windows app and then later on create a Windows Phone and add the two in and then start moving stuff around into the shared folder. So none of these are dead ends. So you can easily right click on a project and to convert it into a universal app.
Right, I'm gonna walk through, there's a lot of demo in this talk. So I'm gonna walk through a work solution, if you like. I'm gonna start with, have any of you ever come across the fuel tracker sample before? Nobody? Okay, it's been around for a while. It's, I think it was originally created by the patterns and practices group as an example.
One over there, thank you. You wrote it. Okay, great, there you go. That's awesome. You should be up here, that's awesome. So the fuel tracker is this, it's a pretty crummy bit of code, frankly. And it's like, you know. But no, it was good.
It was a good example of how to use, you did it for showing MVVM originally, didn't you? Yeah, that's right, MVVM. So I've had, thank you very much, sir. Cause I've had good mileage out of this over the years. And I've used it at various talks for using, showing how you can do unit testing. And I've also adapted it further. So I've got true MVVM with MVVM lighting
and that sort of stuff. So I've had a lot of mileage out of this. Cause it's a nice simple example that's good for conference presentations. And this is a version of it, not yours, one I've created that's added a bit of things. But I've got views in it and I'll run it on my machine.
And this is a fuel tracker app. And this is one I wrote. And so the idea is you enter your car. Excuse the UI, it's pretty primitive. And you put the initial mileage when you get this car. So I bought my Jaguar and it's got 1000 miles on it. And then you choose the picture.
Actually, I don't think I've got any, I don't think I've got any, you know what that'll do. Pictures of cars actually. So that's a car. I know it doesn't look like one, but that's a car. Imagine that's a car. And then we can start doing fill ups. So the idea here is that you, every time you fill up your vehicle, you simply go on and say, okay, well now we've done 1500 miles.
And in that 500 miles, I put in, let's say 30 gallons. And the price per gallon was $3.75. And so now we've got a fill up and that's our last fill up. And you can check how much, what your fuel economy is like. And then you just add more fill ups and away you go.
So that's the basic app. Which is nice. And what are we gonna do now is turn it into a universal app. Cause really this app is so good. I want to have it on my phone as well. So we'll start by, this is at the moment, it's just a Windows 8.1. There it is.
We've got three views that you saw all of them there. Summary page is the landing page. A fill up page where you do a fill up and car details page where you edit the details of the car. And then there's a whole bunch of other stuff, view models. Now I'm gonna add to this, our Windows Phone 8.1 project to this solution. So I just right click anywhere on there
and gives you a warning saying the world's gonna end. And then you say, okay. And now what it has added to my solution is the kind of bare bones of a universal project. So I've got my, still got everything where exactly nothing's been moved. I've still got my Windows 8.1 app and I can run it from there. But it's added in this Windows Phone
8.1 project. We've got some assets with some standard gray blocked out things. I think I've actually got some assets. Let's fix that. Oh no, I haven't. I thought I did.
Did I not do that? Oh no, I didn't do that. Okay, I'm getting confused with another one. So anyway, you can change these for assets that are appropriate for the phone app. We've got a blank empty main page in there and it's got its own manifest. Each of them got their own manifest. These are what I call heads.
So they compile out to a Windows Store app package and a Windows Phone app package. But we wanna build this app as easily as possible. So I'm gonna start transferring stuff down into this shared folder down here. This guy here. And I'm gonna pick up various bits and pieces of this. So the common folder has got some
utility classes in it and some converters. So yeah, we'll have that. There's some more converters there for doing UI, adapting UI that shows on the screen. I have that. They'll have the design. That's got design time data in it.
Images, certainly, yeah. Services, I'll talk about them in a little bit. View model, yeah, I won't do that. The app.xaml, ah, come on. App.xaml, I'm gonna have const, oh, hang on. I'm getting confused here.
Services I do want, sorry. Views I don't want. Those don't, that's all NuGet stuff. This is common stuff. So that's all stuff that actually I can drag all of this down, because it's all shareable, and drop it in. And if I hold shift, it will actually move it.
So it's moved it out of the Windows head and it's now all down here. So this is my shared project. It's actually not really a project. It's actually a shared folder, if you like. So it doesn't compile, there's no compiled output from a shared project. It looks like a project and you can add references to it, behaves like a project, but there's no compiled output.
Instead, everything in here is referenced from both the phone head and from the Windows head. So everything that's in here is gonna be included in both and will be compiled into both. Okay, so that's the start.
I'm gonna fix up my app.xaml.cs, because in the univer, and this is kind of a bit of a prior knowledge, if you like. So in here, this is all your standard bootstrapping logic, but I'm actually gonna want to go off and let's create a,
hang on, I've got two copies of Visual Studio here. Right, I start an empty one, Visual Studio. I'm just gonna create a dummy project, new project, because I want to steal the app.xaml from it, a universal app, blank app. Put it in my junk folder, which one day I will empty.
And then all I want to do is copy when it's built. This is another, this is a kind of a prepackaged one. So here's my app.xaml. Let's have this one. And I'm gonna copy all of this and I'll explain why in just a second.
And I'm going to replace everything in here with that one. And the reason why I've done this is of course this one is already wired up for handling both. It's got this transition collection,
which you just need to resolve that. It's got some Hashif Windows Phone app. So this bit only applies, this is in the shared folder, remember, so it's gonna end up in both. So this bit is only gonna apply if it's a phone app. And actually you can select which one you're looking at up here. So when it's a Windows app, that's not gonna be included.
But this is an app.xaml that will work for both. The only thing I need to change is main page isn't right anymore, because my main page in the Windows is summary page. All right. So we're making progress here. Let's, well, let's build it and see how we're doing.
Be a few errors, I think. Oh, yeah, can I have more than one application xaml item? Oh, that's because I've got an app.xaml still in my phone project. So let's get rid of that. Because that's shared, that's common, build again. And we'll probably get, oh yes, loads of GalaSoft references
and this kind of thing. So this is because this project, now I have to hold my hands up at this point and I'm sure you wouldn't expect otherwise. But I have actually stacked the odds a little bit in my favor in this project because the original one was very well structured and it used MVVM.
So it's nice. I've got a very nice separation between my views and my logic. So MVVM, for those of you who aren't familiar with it, it's just a pattern, architectural pattern where your views are really thin and you use data binding to connect to view models which encapsulates all your logic. And the beauty is your view models don't have any UI stuff in them
which makes them ideal for sharing in this kind of way. And it's ideal for unit testing because UI doesn't get in the way. So there's loads and it's best practice anyway. It's good programming design. So this uses MVVM. And so I need to add in the missing references that are needed by the shared stuff
which is JSON.net is one of them. So that can go in. And the other one is MVVM lite. Oh no, got the name wrong. MVVM, I'll just search for that. That should pick it up. Yeah, there we go. MVVM lite. This is the package I like to use.
I mean, there are loads of them out there so I'm not saying this is better than any others but it's one that I'm very comfortable with using. So I'm adding the references into phone project. So that should fix up all of the missing stuff. So let's build again. Okay, and then the only problem is,
yeah, so the phone project is complaining a bit. So over here, the phone project, Windows phone project has got a problem because this app.xaml is looking for a views slash summary page. It doesn't like this view.
So let's fix up the, this is the last bit of this really. So this is my views. At the moment, I've got these three views in here. I'm gonna just drag that and drop that down into there because I'm gonna share a couple of these pages. So there's views. I'm gonna share the car details page and the fill up page in both.
Summary page, I'm gonna actually keep as platform specific. And the reason I'm gonna do that, so delete it out of there and fix this out first. So hang on, that one is in the shed. So I can get rid of it out of there. And that one's in the shed. So now summary page here. This is my tablet main, the landing page,
which has got, it's basically, it's got three kind of islands of information. Maybe should have used a hub control for it. But at the moment it's just to some, we've got some stack panels. This one is a stack panel for the car photo and name the first one.
And then the middle bit is this guy, all the stuff in there. That's another stack panel. And then I've got another one. These are all positioned in a grid. There you go, there's all that stuff. And then finally I've got this, which is my history bit. So I've got three islands of information, which is okay for a tablet, but doesn't make any sense on the phone.
So this is one of the first key things to think about is that a tablet user experience and a phone user experience are not the same. The way you use them is different. You know, you tend to hold a tablet in landscape and you swipe from left to right. Whereas a phone, you tend to hold it in portrait and swipe from top to bottom. Or you use a thing like a pivot control perhaps
where you do allow swiping from left to right. But either way, you want to think about the presentation. We're not trying to create carbon copy apps here. What we're trying to do is create the best user experience on each platform, but also make that as easy as possible. So by sharing as much stuff as possible. So let's create, I don't want main page.
That's irrelevant. But this guy, let's copy that into my phone project. So now I've got summary page and summary page, but the UI for this one in a phone is not really going to be what I want.
So, you know, there is my, it's just, oh, that's not very good. Let's make that 50%. There we go. So yeah, I mean, so this is not really what I want for the phone. So let's create a nice phone UI from this.
So I'm going to start over actually. I'm going to delete all of the, all the contents of this and start over. I've got an empty grid, I've got an app bar.
That's kind of good, but I want to use a pivot on the phone because a pivot control is, you know, is a better experience. So we go pivot and the header, no title, what is it? Title is equal to fuel tracker,
fuel tracker, fuel tracker, fuel tracker. There we go. And inside pivot, I want to have three pivot items. Pivot item and the header on that first one can be the car details one.
And I want three of these and we can have, this one could be your last fill up. And this one could be the summary, the history. So we've now got pivot and what we're going to put in here.
So let's go and just copy the bits and pieces from the original one. So first of all, we've got the car history bit, which is where, here we go, car photo name. Shall see, and we stick that into the first pivot.
We should be okay. And then go back and have this one and stick that into the second pivot. And that's all looking okay. And this one, shall see, and I'm going to copy that
and stick that into my third pivot. Right, let's build and see how we're doing. Build solution, no errors, two succeeded. All right, so now you've already seen me run
the Windows app. I'm going to change my startup project, which you can do in the toolbar, or you can do as normal over here. And let's see how we do on the phone. And well, it starts, that's pretty good.
Good start, good. So let's try and add a car. Oh, all right, XAML parse exception. Text, so what's this? Cannot find a resource with the name key navigation back button normal style. All right, so that's our first problem. Now, the reason for that is that when we,
these shared pages down here, here's the car details page, has got in it and it's shared between the two, remember, when it's running on the phone. So when we're running on Windows like that, you've got this back button here. Don't have that on a phone app.
That's not one of the UI patterns we have on the phone, but we do have it on Windows. So I'm actually just gonna copy that out temporarily and we'll come back and fix that a bit later on. So there's my problematic button. So we'll copy that out, comment it out and we'll do the same for the fill up page
cause that has the same problem on it. There we go. And who knows, we might, oops, comment it out. Let's try that again.
Try and edit our car. Good, the page shows. Maybe we could fix the layout a little bit so we can go on here and say Jaguar. And we've, our new Jaguar has got 2000 miles on the clock. So there we go. And we can say tick and that's good.
I can go edit it again. And this time I want to add a picture. Oop, we've blown up again. Now, I lost my, where's my exception handler gone? Whoa. So it's blown up again for some reason. Oh, there we go. Now what's happened here?
Exception was unhandled by user code. So here we add, this is the file open picker API which is a Windows runtime API. It was in my common area and worked fine on Windows 8. On the phone, it doesn't work. It says it's not supported. So there's a problem with the file open picker. And again, I'm not going to worry about it yet.
We'll fix that in a moment. But one other problem I just want to show you before we move on is it's going to do a fill up. And maybe, you know, we do a fill up on here. So we do 2,500 miles and we've put in 40 gallons
and the price was four bucks per gallon. And then maybe we want to save it. Now you can save by hitting that or I can maybe at this point, I want us to hit the back button, which is again, this is the way we go back on Windows Phone. And watch what happens now. Okay, we didn't go back to our summary page, which is what you'd expect.
Actually, the app terminated. Now this is because on Windows Phone, that's the normal behavior of the back button. And actually, in every Windows Phone app, you've got to have some code in there to handle the back button. So again, this is one of those little areas where we've got a little bit of a mismatch or difference between the way the same code runs, the app works on Windows compared to Windows Phone. So we're gonna have to fix that as well.
But that was a pretty good start. We copied loads of stuff and it didn't take long to actually get a workable Windows Phone app up. Now, of course, when we talk about a universal app, we're not talking about a universal app at all.
It's a terminology. A universal is still two apps. So we're still creating two compiled outputs. We end up with a Windows Phone 8.1 app and a Windows 8.1 app. And you upload those to the store separately. The key is really this shared folder makes it very easy to share stuff
and very easy to create stuff, code that will run on both. And the question really comes with this. How much can I share? So how successful can we be? I mean, that example there, that demo was a pretty good hope, powerful example of how much you can share. So when we look at our views, looking at the architectural layers of this app again,
so our XAML layer, how much can we share there? Now on that particular app, I'm trying to share a couple of the, I had the car details and the fill up page was shared. I need to tweak some stuff, didn't look very good. And obviously we've got those problems with the code that didn't run well, the file open picker and the back button handling, some stuff to fix.
But we have a good bet, a good go at that. I did actually create a unique view for the landing page because I wanted to have an experience that worked well on both platforms. So that's there. But our view models, our logic there, how much kind of that can we share? Actually, design it right, all of that. This is just non UI stuff, it's all code.
Again, data model, how much of that can we share? Get it right, all of it. So this is where the real advantage comes with this. So in that shared code, we've got stuff we've got in the shared project folder. How can we share stuff? Now you saw me dragging stuff into that shared project.
You can put any file into that, any kind of code file, any kind of images, resource files, data files, anything can go in that. And that actually is, I've got on there as an option, add as link is the bottom there. But you probably wouldn't use add as link because the shared project is just another fancy way
of doing add as link. That's kind of what you're doing. It's sticking everything into a shared project. And one thing I didn't show you back in here, if we go down into go and have a look at how it's stored on disk, you'll see we've got in our, this is our solution.
We've got three, okay, packages, NuGet packages under there. But then I've got my Windows phone head there. I've got my Windows head here. And the shared is just another common folder. So this is stuff in the past before this new stuff came in, this new tooling that's in Visual Studio 2013 update two, before that came in with the shared project folder,
you would structure it like this anyway, but then you'd add as link everything that's in here into each of the separate projects. And that's all that this is doing. It's just giving you nice tooling around it and making it easier to see. That isn't what you're gonna wanna do all the time. Personally, when I'm building apps, I end up with lots of different little class libraries. It's how I like to structure things.
There's a number of reasons for doing different class libraries. First of all, you've got some reusable components that you wanna be able to reuse across multiple projects. That's a good, obviously a great example for having it in a class library. You can just copy the project down and include it in your new solutions and take advantage of it.
And we've got support for that as well. It's an extension of the portable class libraries idea. And that's available to us, which I'm gonna talk about a bit more here. So first of all, the shared project, no binary output, and you can stick anything you like in there. This is exactly like add as link, as I said.
The PCLs for Windows Universal Apps, if you add a class library to a universal project, what you actually get is a portable class library. So you're adding us what you think is just a vanilla class library. What you actually get is a PCL that is scoped to Windows 8.1 and Windows Phone 8.1.
So if you haven't used PCLs before, you've got this, it used to ask you when you created it, who do you wanna target? So if you target Windows 8.1 and Windows Phone 8.1, it kind of filters the references and APIs you're allowed to use in that library to everything that is common to those platforms, which in these cases means that 95% of the Windows runtime,
so masses of stuff. But as soon as you start bringing in others, Windows Phone 8, Windows Phone 7.5, and they're all available in this selection, this targets thing, it obviously zooms down to the common denominator between all of those. So by the time you've brought in older platforms,
you end up with actually not a very usable set of APIs. So PCLs were kind of interesting before now, but now they're truly interesting because you can actually support all the Windows runtime stuff as well. Until this latest release, you couldn't support Windows runtime stuff in PCLs. And in the properties for your PCL, you can say, okay, how do you wanna build this?
So you could build it out, the output could just be a class library. So then you just reference it from your Windows and your Windows Phone projects and everything's cool. But actually you can choose the outputs to be a Windows runtime component. So now you can actually create in C Sharp or VB, or C++, you can create common code
and it will spit out a WinRT, a WinMD, which you can access from your WinJS, your JavaScript applications as well. So you've got really great options for sharing stuff across the different platforms there. Now in this solution,
so in this solution, we've got, here we go. I've got a lot of services in here.
So this folder, this is in the common folder, all these different services. And the reason why I created these is it was actually for unit testing. So if you've got a view model, a view model just represents the state of a page or whatever.
So it has loads of properties that expose the data that your application works around. And your UI uses data binding to those properties and it updates the UI automatically. And there's iNotify property changed, events firing, and it's a well understood model. But when you want to unit test your VMs, your view models,
the other thing that a VM needs to do, and you have to remember in this model, your views, your XAML pages, they reference the view model through data binding, but your view models, they have no idea, certainly no references to. They do not have any concept of who is consuming them, who is making use of them. They are independent objects.
And this is the power of the pattern comes from this. So your VMs are just all about logic and all about state. And they're representing the state of your app at a particular time, and they change state and properties change and this kind of thing. When you want to test it, but you need to kind of eliminate all the other things that are connected like data handling and navigation and popping up dialogue.
So a view model can do all that sort of stuff through these services. You're abstracting away these awkward bits that get in the way of testing to services that implemented at runtime for you. And then unit testing time, you can mock them out so they don't get into the picture. So that's why I use services. So just to give you an example,
I have an interface called an iNavigationService, which just has a number of methods on it. Navigate can go back a property and go back method. And then I implement it. And then yeah, so in my view models, my view models down here,
let's have a look at the car details page view model. You through dependency injection, my car details page view model takes an instance of an iDataService. And an iNavigationService and an iDialogueService and an iViewModelStateService. These are all the bits of periphery, the kind of plumbing stuff that you repeat over and over. And I don't want to worry about them here.
So my view model uses these services to do other stuff. And I can mock them out at unit testing time. But then we use dependency injection to inject them at runtime to actually do the real navigation service. So here's my navigation service for Windows 8 and Windows Phone 8.1, which is implements iNavigationService
and actually does what, you know, it implements those methods navigate, can go back and go back. So this allows my view models to navigate at runtime and it all just works. It's beautiful. This is obviously, this is plumbing code and it's something that I want to be reusable.
So I have created a new iteration of this thing, which has changed slightly in that we've now got a shared, but I've actually got two PCLs in here.
I'm just gonna add a dummy one just so you can see what happens. I can add a new project and I want to add a class library to my solution. It doesn't actually prompt you at all which targets they are because it kind of sets this up as it pre-selects Windows 8.1 and Windows Phone 8.1.
But yeah, I could choose to select Windows 8 or I could choose not to support, well, that wouldn't make any sense. Silverlight 5, I could choose to support Windows Phone Silverlight 8 or 8.1 as well. So you've got different things you can change the targets, but in order to make this a class library that can be used in this scenario,
you want to leave it how it is. And then you can put reusable stuff into here. So what I have done, I've actually, I'm gonna delete this again because I don't want it. I've got two PCLs here. One of which has got my service interfaces in. It's just got iDialogueService, iNavigationService, iViewModelStateService and a couple of ancillary classes that support it.
And then I've got my implementations are in here in this one. And these two are endlessly reusable across all my solutions. I just drag them in, keep using them. Okay, that's a little bit about PCLs. What about these shared,
what about this stuff that's in the shared project? That's actually the shared code. Because the thing about, obviously, anything you put into a portable class library has to work across both. Unless you have some kind of flag, you know, when you call a method on it, you say, oh, I'm running on phone, do something different. But that sucks, frankly. But this stuff is meant to be shared across both.
So the Windows runtime across Windows and Phone 8.1, how actually converged really is it? Very is the answer to that. So we've got all these common WinRT APIs. There are a few that are WinRT only. Such as the search contract. Support for multiple Windows.
Can only have one window on Windows Phone. Resizable Windows. Again, they're fixed size on Windows Phone, but they're resizable on Windows. And printing support. Wish we had that on the phone, frankly. And then on the phone, we've got a few that are unique to each platform as well. Around Action Center, we haven't got that on big Windows yet. The status bar, which is the bit at the top.
Back key handling APIs, which we kind of already have hinted that there's a problem there. So there's a few little bits and pieces there where we have, this is where the circles don't quite align. In addition to that, there are a few common APIs. And we already saw something break in the file open picker.
There are a few APIs such as that, where we actually have slightly different behavior across Windows and Phone. So the unified ones, all of them, it's masses of stuff. I mean, this is just an example. File settings, store, lifecycle, notifications. Ah, pretty much everything you're gonna wanna do. But here we go. This is the file open picker.
And this is why it failed when we did that first attempt. So the, on Windows, you knew up your file open picker. You can set a view mode. You can suggest a start location. You can set up a file type filter. So it will only find files of a certain kind of extension. And then you just call await,
pick single file async. Simple as be, simple as could be. And then you get your file back, check whether the user actually picked something. And away you go. You carry on processing. Now Windows Phone, pick single file async isn't supported. Why is that? Well, instead we've got this pick single file
and continue. And this is all about being able to support low memory devices, these 512 meg devices. The problem is that your app is running, okay? And you get to this bit where you wanna allow the user to pick a photo. And when they do that,
and when you invoke, let's say for example, you could call pick single file async. At that point, the shell, the UI, the OS pops up the picker UI to allow the user to go and pick their file. But at that point, your app is gonna be suspended. Your app is suspended while the shell takes over and handles that interaction with the user.
Which is fine. But with the low memory devices, there is a risk your app, particularly if it's a memory hungry one, could get tombstone, could get terminated. So we have to actually handle this in the application life cycle. You have to enable, accept that this might happen.
On big Windows, you call pick single file async, the picker UI just comes up as a transient UI and your app never goes away. On Windows Phone, your app gets suspended. So there's a difference in behavior. So this is why we actually have some slightly different coding for handling that. And we'll look at the code in just a moment for that.
So now we've accepted there's a few places where there are gonna be some differences. How do we actually handle that? Well, we already saw in that app.xaml.cs, hash if statements, conditioner, compiler conditionals. We can always use inheritance and partial classes. So first of all, those compiler conditionals, we already have in the project templates,
it will define for you in the project properties that if it's for the Windows head, it has Windows underscore app defined. And for the Windows Phone head, it has Windows Phone app defined. So you can take advantage of that. For example, to include just for the phone head, some code to handle the hardware back button,
which is shown there, which is what we need to add to our solution, which is Windows Phone only. So that API doesn't exist on Windows. So then we can use these hash if compiler conditionals to include or exclude stuff as appropriate. And it doesn't end up being very much of this. So don't get too frightened about it, but it just allows you to handle these
to these little differences. One other couple of techniques allow you to think about how you can might handle these differences. You could, you could put in the shared project, a class definition, which would actually be the base class and then override it, inherit from it in the head.
So we should allow you to override specific methods to change the behavior or even implement some new ones. So you could in your subclass, in the child of the base class, you can implement some platform specific behavior. You could even make the base class abstract or have abstract methods on it, which would force the head to override them, which is good practice
because then you don't accidentally forget to override something that you meant to. So that's one nice technique. You can use that. You could also use partial classes, which is another nice technique. I used that in my demo this morning. So the good thing about partial classes is that you have, you have the definition of a class
is actually split over multiple physical code files. But the compiler doesn't know that, it just compiles it all together. So it finds, oh, here's a bit of class A and there's another bit of class A over here. Oh, and here's another partial bit of class A. So just compiles it all together. So that again allows you to have the common bits,
the partial class in the shared folder. And you could have in the Windows head and the Windows phone head, separate independent partial classes that when the compiler builds it all, is gonna merge with that common bit. So that's another technique for separating platform specific features. And there's a little example of it.
You can imagine that the top bit data source.cs would be in your shared folder. But then in the Windows phone head, you might have another file, which could be called anything. In this case, it's called data source.wp.cs, which is another part of the same class. They both, key thing here, it says public partial class data source. And the bottom one says public partial class data source as well.
So you just merge, it just merges them together at compile time. So we got a couple of things there. So the next iteration of my solution, you won't be surprised to find, implements that.
So here's by the latest iteration of this, we still got our Windows head, nothing's changed there. Actually, something has changed there, but I'm not gonna talk about it yet. Windows Phone 8.1 there, and down in my shared code. Now, if we go into car details page,
here we go, we've got a little bit of this stuff going on. There's two things, if you remember, that weren't working there. First of all, there was the back button. I'll talk about that in a moment. The back button. So here in my Windows Phone app, in on navigator two, I'm hooking the back hardware buttons
dot back pressed event, and I'm unhooking it and on navigated from, and all this is only when it's included in the Windows Phone head. Of course, if we look at the alternative, it's all hash if is out of there. Those compiler conditionals, by the way. Go to properties.
Here's the conditional compilation. Here's Windows Phone app is included in the Windows Phone one, and up here, you've got Windows app. So this is where, and you can define your own, of course. And back to this, so here we are in the Phone one, we're going to have, we're gonna hook the back pressed,
and this logic in here actually does something with my view model that means that the back key gets handled properly. You don't have to worry too much about the actual nitty-gritty detail of this particular sample, but there you go. The other thing is the file open picker thing. Here we go, this is the line that bombed when we first built this thing.
So that's only now in the Windows app, but the code afterwards, I've actually split out into another method called file open picker continuation. So this is the kind of logic that executes after we've got a file back, and it does, again, some stuff with my view model to say, hey, we got a photo. Can you do something with this? Process it, please.
So variance in there. Now this whole thing, so now with the phone, we call pick single file and continue, your app gets suspended, the UI does its, the shell does its stuff with the user, they pick the picture they want, and then your phone app will get reactivated. And reactivation is handled in app.xaml.cs,
which if you remember is in the shared folder. So again, we're gonna have to have some phone specific stuff in here. In addition to the stuff that was already in from the standard template, but here you are, this is hash if Windows phone app, on activated. If the kind of activation is a file open picker continuation, then do all your standard startup logic.
This is all boilerplate stuff to reactivate an app from suspension. But where it gets interesting is here. So we're navigating to, on reactivating, we're obviously navigating back to car details page,
which is where we came from, before where we were suspended from. And then what we're gonna do is put onto, we're first of all getting a reference to that car details page, which is the content of our frame, having navigated there. And then we're setting into a property on that page, file picker event, those file open picker continuation event arcs
that we were sent as part of this reactivation. So going back to file open picker, the car details page, sorry, that property, here it is, is there. So this is on reactivation. The setter is going to execute here. And this is where we, first of all,
have a look in those arcs to get the name of the storage file that the user has picked. And then we call our file open picker continuation, which if you remember is the common method I've created. And this is where the windows and the windows phone logic reconverges again.
And we process that file and away we go. So there we go. So a little example of all of that platform specific stuff. Right, what about the XAML? First of all, obviously, just drill home again,
you don't necessarily, in fact, you will very rarely want to have identical pages across the two. But so you think about the user scenario, right? So what can you share? You can share whole pages, and I'm doing it in this sample, I'm sharing my car details page and my fill up page.
Or you could share user controls, so you could just have a little bit of UI functionality, you could share that. That's a nice thing to do as well. Now, but if say you're sharing a page, you probably don't want identical layout on Windows as you do for Windows Phone,
you probably almost certainly don't want to do that. So one technique you can use is Visual State Manager. Anybody use Visual State Manager? Yeah, a few of you. So it's a really useful thing in Blend, it allows you to store different states, which are all dialed in different circumstances. And the classical one is where in a Windows 8 app
where you're showing two apps side by side, and you want to show a narrow view when it's side by side with another one, or a different layout when it's full page. That's a great one to use Visual State Manager for, for doing the design for those two different views of your page. And you can use the same technique here
for your phone apps, for your phone pages compared to the Windows 8 rendering of it. And then in your runtime code, you just activate the appropriate state. So if we're running on the Windows, then we go to the Windows Visual State. If we're running on the Windows Phone, you go to the Windows Phone Visual State. And here's getting a bit more subtle here.
Maybe you want a different data template. You've got a list, right? Or a grid view where you're showing some stuff. And you've got a common page, but you actually want the layout, the data template to be a little bit different on Windows, and maybe show more data, more information, because you've got more space,
but show a slightly smaller, different layout on Windows Phone. So here's a technique, a neat one you can use here. You can actually have, you could create a resource dictionary in each head, call it whatever you like. It's called custom dictionary.xaml in this example. And you could put your platform specific data templates or styles in there, but then in your common app.xaml,
you simply merge in at runtime, that's a platform specific resource dictionary. So they get pulled into the appropriate place. And here's a couple of examples, like, you know, here we've got, on our main page.xaml, we've got a style that's being used to style a text block,
which has got a style called mon text block. And in my Windows custom dictionary.xaml, you style the mon text block to use a color of deep pink. And then for some reason, on the phone version of that, you want that to be red. And that will just work. And that's nice and cute. And equally, we got a item template. This is a data template I was just talking about,
where you can have platform specific data templates in each head. So nice techniques for just tweaking the xaml layout a little bit. And I've used that in this version here. So I've got in, you remember our back button problem?
Well, it's back in the xaml, the back button. That's visual state stuff. Here's my back button, which I had to comment out earlier on, because it was using this navigation back button normal style that didn't exist on the phone.
Hey, well guess what? It does exist on the phone now because I've stuck it into my custom dictionary. There we are, which just says, don't show it. So it's still in the xaml base collapsed, yeah? So therefore my back button is nicely gone away when we're running under the phone, but is visible when we're running under Windows. In fact, in Windows,
I've got nothing in my resource dictionary, but I've got to have one because my plumbing, if you like, here, is merging, merging, expecting to find one and merging it in. In addition, I'm going to go off to my car details page,
which kind of looks all right for Windows 8, but I want to tweak that for Windows Phone. So what I actually did is I went into blend, opening blend, and in my car details page, you can work with a visual state manager.
And so here you go. So let's first of all set my, let's go to the device tab and set to, there we go. This is my Windows layout, which is appropriate for big Windows, but I actually went off to states and I've created a Windows visual state, which is actually is the same.
You see that red line that came around? State recording is on. Now this one actually is the same as the default state. I didn't change anything, but this one, and I'm just going to tweak the layout so it kind of looks a bit like a phone. This one, I've moved stuff around. Different, slightly different values are being applied for margins and this sort of thing.
And so the layout ends up being much better. It's moved over to the left, if you see. So we moved over to the left, but on the Windows one, it's all a bit more central. So I've got different layouts for the different usage scenarios. And it's really easy to define that you can just move stuff around in blend and you'll get the nice layout that you want
for the different particular visual state. And if I finish this, I should do a page rotation ones as well like this. And then, so I've got my page has got in it. I sort of flicked over it. And actual fact, when you work in blend to create visual states, it ends up putting all sorts of stuff in here.
So it's setting, what is this? A width to 200 when we're in the phone state. So I'm modifying layouts. I'm changed a thickness on a content panel. You can see why you wouldn't wanna try and hand code this stuff. You're using blend to try and just to adjust stuff. And there's my visual states.
My Windows visual state hasn't got any changes in it. My phone visual state's got loads of changes. And then at runtime, I simply switch between the two here. So that's a nice way of tweaking your UI as well.
Right, fine, I'm just gonna close. I've got a demo for this cause it's only being a one hour slot. But this actually is just as important as all the other stuff I've talked about. Sharing state. So there's no point in creating a beautiful phone app and a beautiful tablet app
and then frustrating your user because they're entering their fuel fill-ups on the phone. And then they open the tablet version and the fill-ups aren't there. Gotta share state as well. Cause you're creating a linked experience for your users. So anything that's common date, you've got to think about this common data.
Unfortunately, we make that very easy to handle. So it's all about OneDrive and you get a lot of stuff for free here. When you're storing stuff in files using Windows.storage APIs, there are three folders, areas, storage areas. There's the local folder, which is just on that device. And you can store files. And in actual fact, until recently,
this is the only one we used on Windows Phone. There's the temp folder, which the OS might clear out at any time. And you can think of that as being just, well, you know, stick some stuff in that you don't mind getting deleted later on. And then there's the roaming folder. So what are all these things about? So the roaming folder is,
if you store stuff into the roaming folder and there's a roaming settings, which is just a standard dictionary, you can store settings in there, or you can store files into the roaming folder. Small files though, only a hundred K. So we haven't got a lot to play with here, but up to a hundred K of data. Anything you store in there will just get, it just gets synced across the cloud automatically for you
and ends up on all of your, the devices, other clients that are actually on, it uses push notifications to do all this stuff. And those settings will automatically get transferred onto those other devices. Just complete transparently, it just happens. So you can do this, store your fill-ups and I have got a sample
that does this and I'll show anybody afterwards if they wanna have a chat. I haven't got time now. And where you can enter it in one and a few minutes later, it automatically turns up on the other, which isn't really nice. The other thing, the local folder automatically gets backed up to OneDrive, but that's not really of interest to us as an app developer. That's kind of just a user can recover
when their device gets destroyed or something. On the way to do that, this is the roaming settings, it's just a dictionary. Sorry, before I leave that. The way to link these, your app, Windows app and your phone app is simply use the same reserved name in the store. Then you're linking them together. They have the same, what we call a PFN, which is a package family name.
So they end up linked to each other. They are then the phone and tablet version of the same app and this roaming stuff happens. So yeah, store stuff in the settings. It's just a string value dictionary, store stuff in it, anything can get serialized, simple. And there is a setting on Windows 8.1 called high priority, which is for really important stuff and that really will sync that
across the cloud really quickly. Unfortunately, that's not observed on Windows phone. So you can still have a key called high priority, but it doesn't actually change the way it syncs. But my demo, if you just have the, you kind of suspend the app and put the lock screen up on the phone and you've got a decent connection like Wi-Fi,
it bang, it happens. It goes up to cloud and turns up on your tablet. So it's pretty quick and pretty reliable. And then if your app is running on the other side, there's also an event associated with this, a data changed event. So an app will hook this and if some settings get upgraded, get synced to it while the app is running, this event will fire and it can then refresh its UI
or whatever it needs to do. Just be aware though, don't think of this as a sync engine. It's not for large amounts of data. It's only 100K, does take place in the background. So you wanna use this for most recently used files, most recent searches or something like this.
So if you want a more robust solution, you need to be looking at things like Azure mobile services or something a bit more under your control. But it is great for keeping that linked experience across the different devices. And it's only 100K. So if you wanna store larger files like the picture, for example, you can use the OneDrive, the live SDK
and that allows you to do file again using the user's OneDrive as a cloud storage or other solutions. So that's it. I hope that took you through. I took you through an example of taking a Windows 8 app,
moving it across to be a universal app and looking at those different things about the shared folder of PCLs, techniques for sharing code in the sharing folder, the hashif conditionals and partial classes, techniques for doing XAML sharing, the visual state manager and platform specific resource dictionaries.
And then finally, we talked about the state sharing. Thanks very much. Enjoy the rest of NDC. It's certainly been a blast for me to be here. It's been a lot of fun. So hope to see some of you maybe in NDC London or if not around at different shows. So thanks a lot.