Tip:
Highlight text to annotate it
X
[applause]
Tilo Mitra: Thanks guys. All right, thanks for coming out. I'm pretty excited to show
you what I have in store today. A bit about me, so Jenny introduced me pretty well. My
name's Tilo, tilomitra on IRC. You might have seen me lurking around on IRC or on Twitter.
I'm the guy who has a ton of event touch, event gestures, bugs filed against him. But
I wasn't working on those, I was working on this presentation. After this I'll fix your
bugs.
Anyway, today I'm pretty excited to talk about building native Win 8 apps using YUI 3. With
regards to Win 8, I'm no real expert to be honest. What happened was a few weeks ago
we had this sprint to try to get YUI working on Win 8. One of the things that I was responsible
for was making some sort of test infrastructure on the different Win 8 JavaScript environments.
I made this little app with the help of a lot of my team members and it essentially
ran through all of the YUI unit tests. While making this I picked up a lot of stuff, and
that's what I'll be sharing with you today.
I just want to go through what I'm going to cover in this talk at a high level. We'll
start off by talking a bit about Windows 8 and IE10. Then I'm going to talk about WinJS,
which is this JavaScript runtime that allows you to make native apps using HTML, CSS, and
JavaScript. Then I'll connect the dots and I'll talk about how we can use WinJS and YUI
together. I have some demo, I have a lot of code here that we can play around with. Finally
we'll go to questions.
Also important is what I'm not going to be talking about today. Mostly this is because
I don't know too much about these. But I have links here, so when you get the slides you
can just click on these and they'll take you to the respective pages. I'm not going to
talk about in-app purchases. I'm not going to talk about how to package and submit Win
8 apps. I'm going to go into Visual Studio, I'll go into how to debug apps, but I'm not
a Visual Studio expert, in fact I'm a noob, so just take that with a grain of salt.
Cool, so Windows 8. I never thought I'd be up here talking about Windows.
[laughter]
Just out of curiosity, who's played around with Windows 8 here? Okay, so a bunch of people.
How long did it take you to close an application? [laughs] It took me a long time to figure
this new OS UI at least out, but there's actually been a lot of positive feedback. A lot of
negative feedback also, to be honest. But the truth is that Windows 8 is gaining momentum,
and it's kind of obvious.
I have a couple of tweets here that I just got in the last maybe 72 hours. One from Daring
Fireball that had a Twitter app recently reach its limit, API limit. And then Windows 8 store
apps just recently hit 13,000 apparently. I think when it came out end of last month
there were about 2,000 apps on there. So there are a lot of apps that are coming out. I recently
found out that Google has a Windows 8 app. There's an app from Netflix that's out. That
looks pretty nice. Then there's a lot of other third party apps that are coming out, Food
Network, Vimeo, CBS, etcetera.
With apps comes opportunity. One of the reasons I wanted to give this talk is because Windows
8 has this user interface that's actually common across desktop and mobile devices.
As a developer you could potentially target more customers.
Now let's talk a bit about YUI 3. In YUI 3.7.7 we added support for Windows 8. Eric F wrote
this really nice blog post outlining exactly what was in that release. I particularly liked
this line: "we gave ourselves 10 days, which included weekends, to get the job done. We
were able to add support for all these new environments very quickly because of YUI's
architecture." That's really true. As we go on in this talk you will realize that because
of YUI's modular architecture, it's very easy to use it in this new environment even though
this environment didn't really exist a few months ago.
With that I'll jump into Windows 8 and talk about a couple of points that maybe you know
about, maybe you don't, I'm not sure. The first is this thing, which really confused
me. What's the difference between Windows 8 and this WinRT thing that I keep hearing
about? The difference is Windows 8 is this operating system that can run Windows apps,
as in the traditional legacy Windows apps in the desktop mode, and also new Metro apps
which are the tiled apps. WinRT is kind of like Windows 8 Lite. It's designed primarily
for tablets. For example the Surface is I think called SurfaceRT. The point here is
that the Surface can run these new Metro like apps but they can't run the desktop apps.
Really what we're going to talk about today is how to build WinRT apps that can run on
tablets and that can run on desktops in the new Metro user interface. That's an important
distinction to make, actually.
Now in Windows 8 there are four JavaScript runtimes, as opposed to Windows 7 which only,
I think from my understanding, had one JavaScript runtime which was like IE. In Windows 8 you
have IE10 desktop, which is the standard IE that we've come to know and love and hate.
Then there's IE10... I'll get into these, I'll show you some pictures so you understand.
But there's IE10 Start Screen which is the IE10 in Metro mode. Then there's Webview that
you can open up if you're making a C# app. In Windows 8 you can make apps either using
C# or using web languages. If you make a C# app you can open up a webview. Finally there's
this WinJS environment which also executes JavaScript using the Chakra IE10 JavaScript
engine.
I'll skip the IE10 desktop because I think we're all pretty familiar with that, but this
is what I mean when I say IE10 Metro mode, this is what it looks like. The deal here
is it's more restrictive that IE10 desktop, and the key difference there is it doesn't
have support for plugins such as Flash, Silverlight, ActiveX, etcetera. The star there is because
when Microsoft did this they realized oh, there are some legacy sites out there that
use Flash and we don't want those sites to just break. So if you are a big legacy site
and you email Microsoft and get on that compatibility list then your Flash will work in Metro mode.
But for regular developers, you don't have any Flash.
Then there's this webview mode. I haven't really played around with this too much. We
ran Yeti on it so we know stuff works in there, but this is only really if you're a C# developer.
What you can do is I think you can use XAML, using that syntax there, and pop down a webview.
The webview's very similar to webviews as you would expect on iOS or Android. You can
point them to a source. The page that loads up inside this webview obviously does not
have access to onDevice APIs, and it has limited HTML5 support. For example, it doesn't have
geolocation, it doesn't have indexedDB and a few other features. There are some docs
on that.
But the really interesting one is this one, which is WinJS. What it is is a restricted
IE10 runtime with access to native APIs. When I say restricted I mean not all the DOM APIs
are available, and there is some more documentation about that. Essentially it allows developers
to create WinRT apps using HTML, CSS, and JavaScript. There are a lot of other restrictions,
but one of the main ones we ran into was that when you build these apps all scripts and
styles must be available on device, so they have to be packaged locally. This becomes
important when we're working with YUI, so we'll get into that a bit more later.
I want to dig a little deeper into WinJS specifically now. Like I said, it uses IE10 to process
HTML, CSS, and JavaScript. It uses that Chakra JavaScript engine that I think IE10 uses.
Scripts and styles bundle locally. It doesn't have JSONP. It supports CORS over XML HTTP
requests. It has this concept of a safe innerHTML. I'll get into this in the next slide, but
you can essentially dump any HTML that you want. You have access to these traditional
DOM APIs but you always have access to these new namespaces capital Windows and WinJS,
and that gives you access to onDevice APIs.
When I mean safe innerHTML, all DOM APIs which end up appending things to the DOM, whether
it's innerHTML, outerHTML, innerText, etcetera, go through this two static HTML method in
this environment. Essentially that will only allow certain markup to filter through. I
have a link there that's a huge list of what's allowed and what's not, but essentially you
can't have inline JavaScript.
Here you can see in this example, if that was my innerHTML I was putting through, the
scripts would get taken out, the inline JavaScript they're on onClick would get taken out, and
the only thing that would get appended is span click me. This is actually a good thing
that they've done just to make it safer. There were some small instances in YUI where we
were doing something like this. It was pretty easy to take care of, but it's something to
keep in mind.
Okay, so let me talk a bit about a WinJS app. You open Visual Studio and you say new project
and you say I want to create a WinJS project. What you essentially end up with is something
that looks like this. You have a default.html file which links to default.js, default.css,
and it also links to a bunch of WinJS references. What do all these mean?
The default.html, I'll get into this a little later, but think of it as a shell around your
application. Default.js is where you contain all your app lifecycle code. I'll show some
code about that in a bit too. In WinJS you have the full screen view, but you also have
media queries because you can snap apps to the left or the right of the screen. You can
kind of multi-task. Default lets CSS have some of those media queries built in.
Then we get to the WinJS side. In WinJS, again, everything in WinJS is HTML, CSS, and JavaScript.
A new app would have ui.css which contains all the styles to make your app look and feel
native. Then there's base.js which has class management tools and things that YUI already
offers, but if you weren't using a library you'd be using whatever's in base.js. It has
ui.js which is where all the WinJS widget views are contained, all the classes related
to user interface. Then if you're making some sort of master detail application you get
this navigator.js which maintains navigation. I'll dig into some of these a little deeper.
Obviously you need more than one page in your application. If you want to add a page, each
new page that you add, or in mobile terms each new view I guess, is its own set of HTML,
CSS and JavaScript. If you wanted to add two new views here, master view and detail view,
I would have HTML, CSS, and JavaScript for each of those.
Now, those pages, for example master view which has masterview.html, masterview.css,
masterview.js, to me they adopt a model view controller architecture. The view is represented
by whatever's in HTML and whatever's in the CSS. The controller's whatever is in that
JavaScript file, and the model is usually something that's available globally. It's
usually defined in some global space so that all the different views have access to it.
Let's go back to this default.html, because this is a little interesting. In WinJS when
building these apps you're essentially making single page apps. All your pages are contained
in this default.html shell. This shell has no user interface but if you, say, navigate
from page A to page B, the contents of page B get appended to default.html and the existing
content in there essentially gets removed. Default.html always has this shell, and if
you have any scripts or styles that you want access to throughout your app, you can put
that in default.html.
Here you can see you have default.html, but the actual page the user is viewing might
be homepage.html. They don't actually know the default.html is there. Homepage.html gets
loaded along with its scripts and styles, and then that gets placed inside this shell.
The way you do that in WinJS at least is in default.html if you look at the code, and
I'll show you some code later, there's barely any code in default.html. Essentially all
it has is something like this. It says that when this app launches I want the homepage
to be homepage/... There's a typo there, it should say homepage/homepage.html. But essentially
when the app launches that gets processed and homepage gets appended to the default.html
page.
Now default.js is what figures that out when the app launches. That's where you place all
lifecycle events and all code related to the app lifecycle management. For example, there
are a bunch of events that fire over the lifecycle of an app. Activated when the app is launched,
loaded after DOM content loaded fires, ready when the app is ready to use. Checkpoint fires
when the user is navigating away from your app and your app gets placed on the background,
and unload is when your app gets terminated, essentially.
Let's talk a bit about navigation, because this is another tricky thing that took a while
to get my head around. In WinJS if you want to navigate from one page to another you can
use hrefs essentially. Since it's a single page model navigation is done through the
WinJS API which you have access to. You call WinJS.Navigation.navigate and in that method
you pass in the path of the HTML page that you want to navigate to along with any objects
that you want access to on that page. That's how you pass objects from one page to another.
In this case we could say WinJS.Navigation.navigate detailview.html, and that'll navigate from
master view to detail view while keeping sure that both of those are inside this default.html
shell.
On this slide, this is what happens if we use hrefs. If you click on a link and it had
a href to detailview.html, suddenly that page loads but there's no shell anymore, there's
no default.html shell around that page. That page has no idea what... It basically has
no idea of any WinJS APIs or any onDevice APIs at all. There's no way to navigate back
from that page to the previous page essentially. We ran into this problem when we were actually
doing our unit tests, and we had to correct it by going back to the previous model.
Again, to iterate, this is the code that you call to navigate from one page to another.
You can pass in an object, and in the app that I'm going to show you a little later
I pass models from the master view to the detail view using WinJS.Navigation.navigate.
The navigation namespace has a bunch of other methods. GoBack, goForward are standard things
that you would expect. And when you do that what happens is the app automatically adds
the back buttons and the forward buttons as you would expect, so you don't have to take
care of any of that stuff.
I'm going to talk a bit now about the interesting part, which is how we can use YUI and WinJS
to build Windows 8 apps. This section is actually all going to be about re-using code. That's
something that I found out while I was experimenting with this stuff, is because this is a web
runtime we can re-use a lot of existing web code when making Win 8 apps. We can use a
lot of existing concepts that were used on the web instead of reinventing the wheel.
By this what I mean is when you traditionally launch a new app in WinJS, just as you would
expect from Microsoft you get a ton of proprietary CSS which makes no sense. I had to actually
go through and clean up all the CSS and just replace it with nice semantic CSS and CSS
3 stuff which actually works in both environments instead of working just in the Microsoft WinJS
environment.
Another thing I'll be covering in this section is this user interface, user experience thing.
This debate comes up sometimes is that oh, if I use web technologies is my app going
to be less performant, or is it going to not look as nice? I'm going to actually show that
through examples.
I'm actually going to show you an app but before I show it to you, because I'm going
to show it over a remote desktop it's kind of clunky. It's actually very smooth. I checked
it yesterday, I went to the office and I checked it on the machine and it runs really well.
It's kind of clunky but it's over a remote desktop, so I just wanted to give you an overview
of what the app does so you understand it when I show it to you.
It's a very simple map. It's a master detail app. If you guys know what Dribbble is, it's
this place where designers post shots and they get feedback from other designers. I
really like it because it's a nice colorful site. I'm using the Dribbble API over YQL.
This is the homepage of the Win 8 app that I'm going to show you. Essentially it gets
a bunch of images from Dribbble, groups them into three categories. You can only see two
here. Popular, everyone, and debut. Then you can click on one of these and get a detail
view.
What's interesting here is I'm using Y.View to make these views here. They look pretty
native, right? I have some CSS in there obviously, but you would say this looks pretty native.
Then I have a Y.ModelList that contains all of the individual models for all the shots,
then each individual shot is represented as a Y.Model essentially, called shot. If you
click on one of these you go to this page, which is another page.
What I want to make clear here is none of these two pages use anything WinJS specific
when it comes to their models or their views. They only use WinJS code for their controllers.
Now for this page, again, I'm using Y.Masonry, which is a gallery plugin, or gallery module,
to create this brick-like effect for the comments so that they kind of stack nicely. You can
vertically scroll through the comments and horizontally scroll through the page. Apart
from that, I think I'm using Y.View for the other sections. Everything is floated left
relative to each other to create the WinJS sort of UI effect.
Now the other cool thing I want to show you is that I have the same app on... It's not
really an app, right? It's pretty simple. But I have the same code running on Chrome,
or Firefox, on the browser essentially. It's the exact same thing, literally the same code.
I have a GridView, which shows, again, the items. I have the same modelList which shows
the model list of all the shots. And each shot is still represented by a Y.Model.
The only thing that's changed here is I completely changed the CSS because the CSS in Win 8 is
obviously different from what users expect in a webpage. The other thing that I changed
is if you click on a shot, I don't show the Win 8 UI, I just show a completely different
UI. I just use a completely different view. Instead of using the Win 8 view I just pass
in a different view to the controller here. But the models that are getting passed between
the master and detail view are exactly the same.
I want to show it to you. Again, it looks clunky here when I'm going to scroll around,
but that's because of the remote desktop. So here it is. Pretty straightforward, right?
I can kind of scroll through like you would in Win 8. I'm just using... These are just
images that are all floated left relative to each other. There's actually three views
here. I represent each of these groups, so the everyone group is one view, and then the
debut group is another view, and the views are kind of just floated relative to each
other.
When I click on, let's say, this, I go to this view here and just using standard WinJS
navigation you can kind of scroll down through here. Yeah, that's pretty much all it is.
There are some clean ups that still need to be done obviously, but you get the idea. Then
on the browser it's pretty much the same thing, the same views. We have three different GridViews
here and then clicking on one of them basically shows a very simple overlay. I'll go back
in here and talk about how to do this.
If you want to include YUI in a Win 8 app, how do you do that? There are three different
ways. One is to use the Dependency Configurator. If you go to the Dependency Configurator on
YUILibrary.com you can choose the modules that you're interested in and you get a bunch
of script files. You can download the script files because remember you can't include them
remotely, and then you can add them to your project. You can do that but it's manual.
You have to copy and paste script files over, and then if your modules change you have to
figure out new script files to get. So you don't really want to do that.
Another way is to clone YUI and include the build in source directories. This is much
nicer because you can just clone. The problem with that is if you clone the entire library
and then include it, I think it's over 120 MBs, 130 MBs. It's pretty large. You don't
really need all that code.
What I did was I cloned YUI but I only included the build into the project. The build directory
comes to I think 30 MBs of code, which is not bad if you think about an app. You could
potentially include only the modules that you need from that build directory, but that
was a pretty good... I felt that was pretty nice. Now if you were including stuff from
the gallery like I did, I included Masonry and I think I included Eric F's ModelSync
YQL, I recommend now that in the new gallery you can keep your own repos separately, I
recommend just cloning those repos and including the build files from there. Just include the
build files, that's what I would recommend.
To include YUI, if you remember before where I talked about default.html is kind of this
shell for every page in the application, I actually include YUI directly in there and
that gets included into every page. It only gets loaded once because the default.html
never changes, but that way I don't have to include it in the HTML pages of every other
view in my app.
Another interesting thing here is that YUI_config. Let me quickly show you actually how my default.html
looks like so you'll get a better idea. Yeah, at the top here we have some WinJS references.
Then I have this YUI_config global variable. If you go to the API what this does is you
don't have to pass in objects when you do YUI.use any more. The config automatically
takes care of that. I use this YUI_config global and I included all the custom modules
that I'm including in this project in here. For all my other pages I can just do YUI.use,
call the module.
Not sure if there's any con of doing this, but it seems like a good way of keeping everything
organized in one place. All my custom modules are defined here and I know what they require.
Then I can just use them in any other page of my application. Then after that I include
YUI here. Then, as you see, there's not much in this. Everything from all the other views
will automatically get appended into this contenthost div.
After that, let's revisit this MVC architecture that these views use. When I saw this I immediately
thought about the YUI App Framework. Remember how each page in WinJS has its own HTML, has
its own JavaScript, and has its own CSS? We can represent that stuff using the YUI App
Framework. We can represent the model for a page using Y.Model or Y.ModelList. We can
represent the view using Y.View, and we can represent... The controller is interesting,
I'll get to this later, but for now, for the controller I'm not actually using Y.Router.
For the controller I'm just keeping it using WinJS conventions and just doing the standard
stuff that WinJS expects you to do.
Models I feel should be environment agnostic. They basically represent data, and that doesn't
depend on an environment basis. Luckily since YUI 3.7.3 we added support for CORS... WinJS
supports CORS XML HTTP requests, and the new YQL WinJS module allows it to use CORS to
talk to YQL. YQL just works. I'll show you my model code and you'll see there's no WinJS
code in there at all. All it does is load stuff from YQL and save it in a modelList.
That allows this code to run on the browser and on WinJS.
If you didn't use this, if you just used whatever was provided to you when you started up the
initial project, there was a ton of WinJS specific code in there just to make it work
with WinJS views. I'll get to views in a bit.
Let me show you my modelList that represents all this stuff. I think I can clean up the
code more, but you'll get the idea. I create a subclass modelList and I just pass in a
query which is a multi-query that goes to YQL. The cool thing about YQL is you don't
have to use a YQL table to use YQL. I'm just using the JSON table and it's going to query
the Dribbble API directly, get the JSON back. It's not like you have to use a YQL table,
so it's really nice.
I'm using Eric F's ModelSync YQL module allows me to just load, or just call the load method,
get YQL results back and then parse the results out. Then I classify the results that come
back into different groups. Essentially that's it. There's no WinJS specific code in here.
The same applies for the individual shot, which is even smaller. I can probably break
this out a bit more but it's just a standard Y.Model.
Let's talk about views. This is actually really interesting. Should we use WinJS UI views,
or should we leverage Y.View? In this image here you can see a couple of the different
UI views that WinJS comes with. There's the ListView which is on the left, the comments
that you see. There's a GridView on the right. You can do some fancy stuff with the GridView.
You can say stuff like I want some items to be bigger than other items, pass in different
templates, which is what they've done there to have that one image bigger than the rest.
There are some interesting things you can do.
I want you to look at something here. Take a look at this. This is using the native GridView
implementation in WinJS. It's the most standard GridView you can get. You basically pass in
an array and tell it what to show and what not to show. Then take a look at this. They
look pretty similar. Apart from some CSS differences, and one is longer than the other, you wouldn't
be able to tell the difference. If you notice the fonts are the same, they pretty much just
look exactly the same. This is using Y.View.
What's the benefit there? Well with native views here are the pros. It's easy to get
it to look right because they work with the user interface style rules that are provided
by Microsoft. Easy to get it to look right. It's also the conventional way to do it. It's
the WinJS way. Microsoft has documentation, it has code samples, etcetera.
But let's look at the cons here. You can't use the code outside this environment, these
views are proprietary to the environment. And they're only using HTML, CSS and JavaScript
anyway under the hood. The other tricky thing I ran into is you have to figure out how to
organize this native API code with the YUI code. If you have a modelList you can't pass
the modelList into a native view. You have to pass in some alternative functions to tell
the native view how to group stuff, and then you also have to pass in only an array. There's
some architecture that you have to do to make sure your code is at least getting clean.
Another con which doesn't exist on Android or iOS, you could say, is that there's no
performance gained for using native views. Again, it's all HTML, CSS and JavaScript under
the hood.
Let's compare that with Y.View. You can code it once and re-use it in different environments.
You could definitely re-use the JavaScript, right, because that's what I've done. I haven't
re-used the CSS, which is what determines the styles, but the markup is the same. It
works well with YUI, so you can listen to attribute change events, you can pass in modelList
and it kind of just works.
The biggest pro here I think is that achieving the look and feel of Win 8 is really easy,
because Win 8 provides this ui.css file and it's very easy to figure out what my class
names should be to adopt a certain style. Not only that, but since Win 8 the Metro interface
by its nature has this flat look and feel. It's actually a lot easier to work with than
in iOS where you have these gradients that you have to get to look exactly right and
these text shadows. It works really well with CSS.
The con here obviously is that I have to code and determine the markup and styles. Instead
of using a view that was already provided to me, I have to code it. But that's a one-time
cost. I made a GridView here, and I don't ever have to make one again. I could add some
more functionality to it, but that's relatively trivial compared to making a GridView for
a web interface and using a completely different view for the WinJS interface.
To me I think it depends on the app that you're making. In the end, if you're making something
that you don't expect to be cross-platform you could take the hit and use the native
views because you'll save yourself writing some code. But over the long term I think
Y.View probably offers greater benefits. Try using both.
The other issue I found was that the Microsoft code for just... The Y.View code is really
straightforward. Get a view, figure out what you want to put into its render method, pass
in a model or modelList, tell it when you want it to render again based on attribute
change events, and it just works. The native view stuff is not that easy. It's pretty tricky.
I don't even know how to explain it very well to be honest. So try using both, see what
you're comfortable with.
Just want to make a brief note about controllers. I actually haven't experimented with Y.Router
in this environment. Right now my controllers are still using standard... There's no YUI
code in there. I mean there is but it's heavily leveraging WinJS APIs, which I think is fine
because controllers in my book can be specific based on their environments. Page navigation
has to be done using WinJS APIs anyway, and navigation history is already maintained by
this navigator.js file that you got for free. So for now I haven't fooled around with controllers.
Maybe I'll change my mind if I do. But for now I didn't find anything wrong with using
the standard stuff that's provided to me by the project.
Just touching back on this point about UI and UX, won't user experience suffer if we
don't use native APIs? The key here is that everything is HTML, CSS, and JavaScript anyway,
so whether you use native views or not, you're still going to run through a bunch of JavaScript.
The standard rules when applying stuff to the DOM and all that still applies in this
environment.
CSS3 transitions are supported. One of the things that people might say, and I ask myself,
is that when views load there's this subtle animation that kind of happens. These are
native animations and isn't it going to be hard? That's kind of what makes the app feel
like it's native, right? If you don't have those animations suddenly the app feels kind
of clunky because it just kind of pops up at you in different places. I was actually
able to replicate those animations using CSS3 and just using the transition module in YUI.
Again, since these native animations are using CSS under the hood, they're pretty easy to
figure out. I think they're probably in ui.css, so if you probably went through that ui.css
file you'd probably be able to figure out what's happening under the hood.
On that note, it's really easy to leverage the styles that are in these UI files to get
the right look and feel. The key thing to note here is that your Win 8 UI should not
look like your web UI. Changing the CSS makes that possible, but that doesn't mean you necessarily
have to change the HTML and the JavaScript.
I just want to end by talking a little bit about debugging WinJS apps. Obviously very
important. It's actually not bad. I can show you guys if I have some time left. You can
set break points and use the JavaScript console for debugging as you would expect. There's
this Windows simulator that you get if you install Visual Studio, and it's very similar
to the iOS simulator. You can simulate touch mode, you can simulate putting two fingers
on it. It also has simulation for different screen resolutions for different size tablets.
That's nice.
When you're in Visual Studio you can either build locally or build in the simulator, and
if you build in the simulator you can view the DOM while the app is running at certain
break points using this DOM Explorer. It's very nice. That's how I figured out a lot
of these styles sometimes is I stopped it and used the DOM Explorer to figure out what's
happening and what the HTML looks like for some of these native views.
I think that's all I had. If you have any questions or comments, now is a good time.
The code I showed you is all up on GitHub, so you can check it out. It's on tilomitra/Sights.
Cool, thanks.
[applause]
Jenny Han Donnelly: Anyone have any questions?
Audience member: I know that some of the advantages to doing a native app are more to do with...
It's just getting the vetting and stuff, getting in the app store. Can you touch on that, because
from the perspective of somebody trying to make a decision of whether to do their app
either in web or in WinJS on Windows 8...
Tilo: What do you mean by the difference between web and Windows 8?
Audience member: Say like, I don't know, do they have like some way to make your app like
a bookmarklet? Like on iOS where you can tap an icon, you can go to a webpage, it has an
icon, it'll make a bookmark essentially which it'll turn into an icon on your home screen.
Tilo: Oh, I see. To be honest I don't know if that functionality exists. I mean I haven't
read into Win 8 as an operating system too much.
Audience member: Well there's an app store, right?
Tilo: Yeah, there's an app store. These apps are meant to be packaged and submitted directly
to the app store as an app. If you're talking about more of a web page that you want to
place on a home screen, I'm not sure if the OS supports that. I assume it does, I assume
you can favorite stuff onto the start menu.
Audience member: Are you saying that WinJS is not the only way to go through the actual
app store?
Tilo: For sure there are two ways. There's the WinJS way which is meant more for web
developers, and then there's this C# way meant for traditional developers. I think what Microsoft
tried to do there is to prevent the iOS problem, which was in iOS web developers often make
a web app and then add it to the home screen. I think Microsoft's saying if you want to
do that, make it using WinJS. But I can't speak to the fact whether you can actually
add it to the home screen from the web browser. I assume you can, but that's an assumption.
Audience member: Sure. Okay, thanks.
Audience member: Hi. Out of curiosity, did you dig deep into is Microsoft writing now
their own low level DOM manipulation animation stuff? Because I heard actually quite a while
ago that Microsoft was going to invest and maybe "adopt" JQuery. Do you know what's under
the hood?
Tilo: I haven't looked into the files, but I mean it's pretty easy to look into them.
When I looked into them briefly I just saw regular straight up DOM stuff. There wasn't
any library normalization there at that level. For the CSS side, as I said, there were a
lot of WinJS and Win 8 in specific for these native apps. They have a lot of custom CSS,
so they have stuff like GridRows. They're CSS that don't even apply in IE10, for example,
they're just specific to this environment. They have a lot of proprietary custom stuff
like that. I haven't noticed anything that's any sort of normalization, or even in the
documents I haven't noticed anything like that.
Audience member: Thank you.
Tilo: Yeah.
Audience member: Hey Tilo.
Tilo: Hey.
Audience member: I'm just curious if you thought that the conceptual mapping between Y.Router
and the way that it works with paths and callbacks maps well to the native WinJS navigation stuff?
With the sense, like, would it make sense for us to invest time into making router essentially
work on top of either the browser history APIs or the navigation stuff in WinJS?
Tilo: I totally think that's what we should look into. I actually think that's the way
to go because then we'd have a better story to tell potentially. The thing is we could
make router work, but what you get for free, which is important, is the whole history management,
the UI that comes with that history management. We have to figure out how to roll that into
Y.Router as well for this environment.
But if we could, if you could have some submodule that does that, essentially... I don't know
if duplicate, but add on to the functionality provided by this native navigator.js file,
yeah. That would allow us to even better work with models and views and stuff like that.
Audience member: Yeah, yeah, because I think if we could share route handling code if it
made sense to that would be interesting.
Tilo: Yeah, totally. Yeah.
Jenny: Any other questions for Tilo? All right, thank you Tilo.
Tilo: Thank you guys.
[applause]