 So this talk is about mobiles and how do you make good experiences on mobiles and how you can use JavaScript in that. A little bit about me first. My name is Shwetank. I work as a web evangelist for Opera. We're very, very big on mobiles and other devices and we, you know, we have a bunch of experience on that. I'm also part of the W3C, working on two groups. One is called Mobile Web for Social Development and the other is called Web Education Community Group. You can sit over here if you want. If any of you are on Twitter, this is my Twitter, just my first name, Shwetank, and my email, in case you have any questions later on, yes. How many people have seen the show The Wire, the HBO show Wire, right? Four people, damn it. You should all download it, oh, not buy it, as soon as possible because, according to me, it's the greatest show on earth and there's also like a Harvard course on The Wire, so like, anyways, I'm going off on a tangent. But it's basically about, you know, a bunch of cops chasing a bunch of drug dealers. It's a little bit more complicated than that. But the thing in that show is, especially in the first season, what happens is they collect a whole lot of data about each and everything that the criminals talk on the phone, like even the most mundane things, and they're somehow connected together to form this huge, very compelling case against them in court. And I think that's the best metaphor for what we're trying to do over here in the sense that all the pieces matter. That's one of the lines of Lester Freeman, one of the detectives over there, all the pieces matter. So we can't look at one thing in isolation. When it comes to JavaScript, you know, so far, the talks have been great, but they've all been pretty much, you know, in isolation, looking at JavaScript, you know, in a particular context. But when it comes to JavaScript in the real world, we have to use it with HTML, right? So we have to use it with that. So all the pieces matter. It's not just JavaScript to make a really, really great application. You have to use JavaScript, but you have to use it with a number of technologies. So we, in this presentation, we'll see how to use JavaScript together with all these new technologies that we have in HTML5, right, especially on mobiles. So we're going to talk mainly about what kind of browsers are we talking about. We're talking about smartphone browsers, right, talking about Opera Mobile, or we're talking about, you know, the WebKit browsers that you have on Android or something, right? But first, pair of thought on, you know, what the majority of the Web on mobile actually surf on. They don't surf on, you know, very full-featured smartphones, you know, they surf on very low-end feature phones and use stuff like Opera Mobile, Opera Mini, right, which is used by about 100 million people, more than 100 million people every month, right, worldwide. So if you're making, you know, a mobile site, then you have to keep in mind those people as well, you know. But this is about the future, so we will focus on that. We will focus on smartphone browsers like Opera Mobile and, you know, all the WebKit browsers. So I want to ask you a question. What's the most important thing to know about the mobile web? Screen size? Bandwidth? Okay. Voice? Okay. You know, to me, what's the most important thing to know about the mobile web is that there is no mobile web. What do I mean by that? What do I mean by the fact that there is no mobile web? Well, you know, people, I don't know how many people are old enough, you know. I look very, very young, but I'm not that young. I remember the days of WAP and WML. How many people remember WML? Ah, so you're old as me. So, you know, they try to make a different version of the web, you know, not in HTML, but in a certain other language called WML, it sucked, basically. That's all you need to know. And people also pretty much said the same thing. We suck. They suck, you know, but WML will not actually be anything useful. So they went back to the drawing board and said, hmm, there's an idea called HTML. Maybe we should try that. And that's what they did, you know, that's what they ended up using. So ultimately, they wanted to create a different version of the web for mobiles. That didn't work. And they used the same thing that they always, you know, should have used, which was HTML. So ultimately, we have one web. It's not just, it's not a separate version of the web, it's just one web. It's very, very important to know this, you know, keep this in mind. The second most important thing to know about the mobile web is that it's not about mobiles. That is, it's not about just cell phones, you know. It's about cell phones like these. You have, I don't know how many people can see this in the back, but it's basically a cell phone. But it's also about tablets, you know. It can also be about, especially in the coming future, it will be about TVs, you know. The web is about devices in general. And just like you have the desktop as a device, you'll have tablets, you'll have TVs, you'll have gaming consoles, you know, you'll have even flight entertainment systems. And in the future, using a browser. So the web is more than just, you know, PCs and mobiles. It's much more than that. And it's just one web. Keep that in mind. I just had to mention this because I'm from Opera. Smartphone browser is not equal to WebKit. You know, people when they think about smartphone browsers, they always think about WebKit. Opera mobile is pretty big and it's as good as pretty much anything. So, and furthermore, which WebKit are you talking about? How many people have heard of PPK? If you're doing mobile web development, you have to follow this guy's blog. He's called PPK, basically Peter Boulkos. And he's from the Netherlands. And he has a very nice article on, titled, There is no WebKit on mobile. And what he actually meant was, you know, he compared the native Android browser on a number of devices and he found, and he ran a bunch of tests and he found out that none of them behave exactly 100% the same. You know, each and every, you know, browser had a certain branch of WebKit and none of them were exactly 100% the same. So don't assume that just because you have, or just because you've tested, you know, your website on one particular WebKit browser, it'll, you know, display and function on all WebKit browsers the same way. It's not necessarily true, right? So keep that in mind as well. And it's okay if the site looks different in different devices. It's okay, right? If you make a separate mobile site, it's okay. However, if you do that, you always have to provide a link to switch back to the desktop version. Because we in Opera have, you know, got this feedback a whole lot. What happens is people make m.something.com and if they think that, okay, this guy, this user is from a mobile browser, they just automatically redirect that person to m.something.com. And they don't provide a link to switch back. The user wants to visit something.com, the desktop version. But he is always forced to use m.something.com on his mobile, which sucks as a user experience, right? So do not ever do that. If you do, always provide a link to switch back to the desktop version. It's also in a bunch of guidelines. How many people are familiar with this meme? So I just made this, you know, I don't always make a mobile site, but when I do, I make sure that users can switch back to the desktop version. That's a better strategy, actually. If you do something like responsive design, and I'll come back to that, right? But if you want to make a separate mobile site, go ahead. So yeah, this thing that I talked about was in this set of best practices. If you haven't looked at it, please look at it. It's called W3C Mobile Web Best Practices Guidelines. RTFG, do that. How am I doing on time? I think I'm OK. So one of the things that the guidelines also talked about was offline web apps. And this is where I'm going to explain how to do it, and then what role does JavaScript play in it. So offline web apps, storing files to run offline. So whenever you're trying to make something a web application run offline, they're basically two aspects to it. One is loading the files in an offline environment. The actual HTML, CSS, image files, all that kind of stuff. And the second part is loading the data that you need to run offline. So right now, we're going to focus on loading the files. How many people are familiar with application cache? So few. So just for everyone else, application cache is a special kind of cache in modern browsers. And you can programmatically set that cache for different web applications. So it's not like a normal browser cache. It's a special cache. And how do you set that cache? There's a file, just a text file, and that you rename it to something not manifest. In that text file, you say that I want these files to be stored in that cache. So in this case, and the first line has to be cache manifest, by the way. So what you say is I want style.css, script.js, and index.htm, for example, stored in that cache. Now, how do you link that page to this cache? In the HTML, you do HTMLManifest is equal to that thing.manifest. One more important thing to note is that manifest file has to be sent with a certain MIME type. So it's cache-manifest. So you have to do that. I'll go back to this. So what happens is sometimes you want to fall back for something. For example, if the image isn't loaded perfectly, it hasn't loaded completely, then instead of showing just a blank space, have a certain fallback or default image to be shown. You can do that using application cache. So using the fallback section header, you can just say, if original.jpg isn't loaded, in that case, load backup.jpg in its place. So you can do that kind of stuff with application cache. It's pretty nice. Now, generally speaking, people who are familiar with application cache are familiar with all these things. But the problem is, how do you update the cache? So whenever you have a manifest file and you store it on the server, it has a bunch of files that you say that, OK, it needs to be cached. And then you make some other changes. Let's call that manifest file version 2. So what happens? You need to make sure that the cache, as defined by the version 2 of the manifest file, is now used by the browser. How do you do that? That's where JavaScript comes in. That's where certain functions and events come in. So what you do, in this case, what I've done is, I do a set interval and run this every one hour, this function. And what is it? It's called window.applicationcache.update. The primary purpose of update is to just check the server and see if there's a new version of the manifest file available. And if it is, then download that new version. It's still not being used. It's just downloaded it. Once it's downloaded, there's an event which is fired. It's called update ready, which means, basically, oh, I've downloaded a new version of the manifest. I have a new application cache. What do I do with it? So that's the basic fund of update ready. Once that happens, then you can finally swap out the old version and swap in the new version. And you do applicationcache.swapcache. You'll be surprised how many people know about application cache, but when I talk about these things, they generally do not. So I would say, just note these three functions down. And there's also a tutorial that I've written pretty in-depth on dev.opta.com. You can go there and take a look as well in detail. So update is basically just firing and a request to the server saying, if there's a new manifest file, I'll download a new cache based on that. Whenever you hit refresh, it does the same thing as update, actually. So this was about storing the files needed for offline use. You store all the files needed for that. But what about the data? Any questions so far? It will download it, but it will not use it explicitly until you call it. Whenever you go online once again, you'll say that, OK, oh, there's a new version now. Let me download them. But it will not swap in. You will still be using the old version unless you call swapcache, right? So now we come to web storage. So how many people attended PersuRAM's talk on IndexedDB? Quite a lot, right? So you know about storing of data on a browser level and how you can use IndexedDB. But I'm going to focus more on web storage. The problem is you have cookies, they're unreliable. There's no programmatic APIs really to access that. And it's not structured at all. And most of all, the file size, what's the max file size of our cookie that you can store data in? Can I have a price for that? 32K? No. Yeah. So it's 4KB in one or two browsers, but generally it's actually 2KB, right? So it's very, very small. So we needed to come up with a solution which is better than that. So we came up with something called web storage. It has two variants. One is called session storage, and one is called local storage. How many people have heard of local storage? Quite a lot. Good. So you're familiar with this, then? How to do setItem and getItem, right? Pretty standard, pretty nice. But what people generally ask me is, we've done this. But how do we sync it back to the server? How do we use it in a practical use case? So one of the things you can do, one of the things you shouldn't do actually is this. You can actually store images with local storage. How? Does anyone know? Yeah, so you can just convert it into a data URI and just store that string, but don't. Do not ever do that, otherwise I'll spank you. But the reason why you shouldn't is because it's just a hack. You should probably use application cache to store all the files needed. So if you're doing that using local storage, there's something really, really weird, or some kind of edge case, or you're just plain wrong. So one of the things that's pretty cool is automatically save entered form data. So how many people have encountered this situation? You're writing a really, really long blog post about something and the browser crashes, right? Or you're writing a really important email and then the browser crashes. And then you have to start it again. It's like, what the? So you have, this is a solution to that. So what you can do is something like this. If there's a text area like this, call save message every half a second or second or whatever, right? In which what you do is take whatever has been written in that form area till that time and save it to local storage, right? So even if the browser crashes, right? The next time it opens up, you will still get it, you'll still retain that kind of information which was there till the last time it was saved, right? Yeah, so for that you have to use session storage then, right? So that's probably a different use case. That's not probably the best way. I mean, Discuss Uses is, by the way, how many people are familiar with Discuss? Discuss is a commenting system on various blogs. So it uses this, you know, it doesn't do it every second or something, it uses, it does it every few keystrokes or something, you know, it saves it to local storage. So you can probably do this. There's certain gotchas, certain things to keep in mind when it comes to local storage. Two tabs updating the same value, you know? If you have a tab, you know, which is storing local storage data, and then you have a clone of that tab or some other tab which is trying to, once again, store the same kind of data, right? Then there's a mismatch, you know? To give you an example, let me open up. If you can actually wrap your mind around the crazy number of tabs that I have, just look over there on the bottom. It says, change from this to this, right? How did I do this by using something called? Storage events, right? How many people are aware of storage events? One, wow. So it's very, very simple. So whenever something like this has been done, you know, whenever something, whenever local storage, you're using local storage and some other page has updated the same value, then storage event is fired. And when that happens, you can simply do event.allStorage to get the old value and event.newStorage to get the new value. So I use basically this to say, this has changed from the old value to the new value, right? So storage events is something that pretty much no one knows about but should, right? And please, please note that down. Yes, I actually did this demo on session storage. So you can do that. Once again, I've written an article on.oper.com, explaining all of this, so go check it out. One more thing is if you're using local storage or session storage, don't do it on a free hosting service in which they provide a different directory for each and every user. For example, if you have freehosting.com slash user one for your account and freehosting.com slash user two for the other account, you know, they're using the same domain, right? So they can theoretically access your data. So try not to use local storage or session storage on free hosting accounts which provide like a different directory, right? If it's a sub directory or sorry, subdomain then it's fine, right? Yeah, shared hosting, so yeah. So if it's like abc.something.com and bqr.something.com, those are both different origins, right, those are treated as different origins. So that's fine. But you know, freehosting.com slash user one and freehosting.com slash user two, that's treated as the same origin, right? So they can access your data, don't do that. There are other storage options, you know, as been mentioned, you have index DB, you have web SQL. You know, people have been bashing web SQL a whole lot, but I think if you're just concerned with making, you know, a site which is specifically targeted just for mobiles, then I think it's okay to use web SQL. The reason is because browser support is there when it comes to most, pretty much any webkit-based browser as well as Opera Mobile. And that covers a whole lot of mobile browsers, smartphones, right? So if you're just concerned with only and only smartphone browsers, then web SQL is an okay option to consider, right? One more thing, this has nothing to do with JavaScript, by the way, I'm just, yeah. Cookies do still have their place. You can't, you know, this is not a complete 100% replacement for cookies. You know, it is just for storing small amounts of data here and there, right? But cookies have more uses than just that, right? So it's not 100% complete replacement for cookies. You can programmatically do it, but there's no, I think it's clear. I think if I'm right, there's local storage.clear, but I'm not sure about that, I'll have to check. Yeah, you can also manually, if you want, you can clear local storage using your own browser. The user can do it manually. By default, the local storage space is 5MB. So, and if you go beyond 5MB, then the browser is supposed to ask the user, do you want to allow more storage space? So now we come to media queries. How many people have heard of that? Responsive design, yes? Good. So, media queries is all about this. So if, when it comes to mobiles, you have different devices with different resolutions how do you make sure that you have just one CSS file or just one, you know, set of rules and have it adjust to different resolutions? So what you can do is use something called media queries. Like over here, what you do is you say, at PDOL and MinWidth 48TPX, MaxWidth 800PX. So all of these styles are gonna be applied to only those devices whose MinWidth is between 48TPX and 800PX, right? And all those devices whose MaxWidth is less than 48TPX, you know, the second set of rules will be applied, right? So you can search on, you know, media queries and how you can use them pretty, pretty nicely. There's a site called media queries with a dot before the ES, just mediaquery.es, right? So that's a very, very good showcase site of how many sites in the wild are using media queries. If you go to my.oper.com, it's also using media queries. I think the Boston Globe also redesigned their site, which is a very, very nice site, which is using media queries. So go ahead and look on that. I'm not gonna focus too much on this because it's not related to JavaScript. I just wanted to mention it. How many people have known of Viewport? So about 10% people. So Viewport is something also very, very interesting. So if you're familiar with media queries, then you should also probably know about Viewport. There's a meta tag called the Viewport meta tag. So generally what happens is, if you go to a page using your mobile browser, it provides like a zoomed out view of the page like this, and then you tap in or do something and it focuses on that particular part of the page, right? So that's what happens, but if you're making a web application, and you don't want that behavior, you want the user to automatically just have a zoomed in version of that particular page. You don't want him to tap and then have a zoomed in. So what you can do is set the amount of scaling by default, and that's what the Viewport is useful for. So you can do something like this. You can have like meta name is equal to Viewport, content is equal to width is equal to 320. So it will have like a 320px Viewport, and if the device size is more than 320, then it will zoom out to fit 320, right? The best thing to do actually is do something like Viewport, content width is equal to device width, right? So it will automatically judge the device width and set the width of the Viewport to that exact level, right? This is very, very useful, but you can also do something more. You can have scaling constraints. So you can do maximum scale to minimum scale 0.5, so you can make sure that the person can only scroll like maximum of 2x and scroll out maximum of 0.5x. So that's very, very good. Also what you can do is you can disable user scrolling. So in games, this might be useful, right? So you can do, you know, user scalable is equal to no, right? Once again, this has nothing to do with JavaScript. I'm just mentioning it. In Opera, we've also implemented it using CSS because according to me, and Opera in general, you know, this actually belongs more in CSS rather than having a meta tag, right? It's more of a presentation feature. So you can do that using, in Opera, using the AtViewPort feature as well. The exact same thing. A geolocation. How many people know about geolocation? How many people know how it works? Okay, so this was, I'm not gonna spend too much time on geolocation, by the way. So the early web was, you know, how this is my page in HTML, look at it, you know, this is my, these are my thoughts in a well-published format. And then you had like this, but this was, you know, about here we can do stuff together and Wikipedia is the best example of that, you know? And then the next step was, hey, this is what I'm thinking, you know? And this was Facebook and Twitter and all that kind of stuff. I think the next step is, hey, this is where I'm at, you know? And provide me goods and services in relation to where I'm at. And this is where I think geolocation is pretty nice. So you can have like augmented reality, geocaching, location aware, advertising and all that kind of stuff. One thing, you know, to know is if you're doing geolocation, then first of all, you know, feature detect, right? Don't do browser sniffing. I see so many people who are doing browser sniffing for geolocation. They say that, okay, these, these browsers support geolocation, so I'll only have code for that. Don't do that. Instead, do something like this. Navigator.geolocation, if it's available, then have, you know, look geolocation.getcurrentPosition. One more thing is, though, that I've seen some people do call getcurrentPosition and have a set interval for that. You know, instead of that, you can probably use watchPosition, right? So watchPosition, how many people know about watchPosition? No? Okay, so it's exactly like getcurrentPosition. The only difference is, it keeps calling it every time it detects a change in location, right? So every time you move, watchPosition will be called, right? So that's the only difference. GetcurrentPosition is just one short thing. It's just called once, but this will be called every time you move, or every time it detects a move. So, and one more thing is, you know, dealing with errors, you know? So if positionError is equal to one, you know? That means that the user explicitly has said, no, I don't want to share my location, right? Whereas if it's two, for example, then it's, for some reason, hasn't been able to load it. And accuracy, you know? Geolocation is scarily accurate in some places, and retardedly, you know, really amusingly accurate in some other places, right? For example, in Bangalore, it's actually pretty accurate, generally speaking. But in, from where I come from, Chandigarh, you know, it's like laughable. It's like, I'm not here, I've never been there, you know, it's like that. So don't rely on that. Don't rely on geolocation as, you know, in production. Always have a fallback. Always have a way to, for the user to enter the location data, right? Either as a pin code or something else. You know, always provide them a way to choose, you know, what their location is. Don't always 100% rely on geolocation because it's not always accurate. When it is, sometimes it's very, very accurate. You know? It depends on how well-mapped the city is. One more thing, the geolocation spec, you know, it's been quite a while since this has been published, but the new version, people are coming together once again to discuss a new version of the geolocation spec. So there may be some changes here and there, just as a heads up I'm saying. See, yeah, time for a sneak peek. So I'll be talking about, where is it? There's not a gun, don't mind. Is this, it's called device orientation. Let me open up a lab's build of Opera Mobile. Even if it's in, you know, the texture is murdered, doesn't matter. So just play along. Position of this, the background color keeps changing. How did I do this? I'm just moving this around. So there's a new spec called the device orientation spec, right? Which gives you access to stuff like the gyroscope and the accelerometer and stuff like that. And we in Opera have implemented this in a lab's build, where it's gonna come soon in production as well. So this is just a lab's build, by the way. But if I shake it, so this is using the accelerometer, so I said that, okay, I detect the acceleration and if it's after a certain threshold and I clear the form, right? So you can, yeah, it will. So you have to use this with gear, right? The thing is, you shouldn't use this while driving anyways. So this is how you use it, you know? Just have an event listener for device orientation. For the browsers which support device orientation, you know, you'll be able to get, you know, using the event alpha, event beta, event gamma, you can get the alpha, beta, gamma, position coordinates of the device, right? And then you can do whatever the hell you want to do with it. In this case, I set the RGB values going to the alpha, beta, and gamma values, right? So every time I moved it, this event was fired and it set the RGB value of the background color to that. That's why the background color was changing every time I was moving it, right? One more thing is access to the accelerometer, right? So you can do that using the device motion event, right? And then you can get the acceleration in x, y, and z coordinates, you know, and a bunch of other stuff as well. So just keep this in mind, you know, the W3C device orientation spec. Just search it, you know, it's interesting to know. Another sneak peek that I wanted to, I hope this works by the way. It's a very, it's a lab's build, so it crashes all the time. But so this is basically inside a webpage, you know, inside a browser you now have access to the camera, right? So this is pretty cool. This is something that I really, really like. And you can actually even take pictures, you know, say hi, and once again, if I shake it, it's gone. So I used, you know, device motion for that. So you can do some pretty cool stuff, you know, once you integrate, you know, as I did, you know, HTML video, it uses video tag, it uses camera access, it uses device orientation, it uses web fonts, and a bunch of other stuff. I didn't have enough time, otherwise I would have talked about mouse yesterday as well, you know, multi-touch and all that kind of stuff. You can do that, by the way. Yeah, so these, I mean, yeah, there's a whole different presentation in itself. If I try to talk about things on browser to browser, we in Opera support WebM, we support OGG, right? We don't support H264, right? There are certain other browsers which support H264, but they don't support WebM, like, you know, Safari or something, right? Chrome, I think, supports all or something, but in general I think WebM will win. Ultimately everyone will have to support WebM. I don't see any other way. Yes? Yeah? Not right now, but soon, soon. This is a labs version. It's not even a beta, it's not even an alpha, it's like a labs experimental version that we have. So it's not gonna come in any mobile browser soon, but it is there, we have worked on it and everything. One of the main reasons why it's still in a labs build and not in a beta or something, is because the spec is very, very new and it's being changed quite a lot. Even when we implemented this, the spec changed and then we had to re-implement this, right? Yes, what we basically, right? So there is a spec, there is a W3D spec called the WebRTC real-time communication. So it specifies, you know, camera access, mic access, and a few other things that I'm forgetting right now. So, and peer-to-peer communication and that kind of stuff. So right now we've implemented just camera. So yeah, how do you do this? You do something called navigator.getUserMedia. If it is supported, then it probably has camera access, right? So the first thing to check is navigator.getUserMedia. If there is, then you check for no video. If it is there, then a success function is called, otherwise an error function is called, right? So let's see the success function. You, by the way, select the video element. Then what you do is, in the success function, there's a stream element, a media stream element, which is basically just access to the camera stream. So what you do in the success function is, just associate that camera stream with the HTML5 video element that you have. That's it, right? And then what you do is, once you have the camera stream as part of the video, then you can use draw image to put it on canvas. And once you have the camera access on canvas, then you can go crazy, that's shit insane. You can, you know, do all kinds of stuff. So this is how you put it on canvas, you know? You just do CTX to draw image video element, now 00 till canvas within canvas height. This time, and it's my presentation's time as well. So keep in mind, WebRTC spec, you know, the stuff which defines all this, is very much in flux, it's still not ready yet, but we are working on it. Browser makers are continually making progress. Read up on dev.opera.com, these are all, all my articles and a bunch of other very, very nice articles are there. And if you have more questions, you can contact me on Twitter or on email on swethangry.opera.com. And with that, I say thank you.