OK, I think we'll get started. Hello, everyone. My name's Scott Allen, and I'm here to talk about jQuery Mobile. I'm going to be using jQuery Mobile in an ASP.NET MVC 4 project, but we're not really going to focus too much

on ASP.NET MVC 4. But there is a reason that I picked ASP.NET MVC 4, and it's because it makes it a little bit easier to optimize some things for a mobile device. I'll show you how that works. We'll primarily be focusing on jQuery Mobile, which as the name implies is a framework that builds on top of jQuery. So it requires jQuery, and it runs on iPads, on iPhones,

on Android devices, Windows Phone, Blackberry Phones, Kindles, and of course, desktop browsers too, because it's all just HTML, CSS, and JavaScript the whole way through. It's going to be one of those frameworks that you either really enjoy working with, because it

does most of what you want it to do pretty easily, or it's going to be one of those frameworks that you curse a lot, because you're fighting upstream against the way that it wants to work with things. It's one of those frameworks that you have to work with it in a specific way, and during this presentation, I'll show you some of the traps that you can fall into with jQuery Mobile.

Of course, it works with all these devices, some of them better than others, and there's always some things that look really nice on an iPhone, for instance, that maybe don't look as nice or work quite as well on a Windows Phone. But it does a pretty good job trying to balance the amount of features that it adds when you include it in a page versus what

the browser is capable of. What I'll do today is mostly run it in an emulator or in a desktop browser that it thinks is a mobile browser. So we'll see all the good things it can do. To get started with it, if you want to go to the jquerymobile.com website, you can always go there. There's a big download link.

You just click on it. That's going to be a zip file that you extract. And inside, of course, is just some JS files. You really just need the jquerymobile.js file. There's a CSS file, and there's a few images that it uses for icons. The easiest thing to do with jQuery Mobile is to build a new website from scratch with it,

because then you sort of fall into the pit of success with jQuery Mobile, and you don't try to fight against it with any existing code and script that you have. We're going to do something slightly harder, and that is I'm going to take it and add mobile features to an existing ASP.NET MVC application. The ASP.NET MVC music store, which, if you're interested,

that's available for download on the CodePlex site, if you want the source code to that. It's just a sample application. And that makes it a little more challenging, but not too much, because this is a relatively simple application, and the one thing that it avoids that makes jQuery Mobile sometimes a little more difficult is it doesn't use a lot of client-side script. It does some client-side validations.

It does have jQuery already loaded in it, but it doesn't have fancy carousels, and it doesn't do a lot of Ajax requests and dynamically updating the screen. So it's going to be relatively easy to add jQuery Mobile support to this website, but again, I'll show you some of those places where you can run into trouble with jQuery Mobile if you are using it on an existing site

that already has a certain way of working. Most of working with jQuery Mobile is identifying elements and pieces of structure in your HTML code that jQuery Mobile should go out and look for and enhance. And this all starts with the page.

You don't need to identify a page, but it's best if you tell jQuery Mobile, here's a div that represents a page that I want displayed on a mobile device. And all these widgets and structural elements and actually behaviors and certain options, they can all be set through data dash attributes, and it's the data dash role attribute that you can use to create page, content area,

header, footer, list views, collapsible things. We'll look at those. So before we get too far into the slides, let me flip over actually into the application, the ASP.NET MVC music store. Should be up and running here in Chrome. It looks like that. And if I take that URL and put it into a mobile browser,

this is just the Opera mobile emulator that you can download for free and run on a desktop. It doesn't simulate exactly the behavior of a mobile device because of course the iPhone's gonna behave slightly differently, but it does give you the right layout. So when you install that emulator,

you can say, hey, launch a Kindle Fire. That's a 600 by 1024 resolution, or launch on HTC Hero, which I think is what I'm running here, and it does respond to some touch events, some swipe events if I drag the mouse around on it, and it does, if you hit Alt-R, toggle between landscape and portrait.

But you can see the site right there doesn't look very good. So that's part of what we're gonna try to improve. And this particular application, I did already take one step towards using jQuery mobile, which is I went in with NuGet, and instead of downloading the jQuery mobile libraries from the website, I just went in,

and you can see under installed packages, there's jQuery mobile. So if you use NuGet in Visual Studio, and just ask it to install jQuery mobile for you, it'll put the scripts and the CSS files and the images in the right place. So here's what we're gonna do. There's all sorts of ways to take an application that looks like this and make it look better

on a mobile device. You can try to do it with a single design, you can try to do it by building two completely different applications, you can try lots of CSS media queries and things like that. What I want to try is to try to optimize this music store for a mobile device just by adding the least bit of code possible

to optimize for it. In other words, it would be nice if I don't have to change any controllers or business logic or anything like that inside my application, but still make a better mobile site. And in MVC 4, it turns out that that is reasonably easy by using mobile views.

So what you can do, this is the shared folder, which if you're not familiar with MVC, that's the layout template that defines the template for all the views throughout the rest of the application. I'm going to take that and copy it and paste it back in here and then rename it with a .mobile in the name.

So it's going to be underscore layout, .mobile, .cshtml. And now, what ASP.NET MVC 4 will do is when it detects a mobile device and it does that just by looking at user agent strings, when it detects a mobile device it will,

and it sees a .mobile view, it'll always use the .mobile view for that mobile device and that works for layout views, that works for content views, that works for partial views, that works anywhere. So you just need a .mobile. This is going to be our mobile view then. We're going to optimize it a bit. And the first thing I'll do

is just take out the existing style sheet and see how this looks. And leave everything else in there for now, but we'll go ahead and bring in jQuery mobile. So under scripts, I want jQuery mobile. I'll drop it in here underneath of jQuery, which I think is where it ended up, yep.

And another little trick that you can do in MVC 4 is if you just use a tilde in a script or a link tag, you'll automatically generate an app-relative path, which is kind of nice. And we also need the CSS file. So under content, there's a few different jQuery mobile .css files in here. I'll explain what they are later,

but this first one, which is just jquery.mobile .versionnumber.css, that has everything that we need. So include that with a tilde two, and we get an app-relative path. And just see what this looks like. Refresh it in the little browser.

And a little bit different because I got rid of the CSS, but of course we still have that zoomed out problem. I'm sure you all know the solution to that. That's just a meta viewport tag. So under HTML, meta viewport, just instructing mobile browsers to use their device width instead of pretending the entire world is 980 pixels.

That should make things a little bit better. So we're closer. We're zoomed in, the user doesn't have to zoom in on things, and now we can start applying some jQuery mobile changes. Questions so far? No, all right.

First thing I'm gonna do is take everything that's in my layout page and put it in a container, sorry, so that it has a page section and a content area. Just so jQuery mobile knows where those pieces of structure are. So everything here, header, footer, everything.

If I do Control-K-S, I think it was, wrong keystroke. Control-K-S, no, yes, Control-K-S. Surround with a div. Surround with a div with a data role of page. And then the content area is really gonna be

this existing div where the content view renders. That's not going to make, sorry for flipping around so much, too much of a difference here, but it's gonna make jQuery mobile a little bit happier. And what I want you to notice is that when I click on a link inside of here,

there was that brief blip as it animates to transition to the new page, and part of the problem here is this menu appears on every single page, so the content is changing down here, but not when I click up here, because you can't see that. We should get rid of that menu, perhaps. Let's go to Blues, there you can see it changed.

We need to get rid of that, but let me take it out of Opera Mobile, because it's a little hard sometimes to see what's going on in that particular emulator, and instead we'll hit it with Chrome, but I'll have Chrome look like it's a mobile device.

You can do that by opening the developer tools, F12, going to settings, and saying override user agent. It's a little bit quirky sometimes. Sometimes it's set to be a different user agent, but it forgets it, so I'm just gonna set it to be an Android device. That should be enough if I refresh

for MVC 4 to serve up the mobile version of this, and collapse this down. And what I want to show you in the developer tools, if we look at elements and I click through a few things, let me go to, let me go home, let me go to the store.

What I want to point out in here is that here's a div with the data role of page. That was the initial URL, that was the initial page that we loaded, the home page. You can see that is specified data role equals page, data URL equals slash,

but there is also a page down here with a data role of page with the URL of store. And this is one of the things that we'll keep re-exploring today, and one of the things that might cause us problems, or cause you problems when you use jQuery mobile. By default, when you load up jQuery mobile,

and you have these pages, when you click on a link, and that link points to something in the same website, what it's going to do is not let the browser just navigate over there and reload the page. It's going to intercept the click on that link or form post, either one, and it's going to asynchronously request that other resource using an AJAX call,

parse out the page that it gets back in the response, and just draft it into the DOM, and then it will take that page, the current page that is displaying. Not sure if that's the current one or not. I guess we're currently on the home page. But what we'll see is somewhere, I forget where.

This one must be the current one. It'll set these pages so they only appear one at a time. So you can see position absolute with 100%. So it just keeps grabbing these things when I click on links, grafting them into the DOM, and making them pop up on the top,

if that makes sense. The obvious problem there is that now I have multiple pages loaded into the DOM. I have to be a little bit careful about things like IDs in my markup. I can end up with multiple headers. If we look in here, div ID equals header in that page.

Div ID equals header in that page. We'll come back and fix that later. But that's the concept of a page. We'll keep coming back to that one. There's also the concept of a dialog. So when I click on a link, instead of grafting it into the DOM

and doing some things in the URL, maybe I want jQuery Mobile to take the destination for that link and sort of pop it up with a dialog look with the rounded corners and it appears over the page. Very easy to do. All you need to do is, when you have an anchor tag, just use data dash rel equals dialog.

And then you can pick different transitions like pop or slide down. So let's do this. Let's see what happens if I come in to this layout page. And first, let me make it just look a little bit better. We'll keep improving this. But I want to get rid of this list

because it just takes up too much space in the mobile view. And that's a little bit better. Whoops. And let's add another link here for about. So give me a list item that is an HTML action for about.

Excuse me. On the home controller. And refresh that after I fix things up a little bit. Ooh. Not HTML to action. HTML to action link. I mean, this is a problem

because I haven't put everything that I need in here yet. It's just not quite the problem as I was expecting yet. So what happens? So right now, I've pointed to a link to something that doesn't exist yet in the application. And you might just be wondering, well, what does jQuery Mobile do then? And the answer is air loading page. So it makes that request asynchronously.

It gets a 500 air code back from the server and just pops up a little message there that tells the user something went wrong. No real details there. Most of these things are easy to customize. You can customize the air text. You can catch an event when that happens. Might have time to look at that later. But let's go ahead and actually build something

that would respond to this. So just real quickly, I'll add a controller. And this is on the home controller. Don't need a new controller. Just need an about action. So public action result. We'll call it about. Just gonna return a view.

And I'll add a view real quickly. Except the menu's scrolled up the top. I think that's add view right there. Hey, it was. It was hidden. Call it about with the layout page. That's fine. And just say this is some about content.

Save everything. Do a build. Let's refresh this. Let's click on about. Let's see, what did I do wrong? Home controller about.

That's not what I want. Run this in the desktop browser for a second. Which the about link isn't there. But if I go to slash home, slash about,

seems perfectly reasonable. So maybe I formed the link wrong over here. Oh, it added the view folders to the path. Oh, I see what it did. It went to store home. Oh, I knew what I did.

Sorry. That's the text about. I went to go to the about action on the home controller. I just wasn't quite explicit enough in this, I don't think. So, with that in place, refresh. Go to about. All right, so it loaded that as a different page.

And grafted it into the DOM. If I want that to pop up as a dialogue, I could have said, this is where I can add some HTML attributes with MVC4. Give me a new object with data underscore rel equals dlg.

MVC4, when it sees you create an anonymous object for the HTML attributes parameter, it'll turn underscores into dashes. So that should come out as data dash rel equals dlg. Which is, got to change that back to dialogue,

which should turn this into a dialogue. And let's refresh this and start over. Go to about. Ha ha, one more thing I have to do, I believe. All these great HTML helpers.

Ah, didn't pop it up as a dialogue. Inspect this element real quick. Oh, I apologize. One more thing.

Trying to get the order of these parameters right. That's route values, don't need any route values. This is now HTML attributes, that's what I need. So this one, cross your fingers. Everyone have their fingers crossed? Will work.

And then Chrome decides it's not a mobile browser anymore. Android, close, refresh, about, there we go. So probably what I want to do with that about view is not have it be a view that renders with the entire layout view.

Just have it be a partial view so that we only display this content. That would be a different tier. Let me just fix that up real quick. What I'll do really easy here in the home controller is just say let's return a partial view, the default partial view. And just to double check things in my layout view, I don't need any of this stuff.

But since this is a dialogue now, I probably should still have a data dash role equals page. That makes jQuery happy. jQuery mobile when it sees that. And tell it that that is the content area. Then it gets styled a little bit better. So this, control K, S, surround with a div

that has a data role of content. That should make the dialogue look a little bit better. All right. Let me come out and clear this up and go back to the home page and click about.

Wow. I didn't build. Refresh. Click about. There we go. And then I would need to add some sort of link. If you have any sort of link in there, when you click on it, jQuery will close that dialogue.

And you can pick different transitions by using data dash transition. Read the jQuery mobile docs, they'll list all the transitions. Slide down, slide up, pop, fade, things like that. I've told you about the navigation. But there's more to it than just being aware

of how many data dash role equals page divs that you have in the dom and how the IDs might overlap. You also have to think about scripts, which we'll come back to a couple times today too. When jQuery mobile was loading that about page and it was rendering with the layout view,

again, that's how the MVC framework will work. And that layout view had a head tag here that included jQuery, jQuery mobile again, and a CSS file. jQuery mobile, if it's loading something asynchronously, is only gonna pick out the div that has a data role of page.

It literally just extracts that out of the HTML and puts it into the dom. And so you also have to be really careful about where you load scripts and where you execute JavaScript code. Because if you have a script for one particular page in your application

and that script doesn't get loaded or it's not included inside of div data role equals page, then it gets filtered out. jQuery mobile doesn't pick it up. It also impacts your document load event. So if you have a script block here, and we could say using jQuery,

let's wire up a document ready event and just raise an alert so we can put something on the screen. And say the document is ready at this point. Then we go back to the browser. Let me just run it from here. I need the mobile one. This one.

Then I hit the refresh and it's ready. But then I go to admin, about. I go to cart, store. No more ready events. Although in a traditional application when you put a document ready event in the layout template, in the layout view, it'd be on every page.

That event would get fired on every page. But there's really only one document ready event and that's when I first hit this application. That's when the head tag gets parsed, whatever's in the head tag at that point, that will be the scripts that get loaded. If I wire up something in the document ready event, that's when that'll fire. And then all these other pages that are coming in, no more document ready events.

Even if they're trying to wire them up too. There's a different event that we have to tap into if we want to execute some JavaScript code when a particular page loads. And I'll show you what that is just a little bit later. Let's get through some more of these widgets. But I just want to point out this navigation thing because it becomes a pain for people.

So there's a couple different times when I keep returning to that. And you have to do things like get rid of these IDs that are in a layout page because they're going to be multiple DOM elements with those IDs sitting in the browser's DOM if you're not careful. There's also a way to just disable that feature. I'll show you how to do that too.

Let's try to make things look a little bit better. Skip that slide for right now. Toolbars. So there's a header toolbar and a footer toolbar. Again, you put them on the page just by saying data role equals header. You can give them different positions. So by default, they have an inline position.

And if you scroll down the page, they scroll up and off out of view. I'll show you what data fullscreen equals will do. Any links that are inside of a header or a footer, jQuery Mobile will automatically convert them into things that look like buttons, command buttons. And the first link it finds, it'll put it on the left-hand side of the header.

Second link it finds, it puts it on the right-hand side of it. So let's see if we can use that to make this mobile view a little bit better. It would be nice if this section, actually all of this section was inside of a header with this being some sort of navigation bar, which I'll show you in just a bit. So that is as easy as saying

this is a data role of header. That would be that div. Just doing that makes that a little bit darker. It gives it a specific theme. I'll tell you about the theme here in just a bit. Looks like we might have to shorten up the name of our music store

just to get it to fit on this small device, which, not a problem. We'll call it music store. And let me get rid of that document-ready event so we don't see it doing that anymore. Save this one and refresh. And so if I scroll down the page, it kind of scrolls off the top.

If I wanted that to always be on the very top sort of fixed there, what I could do is say data role header, data position equals fixed, refresh, and now it stays there. So if you have navigation buttons in there, the user will always see that. And you can also say data full screen equals true.

This is really only something you do if this is sort of one of those applications where someone's viewing pictures and they went to see everything. So if they click in the content area, the header just disappears. But if I click again inside of that content area, it drops down the navigation menu that I can get to.

So that's what data full screen will do. We'll just leave it with the default settings like this. And I want to add next a nav bar. But before I add the nav bar, why does it have that specific black coloring? Why does the content area have the coloring that it does?

When you download jQuery Mobile, it includes a CSS file that has a theme in it, the default jQuery Mobile theme. If you don't like the default colors and the default font styles, you can always go to jquerymobile.com and they have a theme roller that's an interactive graphical designer where you can tweak the colors and tweak the font styles and it will generate a new CSS file for you.

You can also take an existing CSS file if you've already customized something and you can upload it to jQuery Mobile, the theme roller, and it will load it up and allow you to tweak it. But by default, every theme comes with five color swatches. They're known as A, B, C, D, and E.

The header, by default, will always have a theme of A. The content area will always have a theme of C. But you can change any of those just by overriding the theme with another data dash attribute. So, for example, if I say the header, if I want the data theme to be a B instead of an A,

that should give me a blue color instead of a dark black color. Doesn't look that great, but that would be a different theme. And we'll explore some different themes throughout here, but I could say A, B, C, D, or E. And if you just want to tweak one little thing about those,

then they're all defined inside of the CSS file, of course, and pretty clearly documented and highlighted. So if I do a search, well, it's right here at the top, actually. That's the definition for swatch A. And it does a pretty good job separating concerns. So there's a section of this CSS file that is dedicated just to colors.

So swatch A colors. That's all color stuff and linear gradients and so forth. There's an entirely separate section that's dedicated to structure and layout. So what's the margins and the positioning and font sizes and things like that are componentized in another place in this file.

But you could always go in by hand and tweak things like that if you don't like any of these particular colors. So navbar is one of these components that can take and put usually from two to five buttons inside of the header. You can do more than five buttons,

but by default, I think it only allows you to put five in a row. And what you could do with this, with the navbar, is take those navigation links that we currently have that are spread out vertical and taking up a lot of space on the page and make them stretch across horizontally instead and have it appear inside of the header.

So let me just come in here and say data roll equals navbar. It's nice that it was already an unordered list. That's exactly what jQuery Mobile expects to make a navbar from. And that, just by adding that little bit of markup,

should give me this. Not quite what I wanted. Let me think about what I did here. And let me get rid of that theme. That's kind of ugly. And also, get rid of the admin link and the about link.

Let's see, data roll equals navbar, and it should just be horizontal. Interesting. I'm pretty sure that doesn't have to be in a container,

but just in case it does, we'll try it. Take that attribute out of there and put it in a div that contains that UL, but that doesn't make any sense at all that it would need that, but obviously I'm still jet-lagged or something. All right, that's our navbar.

So we can go home, store, cart. That looks a little bit better than what we had before. You can put icons inside of there. You can position things differently. I think we'll come back to icons a little bit later, though. The other thing you can do is a button. Oh, so by the way, any link that you put inside of the header,

I think I mentioned this already, jQuery Mobile will turn it into a button automatically. So if I say a href equals, give me something that goes to, oh, let's see. Earl.action actually is the one I wanted.

Go to the index method of the home controller. So it's basically a link to the home page. So a link in the header, not in the navbar, but just in the header itself. Save that. Refresh.

It appears here on the left. Automatically gets converted into a button. And I could say data dash icon and tell it to put a little home icon inside of there. You can look at the jQuery Mobile documentation and see the different icons that are available.

There's a home icon and there's a star icon. And it didn't like that one for some reason. See if I can get this to work though. Icon position equals no text,

which wasn't, oh, right, right, right. I'm putting this in the wrong place. Cut that out of there. I wanted that on this anchor tag, the one with the link to home. Try that again. All right, so it just becomes a little home button.

And that's because of data icon position is no text. Without that, I could position it left, right, top, bottom. So there it's on the right. But we'll just make that no text. Now the other anchor tags that appear in the page don't become a button. So like all these are just regular anchor tags,

but they don't appear as buttons because they're not in a header. But if I wanted those to be buttons, I could say data dash role equals button. Data dash many equals true. Just squeezes them down a little bit. Makes them a little bit smaller. You can put buttons sort of together in a control group. So if I have a number of data role equals buttons,

and I put them inside of a div that's a control group, it will style them so that they look like they're all together. Remove the padding and the spacing in between them. Give the ones on the edges rounded corners so it can look a bit like a toolbar. So list view. Let's go back and look at our application once

and see that on this home page that we're at, we can select from 10, or sorry, on the store page, we can select from these 10 categories of music. But it doesn't look so nice as just an unordered list there. If I apply data role equals list view to this, it will look a little bit better.

So let me just find that view, which is a different view now. We're making all these changes and not changing any controllers, just changing views so far. We've only changed the layout view so far. But this one is the store. I believe it's the genre menu that we have right here.

This is used as a partial view. But again, this is a case where I can say copy this and paste it and rename it to have .mobile in the name. And I'll open up that version and say

data role equals list view. And just save that and see how this turns out. Oops, interesting. Amazing. Genre menu .mobile.cshtml, so that was right.

So the question is, does that need to go in a surrounding div again? We'll try it. I swear I've done these things just directly on UL elements before, but control K, control D to do some formatting,

which it didn't want to do automatically because I missed, not sure what I did there. Control K, control D, all right. Try that again. Oh my, no list view for me. Now I'm pretty sure that goes on the UL. So let me move this back real quick.

Data dash role equals list view. Yeah, I shouldn't have to build it when I just save a view. Those get parsed dynamically. Just starting to wonder if it's picking up the right view

or if I modified the right view. Go to store. And I bet I didn't modify the right view. That has to be what happened here. This URL is the store index view, actually.

I'm betting I should have modified this view instead. Yep, sorry about that. We'll copy that view and paste it in as index.mobile.cshtml.

And this is a UL. I should just be able to say data role equals list view. Save everything after I fix that and refresh. Phew, list view.

Which, you know, a lot of things jQuery mode will become a list. It takes a lot of things and just makes them take up vertical space in a way and take up the width of the screen, give the user the ability to swipe up and down through these things, click on things, and everything still navigates to the right place.

It just enhances them a little bit. Giving them a little icon, which you can position and customize. You can nest list view, so you can have a list view inside of a list view. Do all sorts of interesting things with it. So that's a little bit better. Oh, down here, built with ASP.nvc4. We could turn that into a footer,

but just to make it look like the header, too, with that black background. That would be just a data dash role equals footer. But I'll skip that for right now, to make sure we get through everything today. And also point out that there's a collapsible. So collapsible's a bit more like an accordion, whereas the list view's just a list of things.

You click one, navigate somewhere. Collapsible's really about taking some information and rendering it in a way that it saves a lot of space until the user clicks on it to interact with it, and then it pops open. For example, if we look at how it's currently rendering, let's say, the rock albums, that's kind of ugly and not formatted well.

So for that one, what I'm gonna do is go into the store browse and fix that. And actually, we could do it here on the home index view. Let me do it there. Home index view is just trying to show the promoted albums in the store.

But on a mobile device, it doesn't look too well. So we'll make that into a collapsible. Home index view, take that one, copy it, paste it, change it into index.mobile.cshtml, very good.

And this one we might have to change up a little bit more. So the collapsible does expect to be on a div, and it expects an h3 and then some sort of other content inside of it. So we just have to make sure that when we build a collapsible, we're not gonna build a list item anymore,

an unordered list. Let me just change that into a div. What we need to build is a div with a data role of collapsible. Make sure that it has some sort of header inside of it, and that can have the album.title. And then the rest of this,

we could surround it with a div, and it should become the details for this collapsible. So control K, control D, and this might be a little bit better. Save everything, build it, refresh the application, and this will be hopefully collapsible, yes.

So now that is nested in there, and we could do some additional work on this to make things pretty inside of there, the way that's lined up. Just wanna point out how that collapsible works. Oh, so the other thing, right now,

these are sort of independent collapsibles. Each of them has a rounded corner. They look like they stand off from each other a little bit. I can also go to this div and say, your data role is to be a collapsible set, which hopefully is the magic word. And then they don't have that padding

and space in between them anymore, and just the top one has two rounded corners, and the bottom one has two rounded corners, so it looks like they're grouped together a little bit more. There's also a grid system. If you've used grids from like 960 GS

or anything like that, it's not nearly as fancy, but there's a way to lay out things with two, three, four, and five columns. That's UI grid A, B, C, and D. Little bit confusing. So this would be a three column grid with a left piece, a centerpiece, and a right piece, and it's all done through CSS,

just classes that are defined by jQuery Mobile. Form elements. jQuery Mobile will automatically go through any type of input, radio buttons, check boxes, input type equals button, and enhance them, make them look a little bit differently. Take things like check boxes

and make sure that they're easy for someone to click on by extending them across the screen. The clickable area, so I just have to be able to put my finger on any of the space here to select Cheetos. In fact, if we look at the sign in page here,

let me go to, oh, go to check out where I log on. So the rounded corners and the log on button and the big remember me check box, that was just automatic. Didn't have to do anything to that to get that to work.

All right, a little more about scripting. So first of all, the biggest thing you have to decide is if you want this Ajax navigation to take place, and that is when I click on a link, it makes an Ajax request, pulls down the content, parses out a page, and graphs it into the DOM. For a lot of applications that just,

existing applications, that just creates a lot of problems because you have to make sure all the DOM IDs are unique and make sure everything's cleaned up and make sure no one's using document.ready anymore, unfortunately. If you just want to turn that off and just kill that and not have jQuery Mobile do that at all,

then what you can do is bind to a mobile init event and there's all sorts of options that you can set on that. I have a link here to bring that up, interesting, in the jQuery Mobile website, which I didn't want to load. Let me see if I can bring it up over here.

Bad link. If you go to Docs, under API, Configuring Defaults, a whole list of things that you can do. Ajax enabled is the one I want to set, but things like the default page transition. The default is to fade. You could set that for all your page transitions

by catching the mobile init event. So the one catch to this is that you have to do it before the jQuery Mobile script gets loaded. So if I want to turn Ajax enabled equals false one, I'd have to go into my layout page, mobile page,

and up here at the top, just before jQuery Mobile gets included, let me create a script that will go to the document and bind mobile init to a function

that will do mobile.ajaxenabled equals false. So that has to be there, because as soon as the jQuery Mobile script loads, it fires that event, and that's when it assumes that all the defaults are now in place. So by having that wired up before we load the script,

that should work. And so what will happen now, we might not notice too much of a difference as a user just because the site is local and performing pretty well, but it's now a full browser refresh when I'm clicking on things.

So the browser is actually navigating somewhere and pulling down all the HTML and putting it back into the page. So at that point, the only reason I'm using jQuery Mobile is just for a few of those widgets, the header and the collapsibles and the list views and the themes and things like that, because the Ajax navigation features,

sometimes what people really want jQuery Mobile for, they want to build a single page application without all of the work that goes into that. They don't want the browser to do that hard refresh and blank out and redraw the screen so it looks a little more like a native application, but it does cause problems, causes a lot of problems.

That's how you turn it off. I'm gonna comment that out so we can try some other things with script. Events, how many people worked in ASP.NET web forms? Yes. So you remember page load and page init and page pre-init and by now they probably have a page pre-pre-init.

Well, this is even better. These are all the page events that get fired that jQuery Mobile will raise if you want to get involved in the client-side page lifecycle. Out of all of these, the most important one, the one to worry about is page init, because for jQuery Mobile, page init is the thing that really replaces document.ready.

Page init is the event that jQuery Mobile will fire after it has gotten hold of a page, grafted it into the DOM, and also after it has gone through that page and it's enhanced all of the data dash role stuff that it finds inside of there. So it goes through that markup and finds the list views and things like that

and enhances them. Then it raises the page init event for you and that's the point where you can go in and do any work that you might need to do to add things into the page. But you can also find when a page is created, so that's when it's put into the DOM, but before it inits with all of the jQuery Mobile stuff or when it's being shown or removed or hidden

or when it fails to load. You can catch that event too. But with page init, you can do things like find out when a page loads. Let me do this quick example before we look at that bit of code right there. Before in the mobile view,

I had a script that tried to catch document dot ready and do some interesting things. Now let me do this the jQuery way and say give me, bind me to the page init event and give me a function. And again, for right now, what we will do is just raise an alert.

Take that out in a little bit. But for right now, I just want something to pop up on the screen real quick and easy. So with that in place and everything saved, come over here to the browser and go back home. There you can see we got a page init event. Go to store, got a page init event.

Go to home, no page init event, right? Because that page and the first page that you go to in a jQuery Mobile application only ever initializes once, which for the most part is okay

because it stays in the DOM forever. In other words, if we opened up Object Explorer again, this page with the data URL of slash, the original home page that we went to, it stays in the DOM forever. I can click all over the other place, all of our other places inside of here. Go to store, cart, store, cart, they keep init-ing.

But when I come home, it never init again because it never takes that original page out of the DOM, just something else to be aware of. Everything else like store, click on store, right there it got loaded, you can see it here. But then go to cart, cart got put into the DOM,

right here, store got taken out, so when I click on store again, it'll init itself. And so where is this an issue? For the most part, this isn't an issue because what you typically do in a page init event is you go out and you find something that's inside of your page

and you tell it to manipulate its CSS or whatever. And it stays in the DOM, so whatever you do to that widget or that piece of HTML stays there forever. The only time this is an issue is when people expect that if I click on home that all the latest prices or all the latest stock quotes

or things like that would get fed into that page. That's where you might want to look at some of these other events like page show. I want to know when my page is put onto the screen so I can go out and maybe make a JSON call and update any data that's on it.

So the other thing to be careful of with the code that I just wrote is this is binding page init for everything, for all pages. And that's, again, typically not what you want to do. I just did this as an example to see that page init doesn't keep firing for the original URL I go to.

Yes. Typically what you want to do is manipulate a specific page and tell it to do something, get into some widget that's inside of there. And the question is how can I do that? The first problem I have in an MVC application typically is that my layout view is the one

that defines the div with the page. So it's not like I could just say ID equals storefront or something here. Then it would be setting the same ID for all my pages. That doesn't help. The thing is when I render this list

of music categories, perhaps I want to do something specific when that page loads. I've gone around and around on this on a couple different projects. Now I'll tell you this isn't the prettiest thing, but this is the easiest thing that I've found to do. Essentially, put something into the model

or into the view bag from this view that says here's my page ID. We'll call it storefront. Put that into the view bag. In the layout view, when it renders this div with a data role page, it can say ID equals at view bag dot page ID.

Let me just make sure I spelled that the same. Page ID, page ID. Oh yes, thank you. Observation was that this is not the mobile index.

That's the regular index. I went to put that in index dot mobile. Thanks. So that page ID will bubble down into the layout view, which will put that ID here. And now I can write a script that goes out and selects the page that represents that storefront

and do something interesting with it. So the way that that would not work is to try to put that outside of the page somewhere. Typically what we end up doing in jQuery mobile applications is have all of the scripts that all of the different pages need

just loaded right up front. Perhaps right from this layout view. So this could be an external script reference that I'm about to do. But, oh, and let me come up here. What I can do here is I can go out and say storefront. Except this still has a bit of a bug

because it's never actually going to find storefront when this first loads. That view is not the one that's there. That's not there until I click store. And let me get rid of the page in and stuff too. Which I should have if this refreshed properly.

Go to the home page. Go to the store, okay. The solution to that is if you're using jQuery before 1.7, use live instead of bind. In jQuery after 1.7 you can use a method called on

to wire up the event. But that's essentially going to be able to catch page init event from this element from now or any time in the future. If it gets loaded in sometime later. Just to test it. Let's say alert, storefront loaded.

Try it real quick. Let me do a hard refresh. Come to the store, storefront loaded. Good, all right. So now I could do something specific in here. And just a real quick demo. What I could do is I could say this thing that just raised the event which would be the storefront.

Let me bind to swipe left. Which is an event that jQuery mobile provides. It detects when the mouse goes down and how many pixels it moved and how much time elapsed and it'll raise that event for you. Call a function that goes out and does something interesting. What could we do? We could actually add something

to this list we're creating. So if I gave this an ID of genre list then what I could do is I could go out and say hmm, find the genre list. This will demonstrate another little problem

with jQuery mobile. Find the genre list and append to it a new list item that says swiped left and see if that works. Why do I keep thinking I missed something here?

Select genre list and append that HTML. Hmm, we'll find out. We'll run it real quick. Refresh this. Keep going. Seems to want to hit a break point there.

So let me close that. Swipe left, swipe left. I think it put something down there. Swipe left. It only picked up one event there for some reason. But the observation there is that hey, I added a list item to a list view

and it didn't get styled correctly. This is just something else that you learn to deal with with jQuery mobile. If you're dynamically creating HTML you have to do one of two things. If you dynamically put something in the DOM you either have to invoke the create method on that block of HTML. If you want jQuery mobile to go in and enhance it from scratch

or you need to go in and call a refresh method to say hey, you've already created a list view in this case but I've changed it. I've added some things to it. I need you to go in and refresh it. So what I'm trying to do here is demonstrate the swipe left event and how things don't quite work when you dynamically add things.

But that would be simulating the user swipes and you make a JSON call and get some data back and you draft it into the DOM and it doesn't look right. So really what we have to do here and actually the genre list is the list view. So after I do a dot append I could just do a dot list view. So everything I did with data dash role you can do programmatically too if you want.

Walk up to an element and do dot list view on it. Turn it into a list view. And this is quirky but if you've done any work with jQuery UI that will look familiar. That's a method on a widget and the way you invoke a method on the widget is to call the list view that constructor function

and pass in the method that you want to call as a string. So that's telling the list view to refresh itself. So now if I save everything and we come back to this application then Chrome has decided it's not mobile anymore. We will tell it to be an Android again and refresh.

And now if I carefully swipe a few times now it's doing a better job picking them up I can see. Then that worked. Now I should have put an anchor tag in there and that would have gotten the icon on the right and made things look a little bit better. But those are some of the things to think about.

To be aware of that I've hopefully demonstrated to you. Demonstrated swipe left, swipe right. Demonstrated interacting with the widget programmatically. And that's the presentation. What we did was we went into an existing MVC application. We modified it so it worked a little bit better

with a mobile device using jQuery mobile. It was easy using jQuery mobile in this scenario but I've certainly run into situations where we just couldn't use it. There was other, too much legacy JavaScript that we already had and too many decisions about the way, what views should have in them that it just couldn't fit in very well.

But hope you found that useful. If you have any questions feel free to email me and also be hanging around if you have any questions too. So thanks for coming.