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

From Windows Forms (and WPF/SL) to WinRT

00:00

Formale Metadaten

Titel
From Windows Forms (and WPF/SL) to WinRT
Serientitel
Anzahl der Teile
150
Autor
Lizenz
CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
So you have a big investment in Windows Forms or WPF, but it is clear that the future of the Windows smart client is the Windows Runtime (WinRT). What strategies can you use to salvage at least some of your existing code over the next few years? It does help if you are already using XAML in WPF or Silverlight , but there are still differences moving to WinRT. In this session you’ll learn about those differences and get the information you need to start getting your code ready for the future.
SLAM-VerfahrenTwitter <Softwareplattform>E-MailWindows FormsSystemplattformTrigonometrieDienst <Informatik>Kernel <Informatik>Rechter WinkelKartesische KoordinatenBildschirmfensterDifferenteSoftwareentwicklerSystemplattformBildschirmmaskeARM <Computerarchitektur>Tablet PCNeuroinformatikIntelNetzbetriebssystemNotebook-ComputerZusammenhängender GraphTouchscreenDiagrammGreen-FunktionSelbst organisierendes SystemMultiplikationsoperatorVersionsverwaltungDruckverlaufProgrammierungProgrammierparadigmaWasserdampftafelStrategisches SpielFamilie <Mathematik>TermPunktMicrosoft dot netAutomatische HandlungsplanungGüte der AnpassungBitComputerarchitekturHauptreihe <Mathematik>CodeAuswahlaxiomOrtsoperatorSoftwarewartungHinterlegungsverfahren <Kryptologie>LaufzeitfehlerServerServiceorientierte ArchitekturNichtlinearer OperatorClientXMLUMLComputeranimation
Gewicht <Ausgleichsrechnung>WidgetTeilmengeMinkowski-MetrikEinfacher RingSichtenkonzeptKontrollstrukturProgrammierparadigmaLaufzeitfehlerSchreiben <Datenverarbeitung>SoftwareBenutzerbeteiligungProgrammierumgebungMathematische LogikBildschirmfensterProgrammierungBildschirmmaskeMultiplikationsoperatorVersionsverwaltungKartesische KoordinatenNetzbetriebssystemGeradeMicrosoft dot netPhysikalisches SystemQuick-SortDatentypServerTelekommunikationMigration <Informatik>C sharpStrömungsrichtungPlastikkarteCodeFokalpunktNichtlinearer OperatorClientEreignishorizontVisualisierungDifferenteSchnittmengeSchaltnetzLuenberger-BeobachterInterface <Schaltung>Objekt <Kategorie>DatenbankTypentheorieStandardabweichungWeb-SeiteRechter WinkelMagnetbandlaufwerkStichprobenumfangMulti-Tier-ArchitekturComputerarchitekturDienst <Informatik>SkriptspracheAppletCOMPerspektiveBitBenutzeroberflächeDiagrammNeuroinformatikIntelTabelleRechenzentrumValiditätProgrammbibliothekComputeranimationFlussdiagramm
Einfacher RingKontrollstrukturSichtenkonzeptMailing-ListeZeiger <Informatik>Physikalisches SystemGamecontrollerMultiplikationsoperatorBildschirmfensterProgrammbibliothekCodeComputervirusGraphiktablettInternetworkingNeuroinformatikVirenscannerApp <Programm>ProgrammierungRechter WinkelMailing-ListeHumanoider RoboterBildschirmmaskeKartesische KoordinatenInformationsspeicherungGoogolProzess <Informatik>Tablet PCLaufzeitfehlerSichtenkonzeptInstantiierungPunktMereologieTouchscreenProdukt <Mathematik>DifferenteDatensatzMicrosoft dot netSpiegelung <Mathematik>VererbungshierarchieArithmetisches MittelMAPNormalvektorSchnittmengeBildgebendes VerfahrenMaschinenschreibenTrojanisches Pferd <Informatik>NetzbetriebssystemClientInstallation <Informatik>Open SourceWeb SiteEreignishorizontARM <Computerarchitektur>WellenpaketFramework <Informatik>MP3Gebäude <Mathematik>AbstraktionsebeneSchnelltasteNichtlinearer OperatorGrenzschichtablösungQuaderTermComputeranimation
Wiederherstellung <Informatik>ClientBenchmarkNormierter RaumKonvexe HülleVakuumRechenwerkElektronischer FingerabdruckBildschirmfensterGammafunktionMagnettrommelspeicherGruppenoperationTypentheorieGamecontrollerApp <Programm>TouchscreenSichtenkonzeptKartesische KoordinatenInhalt <Mathematik>DifferenteTesselationUmwandlungsenthalpieSoftwareCodeFramework <Informatik>BildschirmmaskeWeg <Topologie>GeradeZeitrichtungInformationMereologieZoomMailing-ListeMAPSoftwareentwicklerQuick-SortUmsetzung <Informatik>Rechter WinkelBildschirmfensterFormale SemantikMaschinenschreibenMinimumPinchingLaufzeitfehlerNetzbetriebssystemOrdnung <Mathematik>BildschirmsymbolPhysikalisches SystemKategorie <Mathematik>SchnelltasteHilfesystemQuaderDatensichtgerätProgrammierungObjekt <Kategorie>MultiplikationsoperatorWeb-SeiteMapping <Computergraphik>StichprobenumfangGesetz <Physik>Bildgebendes VerfahrenTexteditorComputeranimation
Twitter <Softwareplattform>E-MailEinfacher RingSichtenkonzeptKontrollstrukturInverser LimesAxonometrieFormale SpracheGewicht <Ausgleichsrechnung>COMDatenmodellSchwellwertverfahrenSystemplattformBildschirmfensterMailing-ListeGraphikkarteServerNetzbetriebssystemRechter WinkelWeb ServicesCodeTablet PCWort <Informatik>SystemaufrufThreadp-BlockSynchronisierungMehrrechnersystemMultiplikationsoperatorGerichteter GraphKartesische KoordinatenGefrierenMereologieArithmetische FolgeSoftwareentwicklerTouchscreenBenutzerbeteiligungBrowserGraphische BenutzeroberflächeViewerInternetworkingOrdnung <Mathematik>SchlussregelQuick-SortSoftwareHalbleiterspeicherMaschinenschreibenATMProjektive EbeneIndexberechnungProgrammierungGraphfärbungKurvenanpassungNummernsystemGraphiktablettSpeicherabzugGamecontrollerBildschirmmaskeARM <Computerarchitektur>Klasse <Mathematik>FlächeninhaltDifferenteBitrateBitGanze FunktionPunktSichtenkonzeptEinfacher RingQuaderZweiCASE <Informatik>FrequenzKategorie <Mathematik>Demoszene <Programmierung>Physikalisches SystemEndliche ModelltheorieDatenbankCOMAbstraktionsebeneLaufzeitfehlerCAN-BusHumanoider RoboterMicrosoft dot netNichtlinearer OperatorParallelrechnerFestplatteWrapper <Programmierung>ComputeranimationFlussdiagramm
ViereckSchlüsselverwaltungVirtuelle MaschineSpitze <Mathematik>Leistung <Physik>Nabel <Mathematik>FreewareSchlüsselverwaltungBildschirmfensterKartesische KoordinatenInformationsspeicherungInformationTwitter <Softwareplattform>LaufzeitfehlerProzess <Informatik>MereologieApp <Programm>ATMMultiplikationsoperatorUnternehmensarchitekturSelbst organisierendes SystemDefaultp-BlockVisualisierungProgrammierungDifferenzenrechnungSoftwaretestNeuroinformatikPhysikalisches SystemDomain <Netzwerk>Projektive EbeneBitDivergente ReiheRechenschieberSoftwareentwicklerInstallation <Informatik>Güte der AnpassungSpieltheorieTabelleRechter WinkelKlasse <Mathematik>BootenVirtuelle MaschineProgrammierparadigmaSchießverfahrenAdditionTablet PCBildschirmmaskeIntelVersionsverwaltungDifferenteARM <Computerarchitektur>FlächentheorieComputeranimation
FreewareLeistung <Physik>Nabel <Mathematik>BildschirmfensterMIDI <Musikelektronik>Objekt <Kategorie>Windows FormsSchnelltasteProgrammierumgebungDatenmodellTemplateKontrollstrukturAuszeichnungsspracheFormale SpracheDeklarative ProgrammierspracheBildschirmmaskeComputerspielRechenschieberVersionsverwaltungKonfiguration <Informatik>App <Programm>SchnelltasteSchnittmengeMereologieReelle ZahlSkriptspracheObjekt <Kategorie>BildschirmfensterMicrosoft dot netKartesische KoordinatenDifferenteTermOrdnung <Mathematik>SchlüsselverwaltungTypentheorieServerWeb ServicesProjektive EbeneFlächeninhaltTabelleDatei-ServerBildschirmmaskeTouchscreenDienst <Informatik>Shape <Informatik>Rechter WinkelProdukt <Mathematik>InformationsspeicherungGüte der AnpassungProzess <Informatik>ThumbnailMultiplikationsoperatorPhysikalisches SystemTUNIS <Programm>Web SiteComputerspielRechenzentrumPunktWechselsprungNabel <Mathematik>Leistung <Physik>Selbst organisierendes SystemStichprobenumfangDatenbankDreiecksfreier Graph
ComputerspielMultiplikationsoperatorBefehlsprozessorKartesische KoordinatenEreignishorizontSystemplattformApp <Programm>HalbleiterspeicherCASE <Informatik>Virtuelle MaschineNeuroinformatikNetzbetriebssystemTouchscreenZweiStrömungsrichtungAggregatzustandPunktRechter WinkelComputeranimation
XMLUML
Transkript: Englisch(automatisch erzeugt)
Is the speaker on? You can hear me? Wonderful. So then I think I shall begin. Welcome everyone. Thank you for coming to this talk. My name is Rocky Lutka, and I am the CTO at a consulting company
in the United States called Majennec. And it's my pleasure to come here and speak to you. I enjoy coming to Norway. I think this is the fourth time that I have been here, and it's such a beautiful country. This time I was fortunate also enough to be able to bring my family,
so they're able to see the beautiful country as well. So thank you for allowing me to be here and to speak. My topic today is how to migrate from Windows Forms and also WPF or VPF and Silverlight to WinRT.
And so a lot of this talk is going to be about strategy and approach and less about code. And the reason for this is that a lot depends on where you're coming from, what is your start point in terms of what kind of coding techniques
and technologies you're using in Windows Forms, whether you do or don't already know XAML with WPF or Silverlight, and whether you're using two-tier client server or service-oriented or end-tier architectures.
And so all of these are important considerations. And so instead of trying to show maybe one particular approach or two different approaches, I'm going to talk a lot about the concerns and I will show a little bit of code just to reinforce how some good planning will help,
but a lot of this comes down to good planning and thinking ahead. I don't know if I can convince, there we go, PowerPoint to move forward. So before we get into too much strategy, and it's hard to see with the lights, but how many of you are already developing with Windows 8 and the Windows runtime?
I think that would be three. And that's good. It's better than none. How many of you are primarily using Windows Forms for all of your application development now?
How many of you are using WPF? Silverlight? Okay. So the one person who says that he uses Silverlight, congratulations, you are in the best possible position to move to the Windows runtime.
Right? Good choice. Now I realize that everyone says that Silverlight is dead, right? You should avoid Silverlight because it's a dead-end technology. And I will actually argue that so is WPF, right?
Or VPF. VPF is dead. Windows Forms is dead. Are you shocked? Anyone shocked? No? Amused? So Silverlight is dead because Microsoft is no longer investing in Silverlight.
Right? I mean, is that not the reason we're all scared to use Silverlight? Because Microsoft is not putting money into the future of Silverlight. So the question I have to ask you is, how much money do you think Microsoft is putting into the future of VPF? Nothing.
They have one or two developers keeping it running. Right? They're doing maintenance on it, just like they are with Silverlight. How many developers do you think Microsoft has working on Windows Forms? A couple. Maybe two or three. And here's the real question for you. When did Microsoft stop investing in Windows Forms?
When was the last time Windows Forms got major new features and was enhanced in any important way? 2005. So Windows Forms has been dead for eight years.
And yet all of you are still using it. So why be afraid of Silverlight? I'm not trying to convince you to go to Silverlight. I'm just trying to impress upon all of you that this idea that Silverlight is dead, or that VPF is dead,
does this really matter? Microsoft has a ten-year commitment. Once they ship a platform, they continue to make it work for ten years. So Windows Forms ships in Windows 8. So you can continue to do Windows Forms for another ten years.
Congratulations. Are you thrilled? If you're doing VPF, the same thing is true. And of course, if you're doing Silverlight, Silverlight ships in Windows 10 also, or Windows 8 also. And so you've got another ten years of Silverlight.
My point is that all three technologies are in the same position. So the question then is why are you interested in going to the Windows Runtime? Or even maybe what is the Windows Runtime? So Windows 8 really represents two different programming models, or two different platforms in one.
It represents the Win32.net platform, and it also represents this new Windows Runtime platform, or WinRT. The Win32 platform only works on Intel-based computers.
So my laptop, which is running an Intel CPU, can run the Win32 side and the WinRT. But if you have an ARM-based tablet, a Windows 8 computer that has an ARM chip, it can only run the new Windows Runtime code.
So this is the big difference. So the diagram that you see on the screen represents the Windows 8 operating system, showing all of the Win32 components in blue, and all of the new Windows Runtime components in green. And they're all, both are present on any Intel-based computer.
So the way that I think about Windows 8, on an Intel computer, is it's just a slightly faster version of Windows 7, plus it has the Windows Runtime. When Windows 8 first came out, someone asked me if I thought that Microsoft would ever allow the Windows Runtime programs
to work on Windows 7. And I said, yes, you just have to upgrade to Windows 8. No? That was a joke. All right, moving on. If you do Windows Forms today,
the good news is that Windows Forms exists in Windows 8. On the desktop side. Also, if you do WPF or Silverlight, those technologies exist also in Windows 8. So there's no immediate need
to worry about changing or upgrading, there's no pressure. Even if your company or organization upgrades to Windows 8, your applications almost certainly will continue to work. But if you are going to start developing
in the new Windows Runtime platform, and you're coming from a .NET world, so you're coming from Windows Forms, VPF, or Silverlight, the most likely place that you will end up is in the .NET version or .NET environment inside of the Windows Runtime.
Now, the Windows Runtime supports three different programming models. You can program in C++ using XAML, or C++ with DirectX, but C++ is one of them. You can program in .NET, so you can use C Sharp or Visual Basic
and XAML, and you can write software that will run in the Windows Runtime. Or you can use HTML and JavaScript and write software that will run in the Windows Runtime. And I'm only going to today really talk about the .NET perspective,
because if you're coming from .NET, I assume that you would like to reuse some of your code and reuse some of your assets. And so as you move into the Windows Runtime, you'll probably want to bring along as much of your C Sharp or VB code, and if you already are using XAML, as much of your XAML as you can.
I think that's a fair assumption. So this graphic shows kind of the migration picture, depending on where you start from. Like I said, all of the current smart client technologies just work inside of Windows 8.
And so as long as your users are using Intel-based computers, then you have no particular reason to do any sort of upgrade, at least not soon. But if you want to go to the green side and you start,
well first of all, notice there is no diagram, no line from Windows Forms into the green side. That's because most Windows Forms applications, and you can tell me if yours is different, but most Windows Forms applications have a lot of code behind click events
and lost focus events and other UI events. Most Windows Forms have a lot of code behind the user interface, and most Windows Forms applications use data sets and data tables. The combination of those two technologies means that little or none
of your existing Windows Forms code, if that's the way you build your applications, none of that code will move forward. That probably is very sad news, but that is the way this works. If you are using VPF,
some of your code might come forward. Certainly your skills will come forward. Your knowledge of XAML, your understanding of the new data types like the observable collection, things that were introduced with VPF, those are all valid in WinRT.
But I draw a red line because most, in my experience, most VPF applications are written in a way that they talk directly to the database. They're two-tier applications. Those won't carry forward. You have to be at least three-tier. A lot of VPF applications
are written just like Windows Forms, where they use a lot of code behind the pages. So there's a lot of event handlers behind the XAML, and so if you've written a lot of code in event handlers behind the XAML, then you have the same problem as in Windows Forms, where it's going to be hard to move that code forward.
Also, unfortunately, VPF allowed you to use the dataset. And so there's some VPF programs in the world, not a lot, but there are some, that use the dataset or data table, and those will have a hard time moving forward.
But the good news is that if you've written your VPF applications that are using three-tier or service-oriented architecture, and you do not use the dataset, then you're probably going to be able to move some of your code forward. If you're starting with Silverlight, like the one gentleman sitting up on the top row
or near the top row, great for you. Silverlight is extremely similar to the Windows Runtime. In fact, I often think about or talk about the Windows Runtime as kind of being Silverlight version 6. The Windows Runtime is a sandboxed environment,
just like Silverlight. It requires a three-tier or service-oriented architecture, just like Silverlight. It requires all server communications be asynchronous, just like Silverlight. And so if you've already gone through the work of learning Silverlight,
it's not that WinRT is the same, but it's extremely similar. You've already worked through or learned the hard lessons. So WinRT, when WinRT came out, there was a lot of rumor and discussion
about how it really didn't support .NET. Yes, you can use C Sharp, but it's not actually .NET. Has anyone heard that? Is that something you've heard? Well, have you ever heard of this thing called duck typing,
where if I give you an object or an interface and it looks like a duck and it quacks like a duck, then it must be a duck, right? So the .NET code in WinRT looks like .NET. It quacks like .NET.
So how can you tell me that it's not .NET? It's true. Microsoft created a new runtime for .NET in Windows Runtime because it's essentially almost like a new operating system. But you still have C Sharp, and C Sharp is the same.
You still have the standard system libraries, so all of the basic data types that are in C Sharp, and those are the same. And you have a lot of the basic, all the things necessary to write business logic in .NET are the same in WinRT. The things that are different are things that don't even exist in Windows Runtime.
For example, if you use Enterprise Services, right, COM+, that does not exist in WinRT, so that API is gone. There's no API in Windows Runtime to create a web server. It's a client operating system.
Why would you ever create a web server running on someone's desktop? So it's true that there's a lot of things from .NET that are not in WinRT, but that's because .NET is a server-side operating system, and it's a client-side operating system, or runtime.
Yes?
Right. So this gentleman is pointing out that there are other things not in Windows Runtime that are in full .NET,
such as Reflection.emit, which is widely used by especially mocking frameworks and some other tools like that. So in fact, the .NET framework, not C Sharp, this is the base class library for .NET framework, has something like 20,000 APIs.
Silverlight has something like 3,000 APIs. Windows Runtime has something like 1,500. Just to give you an idea of what's missing. But I think that you have to understand two things.
One, the Windows Runtime is designed to be a client-side operating system that runs in a secure sandbox that makes it extremely difficult for someone to create malicious or bad code. And this is not an accident.
How many of you have iPads? Several. When you download an app from the store onto your iPad, do you worry about getting a virus? Do you run an antivirus program on your iPad? No. No one worries about this.
Do you run antivirus on your Windows computer? When you go to the Internet and you go to the program, do you worry that it might not be a real program, but it might in fact be a virus? Right? How many of you have Android devices? How many of you run antivirus on your Android devices?
Really? Oh, you are so naive. Right? Most people that I know run antivirus on their Android tablets because the Google Play Store is pretty safe, but there are other places that you can get Android applications that are in fact viruses.
And that's because Google has not done as good of a job as Apple or now Microsoft in making sure that it's really hard to write bad code. And by bad, I mean malicious, dangerous, right? Viruses or Trojan horses. And so yes, the missing reflection emit is bad. Maybe they will add some parts of it
at some point in the future, but right now I think they look at it as being too dangerous, right? And their primary concern is that they want Windows 8 to be as safe as an iPad. And I think for all of us, for instance my kids are sitting at the top row
and I'm going to pick on them since they're here, but one of them had a school assignment where he had to create an audio recording. And so he went and downloaded an open source product called Audacity, which allows you to record audio and edit that audio. And then he had to convert that into an MP3.
And so he went and, on my instructions, he went and downloaded an MP3 encoder. But when you Google for this encoder, the first entry that you get back from Google is not the real encoder, it's a virus. And so of course when he installed this encoder,
he had picked the first one, which looked like a real website, it ran an installer that looked like a real installer, and it was a horrible virus, right? I mean, we can't continue to live like this. Personally, the faster that we all get off from Windows
and onto either an iPad or Windows RT, the happier I will be, at least as a father. Sorry, Marcus. So when you're programming in Windows Forms, you understand all of the controls in Windows Forms.
And perhaps you've purchased third-party controls from Telerik or Infragistics, right? And you learn all of these controls. And then if you move to VPF, you have to go learn a whole new set of controls, right? So they're similar, but they're not the same. And if you go to Silverlight, you have to learn a whole new set of controls
that are similar, but not the same. So when you go to the Windows runtime, you should expect that you will have to learn a whole new set of controls that are similar, but not the same, right? This is, I think, only to be expected.
What is different about the Windows runtime, and what I think is really exciting, is that in Windows Forms, all of the controls are written in .NET. They're not operating system-level controls. They're not Windows controls. They're .NET controls. And in VPF, all of the controls are .NET controls,
and the same is true in Silverlight. So they're not operating system-level controls. They're abstractions on top. And so they have performance issues sometimes, and they are not necessarily consistent with every application on the operating system, right?
Sometimes a list box or a button will look a little bit different or act a little bit different from a real button. In Windows runtime, the list of controls on the screen are available to you, and they are operating system-level controls.
And these are some of the most common controls that are used to build Windows itself, and also are controls that you will almost certainly use when you build your applications. And I don't have time in this talk to go through and show you examples of all of them, but let me show you just some of the controls
and how they're used just in normal applications inside of Windows. For example, suppose that you want to show a list of items and have it work with the keyboard and the mouse and with touch. And suppose that you would like those list of items
maybe to have images and then be able for the user to click on them. This is the start screen in Windows 8. This start screen is created using a grid view control. You have access to the grid view control.
So all of the behaviors that you see here in terms of rapidly scrolling if I can get my mouse to work rapidly scrolling back and forth being able to select items or being able to just click on an item and have it give you a click event
are all available to you. And because it is the operating system level control that Microsoft is using and you have access to the same control, your application will look and feel the same as every other Windows application to an end user.
So this is good. It reduces training for the user but it also means that your application will be consistent with the rest of Windows and it means that your application will tend to be faster than if this was a control created by the .NET team instead of by Windows itself.
If I run the finance app we can see some other controls. So first of all the finance app is a side scrolling application with different types of content this is also a grid view control.
So this is the same control used to create the start screen but it's styled differently so that it shows different sized tiles and different groups. If I look at a specific news item
now I'm in some sort of a text viewing control but if you look closely off to the side over here you can see that there's where's my mouse? There it is. You can see that there's kind of an arrow that appears and I can pan or scroll through content.
This control is called a flip view control and it flips through views. No surprise. But again this is a control that you have access to and in order to use it you just have a collection of content or a collection of objects and you bind it to the flip view
and it does all of the work of animating the transitions so that you don't have to worry about that. It just does the right thing. Up here is a back button. This back button is not part of the operating system. It is part of the actual application.
So it's just a button and it's using a special glyph or graphic to get the arrow but the code behind this button is one line of code and that's because built into the navigation framework. So every time that your application
wants to show a new page or a new form you use the navigation framework and say navigate to this new form. And the great thing is that the navigation framework keeps track of where you were so that behind this button there's one line of code that says navigation.goBack
and it goes back to where I was. So again inside of your code you don't have to worry about those details because the operating system is helping you do that or the run time.
If we look at the weather app this is similar where it's using a top level grid view control but here there's too much content to fit. This is the detail hourly forecast for where we live in Minnesota and as you can see
the current weather is raining and cloudy but now this scrolling up and down could be a list box control but it's not. It's actually something called a list view control and the list view control is an operating system list control that understands how to scroll.
Usually it's vertical but you can restyle it because this is XAML after all. The last thing that I will point out or maybe not the last but moving on,
on this screen they use something called semantic zoom and so here I'm looking at this list of programs and this can get quite long if you install a lot of software and just let it throw the tiles onto your screen. So maybe you want to get kind of a big picture view
and so this is using a control called semantic zoom. A semantic zoom control is a single control that just has two different views, a zoomed in view and a zoomed out view. And all you have to do is define the XAML for the zoomed in view
and the XAML for the zoomed out view and the control does the rest of the work as the user interacts with it. All of these controls, so I'm using a mouse but all of these controls work with touch as well so it's a pinch or zoom type motion and you might say, well,
but Rocky, that's a visual zoom. This just made it bigger, right? So let me show you another example. Here I am in the weather application and there's a lot of different kinds of information in this weather application. If I use semantic zoom, now it completely changes the display
to just say, okay, you zoomed out. Here are the big categories of information available in this application. And so now if I say that I would like to see maps, it'll just bring me to the map part of the display. So it's not a visual zoom.
It's not like you're zooming in closer to an image. It's changing between two different views and it's really up to you as a developer or a designer to think about if the user zooms out, what would you like to show them to make it easy for them to navigate between parts of your application? Let's see, what else?
The one last thing that I think I need to show you is that when I'm in an application, and with a touch I either swipe down onto the screen from the top or swipe up from the bottom
or use the right mouse button, I get what's called an app bar. And this is really the replacement for the toolbar that you would find in Windows Forms or VPF. The app bar has two parts. It's a top app bar and a bottom app bar.
You can use either or both. So this application uses both. If you follow Microsoft's design recommendations or guidelines, they recommend that the top app bar be used for big navigation. So if you're creating a text editor,
each open document would probably be a tab across the top of the app bar. Or if you're running Skype and having multiple conversations, each conversation will be across the top of the app bar. The bottom app bar should be used for more what you would think of as a tool tip
or a toolbar approach. So this one only has one icon for help because there's only so much that you can do in this application. But the idea is that over here on this side of the app bar, you will have icons that give the user the ability to interact with the current view on the screen.
And over on the right-hand side, you'll have buttons that allow the user to interact with the application as a whole. So not necessarily the current view.
Excuse me. Uh-oh.
So there are a couple other controls here that I'm not going to take the time to show, but I'll talk about briefly, and that is that there's a web viewer, which is basically Internet Explorer 10 that you can embed into your application. You have access to the operating system's
native progress bar and progress ring. Those, even though it seems so simple, to me are a great thing because what application doesn't use some sort of progress indicator, and every application seems to invent their own, like in VPF, and so they never look the same.
Here, they can all look the same. They'll follow the color schemes set by the user for their operating system, and so it'll give the user a more consistent behavior. The Windows runtime, at its core, is actually built on top of something called COM3.
A lot of you may, some of you might not have ever heard of COM, or some of you remember COM as being that thing from the 1990s that we escaped by going to .NET. Well, it's back.
The good news is that Microsoft is using something called a projection, so they take the runtime operating system and wrap it with extremely thin .NET classes, so when we're interacting with the operating system, we think we're just talking completely in the .NET world.
And this is different, again, and at this point, somebody might say, well, then that's no good, because .NET is a wrapper over the top of Windows. I should just go program C++. I don't know if anybody actually says that. I mean, really, who wants to program in C++?
But... Sorry, Marcus. There too, my son learned C++, and now I'm telling him he wasted his time. But, moving on, the thing is that these lightweight projections are really extremely thin. And so, like the list box control in VPF
is actually a control written in VPF that behind the scenes makes calls into the underlying Windows graphics engine. Right? The list view control in WinRT is in fact the Windows operating system's list view. All they did is create a .NET-friendly class
that has properties and methods that directly map into the properties and methods of the control. So there's a very large difference between something that abstracts the operating system like VPF and something that just wraps it with a super thin layer like we have in WinRT.
WinRT has a new application model, and I'll talk about this in a little bit, but it's important, I think, and this is one of the biggest things that I understand moving from Windows forms or VPF where the application is either running
or it's not running. And you go into the Windows runtime where applications might be running, they might be suspended, or they might be not running. So there's actually a whole new mode for your application, which is that it could be in memory but not running.
So it's suspended. I'll talk in more detail. And the other big area that will cause a lot of challenge for most developers is the amount of asynchronous programming that is required. I mentioned earlier that in Silverlight,
Microsoft said that all server-side calls had to be asynchronous. Anyone want to guess why that is the case? Well, Silverlight was designed to run in the browser, and almost all of the browsers run on one thread.
So if your Silverlight application, which is using that one thread for the whole browser, makes a call to the server, it calls a web service, and it blocks, it's a synchronous call, then that thread becomes blocked. And what happens to the browser? It becomes blocked.
So the user can't even switch to a different tab in Chrome because Chrome itself is going to be completely blocked. And Microsoft could not allow that to happen because if they did, then Silverlight would get a very bad reputation very fast. And so they said, in order to make sure that all of us
as developers don't accidentally start locking up everyone's browser, they made a rule that the only APIs for talking to the network were asynchronous. And so that was hard. The gentleman that does Silverlight, that might have been a, for most of us it was a substantial
learning curve to figure out how to do asynchronous programming. In Windows 8, Microsoft is really trying to compete with the iPad and with the Android tablets. And for those of you who have iPads, when you're moving around and interacting with your iPad, does it ever lock up?
No, not really. I mean, if it does, if you're going through a list of items, it's very, very rare for a tablet to just kind of freeze even for a part of a second. Because users see that, right? As they're swiping with their finger, if the graphics underneath the screen
and their finger stop being in sync, the user sees that right away. And so with Windows 8, Microsoft wanted to make sure they had an operating system that worked well with tablets and with touch Well, they can do as much
as they want to in the operating system, but if your code or my code freezes up the application, then the entire operating system looks bad, right? I mean, we might know the difference. I might be able to say, oh, that's not Windows. That's my bad programming.
But to the end user, it's all Windows, right? They don't see the difference between the operating system and your application. And so Microsoft made a rule that said as they created the API for the Windows runtime, anything that can take longer than 50 milliseconds, that's 5-0 milliseconds,
which is a very short period of time, anything that could take longer than 50 milliseconds will be an asynchronous API. So think about what that means, right? Talking to the hard drive easily takes longer than 50 milliseconds. Talking to the network, talking to the camera,
talking to the microphone, talking to the user. If you bring up a dialog that requires the user to click or tap or interact, users never can respond within 50 milliseconds, so even bringing up a dialog box has to be asynchronous. And so this requires
a pretty substantial way of rethinking because most of us, especially in Windows Forms and VPF, are used to just making method calls and everything is synchronous. And yes, when I talk to the database, the application freezes, but the user can live with it. That's always been kind of
our mentality as developers. And now Microsoft is on the side of the users and is saying, you know what? Enough of that. The users hate it when applications freeze. We'll make it really hard to create essentially bad applications or bad user experiences.
So far, everything that I've said to me seems positive and I'll revisit some of those in a little bit more detail, but in the middle of this talk, I need to give you what I think is the bad news. Before I do that, I have to ask you, how many of you are planning to use Windows 8 or the Windows Runtime
to create consumer applications, things like games or small apps that maybe do Twitter or things not for business, but just for end users? So one, two, three. So Microsoft is with you three.
When they thought about how to deploy WinRT applications, the first thing they did is they figured out a really pretty good store solution. So if you're trying to do applications for anybody in the world or at least anybody in Norway or Europe or whatever you want,
you're going to submit them to the Microsoft store. Microsoft will run that application through a series of tests to try and make sure that you don't have any malicious code or that your application doesn't just fail completely. Microsoft doesn't care if your application is actually any good.
They don't care if it's useful. They just care if it's damaged or damaging. And so if you look already on the Microsoft store, just like on the Apple store, there are already hundreds if not thousands of horrible apps. And you can spend your money buying all of these horrible apps,
but at least you know that they will not harm your computer. They just waste your money. Not to say that you three are going to create horrible apps. Don't do that, please. But the rest of you are for people inside of your organization. Is that true?
For your customers, for your employees, something like that. And so you're probably not going to try and deploy through the Microsoft public store because if I've written an application that manages my internal inventory or allows me to enter account information for my customers,
I really don't want anybody on the planet to be able to run my application. And so then I probably want a private store. Microsoft currently has a very limited story around the private store. This is the disappointing news.
And then as the slide goes on to point out, you can also deploy for development and testing. That's a pretty good story. And you can deploy on the Win32 side, just like you always have, or any of today's technologies.
But here's what happens if you want to do a private store. It's a two-step process. Step one is that you have to unlock your computers for sideloading. What this means is that by default when you get a Windows 8 computer or tablet, it's not possible
to put your own applications onto that machine. There's a licensing block that prevents you from installing your own computer. Now, if you are a developer with Visual Studio, the first time you try to open up a Windows Store project in Visual Studio, you will get a dialog
from Visual Studio, prompting you to get a developer key. And those are free, and they last for one to three months. In my workshop yesterday, I said three,
and I thought, I don't know, but these keys are free, and they will give them to you to unlock your computer so that you can do your own debugging. So then suppose that I build an application, and I want all of you to install it, and you don't have Visual Studio. Well, the first thing that we have to do
is unlock your computers. And this table shows how to do that. So if you have a Surface RT or some other ARM-based Windows 8 machine, it will cost you $30 to unlock your device.
If you have a Windows Pro machine, which most of us as developers probably have Windows Pro, it will cost you an extra $30 U.S. to unlock it. If you have Windows 8 Enterprise and you are not joined to a domain, then it will cost you $30.
And if you have Windows 8 Enterprise and you are joined to a domain, then it's free because it's part of your domain license. The one that I skipped is Windows 8, not Pro or not Enterprise. What I always think of as Windows 8 Home, it's the kind of Windows 8
that most people buy when they go to an electronics store to buy a home computer. It's locked. So most people's home computers will never be able to sideload or run your business apps. Everybody happy with this? Do you like this story? Yes?
Legacy applications like Windows Forms? Sorry? Oh, VPF.
But see, VPF applications run on Win32, and so they're not affected. This is only to unlock for the new Windows runtime for Microsoft. So don't throw things at me.
Or what is it? Don't shoot the messenger. But it gets worse, I'm afraid, because I say $30 per device, but you can only buy these keys in a pack of 100. So the minimum cost is $3,000. So if you have a small company
with maybe 10 employees, you still have to spend $3,000 to unlock all 10 of your devices. Now, I don't like this story. I think this is really bad. And I've done a lot of blogging about this, and I've talked to many people at Microsoft, and I've tried to convince them that they're wrong.
And so all I can do is tell everyone the way that it is, and then all we can do is try and tell Microsoft that we don't like it. Right? Because it's not good. The thing is that once you have unlocked your computer, you can install as many applications as you want to.
This is a one-time fee per device. Yes. You can still, if the computer is an Intel-based computer, you can continue to install
Win32 apps like VPF, Windows Forms, even Silverlight on Windows 8 at no additional cost. Right? But if you want to use the new WinRT programming model, then you have to pay extra.
Right? If you create a WinRT application, like today you just start up and create a new WinRT application,
it will not run in desktop mode. It will only run in WinRT. And maybe I wasn't real clear, but the blue and the green slide with the Win32 and the whole Windows runtime, they really are like two different operating systems. If you write a program in Win32,
that program cannot see or interact with a program running in Windows runtime. And if you create a Windows runtime program, it cannot see or interact with any programs running in Win32. They're completely separate.
You're jumping to the end of my talk. All right. So one more thing on this slide, and that is I said it was a two-step process. Step one is to unlock your devices. Right? That's what costs the $30 per device.
Once you've unlocked my device, it's unlocked forever, but that key is non-transferable. So if it's my device, my personal device, and I leave your organization and go to another organization, my device remains unlocked. So these keys are used one time, and they're not transferable.
But then you still have to actually deploy the application. And there's really two ways to deploy WinRT applications. One of them is using Microsoft's product called Intune, which is a product you buy from Microsoft that gives you
a corporate store or a private store. And Intune costs either six, eight, or $11 per device per month. That's the price for this tool. And there are three different versions of Intune, so it depends on,
the price can be different. So I saw you guys laughing. This is also maybe not a great story. So if you don't want to pay for that extra cost, the second option for deploying applications is that you can run PowerShell scripts to do the deployment. And one of the people at Microsoft
I was talking to suggested that the best way to maybe do this is to put the application on a USB thumb drive and have a low-paid employee, like an intern, maybe go to every device to do the installation. You might remember this
as being something called SneakerNet in the mid-1990s. Is that a term in Europe where someone would run around with their sneakers to do all of the installing? Yeah? Great. So apparently some of the people in Microsoft still think that it's 1994.
You can, of course, put that PowerShell script on a shared file server inside of your company, so that's maybe a little better. Microsoft just announced that in Windows 8.1, which is the next version before the end of this year,
they're going to open up some of their APIs so that third parties, so other companies, can create some products to compete with Intune. And so maybe that will make this a better story. So Windows Forms,
when you go to develop, you use Visual Basic, you use C Sharp, you use the Windows Forms Designer, and then probably your data comes from some .NET objects. If you do VPF, it's pretty much the same except that instead of Windows Forms
and its proprietary form designer, you can use XAML. Silverlight is basically the same except that Silverlight does not support the data set. So there's no data set and no data table. How many of you use data sets or data tables?
So those of you who raised your hand, you're going to have to move off from the data set and data table onto the use of objects and collections. And that's because Silverlight and WinRT are the same in that there is no data set and there is no data table.
And so everything is based on the use of objects. So your primary areas of concern as you move forward is that today, if you do not use XAML, you should start learning XAML.
The closest type of XAML is Silverlight, but VPF is pretty close too. Basically, if you use VPF as though it were Silverlight, you'll learn the right kind of XAML. The history of this, and I'm not going to have enough time to go into it in depth,
but VPF came first, and Microsoft tried a lot of really interesting things and discovered that some of the more advanced features in VPF were too hard for most people to figure out. And so when they created Silverlight, they took away the parts that most people struggled with and they added in some other parts
that were simpler. And when they created WinRT, they really copied Silverlight to the version of XAML. And so if you use some of the most advanced XAML in VPF, then you're going to have trouble going forward. But if you're using something very similar to Silverlight XAML,
it'll probably be very similar and some of it can even be copy and pasted into a WinRT project. Data access. In Windows Forms and in VPF, most applications talk directly to the database. They're a two-tier application.
In Silverlight and in WinRT, there is no data access API. There is no system.data. You have to call a web service or a WCF, I guess, VCF service in order to get your data from an application server.
Now if you already use an application server, you're in perfect shape. Your service will probably continue to work as long as it's not returning data sets. Because there is no data set. Data binding in WinRT is XAML binding.
And so if you use data binding or XAML binding in VPF or Silverlight, it's the same in WinRT. If you do Windows Forms, you might or might not use data binding. Some of us, like myself, really worked hard to learn and make Windows Forms data binding productive.
Other people, like my good friend Billy Hollis, said, this is too much work, and he never used Windows Forms data binding. But when you go to XAML, you really have to use data binding. There's no real option here. I already talked about the asynchronous behaviors. I talked about the sandbox.
I talked about navigation. I do want to talk briefly, if my slide will advance. There we go. Okay, I talked about that.
I want to talk about the application lifecycle. This is also very important, because in Windows Forms or VPF, the user starts your application, your application runs, and then the user closes your application and it's gone.
And as long as the application's running, it can do anything, right? It's always working. Even if it's not visible, if the user minimizes the application or hides it behind another window, it's still running, right? But in WinRT, only the application that's visible to the user
is actually running. And so when I'm looking at the stock app, this app is currently running because it's visible on the screen. And if I switch to the weather app, now the weather app is running because it's current on the screen.
And what happened to the stock or finance app? It is suspended, which means that it's still in memory, but it's not getting any CPU time. None. It also means that right now if the computer starts to run out of memory,
it might just get rid of the stock app. And you won't be notified. It just clears it out of memory to recover the memory. It's also the case that the user could go over to the sidebar, find the stock app, and they can right-click and say close.
And it just went away, and that finance app was not notified that it was going away. So what this means is that as you develop WinRT applications, you have to think that your application is in only one of two states. You get an on-launched event
when the application starts, and that allows you to start up and do work. And then at some point, your application will become suspended. And the way you have to think about this is that you may never come back from being suspended. So when you get the on-suspended event,
you have to save any data that actually matters. Because from being suspended, you can be terminated, and you won't know that you were terminated. You can be terminated because the operating system ran out of memory or because the user closed your application or because the user shut down the machine.
And so Microsoft has events built into the platform to make this possible or easy, well, you know, manageable, but it's definitely a new concept. So I have exactly four seconds left, but I want to close this talk
by suggesting this. WinRT is version one, right? And as such, I think it's going to take some time to get started.