>> Ben Lower: Welcome. My name is Ben Lower and if you are just coming in, there is pizza
out back here, so please help yourselves. I work in the Windows Phone team. I am the host of
ZAP fest. I am a cosponsor with Microsoft Research for the Hawaii intern ZAP fest as we are
calling it this summer. Is everybody in the room here an intern? Yes? Everyone is an intern?
Cool. I hope your summer is going well so far. I was an intern a few years back so I know how
fun it is. Hopefully you are having fun. I put the schedule appear just as a reminder so if you
haven't started building an app and you want to enter the contest, it's not too late, but I do
want to impress upon you the time to start is now. The apps need to be published in the
marketplace on August 6th. That is the deadline, the first deadline there in the red box and
then after apps are submitted we are going to take a couple of few days and we are going to
judge all of the entries and we are then going to get it down to the eight finalists apps who will
all present on August 14th. Do we have any questions just before we start with our
presentations just about the contest for loaner phones or anything? Yeah, Dan?
>> Dan: For semifinalists and finalists, what are your plans for people who are not going to be
here?
>> Ben Lower: The question was--when's your last day?
>> Dan: August 4, or August 3.
>> Ben Lower: Yeah, so Dan's question is I am not going to be here. I am leaving August 4.
What do I do? Our arrangements for that, if you make the finals, let me start there; you will
have a video that will be produced by Microsoft Research AV video team. They do a great job.
Even in the final event we will show I think it's a 60-second video and that’s sort of the
presentation to the audience and the judges and then you would come out for like Q&A. We
did that partially to make it fair for anybody who wouldn't be here, so the plan that we have is
when you registered you put in your end date, hopefully, and what we're going to do is we are
going to proactively work with anybody who's leaving early and will have the videos done
ahead of time. I think the first exit date for interns is July 27 and then it happens kind of every
week after that, so we will work with you to make sure that you have your video done before
you leave and then if you do make the finals week will just set up a link or a Skype call and you
can participate remotely in the judge’s Q&A that way; we had a guy do that last year. I've got
time for another question if anybody has… Yeah?
>>: How can you obtain a loaner phone?
>> Ben Lower: The question is how can you obtain a loaner phone? Have you been to our
SharePoint site for the contest?
>>: No.
>> Ben Lower: If you go there, there is actually an FAQ at the bottom and it says hey, how do I
get a loaner phone. Essentially what you need to do is you need to fill out the registration
survey, just your name, your end date, tell us your App Hub ID like when you sign up an App
Hub and then we have an admin who is working with us name Tam who sits in this building and
then he will make arrangements with you. You just have to e-mail him and make arrangements
to pick your phone up.
>>: I have a teammate [inaudible] saying [inaudible] loaner phone but I really need one, so do I
go back and change that?
>> Ben Lower: You could fill out another survey. I think, I mean there is probably a bug in our
survey process. I think we kind of suspected that there would be one phone per team, but if
you guys are doing something that needs two phones if you just fill out another survey. That
might be the easiest thing to do, but just e-mail Tam and we will take care of that. Anyone
else? We've got Shawn Henry from the DevPlat team and he's going to talk to us about getting
started with Windows phone development using Silverlight, so I will turn it over to Shawn.
>> Shawn Henry: Which one are you on here? Is this guy on? Can you guys hear me all right?
It's been said, my name is Shawn Henry. I am the program manager on the Windows Phone
developer platform team so that's the team that builds all of the nice frameworks, the
Silverlight XNA and we work with the DevDiv to build the tools that we use to build Windows
Phone applications. Just to kind of get started, how many of you guys have like started your
projects already and have thought of stuff? Couple of you. How many of you guys have used
Visual Studio before? Okay, most of you have used video studio. How many guys have built
phone apps before, Windows Phone apps? Okay. I'll sort of start off fairly slow but then I'll
start sort of cruising through stuff later. We'll do Silverlight overview, navigation, the
application life cycle, talk a little bit about data binding and then some of the features that you
may want to use in your app, background tasks, pushing tiles, camera and sensors. To start off,
how many of you guys are using Windows phone right now? You can be honest. Some of you
are using iPhone; that's okay. I've been on the team since the very end of 7 and one of the
things we sort of did when we were first starting with Windows Phone is we sort of looked at
the other phones that are on the market and we got IOS and android and these guys not doing
too well these days, Blackberry and Palm, and basically we said well these are all just a big grid
of icons and it's actually not all that inspiring. We wanted to do something that is different. So
we came up with this Metro UI. We were actually the first Metro UI when our friends at
Windows sort of copied us. We are happy for them but we were there first. So we designed
this whole Metro UI around having let you have a different experience sort of letting your
content comes through. So one of the things that you will see with Windows Phone, so Metro
is kind of our designed language, so it's all of the ideas and concepts that we use for the UI in
Windows Phone. Our marketing team would call it clean and light open content, not chrome,
so that means, chrome is like little things that tell you where there's a button, like an outline
stuff, lines under hyperlinks. We don't do any of that. A motion through motion, great
typography, we actually invested a lot in fonts at Microsoft. There is a font called Sukhoi
[phonetic] him which is used everywhere now we actually paid a bunch of money to have that
font developed. It's ours; is uniquely ours, of course, I guess we are honest and one of the
things, a couple of things to me more about Metro and I'm kind of getting to a point here is that
we call them Metro authentically digital and that sounds a little bit like a buzzword but what it
means is that, well it means all of these things. It means it's really just about the content
shining through and it's easy to sort of contrast that with what you see on some other
platforms. Does anyone know what skeuomorph means? Have you guys heard of
skeuomorphic, anything like that?
>>: Frills.
>> Shawn Henry: What's that, frills?
>>: [inaudible].
>> Shawn Henry: Yeah, like when you have an eReader application and you turn the page and
the page curls over and it turns like that, or you have like leather bound stitching at the top of
the calendar wrap. You don't see any of that kind of stuff on Windows phone. The content, it's
just about the content which is good and it’s bad. It's good I think because it's very clean and
simple to use, but it means that if you don't think about design your applications will look
pretty ugly, so kind to my first point here is think about design when you're building your
applications. Look at some of the applications on marketplace. Look at the sort of first party
kind of built experience on the phone and really sort of base your apps off of that and I think
Korina [phonetic] is doing a session later for--oh, she's already done one?
>>: Last week and it was recorded and it's available…
>> Shawn Henry: So you should definitely go take a look at that if you haven't already because
we have a design studio that talks a lot about that stuff and it can give you some guidelines.
Certainly having a good looking app I'm sure will help you. On with the show a little bit. How
many of you guys have downloaded and installed the tools? Most of you? So if you go to
MSDN.com. I think create MSDN.com works just as well. You can go and find the tools. You
can download them. There are kind of two pieces to the Windows Phone tools. There's a
designer called Blend and Visual Studio, which is the compiler and linker and the integrated
development environment. Blend is really what you want to use for what you might want to
use if you're doing your UI, just UI for UI prototyping. It's designed for if you have teams where
there is a person who was only doing design and not doing coding or only doing design and a
little bit of coding and a little bit of interaction, so they can work exclusively in Blend and they
can build UIs and then move them over to Visual Studio later. You can actually build projects in
Blend. It's actually the same project format as Visual Studio so you can go, you can do that.
Actually where I end up using Blend the most is where I want to figure out, make an animation
look right or get some of the layouts to look right, I often do it in Blend and then copy that over,
copy that piece and bit of code which you can go get from Blend and that over to Visual Studio.
I like using Visual Studio more. Some people like Blend a lot for design, but that choice is yours.
The other option is Visual Studio all the demos you doing today are going to be in Visual Studio.
Visual Studio has a much less rich design and it's got this, if you're scared of code, hopefully
you're not here, but it's got code. It's got XAML and those kinds of things in it. You can choose
either one. I would choose Visual Studio for the most part. Blend is kind of fun to test out UI.
Just rehashing all of this stuff. Now what I'm going to do is give you guys a quick tour of the
tools. If you install Visual Studio you'll get just, if you install it off of MSDN you'll get these
express tools right here. You can also if you're using Pro for your day job you can use that as
well and these will sort of plug into those. What I'm going to show you here, if you have just
the express tools, these are the only project types you will have. If you're using Pro and you
install this on top you'll see a lot more stuff on the left, but under C sharp you'll see Silverlight
for Windows Phone. And if you click on that you get this list as well. There are a whole bunch
of different types here. Windows Phone application is kind of the most basic one it's kind of a
hello world application and there are other different types. I'll show you these little bit later,
but you can jump right in and build panorama applications, so if you look on the phone, things
like the people hub, where you have that nice picture in the background and then you have
your content that sort of slides across the top. You can use that as a template. Start from
there. Pivot is also nice. If you have data and you want to show different views on that data
that you can use the Pivot application. It's just a nice starting point. There's nothing restricting
you from adding a Pivot to a regular phone application or a panorama or mixing those two
other than making it hard to use, but these are just kind of good places to start. I'm going to
start quickly with… Yes?
>>: [inaudible] do they only work in portrait mode or do they also work in landscape mode?
>> Shawn Henry: Panorama only works in portrait mode. Pivot I think will work in landscape.
You want to just try that? I'm trying to remember now, actually, yeah. I could've done a simple
application that I will do a Pivot here since you asked and so what we've got here when we
launched this, when we start this project is we've got on the left we've got our designer, which
is a visual representation of our UI. On the right we have the XAML. How many of you guys are
familiar with XAML? Some of you. So XAML is the declarative UI language we use all over the
place at Microsoft. It's a little bit different with different technologies. This is closest to XAML
for Silverlight and it's a markup language so it looks a little bit like HTML. It's basically a tree of
all of your UI elements so you can see here we have a phone application page at the top and
there's a layout grid and a Pivot control and those things are all laid out in there. On the right
we have our project with all of the files associated with the project and then properties to
control those, and I will show that later. When we actually run what happens is it gets run in
what's called a Windows Phone emulator, which is not actually an emulator. It's a simulator.
It's actually running an x86 version of the OS, so it's fast, which is nice because trying to
emulate these fast phones would be slow. When you launch you get your sample applications,
so this one's got a Pivot which we will switch between the two and then just to see if this
actually works we can rotate here and actually, so that doesn't work, but we didn't actually
check this, yeah. Support orientations, so I will show you how to do this later. There we go, so
Pivot does work in landscape. So quickly, what I did there is I just did a markup. I said it
originally in the template it said the only support orientation was portrait and I changed that to
portrait and landscape. We'll go back to a hello world application so we can kind of continue.
This application is little bit simpler. When you start a new project you will get this dialog that
says you would want to use 7.0 or 7.1. You guys want to use 7.1. 7.0 is if you're trying to build
an application that is compatible with non-upgraded versions of Windows Phone. There are
not very many of those since we upgraded all of our Windows phones to 7.5, so you definitely
want to do that. So 7.5 and 7.1 are basically the same thing. It's just a quick tip. Sometimes
you'll see things in 7.5 and sometimes you will see things in 7.1. 7.5 is our consumer customer
name. 7.1 is the platform version. You see this same sort of things in Windows, how like
Windows 7 is actually a version of 6.1, whatever. Here is a hello world sample application. This
is a little bit simpler than the Pivot, so we can see what's going on. What we have on the XAML
side is we have this page called main page.XAML, a bunch of stuff up here that you don't have
to worry about yet. It's got a grid to use for layout with two rows defined. The first row here
has these two elements, the application title and the page name, and then there's nothing in
the second grid which is the content panel. A StackPanel, someone asked me last time I did
this, a StackPanel is just something that allows you to instead of arbitrarily placing controls, it
keeps them sort of stacked properly which is helpful especially if you are doing orientation
changes, that will keep things in the center. I'll show you that with actual buttons in a second.
First thing you will want to do is you want to add controls, so there are a couple of ways to do
this. The easy way is to go over to the toolbox over here and you can see all of the controls that
are available, images, more grids, rectangles, radio buttons, or regular buttons, and we can just
drag stuff over from here into the UI and it will show up. If we are feeling adventurous, we can
also add them like this and we get nice IntelliSense that helps us out and the interesting thing
because I didn't specify a size of anything, it's taking up the whole page and so this would be a
good place to put in a height and width, but it's still not getting placed where we want it to.
This would be a good situation here where you might want to stick both of these guys in a
StackPanel, because the reason why this guy is getting placed in an arbitrary location is, and we
can actually do the same thing with this guy if we move them, but what happens when we do
that is it adds these nasty little margin guys which basically kind of force the control to be
where you want it to be, and if you do this what ends up happening again is if you rotate the
phone into another orientation or if you change your layout a little bit, those don't really work
so well because the controls get squished and these are absolute margins. Another pro-tip is
don't use those margins. Instead, stick things in a StackPanel and we can just move these guys
in there and we can get rid of the margin. And with this guy to get rid of his horizontal
alignment too, and so now they show up nicely centered, stacked; they look pretty good, and it
also works fine if we rotate to landscape. So that's adding buttons. Now I suppose what you
want to do is have those buttons do something when you click on them, so again, we can use
the UI, so we can go over here to this properties pane and you can see all of the properties that
you can set on the button so we can change things like height here that we've already set,
width and so on, vertical alignment which actually we don't want anymore, so we will just give
you that one. And we can also hook up to events. There are a bunch of events we can list to on
the button. The most interesting one for buttons normally is click, so we can just type in here
whatever you want to call your event and now it has popped us over into the C sharp side and it
has created a little event handler for us. The other way we can do that is again, like always just
start typing, click and then we can say we can use that one or we can look to our own event
handler and it will create one for us. It doesn't have the best choice of names. So, every XAML
page is backed by a C sharp page behind it, so this is called the code behind. It used to be called
the code behind page and this is the code that sort of backs up that page, and so this is where
you can actually put in what you want to do when those buttons are clicked. For instance,
these buttons are hooked up to these event handlers. If we want to perform some action on
the elements that are in the foreground in XAML, we can access anything that has a name
associated with it, so I've added, well the template has a name added to these text blocks so
you can put a name on a StackPanel, on the grid anything can have a name on it, just about
anything. And we can then modify them, so I can say page title, shows up nicely on IntelliSense,
take text property and I can set it to hello everyone. Then we can build this. It's built, plus the
emulator and if we click on this button the text changes to hello everyone. Awesome. Any
questions about that? That's pretty straightforward, right?
>>: [inaudible].
>> Shawn Henry: Where's page shall define? D XAML. Because I added a name, so it's actually
happening if you're really interested, there's actually, you'll see it in your build directory.
There's a main page.XAML.g.cs which is the generated code for the XAML, so this is actually
something, the XAML interpreter will then convert it to C sharp code and all of the elements
will get names and if you've named them something you'll be able to access them from the C
sharp, so define in the XAML is the short answer. Yes?
>>: [inaudible] X: [inaudible] X, XML S or something like that?
>> Shawn Henry: Yeah, I can get into that a little bit later. I can show you an example, but that
sort of comes from up here. So this is kind of the heritage of this being based on XML is that
you have to define the namespaces, so for the most part most stuff is in that default
namespace, the XAML one at the top, so you don't have to put a namespace in front of it, but if
it's a property that is not there--I'm sorry. If it's an element that is not there then you have to
use namespace. Name is one of those. I don't think that there's anything else in the template
that uses those. You can see the phone application page at the top is in the phone namespace,
and what they do is they resolve the different assemblies, different DLLs that have those
controls defined in them, so I'll show you a little bit later with maps how that works, because
maps is in a different control, if we get there. Yeah?
>>: [inaudible] if you use the mouse on the toolbar [inaudible] and stuff like that?
>> Shawn Henry: No, you mean if we use the toolbox? It's mostly okay. If you've ever done
any like design with like HTML or anything like that and used any graphical designer, it's the
same sort of caveat, some potential issues, often things don't flow as well if you resize them, if
you change the orientation because when you use the toolbox it sort of places them where
your mouse pointer was and you can end up having things maybe not aligned quite right
because you've aligned them with the mouse and so I always like having things lined up with
StackPanels and grids and things like that, but there's no reason that you can use the toolbox.
>>: But you could use a StackPanel [inaudible].
>> Shawn Henry: I don't know if the StackPanel is in the toolbox. Is it in there? Yeah, it's in
there. Yeah, you could add that and I think you add these guys like that to it and you can
always check if it shows up there, so yeah, there's no reason not to. It just depends on what
you like. That looks pretty ugly. Any other questions, yeah?
>>: Is it helpful to create UI in [inaudible]?
>> Shawn Henry: Yes. Absolutely, so if I wanted to create--I'll show you that really quickly. It's
kind of a neat--so if we name the StackPanel, so I'm just going to add a name to it. What we
can do in here, you should always wait until after you initialize the component. Actually we'll
do it in here so we can say my StackPanel and it's got children and you can add a, add new
button, actually I should, do button. Just to show you guys how this works and then we can set
some properties on it, content equals, that may be enough. The only sort of downside of doing
it in code is sometimes there is a bunch of stuff that gets generated from this XAML, so there
may be some properties in here that are not in there. Button is kind of a tricky one. Some
things are easier to add and others. Let's see if this works. So it added that button, so you can
add them all programmatically. The only thing to be careful of though is sometimes there are
some of these properties that have to be defined or the control won't load. I mean it would
just depend on the control.
>>: [inaudible] error?
>> Shawn Henry: It will throw you an exception, but sometimes it's an obscure exception that's
not always obvious what's going on. But for the most part that works. Most things work that
way. Actually everything works that way but you just have to make sure you define everything.
Yes?
>>: [inaudible] all these namespace is in every page?
>> Shawn Henry: Yeah. The templates will have them in there for you, so you actually in
practice don't have to worry about them that much. Actually that's the next thing I want to
show you if you want to add another page. The application model in Windows Phone is pagebased, so for Silverlight applications, so you have multiple pages that you navigate between
kind of just like again like a web browser, or a website. We can go in here either from here add
or you can go up to project and we can add a new item and we can add another page, so these
are all of the things that we can add, classic interfaces and so one. We can add pages and
again, these templates just have some things already set on them, like a Pivot will have a Pivot
control in it, for instance, but we're just going to add another simple page here. It will show up
right in our project as the second page. We will just call it page 2 so that we know that we are
here. That's great. We've got a second page. Next question is how do I get to that page. In
order to do that we use what's called the navigation service. The navigation service is the
mechanism that's used to navigate between pages with an application, so if we go into
navigation service we can then navigate to any page we want. Page navigation uses URIs.
Always remember that forward slash is not going to work for you and then we just put in the
name of the page we want to go to and it's always a relative URI. Absolute means that it has a
like HTTP or a protocol handler on the front, and if we do this, simple as this, hopefully. We
click the button and it will now navigate to the second page. Thunderous applause, right? We
can now go back to the first page by hitting the back button, so every Windows Phone has this
hardware back button. We handle the page stack in the background so that you can use that.
The back button will always navigate sort of backwards in the page stack. The next question is
though what if I want to, what else can I do when I navigate. If you are in, say we are in here,
we can add another button. We go back, and we can, a little trick to get to the code, and we
just do that. We actually need to add a handler for this. Hence, click, go back button, actually
we go back button click; that would be more appropriate, and then we can do navigation,
navigation service stack, because there are a bunch of things we can do. We go back and we
can go forwards and we can navigate. So if you run this, we can now go backwards and
forwards and I'm sure you guys are following along and this should be obvious. Go back and
now this button takes us back to the first page, so we do it both programmatically or through
the button here. The interesting thing is that if we had to go back from this page, actually we
can show that quickly. We would actually get an exception because you can't go back from the
first page that you are on. You can't leave your application programmatically. You can leave
your application using the back button, using the hardware back button. For instance, what I
mean by that is if I hit, go back here, I actually get an exception because I can't leave the
application programmatically. Yes?
>>: Several pages [inaudible] like share the same.
>> Shawn Henry: Several pages…
>>: Only one object for this button for different pages.
>> Shawn Henry: Not easily. What are you trying to do? What are you thinking of? If you want
to have the same button or the same style between pages, you can definitely do that and you
can define the button as your user control and you can have that defined in multiple pages, but
it's not sort of the same instance of the button. You can do it if you really want to, if you sort of
pull away the pages and you work with the frames, but then your navigation gets all screwed up
as well. Is there a question back there?
>>: Is it possible to put [inaudible] in the screen?
>> Shawn Henry: Not at the same time. Generally it is only one and you navigate between
them.
>>: And which is the designer of this page?
>> Shawn Henry: Pages are inside a frame. Actually I think I have a little slide on this.
>>: So, I can put [inaudible] in the frame?
>> Shawn Henry: You can. You can pull the page out and you are working directly with the
frame but then you don't get navigation. I recommend you guys all stay within the page model
because then the back button does with users expect. I will quickly show you; often you'll want
to do something when you navigate to a page, like you want to change some content or
something like that. When you're navigating between pages the constructure only gets called
the first time you navigate to the page because once the constructor is called the page is in
resident memory and it won't get called again, but there are some events that do get called
each time. If we do, protected, voice, override, navigate to, so there is an un-navigated to and
an un-navigated from event. Un-navigated to, now I will just add these guys here and here and
I will show you what they do. You're going to see some break points so these will get, these will
fire and I will show you the order in how these work. It's fairly obvious, so when I launch it I
should have, add one here too. I am just going to add one on the constructor of this guy. If I'm
on my first page, so you'll see actually if we were back here that un-navigated to gets called.
The constructor gets called but you can see that it's at a break point. Un-navigated to gets
called. The page gets loaded. If I navigate to the next page the constructor for that page gets
called and then the un-navigated from from the previous page gets called and then the unnavigated to for the second page gets called. If I go back either way the un-navigated from gets
called and we will just do this to show you that it doesn't get called. Then the constructor for
main page doesn't get called because it's already been instantiated but the un-navigated to
does get called. So that's navigation within the app. It's pretty simple I think. Where things get
a little bit more complicated is navigation outside of the app. I will set up some more
breakpoints quickly. One thing I didn't show you guys yet is there is an application class here as
well and it has a bunch of already built-in templates and it's got a bunch of event handlers here
for launching activated or deactivated and closing and I will show you how these guys work.
These guys gets called when your application is either navigated to from a system experience or
navigated away to a system experience, so that can happen if you are in the application either
by the user hitting one of those keys at the bottom will navigate you away from the application
back if you are backing out of the application start will always take you to the start menu and
start will always take you to the search menu. The first one that gets called is launching. This
will get called; it's the first thing that really is actionable by you that you should put code in
when the application gets launched. Then your main page gets initialized and it gets navigated
to and now our application is running. If we hit the back key from here, we can now navigate
from. We are navigating away from the page and then we get application closing because the
application is closing, so that's pretty straightforward. Navigated from, navigated to,
application launching and application closing. But where it gets interesting is if we start this
again and so we see the same activation model here, so we get launching and we get
constructed and we get a navigate to and now we are in the page but if I hit the start button, I
get navigated from but I get deactivated instead of launching. And now I'm at the start screen.
From here going back to the app I can go one of a couple of ways. I can go to the start menu
here and I can click on the app or if it's in the app list or in the start menu and start the app, or I
can hit the back button to back back into the application and two different things will happen
depending on how the user gets back into the application. If I hit back I will get an application
activated event. If I had gone to it from the app list I would've gone through a launching event.
What's the difference between all of those? The way you should think about it is not only do
applications in Windows Phone have a page model but the whole system has a page model and
if users hit the back key they expect to go back into the last thing they did, so if I, let me just
show you quickly here. I will just remove all of these breakpoints so it will go a little faster.
There is no remove all in this express version. All right. We will just cruise through quickly.
What happens if I'm on the second page and I hit the start button? I hit it away and I get
deactivated. Now I hit the back button and I get activated again but now I get activated on the
second page. I am not on the first page. The user expects to go back to the second page, not to
the first page. If they launch it from the start menu they are expecting to launch the app again
from the first page, so that's why we have these different event handlers. The activated and
deactivated are from when you are going out of the application from the start menu and then
the launching and closing are from when your application is actually closing. What you should
do as an application if you get the activated and deactivated event is that you should store all of
your current state either in isolated storage or in the phone application service dictionary and
then when the user backs back into your page you should deserialize all of that state and put
the user right back where they left off. In both cases your application is potentially getting
killed so your process is restarting but you have to put it back to the way that it was before and
that is sort of your obligation as a developer on Windows Phone. That's a little complicated, so
there is a complicated diagram to go with it. That's where things get a little more interesting
after this. Basically what this says is that an application is running. It can obviously navigate
between pages. Those are the blue boxes and then if it's killed it goes to the closing event. If
you back out of it and launch and start the application again. The interesting ones are the
activated and deactivated. That's if you hit the start menu and the application then moves into
this dormant state and what happens in this dormant state and this is actually new in 7.5. In
the original version of Windows Phone we went right into this tombstone state which meant
that your application had been killed. The dormant state means we're actually going to keep
your application in memory but we might kill it at some point if we run out of memory. So the
best thing to do as a developer is to assume that you are always going to end up in this state,
which is that your application is going to get killed, but sometimes you won't and when you
don't your application will actually switch back a lot faster. That was like a performance
optimization that we did. Any questions on that? Actually it's a little bit complicated but it's
important to have an application that works properly with the navigation model on Windows
Phone.
>>: Is there any way to enforce the whole thing by not letting the user go back?
>> Shawn Henry: No.
>>: That has security problems. Let's say you're using online banking. Some applications you
want to go back to you don't want to be doing like buying airline tickets and doing stuff like that
you don't want to go back. How do you fix that?
>> Shawn Henry: You don't want to go back to a particular page?
>>: You don't want to go back if you click. You just want to close it; you just want to force the
closing and shut it down completely.
>> Shawn Henry: Certainly what you can do in the case of like banking you have some secure
token or something like that and you can ditch that token and require them to login again the
next time they navigate back to that, and you will see that with a lot of banking applications.
Your application is still around but it doesn't mean that secure data is still around, right, so take
a banking application. So let's say you are on your account page and you're looking at your
checking account and it shows that you have no money in your checking account or whatever
and you don't, whatever; I'll get to that in the second, but let's say you don't want to show that
again. As soon as you hit the start button when you go to that deactivated event you ditched
that login token and when you come back you just don't show the data again, because you're
reloading the data into the page. Now the interesting thing is the question is whether you want
to do that or not. I think I would argue with you as to whether it's a change of security context
when a user navigates away from that. It's not quite the same; I don't think it's quite the same
as a web browser where you might be on a public computer on a desktop or something like
that. You don't want to have that still in the history. It's not quite like that in the phone
because the phone is a personal phone. You've got a pin sometimes to unlock it and so it
comes down to whether you want to do that or not. I think some banking applications do and
some don't. Question here.
>>: Is there anything like a close app [inaudible] that you can close [inaudible]?
>> Shawn Henry: You can't close your own app.
>>: You can't open [inaudible]?
>> Shawn Henry: There is one in XNA because games can do it. We generally don't recommend
that you close your own application. It messes with that sort of back stack because it ends up,
all of those pages get pulled out of the back stack so the user gets back and they end up
somewhere else.
>>: How far can you go back [inaudible] but can you go back up to like 10 applications before or
it's just like…
>> Shawn Henry: Yeah, there's a limit. Eventually the system enforces it. I'm not sure what
that limit is and it can depend on how much memory is also on how far back it will go over
there is a hard line. I don't know what the numbers.
>>: But at some point the operating system starts closing down [inaudible]?
>> Shawn Henry: Well, there are two pieces. One is whether something is navigable from the
back button, whether I can get to it from the back button, and then whether it still resident in
memory, and what we do in Mango is we let things stay in memory, suspended in memory until
we run out of memory and then we pull the last thing out of memory. You launch Angry Birds
and then you go do your banking and then you go to Internet Explorer. Internet Explorer uses a
whole bunch of memory and we don't have enough left on the system so we shut down Angry
Birds. Pull it out of memory. It suspended; it's not running, but it's still available in memory so
we can get to it quickly, but if you hit back twice even though Angry Birds is not in memory
anymore, we will reactivate it and you'll get this activated message and you'll have to know that
even though your application has been killed, Angry Birds has been killed, you can take the user
back to the level that they were on instead of to the start screen. Question back there?
>>: What if you put like on un-navigated from you say go forward or something?
>> Shawn Henry: Un-navigated from, yeah, so you can do that. You can end up in circular loop
so you don't want to do that, but sometimes you often want to do that if you have a login page
that you want to skip over the next time, or you don't want people to back into so you can back
up two pages; you can do that.
>>: [inaudible] three pages [inaudible] page 1 and you click to page 2 and to page 3. If you
press back you go to page 2 and if you press back again do you go back to page one for you…
>> Shawn Henry: You go back to page 1, yeah. It's a stack so you just keep moving back in the
staff. All right. I will move on. I think the next topic is data binding. I'm not going to get to into
this. You can choose to use data binding or not. It is super convenient. It's nice especially if
you got a team and you've got like someone working on a component, you get different people
working on different components. There is a template in here and there are of course tons of
examples on MSDN. What data binding is is it's a really quick way to instead of having to set
things like use offsetting elements, you know, equal to something in C sharp each time, you can
actually just do this binding. You see down here, we have binding down here on line one and
what that does is behind the scenes the system figures out where the line one variable is and it
binds directly to that, so it's kind of the opposite of what the XAML generation was doing
before. You can even have it so that when that line one variable gets updated elsewhere in
your code, so you do line 1 is equal to foo, it will then do a property change notification and the
UI will get updated. You can see where that's happening here, so what happens in the sample
is on our main page we set this data context. This is a data context for the page and we set it to
this object called the view model and the view model then contains a list of items and the items
have these properties. Line 1 so that will automatically show up. It's also really nice if you want
to add sample data in the designer. You can do the same thing in XAML as well. Where this
comes in handy is if you are doing MVVM. You guys know what MVVM is? Anyone know what
MVVM is? One guy. Couple back there. MVVM is model view view model. Do you know what
model view controller is? Maybe more of you have heard of that. It's a little more common.
MVVM is kind of Microsoft's flavor of that. Basically the idea of it is to kind of separate your
application into different things. Your model which is kind of the piece like if you're talking to a
web service is the part that talks to the web service or talks to your data and it has all of your
business logic in it. Then a view which is your XAML which is your UI and then a view model
which is kind of your glue that takes the data and converts it into something that the view can
use. Binding is really nice because it sort of takes care of the view model piece a little bit better
for you. And where this is really nice is if you have slightly larger teams you can have people
focus on honing different pieces and you have contracts between the two and then also if
you're going to test your applications, it makes it a lot easier to unit test things and of course all
of you guys are unit testing I'm sure, so that's data binding and you don't have to use it, but we
like to push it because it's kind of cool. That's it for sort of the core technologies. The next
thing I want to talk about the Silverlight toolkit. This is the number one Pro tip. As soon as you
download tools, go to Silverlight, go to Silverlight.CodePlex .com and download the Windows
Phone toolkit. Do that right away. The toolkit is a whole bunch more control, so in Visual
Studio there weren't all that many controls on the XAML. In the toolbox you saw them there
are tons more in the toolkit. This is all you get by default. If you download the toolkit and
install it you got a whole bunch more controls. You'll also get, it's open source. It's on
CodePlex, so you can actually look at the code. You can see how these things are made. You
can modify them if you want. Actually a really good recommendation is to look at this. Most of
the code in there is pretty well written. If you want to learn how to do something or
understand how something works a good place to look is in the toolkit code, and I'll quickly go
through some of the things that are in here. [inaudible] deploy failed. This is going to be used
by another process. I already have this bad boy on here. There it is. This is the sample
application that ships with the toolkit. It's got examples of a bunch of the controls, so we got
stuff, auto complete boxes, context menu, so tap and hold and the menu comes down. Well,
this has gotten slow all of a sudden. So you saw that. There it goes. That drops down. My
machine’s gotten a little slow but trust me those are nice and smooth on the device. Date, time
pickers, if you want to have one that looks like ones that we use on the system, you can do that.
Other things that I think are really good to use on here is you obviously have a specific use case
like some of these date, time converters and stuff, gestures so you can pick out sort of swipe
gestures and stuff like that. It's got some built-in stuff for that which I think is really useful.
Long list selector is great if you're doing lists. It's a lot faster than list view and it also has those
nice headers at the top, this A at the top and then you can do jump lists like that, like we have
in the system. The other one that's really good in the toolkit is performance progress bar, we
should use that. Tilt effect. You should sprinkle this all over the place, so make sure your UI
sort of, see how that goes a little bit? It's always a nice touch, gives you feedback in your UI, so
the user knows that something is actionable. One that's really useful is to get nice page
translations is to use the transitions that are built-in, so you might want to, this one is little fast,
but you can get a whole bunch of page transitions in here and they are all sort of the right
speed to match the system. The computer is getting a little slower. Yeah?
>>: [inaudible] slides [inaudible]
>> Shawn Henry: Yes. So toolkit, context menu, yep, daytime switcher, toggle switch,
awesome, great, all of these things are good. Other stuff, so that's kind of Silverlight. Yes?
>>: I wanted to ask since we have this page model can we share topics [inaudible]?
>> Shawn Henry: Yes. What you can do is you can either set them up like a [inaudible]. You
can do that, like a static class, that's fine, a static instance. You can also have them hang off the
app class, so you saw the app in here, so if we open the app, that's yes. If you want to have an
object that's available to everyone you can just stick it off the app here so you can do, I don't
know, a string, go string, and then all of your pages can have access to it here.
>>: [inaudible] pulls from one page from another page? When I click the button something
else should happen on the other page that I navigate to?
>> Shawn Henry: Generally no, I'm not sure what you're trying to do. You can achieve what
you're trying I think, but normally I think you wouldn't want to do that. We can talk about that
later if you want. Upfront here.
>>: [inaudible] can you have like one main page and create the other pages as [inaudible] on
that page… Access to…
>> Shawn Henry: You can do that as well. That's actually another good point. If you want
something common across all of the pages, you can certainly subclass them so you can create
something between off of a phone application page here and have all of your pages inherit
from that instead and put all of that stuff in there, absolutely.
>>: Move stuff between pages you can actually add it to the URL?
>> Shawn Henry: That's right. If you are trying to send data between pages, just like I showed
you the navigate to, the URL, you can also put parameters on the end. So you can say if I want
to send some parameters you can do like question mark you know, foo equals bar and then you
can retrieve that in here by I think the navigation service has it when you get navigated to, or
maybe it's under arguments. I'm not sure. I can find out later if you're interested, but…
>>: [inaudible].
>> Shawn Henry: Right. If the parameter is not there it will throw. We've got a few minutes
left. I want to talk a little bit about background agents, so in Windows Phone 7 on the first
version in most cases your application is only running when it's in the foreground. Once
navigated away from it doesn't get any chance to execute. We do this of course to save battery
on the phone. If you want to do something while your application is not in the foreground, you
have two options. There is a periodic agent a resource intensive, periodic tasks and resource
intensive tasks and what those are is periodic tasks allows you to have some of your code wake
up every 30 minutes and you can do whatever you want for 30 seconds. And resource intensive
agent, not intesive, intensive tasks will if your phone is plugged into the wall, charged and on
Wi-Fi it will launch you go do stuff. Periodic task is good if you want to do a syncing operation
in the background or you want to stay logged into some service, you can do that every 30
minutes. Resource intensive is good if you want to download a whole bunch of stuff when the
phone is charging and plugged in, so if you are syncing from some podcasts and you were
syncing a bunch of podcasts. I'll show you really quickly in code how those work. It's really
simple. We’ll take this guy, I guess, then we go to project and then we can add, sorry will go up
to solution and we could add a new project. Also in this list here, so two I didn't talk about are
the audio streaming and the audio playback agents and those are two specific areas if you're
building something like Pandora or SpodifyI and you want to have your audio continue to work
in the background and integrate with the play pause controls at the top, so I won't talk about
those. The schedule task is where, is what you want if you want to do the resource intensive
agent or the periodic agent. The first thing you do when you add these as you have this guy
reference them so that he knows where he is. Then to add it, so, what will happen when this
agent is fired is this method will get called on invoke. In order to set this guy up, you set him up
on your main page. We will use what is called the scheduled action service, another pro-tip is
spell things properly and if they don't show up we will just do a little resolve here and it will
figure out you're using so actually what want to do is we want to let me just get this here, so if
we want to do like a periodic task the first thing we want to do is you want to find it because it
may already be scheduled. This is just a pattern so we just go to find, find my task and if it's not
there, so what this is doing is it is asking the scheduled action service as periodic task, if it's
already been scheduled. If it hasn't we create a new one, new periodic task named my task.
One tip for these is that you always have to set the description for them. Description. And
then we schedule them, schedule action service.add task. What's going to happen is this task is
now going to get launched every 30 minutes, but you may ask, well, I don't want to wait around
30 minutes to debug this code, so what we also have is a funnel API that lets you do launch for
tests and you give it the name and you do a new time span of however long you want. Let's say
10 seconds and after 10 seconds this guy will launch, and before I run this what I'm going to do
is show you one more API very quickly that is kind of neat and that's called shell toast. If you
want to have these things run and have the user launch your application. The application can't
actually launch your application directly, but you can show a little toast message that they can
click onto and then launch your application. And these guys to resolve. Consider content equal
to [inaudible] title. Content equal [inaudible]. Then you can set also a navigation URI to
[inaudible] URI, whoops. And this will then, ah, come on. Where is URI? Whatever, we won't
worry about that one. It's [inaudible] URI. And then we can do toast.show and let's cross our
fingers and see if this works. So my application is going to launch if all goes well. I don't need
these guys anymore. So the scheduled task has been scheduled. I can then actually navigate
away from it. That's fine. Thank you. And what you'll see, actually I should put a breakpoint.
[inaudible] here. Let's see if it caught that. In a few seconds what will happen is that on invoke
method that we called and from within there you have 30 seconds to do whatever you want
and see there it's loading up. On invoke got called and if we continue to run hopefully, there
we go. We got a little toast. If we click on that it would launch our application. But still. There
goes.
>>: [inaudible] application [inaudible]?
>> Shawn Henry: Should be alive?
>>: [inaudible].
>> Shawn Henry: No. It does not have to be alive in the background. It can be totally gone and
that background agent will keep firing every 30 minutes. In the back.
>>: The little [inaudible] how does it indicate your application so it knows what application is?
>> Shawn Henry: Oh yeah, so you saw the little icon there? That is your application's icon. If
they tap on it, it will launch your application. You can specify, if you don't specify anything like I
did. I didn't specify anything here for the navigation UI because I couldn't find the namespace.
If you don't put anything it will launch your app but you can also put like a page in there so you
can go to like page 1 or page 2 and you can put just like in the navigation service and it will be
linked into that page, yeah.
>>: Is the whole 30 minute time frame hardcoded? I mean can you change that at all?
>> Shawn Henry: No. 30 minutes. If you need less than, if you don't need 30 minutes, like
every six hours or something, then just don't do anything. Just immediately quit. It's always 30
minutes and it can't be any sooner than 30 minutes. Yeah?
>>: Can you have multiple scheduled [inaudible]?
>> Shawn Henry: No, one per app.
>>: Is there a way to speed that up for debugging?
>> Shawn Henry: Yeah. We can set it to go 10 seconds. Right. What I did here was I called this
launch for test API and you give it a time span and then that tells you how soon you want it to
launch.
>>: [inaudible] production [inaudible]?
>> Shawn Henry: That's right. It doesn't work in production. Don't be sneaky
>>: [inaudible].
>> Shawn Henry: Pandora uses a background audio agent so background audio agents are a
little bit different. There is a template for them in there. The way they work is they get
launched right away. You can explicitly launch them and the user controls them with, as soon
as they are launched you get those play forward back controls at the top of the screen and if
the user ever hits pause and then after a certain amount of time the agent goes away as well.
The idea is we don't want on the phone sort of services running for a long time potentially
eating a battery when the user doesn't know about them. Yep?
>>: The resource intensive task, is that only allowed when the phone is plugged in?
>> Shawn Henry: Yes. I will quickly do. I see Oren is here, what would you guys prefer to see,
push or Maps on location? Maps, push, great. Maybe we will try to do both. I'll be quick.
Maps are actually really easy. We have awesome map support. First thing you've got a do
though, it is not in the core set of assemblies so you've got to go find it. It is down here in
Windows Phone controls.maps, so now it is added, and now as we were talking about this
earlier, we have to go XML name spaces so I have to add one XML namespace. We will call it
map. Fortunately IntelliSense is to the rescue and we can go down and we can look at our map
one and it figures everything out for us. What we can do after that is adding a map is as simple
as adding a map. There we go, so we've got a map. We can actually run this and we can…
>>: Are there any defaults for it? I can you default to your current location or…
>> Shawn Henry: Yeah. Let me show you that in a second. Wow. Come on. So this is a real
map and we can move around and it works and it zooms in and it updates all of the stuff
eventually. Yeah, what you want to do is you obviously want it to go somewhere. What I'll do
this quickly here is I'll just show you it's hooked up to the GPS on the phone, so for that we can
use the geo-coordinates, net watcher. And he is also not in the default set of assemblies. If you
ever don't know where something is I think the fastest way is to just wing it. And so you can
see that this guy is in system.device.location. It's not showing up in the search results. It will be
right here in the assembly, so you just go and you add system.devices right here, so that guy
will show up. We will just move him up like this and then what you want to do is you want to
add handlers so this can change. Actually there are other things you would probably want to
hook up to, but for the sample we can just have the one and then we want to start him, so what
will happen is every time the location gets changed, this guy will get updated and what we are
going to do is we're going to give our map guy a name. And we are going to set dot, what do
we want here? Wow, look at all of these things. Center, yeah, there we go, center equal to,
center takes A geo-coordinate E.which fortunately we have right in here, location and we will
also zoom in a little bit.zoom level equals 16. Yes. And then if we run this, hopefully this works.
So this guy, the emulator will simulate GPS location. I'm not sure what is going to pick up for
this laptop, but obviously if we have a phone it will use the GPS on the phone. It's coming.
There we go. That's pretty close, right? That's my office and studio office. So that's pretty
good. The other thing you can do is you can in the emulator there is a little, you click on this
guy there's a location simulator in here and you can move things around and that will show up
in the emulator as well, if you want to simulate a location. That's maps and location. I will try
to do push notifications in under 5 minutes. Then we will get to Oren who is going to tell you
how to make your code fast. Push notifications are actually pretty similar in terms of the
pattern to schedule agents. Do you all know what push notifications are? Does anyone not
know? Okay. So the way push notifications work are if you want to send data to the phone to
update a tile, to send one of those toast notifications but you don't want to do it from an agent
or anything from your web service, you send a push notification. And the way that works is
that you have some web service. You talk to our push notification server. It maintains a
connection with the phone and then it sends that data down to the phone, so you never talk to
the phone directly; we do it on your behalf and we do it in a reasonably efficient way again so
that the battery doesn't get killed. If we want to do push notifications we use a HTTP
notification channel, so we want to set up a channel. This guy and we will resolve this. Same
pattern as we look for it first. We look for it first. Dot find, if it's equal to null, create a new one
and depending on what we want to do with it we actually the first thing we want to do is we
want to hook up to some of these events. I'll tell you what this one is in a second. It's
important and also to this guy. Whoops. Then we want to channel.open, so again this is very
similar to scheduling and we also want to, there are different things you can do from push. You
can send a toast notification. You can send a tile notification. You can send a raw notification.
If you want to do a tile or toast you have to explicitly bind to them, so basically tell the system
that you are expecting these to come in at some point. What I will do here, I'm just going to
output this. Perfect. I'll just get rid of this. That's how you set up a push channel. What this
does under the hood when you set this up is it goes and talks to our push notification server
and it gives you back a URI which your service can then use to talk to the device. Sometimes
this takes a little while to happen and sometimes it doesn't happen at all, but it looks like it
happened here. It gives us his big long URI here. I just have that output, so here it is and what
we can do is we can take that URI and I have a little web service set up here where we can type
in that URI and what this web service does is it talks to our push notification server. There is
code for this on MSDN. It's a little more complicated to do the server-side, but it's actually not
that hard. From here what we can do is we can send notifications. First of all we can send a
raw notification which we can put any kind of data that we want in and that will get sent down
to the device and you can see our device got activated. This is information coming from our
web service and the raw data will be in here somewhere. It's actually going to be a byte stream
so it's probably not going to show up very clearly. Anyway, link the file, so you can assume that
it's in there. Trust me. Raw notifications, which is what this one is, only get received if your
application is in the foreground. You can send whatever data you want through here, like you
got 3 kB of data but it's only when your application is in the foreground. Kind of more
interesting than these is if your application for instance is not in the foreground, it can be
completely terminated; the user hasn't used it, you can send things like you can send toast
notifications, so there's a toast that came down. This came down from our web service. You
can also do things if you have the tile, crap, what number work we? Eight? If you pin this guy
to the start menu you can do things like change the count on the tile. If it's seven you can add
text. I did that one earlier --that was cheating. But you saw that flip over to the back of the tile,
so you can do a bunch of stuff to update the tiles from your web service, so if you got like a
newsreader application, you can tell the reader that there are seven unread messages. You can
put maybe if it's a newsfeed or something you can put the headlines on the back. That's kind of
what you can use this stuff for. I'm not going to have time to go through the next few things
and they don't work that well on the emulator anyways, so we better test them on the device.
Camera, there's tons of camera stuff. You can get access to the frames coming directly off the
camera. If you want to do any image analysis you can actually get the [inaudible] YUV frames
directly or you can get ARGB frames and you can build your own little camera application that
captures those, that stuff, actually, was there any questions about push? Go ahead no.
Camera, so in the slide deck there is a bunch of code. There's also code on MSDN, tons of
camera stuff.
>>: [inaudible]?
>> Shawn Henry: No that's on purpose. You can get images through just like choosers which
the user can select which image they want to give you, but you can't delete them.
>>: [inaudible] save an image not to the media library?
>> Shawn Henry: Yeah. You can save it to your own application’s isolated storage.
>>: Say if I wanted to download [inaudible] game [inaudible] would there be a pull and a push
[inaudible]?
>> Shawn Henry: There would be two pushes. Take like Scrabble, for instance. If we're playing
scrabble against each other, my turn is done so I will send you a push notification telling you
that it's your turn. In fact you don't have to have a web service in the middle. You can actually
have a push come directly from one device to another. You just use that URI and on MSDN
there are docks of like what the message looks like and you can push directly between two
devices. Quickly, sensors, accelerometer on the device again works very similar to the geocoordinate watcher, same pattern. In fact, in Mango there is a nice thing called a motion API
which sort of pulls information from the accelerometer and the gyroscope and brings them all
together to sort of get really good absolute orientation and position of your device, and you can
get if you like using like all of the matrix, quadirion and all those great, if you like math, you can
do all sorts of cool stuff with that. You can actually combine it with things like the camera to do
sort of augmented reality applications as well, and then just quickly to wrap up and I'll get out
here, I think I talk to most of these things. The camera, GPS, accelerometer, Gyro, there are
native socket access if you want to do just network sockets like BSD style sockets, Winsock.net
versions. SQL CE is on the phone. There's access to the phone contacts if you want as well, as
well as calendar, maps I showed, so you can do launchers and choosers I didn't talk about, but if
you want to get things like photos or add things like contacts to the database's launchers or
choosers which our system UI that comes out and the user can put data in there. Controls,
great, talked about that a little bit, tiles are talked about. I didn't talk about multiple tiles.
Applications can have multiple tiles and you can actually have them programmatically pinned so
you could have like a game, again, like your Scrabble instance, you have the Scrabble one on
the tile and all of them are playing three or four different games and you could potentially have
a tile for each of those. You can integrate a little bit into the search hub and music hub and
photos hub. Here are a couple of links, quick starts, a whole bunch of code that you guys can
use to see how these features work. For some design stuff, the noun project is kind of neat.
It's got a lot of icons on it that look kind of Metro. I always find them when I'm looking for
icons. The toolkit available in several places like CodePlex.com there are a bunch of designer
resources. Microsoft design toolbox and if you want to do things like build that push service
really easily, there's the Azure toolkit that you can use as well and that's on CodePlex. Any
questions? Yep?
>>: The push notification right that's for let's say I have like an app and like 10 players are
downloading it.
>> Shawn Henry: Yeah.
>>: And I have a server and I'm setting up it would be 10 different IDs sort of thing?
>> Shawn Henry: Yeah, each instance will have a different URI for it, so if you have 1000 people
with your app that you have to send push notifications to, you have an thousand URI's.
>>: All right.
>>: Is there any way to do audio analysis, say like you have a composition and you want to
[inaudible] otherwise the [inaudible]?
>> Shawn Henry: You cannot actually plug into the phone service, so if you want to record
someone's phone call, you can't actually do that, but within your application there are APIs to
record audio and those are actually, they are under XNA, so I didn't talk at all about XNA. XNA
is the game framework but there are APIs in XNA where you can get raw microphone inputs so
you can get like a PCM buffer from the microphone and you can do your analysis on that. Yes?
>>: The Silverlight toolkit, right?
>> Shawn Henry: Yep.
>>: When you are using it on an app do you need to reference something?
>> Shawn Henry: Yes. Just like they did with maps, you go and find the DLL and you reference
it that way.
>>: Can push notifications be pushed to different pin to start shell tiles?
>> Shawn Henry: They can be sent to different pin to start shell tiles? Yes, so like the
secondary tiles, yes. There is like a tile ID thing. I don't know if you saw it there.
>>:-No shell tile that time.
>> Shawn Henry: Yeah like here there is a tile ID and that is how you would find them and you
would get an ID back. Yep. Cool, thanks.
[applause].
>> Oren Nachman: So we are actually going to get started. This is like a great group to have for
performance. We could do like a whole group therapy session with this amount of people. My
name is Oren Nachman. I am an [inaudible] on the developer platform performance team so
we do all of the performance for the developer platform and by extension the system as well,
because if we find something that is slowing the system that no one else cares about them we
are the ones that go in to work out what's going on and drive for a fix. I talk pretty fast, so slow
me down if I skip things or if something doesn't make sense. Anybody that wasn't in the last
session or anybody that hasn't touched any Silverlight code at all like the XAML code or hasn't
really done much, I might be talking like over here, so just raise your hand or yell out. It's a
small enough group that we can just do it casually. At the end of the day, at eight o'clock--oh
sorry, it is supposed to be eight o'clock. At 8:21 PM at night you guys are sitting here for one
reason only, and that's performance. That's the only thing I'm going to talk about. If that
doesn't interest you, the door’s right there. If it does interest you what we're going to talk
about is not performance of code. I'm not interested in performance of code. I don't really
care. If you right the slowest bubble sort that you can think of, you, that's not what I'm going to
talk about. That's not my point. My point at the end of the day, I don't care how fast your code
executes. I care about one thing and one thing only. I care about you writing an app for the
phone that is performant, not fast. And will talk about the difference in a second. I also run
around a lot so just like ignore it. A couple of things. This is what we're going to run through.
Going to talk about what is performance. What am I actually going to talk about? I'm really like
complexity for example, the different measures that we learn about at University are extremely
useful and I was actually kind of shocked that you really do kind of use them every now and
then in your day-to-day in your job, but that's not what you're going to do when you write a
little Windows Phone app. We're going to talk a little bit about basics a little bit about how the
framework works on the phone, what it does, what it looks like kind of behind the scenes, so
what is happening on your behalf. We're going to talk about some real world app pain points.
We're probably not going to run through the slides. You can check out the slides later on.
We're going to talk about most of those points just through a debugging session and a
debugging [inaudible] session, for example, and then we're going to run through the regular
just QA if we have time. Feel free to stick around afterwards as well ask questions or send me
an e-mail. That was right at the beginning there. So there's my e-mail; don't be afraid to ping
me. So when we talk about performance especially in the beginning, especially if you're just
coming into the project, this is kind of the initial reaction. Sure, performance, yeah, that's right
at the end. That's so feature complete, yeah then I can go in and I can tweak, because there's
no point thinking about how fast things run or how well it runs when it doesn't work. Kind of.
So what is overall performance? Anyone? What about performance? What is it? I've already
said that it isn't code, right? I really don't, I mean there is an aspect as to how fast you write
your code, but again I trust that everybody sitting here today has enough technical like acumen
to be able to write good code. Maybe not the superspeed fast code that requires 10 years of
postdoc research, but good code. So what is it? Come on. I know that you are eating but that's
why I'm picking on you. What is performance in a mobile device? You're the only one with
food, sorry. I saw you with it. So come on, what is performance? Seriously dude like I have my
phone what is performance? How do I judge performance on a phone?
>>: Smooth.
>> Oren Nachman: Smooth. Thank you. Anybody catch the android thing two days ago,
android I/O? What was that new project called?
>>: [inaudible].
>> Oren Nachman: No, no, no. That's all consumer rubbish, sorry, the developer one. The one
that they were all excited about.
>>: Project butter.
>> Oren Nachman: Thank you, project butter. Butter is smooth, buttery smooth, sorry. That
was our official line; we picked it like three years ago for Windows Phone. But anyway, we will
get there. Anything else? Okay so we have like smoothness in general. Anything else? What
does smoothness mean? Come on? Come on, work with me. This is such a small group, come
on.
>>: Response time.
>> Oren Nachman: Response time for what?
>>: Display.
>> Oren Nachman: Well, the display draws even if you don't draw. The display doesn't care
about you. The display runs; it draws. But okay, expand on that. What does that mean,
display?
>>: How quickly things change.
>> Oren Nachman: How quickly things change, okay. All right. Yes?
>>: Response to user input.
>> Oren Nachman: Perfect Great. Response to user input. If I put my finger down I want to see
what? A reaction. As quickly as possible. The user has to know. It's funny. People always say,
what's the hardest thing about typing on a screen. There is no tactile feedback. That is not
completely correct. You start feeling through your fingers just by virtue of seeing, by virtue of
you seeing or even feeling in the case of little vibrations depending on the device, but by virtue
of you seeing that button highlight when you tap on it, it's translated in the subconsciousness
very similar to the same effect as if I felt myself touching on it. It doesn't work for a keyboard
obviously because you have heaps of tactile feedback like this visual feedback and you don't
know what you've tapped on. But if you're going to on a big button and you don't see that
visual feedback right away, you're not performant. It doesn't matter how quickly the action
performs underneath the covers. Anything else? Any other ideas? What's wrong with using
your own phone? You've got like SMSs. Power consumption, that's a great one. So we're not
going to talk about power consumption today because as a developer you could care about it
less, but it's a very important one. You care about it less for one reason and one reason only,
because if your app uses a lot of power and your user is using it, and you are using that power
because you need to because they're playing a game, then the consumer, the guy who's using
it, your user, he knows that he's going to suck up his battery. We had a conversation about this
couple of years ago we were designing, when XNA performance was coming together and the
question was well we are sucking a lot of battery while playing a game, so we could do all of
these tricks to try to kind of optimize them, and we did as many as we could on our side and the
question is well, should the developer care? Should we give them all of these fancy tools to
measure how many watts are they pulling? And at the end of the day we have a bit of tools for
that but it is not a major focus because if you're going to be playing some immersive 3-D game
or on the flipside if you're going to be playing Netflix on your bus ride home, you know that it's
going to suck up your battery. We do a bunch of stuff in the background to make sure that it
sucks up as little as possible, but as a developer on your level you shouldn't have to worry
about it too much, but it's a good point. It is definitely performance on the phone. Anything
else? I guess that's the downside of a small group. Performance is a magician's trick. That's all
it is. It's a sleight-of-hand. It's the speed at which the person does not realize what you're
doing has been done. It's not at the end of the day, it's not about how quickly your cycles run
on the CPU. I have a demo that I do at conferences sometimes where I have two apps. They
are identical, identical startup. One of them starts off with a blank screen until it's ready and
then it shows all of the UI, and the other one is exactly the same startup but it starts up half a
second slower, so half a second slower but it has a progress bar while loading. Can you guess
which one people think starts up quicker? Obviously side-by-side they'll see which one is
quicker, right? That's why I don't do it front of the camera because it's kind of annoying, but
when they just load the app, okay, now load the second app. Which one started faster? Can
you guess why, you people, like which one? The progress bar one, why? Because it feels faster.
There's this whole feature in Visual Studio and light Dev [inaudible] 11, in Visual Studio 2012.
They actually have proven that it's 250 milliseconds slower, but because it's user cancelable and
the UI does not lock up while it's happening like it did in 2010, everyone thinks it's so super and
fast, but when the person looks at it they are like, oh my God, it's like 250 milliseconds slower,
but no one cares. Here are a couple of things that I like the big four that I call out that you guys
have to worry about. We spoke about touch response. How quickly does the screen react from
the user’s finger? How quickly does the user see that something’s happened based on the fact
that he touched the screen? Visual cues in general, so that's the progress bar while we're
loading, so that's not showing them a black screen. Smoothness, if I'm animating, if I'm moving
something around the screen, if I'm pinching or panning or whatever that is; I don't what that
is, zooming? And patience. At the end of the day although it's the fourth one on the list the
code does make a bit of a difference. The user does not want to wait 20 seconds for something
to happen even if you do have a progress bar. So it's a juggling act. You need to juggle all four
of these so that you get a good combination, a good mix of fast code that responds and reacts
beautifully and perfectly and is buttery smooth. So the golden rule at the end of the day is
platform performance, this is what I measure. I measure it in milliseconds. Sometimes when I
do really fun stuff, it's even less than that. But you guys do not have to worry about that. If
something took 10 milliseconds instead of 20 or 20 instead of 10, okay, sure, unless you are
writing something like high-performance, like you’re writing like a really high-performance
game where you really need that extra frame. If it's happening every frame sure, then every 60
frames--we run at 60 frames a second all the way back to Windows Phone 7, so if every frame is
16 milliseconds and you're taking 20 milliseconds, you're going to start skipping frames. Then
you look at it and you say whoa, my game runs beautifully at 50 frames a second or whatever
20 milliseconds is. I think it's close to 50, so that might be fine. It depends on what the user
experience looks like. For you at the end of the day what you need to worry about is the
perception. What does the user feel when he touches your app? We are going to see that a
little bit later when we run through an app that, a little demo app that I've written up. What
we're going to do is we're going to look very quickly at just a couple of just general concepts of
what the framework looks like. We're going to look at a very quick demo. This was written by
Roger Peters. This is actually a game that is actually in the marketplace. There is an XNA
version, and a very early Silverlight version. This highlights some really cool performance issues
which I find really nice to demo on. And if I can find it. Every new system it takes a little longer.
It was upgraded and now it's slower, that's why we talk about performance. This is kind of a
little hard to see. Can you see the green lines running across the screen? If not you're sitting
too far away. Come closer. There are two progress bars. The one on the stop is the standard
stock progress that comes with Windows phone, comes in Mango. The other one is the same
one but with a better template applied to it. Let's see if we see any kind of difference. We
have this concept called the UI thread. If you haven't done a lot of UI, you might not have run
into it, but it's basically a thread that drives everything that the user sees, the user interface.
I'm going to block the user interface thread. Anyone notice anything? Please tell me you
noticed something. All right, good. The one on top blocks. It stopped. It's not moving. The
one on the bottom, buttery smooth. So whenever I show this demo and I explain what's going
on people like, but no one ever blocks the UI thread, at least not for that long. I think that's like
one second or 2 seconds, no one's ever does that. No one is that silly. No one would be that
stupid. But let's take the XML file that is exactly the same size as the one that Facebook
downloads. It's not the Facebook one; don't worry. Like we are not trying to rip them off or
anything, but this is the size of the Facebook app on your phone downloads and pauses at
startup. I am just going to wait for the remaining compositions so that you can all see. All right.
So what's going on here is the UI thread is not completely blocked, but can you see the jitter?
Can you see the smoothness? Is that smooth as butter? That's like the keyword to them, so it
stuck in my mind. In Techit I refuse to say it. That sounds so corny. But now… As you can see
the top one is jittering like crazy and the bottom one is just fine. Does anybody know what's
going on? Okay. You were here last time. You cheat. [laughter]. So Silverlight has this
concept of two threads; they are system threads. They are not your threads. You cannot touch
them. You can interact with them. You can't stop them? You can't start them, nothing like
that. One is called the UI thread and one is called the compositor thread. The UI thread is what
generates the user interface. It's what draws, it's what creates the pixels. When you say I want
a border around a button, a button has a border inside it and that's what gives you the white
line. And it does a few other things. It interacts with the system in some ways. That is the
main thread that all of your code runs on by default as well, so if you have a general callback,
main page loading in there it is going to run on the UI thread. We also have another magical
thread called the compositor thread and the compositor thread is another thread that runs in
parallel to the UI thread and it ticks independently of the UI thread every 16.6 milliseconds or
60 frames a second it gets a ping from, essentially it gets a ping from the video driver and says
bang I am ready, v sync. I am ready to draw another frame and the compositor says that's
awesome because I know that I am animating this progress bar so I'm going to draw it even
though the UI thread is blocked. The one on the top is a bad animation. It's tied into the UI
thread. It has this little thing that checks every single loop every time it updates only
[inaudible] HX border orientation on my end. It's a bug and it will be fixed. But that's a bug. So
this shows you when you are tied to the UI thread that's what happens when you get tied to
the compositor thread. 99.9% of the time if you are doing an animation you want to make sure
that you say on the compositor thread. Why? Because if you do something like parsing a very
large XML file you are going to get the nice smooth animation as opposed to the choppy one.
Question? Nice. Either I'm really not explaining this well or no one understands what's going
on. Or I finally like the sweet spot. All right. Oh, I tapped on something. Come on. Silverlight
has this thing called counters and these counters, sort of helpers really. I call them helpers and
these are visual debugging aids that we give you as part of the platform and we say use these to
help find your initial performance problems, so we are going to run through them. We're going
to see the different types now. The very first one is the one that I already mentioned; it's called
counters. So in general this is a very simple game. You have this poor dude. He doesn't have
any food. Someone, I don't know who, someone, you know, I think in the original game there is
a monkey. Someone is throwing fruit and you have to catch it. There is a really awesome bug;
can you see if you can catch it? [laughter]. I'm pretty sure that's my fault. Someone was
playing with the code, but that's not the important part. [laughter]. What we have are these
things called counters. You may notice that they are along the side. If you've done Silverlight
development on the desktop you'll notice that they are on the top. They can't be on the top
here. Does anyone know why they can't be on the top for a Silverlight app on the phone?
Anyone? What do we have on the top of an app, usually, sometimes, not always?
>>: Notifications?
>> Oren Nachman: Nope. Notifications do pop up, but they got away quickly. What can an app
have to have that they can get rid of?
>>: Menu?
>> Oren Nachman: No. Not a menu.
>>: [inaudible].
>> Oren Nachman: There you go. The notification area at the top that has the time and the
battery et cetera, so that would draw underneath that normally. We have them on the side.
And what you are looking here at different counters that give you the very basic health of your
app. And I can tell something is not healthy already because something is red and we will get to
it. So we highlight red things when something is problematic. So what are the numbers?
Remember I said that there were two threads? That's the compositor thread frame and it is
currently running about 40 frames a second, 40, 41, 38, 39. That red one here, what is that?
The UI thread. The next one here is video memory. Unless you see like all nines it's probably
not an issue. These are the number of surfaces that you've created, so we will talk about
surfaces in a minute, but in general surfaces are everything that you see on the screen. Each
banana is a surface. Each wave is a surface. The little dude in the boat is a service; the trees
are surfaces; they are surfaces. We only have, we have 10 surfaces and you can see that they
are changing. You can see the changes as the fruits come in and out so there is obviously a
surface, something being created there. This one here, this 002, implicit surfaces. These are
surfaces that Silverlight has said oh, I think you need an extra surface here so I am going to
create it on your behalf. If you don't see these numbers going nuts like really, really high, it is
not an issue. Very rare. This one though is the most interesting one apart from the first two. I
guess it's the third interesting one. That is what we call the fill rate counter. Now the fill rate
counter counts the number of pixels that you are pushing to the GPU every single frame. It is a
count of how many screens worth of pixels are you pushing every single frame. So the number
there is three, so that means every single time the GPU is ready, the GPU is ready to get
another screen, I am pushing three screens worth of pixels. You'll notice that there doesn't
seem to be, like sure. I can see that there is like a little overlap, so I can see that sure the
background probably goes all the way to the end. There are some waves. There is this little
dude. There are trees, but that doesn't look like three screens worth. We have a problem. The
GPU on this phone is extremely powerful, relative to its size. But it's not that powerful and it
starts breaking down at around 2.5, 2.75 fill rate. If you are sending 3x800x480 because that's
the resolution of the screen pixels every single frame, the GPU starts slowing down. The GPU
says hey, you are giving me heaps of screens. No worries. I'm going to process them. I'm going
to display them, but I'm not going to give you your v sync every 16.6 seconds. I'm not going to
ping you back and say oh, I am ready, go, because it can't. It can't do it that fast, so it does it. It
doesn't reject any of the pixels, but it is going to slow you down and that's the reason why the
compositor thread is kind of slow here. So let's figure out where things are going and what is
happening here. So the first one to see is let's see if we can find the size of our textures, so the
size of our textures that I am sending to the GPU every time and let's see if we see any issues
there. What we have here is redraw regions. Redraw regions is a really cool flag that basically
every single time you redraw something on the screen it will tint it. As you can see the different
tinting. Now if you redraw something that is already tinted it will change the tinting color. Can
you see that? Anyone see the bug? There are two bugs here.
>>: [inaudible] screen.
>> Oren Nachman: First of all, he's on one massive screen and you can't really see it but in the
top left corner there is a little button that was supposed to be a menu button, and he is being
locked in with the menu button, so that is one bug. There is this massive texture, so if I go to
here, that's one whole screen worth of pixels. Does anyone see any issue with that? One
whole screen worth of pixels? Okay. Pardon?
>>: Lot of pixels.
>> Oren Nachman: That's a lot of pixels. There you go. So here's another problem, anyone
notice that the tinting is changing, or that when I touch on the guy kind of moving him, the
tinting kind of changes?
>>: [inaudible] multiple layers there?
>> Oren Nachman: One layer, same layer, what did I just say? When I change the tinting, what
happens?
>>: It is redrawing.
>> Oren Nachman: Is redrawing. Why would I redraw that? Let's look at a better example.
Check out the fruit. Is the fruit tinting?
>>: No.
>> Oren Nachman: It's tinted because it is drawn, but it is not re-tinting because it is not
redrawing. Let's think back to graphics 101. If I have a texture and I give it to the GPU, I can say
draw that texture and then I can also say move that texture. I wish it was that easy, but that is
essentially what you are doing. Translate it, move it around, so the GPU doesn't really need to
go, we don't really need to go on our side and say oh, I got this fruit. I've now moved it like that
so let me redraw the pixels on my side and then give those pixels to the GPU to render them to
the screen. Or I could just tell the GPU no, just do that. And the GPU will redraw them for me
and off I go. So what's happening here is this surface is not cached and we will see with the
caching in a minute, but at the end of the day if you know that you are going to animate a
surface there is a flag called bitmap cache. Go to the surface and say bitmap cache equals, or
cache mode equals bitmap cache. Magic. Remember that. You won't remember it so come
back to the recording to remember it when you see that things are redrawing. Silverlight is
smart enough to auto cache most things. See how the fruits are not cached, are not redrawing?
It's because they are cached automatically because we say oh, you put in animation on the
fruit. I am going to cache that because you're not going to change that. On this, because the
movement is happening on the UI thread, it's happening in user code, so this code that says
hey, my finger moved; move the guide to match my finger. There's no automation on it so
Silverlight doesn't know what you're going to do with it so it redraws it every single time. So
when we are talking about how many, for how many actual textures do we have. This one is
called cache visualization. This one tints exactly the same thing every texture but it tints them
blue, and the more blue your screen is, the more static textures you have. So you can see how
blue it is over here? I don't know if you guys can tell. You see the differences in the blueness?
Is that actually like highlighting my finger? Oh my, I have dirty fingers. Smudge marks are not
included in the counter. You see how this is way bluer than that? That's because every single
wave for some reason is an image that for some reason goes from the bottom of the screen to
the top. Now the developer doesn't think about that, right? It's an image. It's a pane; it's
transparent. It's fine. I'm going to put it on, but no, every one of these pixels is more pixels
that I'm pushing towards the final GPU picture that you see rendered on the screen. Finally and
we have a downloading [inaudible] we have a little tool which is even more useful specifically
for fill rate and this little tool will go in and it will read through your visual tree. Your visual tree
is the tree that represents all of the UI elements on the screen, and it will grab a screen shot of
each one of them and it will tell you the size and pixels of each one. Let's see it in action.
Performance, come on. If this was a real app there would be a progress bar [inaudible] nice and
smooth. Hey, it didn't work. That's cool. [laughter]. The problem with having small buttons.
There we go. Sorry. Small buttons, big fingers, not good. What I have here is a visual tree. By
the way last time there were all of these like glitches in the demo so I was going to say okay this
time I'm going to try it without glitches, but it's a Microsoft presentation so I know that's not
possible so I shouldn't even say it. [laughter]. So here's the visual tree and it's laid out like a
tree so you can kind of see what's a child of what, so this rectangle is the child of the layout
route which is a child of the backdrop control et cetera. And next to each one is a little number
and the number is the count of pixels. Does everyone know off the top of their head what
384,000 pixels corresponds to? Come on, interns. You guys are in university. You know what's
going on.
>>: [inaudible] 640 x 40?
>> Oren Nachman: Close. 480 x 800. So 384,000 pixels is one whole screen, so there's
something here that is drawing a full-screen. Okay, let's see what it is. Okay. Did everybody
see that? No. Zoom out of it so you can see what's going on. It's that. And that's the
background. Can we do anything about that? No. We need the background. It's the whole
screen. Perfect. Okay. That's not an issue. Let's keep going down the list and see what else we
find. Here's another 384,000 and this one is already kind of weird to me. It's called the palm
trees image. This actually [inaudible] right away. It's two palm trees. That takes up the whole
screen. Does anybody know why that takes up the whole screen, by the way?
>>: All the spacing between them.
>> Oren Nachman: Pardon?
>>: All the spacing between them?
>> Oren Nachman: Sure but the spacing has no color. It's transparent. It's pink. Why does it
pick up pixels?
>>: [inaudible] black background?
>> Oren Nachman: No. There is no black background, because we saw it before. The
background blends through. It's definitely transparent pink, definitely 100% verified confirmed.
I don't know a lot, but that definitely.
>>: Like it's [inaudible] layer?
>> Oren Nachman: No. Because we don't care about that. It doesn't matter.
>>: There are a certain number of pixels between the two palm trees?
>> Oren Nachman: Sure. There are that many, 800 x 480, right?
>>: That's probably the PNG [inaudible] of the image though.
>> Oren Nachman: Sure, but the image is 400 by 800, though, the image is 800 x 480. It is sized
to the screen. It has transparent pixels in the middle and color. All right. Last one.
>>: Is it [inaudible] the first image?
>> Oren Nachman: No. It is one image displayed once. Sure, one more, why not?
>>: It has to process the pixels anyway because even though they are transparent.
>> Oren Nachman: Perfect. Right on the money. The fact that a pixel is transparent doesn't
mean that it is not there. It has a color. You know the color is? Transparent. So we don't go
through and say oh that's transparent. That's not a pixel so we can't draw it or that it doesn't
exist. We create a texture that has all of these transparent pixels. We give it to the GPU and
we say here's green, green, green, green, oh, here's a negative pixel. It's some transparent.
Draw whatever is behind it. Just don't draw it. Okay. GPU says fine. I will draw it. It goes to
the next one. Oh it's transparent. It goes to the next one. It's still a pixel. It still needs to be
processed. And that is something, you don't know how many people make these mistakes and
not just in games. We are talking about apps that have pretty graphics and things like that and
they just don't realize that it's sometimes better to split an image into three images and have
them overlay rather than have one big image with all this transparency in between because it
will kill your fill rate. Now we can run through other things like we saw we were talking about
the water. You see the water itself takes up a lot more than it should. Et cetera. And you can
run through. In this boat drag area, will that's empty but it still takes up a lot of pixels and that
one quite sized et cetera. That's a little tool that you can download just to help if you do see
that flow rate counter go red. It goes red above 2.5. I'm not sure if we change that to three in
the end. Take away one thing from here is the fact that performance is really important. Take
away two things from here, well there are other things. Take away 10 things from here,
number 10 don't use the emulator for performance; that is number three maybe. Very, very
quick demo. So this is the [inaudible] demo that I just showed you. We have our good friends-I wonder if we can enlarge that. We have our good friends the progress bars. Let's see what
happens this time when I block the UI thread on the emulator. Whoops. Yeah. Even if I do the
realistic one, they both kind of suck. The bottom one is still a little better, but not by much. So
that's just a really quick, really just a little [inaudible]. It's just a little demo as to why you
shouldn't use the emulator for performance issues. Use the emulator for your functional stuff.
Get your app up and running always test on device, always. The emulator works both ways.
The UI thread itself runs faster on the emulator, so by itself. It has problems with the
multithreads and stuff like that, but the emulator itself runs faster on the UI thread, so you
might think things are really awesome on the emulator anything ha ha, I've got no problem; I'm
awesome. Then you come to the device or you publish it on the marketplace and the first
review that comes in this app sucks. And you're like, I wonder why that is. And the second
review comes in, this app is really slow and the third one comes in and it's like this app crashes
on startup because you hit the 10 second and you kill it. Did you guys know that? Did he
mention that previously? 10 second start-up; you’re killed. If your startup is too slow you are
dead. System watchdog comes in each you up; you are dead. You don't even have any chance.
There is no recovery. There is nothing you can do. So if your startup takes longer than 10
seconds, you better re-factored it so that your startup starts up and then does whatever actions
it needs in the background threads. Yes?
>>: [inaudible] how do you tell the system you are [inaudible]?
>> Oren Nachman: You don't. You don't have to worry about that. As soon as your UI starts
displaying, you are fine. We do it in the background. So if your UI starts up, so your page starts
up. It pauses basically the thing here is don't do like heavy work unloaded. Don't do heavy
work on navigation complete, all that sort of stuff. All of those events that make sense to not
do a lot of working, don't do. You can kick work off. You can schedule work. You can use like a
dispatch of time like and say okay, once I start it up on the next UI thread tick, UI do whatever
work you want. You could start a background thread. Start a background thread. Go off to the
website. What you don't want to do for example is start hitting like 20 websites. Even though
the responses come back in a background thread, still just kicking those off on the UI thread is
still little bit of work. And especially if things are slow et cetera. I had a guy who had a mutex,
so he was waiting for startup for when he would get his response back because responses
always come back, web quest responses always come back on a background thread. There's
nothing you can do about it. That's the way it works. Same in Windows. The whole point of
the asynchronousity of your code. I had a guy who had a mutex that said okay, I'm going to
block startup until I get a response from the website because I want to know whatever, I need
this data. So it worked fine on his emulator. It worked fine for him on his like home internet
Wi-Fi, and then he didn't get through certification because they test without internet and
[inaudible]. So the idea there is you wait and you show a message to the user saying hey, I
can't do it. Very quickly, now this comes under the basics but it's usually the part that no one
understands. Don't stress about it too much and feel free to ask questions if you're not getting
what I'm talking about. It's more again in the conceptual, so this is actually going to bring out
the conceptual diagrams that match what I was just showing you with the compositor threads
and the UI thread flying around. On the desktop what usually happens in a lot of frameworks if
you have a UI thread and we have user threads, the UI thread is always active. It's always
there. And we have user threads that you bring up, new thread, they are active, they are
active; they die. You bring up another one, they die, et cetera. You do a web request and
another one comes in. On the phone we are very strict about this is we have this extra thread.
By the way this is now the same model as Metro, so if you are ready into writing like a Metro
app, it's exactly the same thing. It's a compositor thread or UI thread. A few other interesting
threads as well, even on our side, but those are the two main ones. And again, the compositor
thread runs for the life of your app. The compositor thread can run as fast as it wants. It's not
tied to the UI thread. UI thread is tied to the compositor thread. If you somehow manage to
bog down the compositor thread you give it a fill rate of 20. You push 20x800x480 pixels into
the GPU every single frame, you're going to slow down the compositor thread in the UI thread
is going to say oh, the GPU server behind me that I'm running faster than it and it's going to
slow itself down to match, so that things don't get out of sync. So let's see how they interact
with each other. Let's say you go in to XAML and you create your nice little shape. It's a circle
and it happens to be yellow. It's that kind of day. And you say hey, I've got this awesome circle,
let's animate it across the screen. Why? Because it's cool. I'm going to animate my circle. So I
start my animation. I have no idea why one is yellow and one is orange. Just imagine that they
are both yellow or both orange whatever mood you are in. The animation starts at the bottom
of the screen and it runs bang bang bang and gets to the end. It's a story board animation. Did
you guys see that in the previous talk? [inaudible] story boards? Okay. So this is more, I guess
he was talking more about platform. So Silverlight has a development model and one of the
things that it has these really nice XAML defined storyboards, and you can say I want to do
these actions. Like the progress bar that you saw before that was extended, it was scaled. All I
did was they render transform it. Every time you render it, render it so that on the Y axes it
scaled times 10. I didn't do on the X because then the animation flies off the screen and it's
really funky. But you can do the same thing here. So you just do a translate transform and you
are going to say okay, I'm going to move my ball around. Okay, the ball moves. Now that
animation is something that the GPU can do by itself, right? There's nothing in that animation
that a GPU can't do on its own, so we pass the compositor thread and we say hey, run by
yourself. I don't care what's going on. Just do it. Perfect. We get to the end of the animation
and nothing happens. Now [inaudible] comes along and he says okay, well the ball was
interesting but now I want a colorful wall. I want it to move from the bottom of the screen to
the top of the screen but I wanted to change colors as it goes. Okay? So we give up the UI
thread and we say all right, we're going to start off with orange because that's the default
anyway. And then I'm going to run another thing on the UI thread it is going to move a little bit
I'm going to change to blue. But now as I'm doing that the user gets another button and this
button is go out to my awesome web service, do something really cool, parse a really big XML
file and come back. Okay. Well, the UI thread is busy, right? It missed that tick. It missed the
movement. So it didn't change the color, but what did happen to the animation? It kept
moving. Why because it's on the compositor. The compositor doesn't care. The compositor
lives in its own little world. It has a ball. It's been told take this ball and move it from here to
here. What you do with it along the way is your problem, UI thread. If you missed a tick, that is
your problem. It is your fault. I'm still going to be buttery smooth. And that's what's
happening. Now the UI thread is finished. It's finished its work. I don't know what's happened
to the colors here. Okay. You can kind of see that it changed colors. Okay it's finished its work
and it's changed the colors. It's gone back to changing colors, because the UI thread picked up
where it left off. You can imagine that's I don't know, red, green any other primary color,
whatever you want. And that's the way they interact. So basically you're compositor thread
animation is good. UI thread animation is bad. We'll talk about what gets you kicked off in a
second. This slide you can look at. This is really interesting for people who really want to know
like what is happening while it's working. This is like take what is happening in the UI thread
and what happens in the compositor thread and you can see, I mean, I'm sure I am
oversimplifying here but just the fact that in the compositor thread there are only two boxes it
just shows you how tight that architecture is. The compositor architecture literally is hey, I'm
going to animate something and then I'm going to draw it and then I'm going to animate and
then I'm going to draw it and I don't care what else is happening in the system. So what gets
kicked off the compositor thread? Anything that modifies the base texture of an object, so the
color for example. We are changing the color, so it didn't animate on the compositor thread.
That makes sense. We are changing it on the UI thread so that bit of the animation happened
on the UI thread and that's why it didn't happen when the UI thread was busy. That's why we
missed the bit. Opacity mask. Opacity mask is that really cool thing that lets you create those
kinds of gradients, gradients like circles and weird shapes. That can't happen because that
doesn't work on the GPU. The GPU is not very good at handling kind of gradient. It's really
good at handling a texture full of pixels or something solid. Nonrectangular clips, so if you have
something that's not square, we have to do a lot more work. The GPU loves triangles and by
extension rectangles. So if you have something that's a triangle, we are not smart enough to
figure it out because it has to be and exist--sorry. We're smart enough to figure it out. We're
not stupid enough to spend time figuring it out if this is an exact triangle that can go to the GPU
because it has to be pretty exact to fit into what's called a triangle strip. And non-storyboard
animations, so if you have a thing using what's called composition target rendering, if you
haven't used it, you don't have to wonder about it. It's a callback that's called every single
frame, so as the flames tick along the screen even though you are not seeing anything, the
screen is drawing. Every single frame it's going to call you back. Every 16 milliseconds if you're
fast enough it will call you back every 16 milliseconds. If not you're going to miss some of them
obviously. So if you animate there, so if you take an animation and you say okay, I'm here,
move my x little bit. Move my x little bit more. Obviously the compositor thread can't animate
that. Does anyone know why? Because we don't have ESP. We don't know what you're going
to do next and I can't run your code on the compositor. With the storyboard animations you
tell me I want you to move the ball from here to here, and you can do that with code behind as
well and then the compositor thread knows exactly what's going to happen next, but you have
some funky code that says hey, if the time index finishes with a two, then move the ball down,
but if it's like a, if it's the seventh prime number then move it backwards, well the compositor
thread has no idea what you're doing, so you run that on the UI thread. Actually one point
about that. The phone even though the screen is on and you can see my screen is still on,
everything is shut down. The UI thread is not ticking. The compositor thread is not ticking.
Nothing is ticking, but if you do do composition target rendering you are telling us we want you
to keep ticking even though you're not drawing anything, and that's a battery feature by the
way. Like as soon as, and we have these things called health violations, as soon as the device is
idle even if it's running an app, everything needs to shut down. And then as soon as like it
reacts to some kind of input, a web request coming back, a user touch, something like that then
we wake up. These are your best friends. These are the different counters that I showed
before. We will grab it afterwards. How much time do I have approximately? I started at 8:29,
8:28.
>>: Yeah, I know.
>> Oren Nachman: Okay. Just checking.
>>: We were running late so.
>> Oren Nachman: So feel free to leave. [laughter]. I'll get a taxi home tonight. All right. So
we're going to do now is we're going to look at a little app. I am a fan of Reddit. So we are
going to look at a little app that I wrote. You can grab the source from CodePlex. Come on.
And it's a Reddit app. It's very simple. It's very basic so it's really great to demo. It's really
great to learn from if you want to dissect the code later on. All it does is load Reddit, pings the
Reddit website. The Reddit website has a really cool feature where a few websites have now
docked it where you can just add.Jason at the end and it will give you the Jason feed instead of
the HTML page. Then I parse out the Jason using Jason.net. You can use any of the standard
libraries and then I get through a listing of the front page and I have like a little list of sub
Reddit's and I have some pictures that come from pics. [inaudible] is filtered. So the app looks
good, right? It looks, nice. It's performant. It's all right. It's not too bad. The list is, I mean it's
decent. It's there. Now let's see what startup really looks like for this app. Hey, I have e-mail.
So the app starts up and I get a splash screen. Now it goes to--I'm not interested in--I want to
see the pictures. No I want to see the pictures, really. Oh, there we go. Did you guys see that?
I'm a real fan of pictures. I look at the pictures. That's all I look at right. So when I start up my
app my app doesn't have an option to have pictures, so I want to see the pictures and I want to
see them right now. But it doesn't work. Now sure, I might be like overdramatizing, but at the
end of the day that's what happens to a lot of users. It usually gets to learn your app. He learns
that when he starts up your app, sorry to pick on you Daniel, when he starts up your app he
wants to get the train schedule for Chicago right now for this little like bus stop. No, it's a train
stop, right because it's a train schedule. He wants to get the train schedule right now. He
knows, he remembers exactly what he needs to press to get the current timetable. So when
your app starts up he doesn't care that you are loading things in the background. What he
cares about is how quickly can I get what I want now. So I remember that in my app I have pics
and I want to get to them now. Or I have my main list. See it one more time. I have my main
list and I want to get to number 10. Why? Because I don't like what's on top. Oh, where is this
going? Oh there it is. None of these leave great impressions. And that's where it comes down
to perception. I have an app on the marketplace. Most of the apps that I wrote were apps that
I wanted. It's something that I wanted. If you find a use for it, great. Go for it. Grab it. If you
want to pay me some money, sure, I will take your money, but most of them have free apps, so
just grab them. One of the apps I wrote was really, it solved a problem for me. It's a
[inaudible]. It's a remote control. I can't design for crap so it looks really bad, but there was
one remote control there that existed already, but it was really slow and it bothered me. Not
because I'm a performance guy so I'm constantly like nitpicking these things, but because it was
really slow. It would start up really slowly. It would crash now and then and they had a really
easy API so I knocked together an app and I published it because someone else might find it
useful. If you look at the comments from my app, now they've upgraded the other one so, you
know, a bit of competition always helps. If you look at the comments, some of the comments
are so much faster than the other one. And that's what you want, right? The very first talk I
gave at PDC, the introduction was you guys have a great idea. You publish it to the marketplace
at the same time someone on the other side of the world also had exactly the same idea and
you publish the same app. Both are functional. But one of them is really smooth and nice and
usable and beautiful and it just responds and the other one, yours, it blanks, it jitters, it doesn't
load fast. Who's going to win at the end of the day? And the funny thing is which app are you
going to want to use? You're not going to want to use your own app. Let's be honest, right?
You are going to use this other awesome app that is really quick. So the design is really
important. Your code is really important. The functionality that you code exposes is extremely
important, but the experience is topped off by performance. How performant your app is. So
let's see if we can improve this a little bit. Let's see if we can do it. I'm not as good as Shawn is;
I have a lot of cheat sheets. I'm sorry. And actually it was actually great because Ben was
keeping me honest last time so I've actually added a bit to the demo, because it was a little too
complex to do on the spot. I didn't have IntelliSense last time so I was kind of like really
cheating. [laughter]. Let's see if we can clean this up just a little bit. Can you guys read that?
Okay so my code is really simple. What I have here is my XAML. Everyone has seen XAML
before, right? XAML is like XML similar to HTML. It's not like XML, sorry it is XML so it's strict
XML. And it defines what's going on so I have like my [inaudible]. I have a couple of styles that
I'm applying. I have some fonts that I am using; these are the standard things. And I have my
layout root. This is where things get kind of interesting. This is like my app starts here basically
and this is just a standard panorama app, right, so this all came from the standard like startup,
like, you know, file, new project, panorama. I have a title. I have my images; I have some
controls. I have my template. Here is the main list, so here is the list box for like the current
views so it has an image and then it has a text box with the actual text from the thing et cetera.
And I can keep going. There is another panorama item. This one has all the sub Reddits so it's
just a StackPanel with some images and then I have another panorama item. So this one is
really interesting and we'll talk about this quite a bit, is the rack panel, so it's just a great
example of a very useful list that is very low performant. So it's the panorama, that's what does
the pictures. So the pictures come in and they wrap so instead of a list box where it all goes
down here when it hits the border side it drops down and starts a new row. That comes with
the toolkit by the way. That's what Shawn showed you right at the end of his slides. At the end
I have this about. That's nothing. That's just for fun. So there isn't really much going on here.
What happens when I start up? This is what I was talking about. In your main page
constructor, this is happening during your startup. Any code down here counts towards your
startup. The more code you do here, the slower your startup is. Do things on the UI thread
what still kills you? It's as easy as that. So what am I doing? Well I am sending the data context
to my view model, so I have a view model. I'm not a big MVVM guy but if you guys are feel free
to do it, so you have these views and models, data context is just for binding, so binding is
basically in XAML where I have like text binding data title, that just means it's a really neat way
instead of me having to write in code, you know, this text box doesn't have a name, but let's
assume it had a name called awesome text block. Instead of me having to code awesome text
block.text equals something, I can just say bind to the title and then if I change the title later on
it's really easy for me to say raise the notification. This is a data title change and update it,
standard Silverlight feature. So I sent my data context so that all data comes out of there. I
have a loaded event handler which I bring up that is down here. I look for some property
change just so that we can, so basically what we have is, I have, I probably changed the event
that says hey, I finished loading this stream. I have finished loading this stream. The important
thing to note is that Reddit, that when you download this app from CodePlex, it's not written
badly. The code itself is not slow. There is nothing slow in the code. But there are patents that
haven't been done. And I'm [inaudible]. That's fine. That's the app. [inaudible] property,
change, so I go through all of the different submissions and I add them into the rack panel, and
that's it. We are done. That's all just comments at the bottom. So that's the whole app.
Obviously there is a whole other library here that you can check. All these little bits and pieces
of Reddit that parse out the Jason. There's nothing interesting in there. I might be able to
optimize and make it 10 milliseconds faster. It's not interesting. It works and it works well. It
doesn't take 5 minutes. What I have established by looking through my code is that startup
cannot be any faster. I might be able to knock off 20 milliseconds. Usually you don't notice
that. Let's go back to my very first slide. What is performance? It's a magician's trick. What
kind of magician's trick can I do to make my startup faster? I already hinted at it right at the
beginning. No, shush. Come on. Someone. Anyone.
>>: [inaudible].
>> Oren Nachman: For the people that are listening in, I am doing like a more symbol with my
hands. Oh, I have one thread. Deposit the data.
>>: [inaudible].
>> Oren Nachman: [inaudible] what?
>>: [inaudible] startup [inaudible]?
>> Oren Nachman: Sure, but fine, that might delay my startup little bit, but at the end of the
day my data is not going to come up any faster. So I've establish that to get my data to display I
can't do it any faster. So can we think of a way to make it faster without actually making it
faster?
>>: [inaudible]?
>> Oren Nachman: That would make it faster. And you would get stale data, yes?
>>: So [inaudible] when the user requests it?
>> Oren Nachman: But he has requested it, because he started it up. It's like going to a
website…
>>: You want to view the pictures. I don't know that those pictures…
>> Oren Nachman: Sure. The pictures to be honest I loaded afterwards anyway. The pictures
are only loaded once it started out and when I started panning, remember when I was panning?
And it wasn't displaying, that was because the app has completely started up so the watchdog
already is not looking at me and then I start loading the images. So the images are already on
loaded delay. Yes?
>>: Display a loading page?
>> Oren Nachman: All right. I like the way you are thinking. Display a loading page. Yes?
>>: Display just the pictures, the pictures as you load them.
>> Oren Nachman: Okay. We will get to that for the pictures, but again the pictures are not
affecting my startup. They are affecting my usability after the start of. They're the reason that I
can't pan when startup starts, but they're not affecting my startup at all.
>>: So you're actually putting in an event handler and you are displaying something else.
>> Oren Nachman: What do you mean?
>>: I didn't finish.
>> Oren Nachman: Sorry.
>>: Like this [inaudible] you're putting the main page loaded, so that would…
>> Oren Nachman: Loaded happens before it renders.
>>: Right.
>> Oren Nachman: Loaded is hey, I am ready to go. Do you need anything last minute before I
like throw up on the screen. So loaded is…
>>: [inaudible] asynchronously, right?
>> Oren Nachman: Synchronously. You y-thread call back.
>>: [inaudible] single.
>> Oren Nachman: Sure. So when I say Vista loaded, I am saying UI thread, when you are
loaded and ready call me back.
>>: Yeah, call me back.
>> Oren Nachman: But it calls me back on the UI thread. One last one. It was someone,
someone. I saw a hand.
>> Oren Nachman: Hey, you don't have food anymore. Sorry. I'm not listening to you
[laughter]. Yes?
>>: Kind of another [inaudible].
>> Oren Nachman: We kind of do that already. Okay I'm going to go back to the loading screen
idea. So what I'm going to do is you saw this splash screen? I'm going to add a progress bar
into that splash screen that says hey, user, I know you really want your Reddit. What's that
Main [inaudible] thing. I know you want your Reddit, but you're going to have to wait 2
seconds while I load it for you in the background, or one second as is the case. I'm going to
show a progress bar. Does that make sense? So all of your ideas are great, but what you'll see
when you get the code is that those ideas already exist. I'm already doing the HTML in the
background thread, the Jason actually. I'm parsing the Jason on the background thread. All of
that stuff is happening but at the end of the day I am constructing my panorama to bring up all
the sum of the extra items to bring in the initial image list, all of that stuff happens during
startup. Now I will give you an extra bit, I don't want that to happen after the user starts up
because I want the user to see my panorama full of data. I don't want my data, I don't want my
game to start up, my app to start up and then show me all of these progress bars. I'll give you
an example, and I am sorry to rag on the developers of this app, but I use it all the time because
it has pretty graphics but at the end of the day it's pretty bad. Check it out. What do I want to
do now when I hit the 18° tile? What do I want to do? What? This one. This one. The one
that has a little bit of rain. This one that tells me that summer started yesterday in Seattle and
finished this afternoon [laughter]. What do I want to see when I tap on that tile?
>>: The weather.
>> Oren Nachman: The weather. I want to see what's going on. Now let's see what's going to
happen. Okay. I have a splash screen. That's great. Splash screen is a little long, but that's
fine; I can wait, because the data is loading in the background. Okay. Well, that's fine. I just
want to see the forecast for tomorrow. Come on. That was actually responsive. Look at that.
Did you notice that the forecast said Wednesday? But it's Thursday today; it should be Friday.
Oh, because it's using cached data. There we go. It warmed up. I'm sorry. That's not a good
experience. Sure it kind of responded. Did you see that I managed to catch it just at a point
where it was responsive and it went to forecast and that's not good. Here, I will give you
another example, by the way, since I'm already hearing demoing. This is an example of what
not to do with sleight-of-hand. Check this out. This is an awesome game. It's a lot of fun.
Come on. This is a really slow phone by the way. It's an engineering phone and that's why your
phones are faster. So this is really one. I keep it on my phone solely for demos. It's called Fruit
Ninja. You guys all know it. It comes up. And it's loading and it's a game. Games to me get a
free pass automatically. I'm happy to wait 10 seconds for a game to load. I want to see that it
says loading, so I want to see this loading thing, but I'm happy to wait. That's fine because it's a
game. It's got to load all the texts and then it's going to be buttery smooth once it's started up.
So did you guys notice how long that took? It was 10 to 12 seconds, somewhere in there. Now
check it out. Come on. Yeah, yeah, I really want to quit, yes. I'm sorry. Okay. This is not
performant. Yes, I really do want to quit. I didn't pay for the app so I will give them a four on
that one as well. Now check this out. So it was 12 seconds, right? See if you guys can count
with me. So Fruit Ninja comes up. The initial splash screen comes up and we have one second,
2 seconds, 3 seconds, 4 seconds, 5 seconds, 6 seconds, 7 seconds, 8 seconds, 9 seconds,
anybody notice anything? It was way faster. Do you know why?
>>: Because you are tapping on it?
>> Oren Nachman: Why does that make it faster? This is hilarious. We, like we had to figure
this out. Like this one, someone loaded a bug they are like if I tap on the splash screen while it's
loading it's faster. [laughter]. Ohhhh, you turn on your Windows Phone and the first thing that
you see when it comes up is it says tap on your splash screens to make them go faster. So we
look at them and you know what they do? They loaded. They have started up, but they want
you to see their loading screen, so they have it showing there for over 10 seconds because it's
on a timer, but they are developers and they developed the app; these guys are awesome. The
app is pretty cool. They didn't want to wait every time they debug, so what did they do? They
put it an escape clause. Hey if anyone interrupts, cancel the timer. That's what we call an antipatent. That's the opposite of what I want you guys to do. We have the two extremes here.
We have the one guy who is hiding his loading screen behind a loading screen, but then he's
forcing you, no, no I want you to know I'm working for you. And then we have this other guy
who's like, no, I don't need a loading screen. I start up really quickly but in reality he doesn't.
So this Reddit app that we have here, it's kind of somewhere in the middle. It's displaying
something but not everything but it's still taking a bit of a while and it still delaying some of the
load, which is not good because then the performance isn't there. So let's go and let's see if we
can implement… Yeah, yeah, I know you're connected. That's a good boy. Let's see if we can
implement some kind of layer, and this is a nice little trick, but it's a really nice magician's trick.
You saw the splash screen, right? We have the splash screen image in our project because we
created it. It's mine. You can see it right here. Just in case you don't believe me, it's there. So I
can use that in my app. So why don't I show the splash screen image after the splash screen
image and then only get rid of the splash screen image when I want to? Why don't I control the
splash screen image so the splash screen image shows up when I want it to show up and so it
goes away when I want it to go away? So to do that we will have to add the splash screen
image to our XAML so this isn't a XAML course so I am cheating. All I've done is one thing. I've
created a StackPanel. It's a panel that controls things and stacks them so one on top of the
other and I put two things in here. I put an image. Can anyone guess what that image is?
Yeah. I put in an image and I put in a progress bar. Now you notice that the performance
progress bar is from the toolkit, so that's the one that's tied completely to the compositor, so
it's the one that animates beautifully so that we don't see it going di di di. And I've set it to easy
determinate equals true, so that's those dots that animate because the progress bar also has a
fill a mode where you say go from 0 to 100 and I'm going to update you and it's going to fill up
slowly. It's really useful for stuff like downloads, for example. And then I'm going to display it,
but I'm going to do another trick. I'm going to hide the panorama. I'm going to set visibility
equals collapse, so there are two visibility states. There's collapse and visible. Collapse means
don't show it to me, obviously. It's collapsed. So I'm going to hide the panorama and I'm going
to show the splash screen. So let's see what happens. While this is loading because this is
taking forever, what did I forget? Yes, on purpose, but what did I forget? So I have this
awesome screen. There's my splash screen. There's my progress bar. Can you see it down at
the bottom? What did I forget? Okay. Before that? Did you see that there was no flicker
between the splash screen and now my splash screen? That's because we do that on purpose.
We draw behind the splash screen and then we get rid of the splash screen so that if you draw
your splash screen behind the splash screen, what are you going to get? Your splash screen?
And it's a really neat trick that you can use in all of your apps to have startup continue, like to
have the splash screen show a little bit longer but actually show a little bit of interaction. Have
you noticed something weird? The app hasn't loaded. Why? Because I have a splash screen
and I have dots and I haven't told it to get rid of it. So let's see if we can do that again. So we
have these eventing models and I have an event; I was smart. When I created my model and I
said okay, download this stuff of the internet, I had a little callback that I said hey, I have
finished loading if you are interested. I hooked that up if you remember here. Property
change. I called property change. You call it loading. You call it whatever you want. For me it
was property change because then I can get separate notifications on every bit of the view
model as it changes. So I know that there is a property called submission list and that
submission list is a list of news articles and I am going to say okay, cool, when the submission
list comes up, what I want to do is--someone hasn't heard of block commenting. When the
submission list comes up I want to make my panorama visible. I want to make my loading stack
collapse. I want to hide it. There is my magician’s hand, the sleight-of-hand. And I want to do
that. Does anybody know why I want to do that? Can anyone see that? So I want to make a
progress bar that isn't determinate equals false. Does anyone know why I need to do that?
Let's not do that. Who cares about the progress bar, right? So let's see what it looks like now.
Anybody who wants to nod off, feel free to leave. I'll be finished in 10 minutes though. I am
compiling, deploying, there it is and there is my progress bar and my app. Sweet. Okay. That
looked a little bit better. The list as you can see was there right away. I have a question.
Remember those friendly counters that I was talking about before? So there is something
weird about the friendly counters. The friendly counters are always there when you are
debugging. They are on by default. You can turn that off in your template by default when you
press F5 they are going to be there. Now remember what I said that if the app is doing nothing
in the user is not interacting with the app, what happens to the UI thread and that compositor
thread? They turn off, right? They stop. Okay. Does anyone remember what the second one
is? UI thread. It's ticking. Does anybody know what's ticking? Bingo. The progress bar is still
animating dots in the background. You know why it's animating dots? I never told it to stop.
So here is the obvious question, well, soon I noticed that it is not drawing on the screen, so why
is Silverlight updating it? Anybody know the answer? I only ask that because people like to rag,
oh it's the framework’s fault.
>>: [inaudible].
>> Oren Nachman: One sec, one sec, yes?
>>: Can I…
>> Oren Nachman: Sure.
>>: [inaudible] you command?
>> Oren Nachman: No. That stops it. But why is it animating now? It's not on the screen. I
can't see it. It's not there. The progress bar is sitting if you guys can see it around there. That's
approximately where it was and it's animating like crazy. These dots are flying. So why hasn't
Silverlight said hey I am smart enough to know that it is not drawing. Why haven't I stopped it?
Food guy?
>>: It's collapsed.
>> Oren Nachman: What?
>>: It's collapsed.
>> Oren Nachman: Sure, it's collapsed. So why isn't Silverlight stopping the animation?
>>: It's ready for you to set up visibility [inaudible].
>> Oren Nachman: Beautiful. Your second bingo for tonight. Silverlight doesn't know what you
want. You've told it to animate. From its point of view it's animating a progress bar that's filling
up. It doesn't know that it's a progress bar. It doesn't know what it is. From its point of view
you are animating something that has to be done and it has to be done within 20 seconds
because at 15 seconds you might show it again, because the user might press a button to show
it again and they are going to want to see the state that it was in, that it should be in after 15
seconds. So Silverlight optimizes here. It's not pushing those pixels to the GPU. The GPU from
its point of view there is no progress bar. But from Silverlight point of view it's going oh, you
told me to animate so I am going to animate because now I collapsed that, you are going to
want to see it where it's supposed to be for the amount of time that is animated. So you have
to keep that in mind because often what will happen is you're going to hide something and
you're not going to think about the fact that actually I kind of needed that. So if I jump back
into code very quickly we can obviously disable that. Setting is indeterminate stops the
animation. Now I have another thing. Did you notice that when I flicked the list, first of all the
list didn't come. It took a while for it to come up. When I flicked it it was completely blank for a
long time and then all of these images and text came in? So what's happening there is I'm
loading images and I'm loading text. The text comes in on the UI thread and it says hey, render
what is new. So the UI thread says I know how to render text. It's really easy. Load the
[inaudible] pixels. But then I'm saying hey, I got these 20 images for you and I want you to
decode all of them and render them. Now it's going to do all of those as quickly as possible on
the UI thread. Now I've added them in all at once. So the UI thread is going to be what? It's
going to be blocked because it says you told me to render 20 images. I am rendering 20 images.
So what we can do is we can give a hint to the UI thread and we can say hey, UI thread, I got
these images to come in, but I don't need them to pop in as soon as possible. They can wait a
bit. Let's do them on a back ground thread. Let's go down to my image just to prove that I can,
just to prove that I can't, I'm going to try to do without my cheat sheet. It's not going to work.
So here is my image. This is the image I was looking at before. Visual Studio keeps moving this
back for some reason, so we are going to ignore it. What I'm going to do is I'm going to change
this. I'm going to break out the image and I'm going to say all I want is an image with no source.
But we need the source because we need an image, right? So I can break it out in XAML and I
can say give me a bitmap image. URI source equals--oh, no. There it is. So I am saying break
out the source, so what's happening here is we have a thing called a parser. The parser comes
along, takes the XAML and it says hey I am going to create all of these objects for you and you
say image source equals this thumbnail. Now the parser is smart enough to say hey, the source
is actually a bitmap image. I am going to create a bitmap image for you, stick the source into it
and show it. But that doesn't give you a lot of control over the source, does it? All it gives you
control over is the URI, so what I'm saying is no, I am going to specifically say I want to set a
bitmap image and I am going to specific say that the URI source is that, and then I'm going to
say bitmap image let's set some properties on bitmap image. Actually, I'm pretty sure that we
have updated this, yes. Sorry. I'm going to set some properties, but I'm going to set up nicely.
So what I am going to set some create options and hey, I have some options that I can do to
determine how the UI thread will create this bitmap for me. I have this really neat one that we
added in Mango called background create. What that does is it says hey, here is this image, do
whatever you need to do to this image. I don't care, but do it on a background thread. You do
it nice and slow, take as long as you want. When you are finished draw it on the UI thread and
then we have a lot less impact. I will compile, wow. I honestly didn't think I would be able to
do that. Let's see what it looks like on the device. So, up comes my screen. Here is my
progress bar. You will notice that the counter will stop moving as soon as the progress bar is
gone. Did you see that it has stopped moving? Ah, we are still loading some stuff. Okay, we're
done. Did you see the image just popped in, instead of just being there? And now when I
flicked my list you see that it blanks a little bit still, but it blanks way, way less. Before I
managed to get a whole screen out of one blank, out of one flick. We can optimize this more,
but we're not going to move into it not too much. This is actually because of the amount of text
that I'm sticking into it, but you can see that it is loaded. Now we haven't solved everything.
This is what Ben pointed out last time and I was trying to hide it and… Remember me? I'm the
guy who really likes his pictures. I don't care what's new. Now the app developer he didn't put
in this thing for pictures, to jump to pictures straightaway, so I've got to get my pictures. So I
got to my pictures. But you saw how long it took me and you saw the frustration of my fingers.
And the user feels that frustration, trust me. Anybody that is using a mobile app knows what
I'm talking about and it doesn't matter what system you are on. Every mobile app somewhere
you have run into it. Now let's apply that same thing, that same idea of pictures, let's decode
those in the background. So here is where I go through and I say for every submission in the
picture submission list… I'm finishing up, promise. What we're doing is we are going to very
quickly say okay add, create options. Create background options. So now these images load in
the background. Exactly the same only this time instead of creating them in XAML I happen to
be creating my stuff in code, so everyone has a URI. It has a border. It has a new image.
Create the bitmap image, set the create options, add the child, add it to the rack panel. Now
it's loading on the background thread. Let's see if that helped. Come on. So it's a little better.
But it wasn't perfect by a long shot. It was still better. I didn't get really frustrated but it was
still stopping. Can anybody guess why?
>>: Text was still drawing on the…
>> Oren Nachman: Text was drawn already.
>>: Oh it was?
>> Oren Nachman: Yes, definitely. I can show it again. Here actually this time I will do a deploy
so you can't even say that it is the debugger. You don't know how many times people have said
hey, I know why you are slow. It's because you're running on the debugger. Sorry. It's not
that. The debugger does slow you down obviously because it's processing debugging. Okay,
the text is there, the images are there, okay. I was waiting too slow with that thing is a cast, but
let's assume that the images are not there. It doesn't matter; the images don't matter because
they are running in the background thread, the first ones. So the text is there. I'm going to
stop when the text is there. Anybody notice something funny about the pics? That was a really
good one. Did anybody notice something funny about how they loaded? All at the same time.
Sure. Why? I didn't tell it to do that.
>>: [inaudible].
>> Oren Nachman: It's actually how I'm adding it. So let's take a look very quickly at my code
and we will finish with this. I get this call back on the UI thread that says hey, my property
changed. So my code goes and says hey that's also, I have been waiting for that to happen.
Let's start adding things into the rack panel. What threat my on right now? Perfect. I'm on the
UI thread. And I'm saying I don't know there's like maybe 30 images down there or however
many there are in there. I'm going to add them all on the UI thread, so as quickly as possible
let's create a border. Let's create an image. Let's create a bitmap image. Let's set them
through background and let’s add them through UI thread. Now this is happening in one UI
thread tick, so the UI thread it ticks as its working and the tick says okay, run user code. The
user goes in and says hey, and all of these things to visual tree. The user code is done. The UI
thread says hey, draw the visual tree. Whoa. I have like 90 new controls to render because I
have my border. I have my image and I have my bitmap image within it and I have to add them
into the rack panel. Whoa. But it says hey, you told me to do that so that's what I'm going to
do. And it slows down. Because as fast as Silverlight is and as optimized as it is to add controls,
if you add too much into it, it's going to die. So we have a very quick fix. You guys mind
spending like 2 minutes running through it or should I just copy and paste the code? All right.
There is no way I am going to be able to do this like directly, but we will try. When I am going
to do is this. I am going to spit this out on a separate thread. Now that's not necessarily as easy
as it sounds because all of these things require that I'd be on the UI thread. Does anybody
know why? Because they are contracting with the UI creating UI controls. So to create a UI
control you have to be on the UI thread. So catch 22, right? What we're going to do is this. I'm
going to break out the whole thing into a new thread. So I'm going to say thread T equals new
thread and I'm going to say what are we going to call our function? I don't know, load pix.
Okay. And I am going to say thread start. Then, I don't know how to use this exactly, but there
is a, supposed to be a feature here called re-factor. There we go. Extract method. Yes, I
missed a thing. We are going to call it load pix. Usually I use cut-and-paste, to be honest. And I
am going to get rid of this call because obviously we don't want that. It's in the thread stack.
Basically all I've done is I've created a new user thread and you can create background worker.
You can create any type of thread you want. At the end of the day they are all going to be the
same thing but the one big thing you can do is you can use like the thread pool. Then you are
restricted by the number of threads, but you know that you are not overloading the system
with too many threads, so that's just how you manage your threads. All threads are
background. We have no control over them. There is nothing you can do to make a thread not
background. There is background property and I love the end documentation. This property is
ignored. Don't believe me, look it up. Bing it. So we have this load pix. This is happening on a
background thread. If I run this it will crash. Trust me. Believe me. It will crash. Why?
Because it's running on the UI thread. I can show you what it looks like. It's like, it will crash.
And it would crash and it would be awesome and yeah. Come on. Don't embarrass me now.
It's not crashing. But there are no images either.
>>: [inaudible].
>> Oren Nachman: The debugger should catch that but it might be that with these tools, it is
not. Let's see if we can see what's going on. Oh, here we go. The [inaudible] over here. I don't
know why but I might have mucked around with my debugger settings. See all of these
unauthorized access exceptions down here? Unauthorized access means one thread is trying to
interact with another thread and doesn't have the access to do it. It can't. It's not allowed.
You cannot, there is one way to interact with the UI thread and we will see it in a second. Okay,
so let's stop this and let's see if we can fix this. What I am going to do is I am going to say for
each submission, now that is problematic. For each on a background thread if I'm modifying
the background, the collection for each will fail also with an unauthorized access exception. So
what I am going to do is I'm going to cheat. You can do it also within unlocking and cool things.
I'm just going to cheat very quickly. Actually I can't use i for current equals zero so use i down
at the bottom, zoom in. Current is less than half view model, pick submission list count and
count plus plus, okay I always leave it just like that because it doesn't require locking the object
and now I need my submission, so submission okay. So now I have code that is essentially the
same as it was before. But what have I forgotten? Well I don't need to initialize it but I never
set it. You need to either initialize or set it, so compiler’is branching logic is smart enough to
determine that you have either, there is no way that you are ever accessing the variable
without using it or initializing it, so submission equals app, view model, which is submission list
and then [inaudible]. Okay. So the compiler will now be happy because it says oh, there is no
way you are using submission without that. So I go in. I go through. And essentially the code is
essentially what it was before. So what I am going to do now is I'm going to take advantage of
the little trick called the dispatcher. I'm going to say dispatcher it up [inaudible] and I'm going
to say [inaudible] because I can't be bothered writing another function and there's no need to
and I'm going to say invoke all of this code in the dispatcher and what the dispatcher says is
hey, take all of this code and shuttle it over to the UI thread and run it on the UI thread. Now I
still got the same problem. There is this background thread that is shuttling as quickly as
possible heaps and heaps of code. It's still going to run in the same tick because all of that code
is going to queue up.
>>: [inaudible] call not continuously.
>> Oren Nachman: But it is going to be continuous because the four, it runs as quickly as
possible. So the four runs bang, bang, bang, Q, Q, Q and the UI thread comes up but it's got 30
dispatcher things all queued up.
>>: Right but it's still on a background thread…
>> Oren Nachman: Not with the dispatcher. The dispatcher moves all of the code in here onto
the UI thread. This is a standard pattern, by the way. For you wise there is this one way to
move your code onto a background thread, from a background thread onto your UI thread. But
because I am on the UI thread, I am on a background thread, I can slow myself down. I can do
something that says hey, don't go so fast. Hey exactly. And this is where sleight-of-hand comes
into play. I am intentionally slowing down my code. But by slowing it down even if I sleep by
just a small amount, I am going to sleep by a large amount just to show you what it looks like,
the actual effect. But even if I sleep small amounts I say hey, yield to the UI thread. Even if you
do a thread sleep zero, it basically means hey my thread is done for now, schedule someone
else instead of me and then come back to me as quickly as possible.
>>: [inaudible].
>> Oren Nachman: Exactly, but the first thing is a little quirk of the, just a very small quirk of
the dispatcher is actually, well I could actually put the dispatcher in to the [inaudible] but I'm
not going to do that. It's going to copy the variable over so I have a local copy. And I'm going to
call that submission original, original, original, because otherwise what's going to happen is
when that code runs it's all going to get the same submission. All of them are going to have
exactly the same picture. So then the last thing I need to do is to compile and double check is
right at the end of the dispatcher call and I'm going to sleep for a quarter of a second. That is a
nice number.
>>: [inaudible].
>> Oren Nachman: What.
>>: [inaudible].
>> Oren Nachman: Yeah, but I want to visually be able to see the effect of what I am doing so
you can see that I'm not tricking you, I'll say it like that. So I bring it up. I bring it up. My app
starts up. And if I copied the code correctly, it's deserializing and I move across, and it reacts
immediately. Oops. That was me actually not swiping. And you didn't even notice that it took
250 milliseconds to load every single one of them. That was your thing from last week. And so
these are games. You might want to wait like 30 seconds, okay? Does anybody know her? All
right. You can throw it to her afterwards if anybody does know her. Alright. So I'm going to
finish with that. The slides have a bunch more general information on them. There is a bunch
of other stuff in there. There are some pain points, just some different things to look at. It's
very hard in a performance talk to cover every single thing because every app is unique. Feel
free to e-mail me if you have any questions or anything. 60 frames a second is the goal. If you
are 45 the user won't notice the difference. You are good. If you got 30, work on it. On the
compositor thread. UI thread, you are fine. I'm done. If you want to stick around and ask
questions et cetera. Grab a T-shirt; grab things. I don't have that many T-shirts unfortunately I
was a little bit disorganized relative to last time where I had like 300 shirts, but I have a few
things. Hey dude in the blue, catch. All right. AT&T overrides [inaudible] team or what?
>>: Me?
>> Oren Nachman: Yeah, you.
>>: [inaudible].
>> Oren Nachman: Ah, crap.
>>: [inaudible].
>> Oren Nachman: Come talk to me afterwards. AT&T [inaudible] worked really well. AT&T.
I'm not throwing this. Come and get it. All right. I am done. [applause]. I am throwing it. Stay
there.