meier: so good afternoon,everyone. thanks for coming along. it's impressive to seea packed room, considering the quality of someof the other sessions on, but, uh, thanksfor coming along. my name's reto meier. i'm a developer advocatefor android. this is michael mahemoff. he's a developer advocateon the chrome team.
today we're gonna have, uh,a bit of a lighthearted debate, looking at some ofthe comparative differences or advantages of developingfor mobile, uh, usingeither native libraries or, uh, web tools. so before we get started, um, it would be good for usto have an idea of the audience, see where we stand, see which of us needs to be,um, more convincing.
so with a show of hands,how many of you are doing web-basedmobile development? ooh, i could be in trouble here.mahemoff: pretty good. pretty good.and the android track? nice. meier: and, uh, and how many ofyou are, uh, android developers? outstanding. mahemoff: i think you'reon safe ground, too. meier: yeah, i like this.i like this. all right, so we're both gonnahave to be really convincing.
that--that works.that works pretty well. so, uh, to get started,i'm gonna introduce, uh, or let michael take us offwith some mobile tips for web development.mahemoff: excellent. so yes, uh, i'm making the casefor html5. and of course,when i talk about html5, i'm not just referringto the actual technical spec. i'm talking about all the coolweb technologies we can use today--
uh, the open web stack of html5 or html, css, and javascript, and just this general trendtowards getting more know-how about how we're doing things,about faster browser run times, and a whole community that'sevolving around these standards. i want to frame this argumentaround these three points, so basically to say that html5is a technology that is here on the variousmobile platforms, and then i want to tell youthat html5
is a very capable technologyas well, because, you know,i could say that--that, uh, batteries are also availableon the various mobile platforms, but they won't writeyour killer apps. hopefully i can show youthat html5 will. and finally, to talkabout some of the openness and the fact that it's sucha widespread standard as an advantage even overa single native capability or a single native platform.
so in summary,to show you that html5 on the mobile devices rocks. firstly, the html5is here on various mobiles. and that--those are-- that's a bit of a summaryof some of the native platforms you have to consider when you're actually goingto reach people on the differentmobile devices-- um, linux systems,microsoft, apple,
and all thesedifferent versions. each of those things have got their own programming languageto deal with. and, you know, apis and sdks--all of those things differ. and you're gonna be havingto do a lot of relearning or a lot of outsourcingand a lot of work if you want to actually targetall the different users using these variousmobile devices. so this is why you getcomments like this.
uh, this one'sfrom the magazine industry. they've got the sort of monthlyor weekly publications coming outand just struggling, you know? it's costing them a lotof time and money to actually have to go throughand test, you know, see what the content's likeon all these different sort of, uh,all these platforms that they're puttingtheir apps out onto. it starts to become compellingto think about--
could we have one platform to target all of thesedifferent devices? and html5 is here. it's working on the mobilesof today. you couldn't imagine gettinga new phone without having a browser. and many of them do havethe latest features of html5. you know, they're--manyof these phones using webkit, which is what we also use
on the desktop browserslike chrome. they're also on the tablets and even on other devicesas well, like tvs. so they have browsers. you can put your appsin browsers. users click on links when theysee a tweet, for instance. they'll click on a link,and they'll-- that's what they will be openingis the browser. so you need to be thereon the mobile web,
ready inside people's browsers. and you can also embed your--your apps, or your web view--your web apps inside native apps as well.there are techniques for this. on the whole, uh,the various operating systems have said we don't wantthe experience of the user having to clickwhen they see a link, and then it would open upa separate browser app. so the various native platformstend to provide a way
to actually embed a web viewinside a native app. and because of that,web advan-- web developers have takenadvantage of that to actually embedtheir own web app inside the native appthat they've actually published. so when you look at thesevarious programming languages, you can also look at itanother way. you can say, "well, let's justdeal with it as one platform, "one programming language,one set of apis,
one set of design patternsand conventions." but is this for real? like, can you really tryto pull this off, this idea of one platform and one programming apieverywhere? the reason it works is--is not because of some magic that says that you writethe same app everywhere, it's because you doactually have
the same technologieseverywhere, but you still have to dosome customization and make things fit the device you're actually working with. so right at the heartof the web is all of these concepts of dealing with multiple typesof devices. the web has thesethree technologies-- html, javascript, and css,
you know that the-- they distinguish the content,being the html-- that's something likea content creator. it might be a journalist-- that's the thing that they'reactually creating. the javascript is the logic. that's the thingthat programmers create to actually controlthe user computer interaction. and the css is the kind of thingdesigners work on.
and so because you getthat separation, you can reuse a lot acrossthe different devices. you can have almost the same, or exactly the same html, uh, the actual content. you can reuse a lotof the javascript. and you can hopefully leveragesome of the css and then customize it further. we actually just showed thatin the previous talk,
uh, that i was involved withearlier on today, uh, just doing exactly that, having very differentsort of user experiences but the same markupand most of the same javascript. so this is somethingthat the web's always had, because the web evolvedfrom a situation where it wasn't tiedto any one particular device or operating system. the web spread like wildfireand continues to spread today
because it does runon this huge variety of different platformsand operating systems. graceful degradationis another aspect of that, dealing with different typesof devices and different levels of support. so we talk about all theselatest and greatest html5 features you've seenlike in the keynote today. they're not all therein all of the browsers. but they don't--the appjust doesn't just go and explode
if--if your use--if you're relying on something. if you're doing it rightand doing it the way web developershave always learned to do it, you can fall back, and the web actually supportsthat intrinsically. so you've got this capabilityto--to say-- the
instead of the
and you can just choosea single file instead. the style--the font'snot supported in this case. so we can actually choosethe best possible font we would want. html5 lets us be very flexiblewith our fonts. we can actually--again, we canfall back to a font that does. so this is all the way-- the whole spiritof the way the web works. cascading style sheetsis another aspect of this.
so you can actually haveone style sheet, and then that gets overriddenby other style sheets. so you can say, well,we've got our desktop app. you can just publisha normal app for the web first, see if it takes off, seeif it's interesting to people. people can start using iton the mobile already. and then a coupleof years later, you decide, well, now we canstart to customize a bit more for the mobile
and have those rulesoverride the previous rules. and then you can goeven further than that. you can say, well, we specifically careabout android, or we specifically careabout, um, the motorola xoom or whatever. you can go as far as you want, and actually customizeas much detail, but you don't always have to.
you can startfrom a basic point, get your app up and running,and see if people like it, and then tune it from there. the web's always had an ideaabout fluid layouts as well. so just by the nature of the waythe rendering works, things tend to stretchin a reasonable way. and even more so, people have gotwell-established techniques now for doing these kindsof fluid designs
to deal with all sorts ofdifferent screen resolutions. uh, we've got sort of likethe idea of-- of one cloud. um, this is a very big--big idea in our industry. and now what i'm saying to youis with html5 you've got the ability to scalehorizontally very quickly, because you're reusinga lot of the logic. you're--you're usingthe same technologies when you're jumping
onto these different typesof devices. so you might actually still becustomizing a bit, but you can do thata lot quicker. so that's sort of the viewfrom, like, html5 as a platform. um, on the mobiles,html5 as a platform, as faras the functionality goes, it's starting to getthese technologies that will rivalthe native technologies.
so we've got user interfaces-- let you see a lot of greatcanvas things, like "angry birds" and so on. but there's also thingsbeneath the surface as well, the networking and offline-type capabilities,too, that we need. and i'll show you some demosof this in a moment, but first i'll--i'll go throughsome code examples, just to show youthe kind of apis
that will supportthese sorts of things we've always hadin the mobile browsers. so we've got, for instance,geolocation. we can actually--these are the kinds of things that are actually in many casesinspired by mobiles, but they've come backinto the web so they can be usedin mobile web apps as well as on the desktopand elsewhere. um, very straightforward apifor doing geolocation,
and as with allof these sorts of apis, it's potentially sensitive. so just like you would geton an android app-- you know,you'll actually get asked if you'll give it permission, the web has that conceptnow, too. you can do multi-touch, so we do now have touch events, and specifically we havethe ability
to do multi-touchas part of the web-- the standard waysof handling events as well. we get an array--you can see there, when there's a touch event,you get an array of all the touch objects. we can do device orientation. so there--that's now partof the standard, too. it works on chromeon the desktop and some tablets as well.
starting to get there. and we've got standardsfor speech recognition. uh, apologies,that's a little small. so that's input x-webkit-speech. that works on chrometo do speech recognition. and there are device apisas well to actually just capturedifferent types of media. and you can see that they'reactually building on the existing standard.
so it's just a file input,but if you give it this extra attributeof what it accepts, the devices will be smart enough to actually switchinto that form. and on the output sideof things, uh, we can do markupand styling with semantic tags. so we've actually got thesekind of much richer things-- much richer ways to explainthe content on our page. and this is really useful,right?
this means you createyour web app like this, you've already got your content.you've handled your seo. you've got your--almost likea kind of api built in, because you've got this contentsitting there openly on the internet. you don't have to. you canclose it off if you want, but the web tendsto be open by default, unless you get that kindof sharing experience just by structuring your appslike this.
and--and then you can style itreally nicely, too. so css 3 gives youall these ways of decorating that content and getting the bestof both worlds. you've got canvas, so for doingeven richer graphics--canvas. you've seen 3-d canvasor webgl today as well. um, we can do these kindsof graphics, um, more and more insidethe various mobile devices.
and multimedia as wellis possible, too. so we can actually do videoand audio now as part of html5. this is an example of a nativeapp that's on the ipad. "just one more"--they're usingvimeo's html5 video api to actually show videosinside this native app. i'm gonna switch gears now. i'll show you a demoof some of these things i'm talking about here.
let's see. get this guy on. whoa, which one are we on? two, four? meier: two.mahemoff: two, gotcha. so this is geolocation. so just to prove this works,let's see how it goes. so it's asking me if i wantto share my location. so we've got the coordinatesshowing up,
and it's doing a bitof mashing up to actually show the weatherand so on. multi-touch test--so this isinside a browser. as you can see here, it'll actually detect all ten. i'm gonna leave that one.there's a more fun one. so this is 3-d, 3-d transformations with css 3. so that--you know,this is decorated.
we can actually decoratecontent this way. and this is bitly. so we'll jump here. uh, it's generating those graphsin real time inside the browser. but the most fun one is the one i've actually writtenfor this talk. so you can see i've takena few photos around the place here.
inside the browser-- let's see if i can getthis working upside down here. there we go. and this app's runningoffline as well. so it--whoops.back up. yeah, so this appis actually running offline, so it's just stored,so now i'm in the dom. so i'll go and put you guysin the dom as well, in local storage.
wait for it. i'm gonnaswitch the camera around. so say hi. sorry, i can onlyget the middle row here, the middle aisle,but go on, say, "hi, i/o." that--whoops, wrong way. [laughter] mahemoff: all right. and it's kind of jumping around, which way--whichever way i go. i'll leave the--okay.
so now you guysare in local storage as well. so--so i can actually--if i reload this... actually... i don't know. i'll reload itjust to show you that--that'sactually coming-- well, anyway,it won't go offline, but it will work. you can try this later on. if you try that url--html5photos.appspot.com,
you can see how that works. you can try it on the tabletsyou got yesterday, 'cause i've tested it.it works on there. it's just a basicproof of concept. and it also workson the desktop, um, where you canactually use it as a way of keepingphotos offline just by using the file import and pulling photosfrom your hard drive.
now let me jump back. but it's more than just the userinterface side of things, it's also about doingthese sorts of things in, uh, you know-- the sort of back-endfunctionality as well, so things like networking. the--where the webreally took off was a few years ago when we hadthis concept of ajax. it was the recognition
that suddenly the user could beworking in the browser, and at the same time you couldhave all this communication going on back to the server that sent down that application. for security reasons, you couldn't actually goto other domains. a few hacks have come aboutto make that possible, but now we've actually got that built into the standardsas well.
so we can start to doreally sophisticated mash-ups by using cross-originor resource sharing and going acrossto other domains. and we also have websocket and some other technologiesas well to do proper real-timestreaming. so it's not just a caseof the browser making a request. we can also doa live communication channel back and forth.
you can see,rumpetroll will work already on some mobile devices. uh, offline-- so this app here,it does work offline. you can try it for yourselves. just visit it onceand then take it offline. and try itand then hit "reload." you'll see it'll work. it's usingthe application cache--
very straightforward technology where essentially you just needto list your assets. and some of you might have seen the chromeweb store talk yesterday, where people like"the new york times" were mentioning that it'snot just about being offline. it's also a massiveperformance improvement. so the same sort of situationas a native app, where you have your content--
you have your appas well as your content that are all storedinside the device, you can do the same thingwith the web now. you don't have to make itlike every time you go and start this app,it's gonna load the whole thing. and offline storage isanother aspect of this as well. so you can actually have,you know-- storing not justthe application logic, but also the actual content.
so that's showing you that html5is here on the mobiles, and it's also a very capabletechnology. but it's more than that. it's also just someintrinsic things about the way the web works. and i think they'requite compelling for developers. it is based on standards, so while it takesa little bit longer for those standards to evolve,
and it's kind of a messystandards process, ultimately what you end up withis several implementations of these standards, and these implementations,like you've seen-- with these massive performanceincreases we've seen from the likes of chrome, that it causes a lotof competition between the different browsers to keep innovating,
and also to keep coming upwith new standards. like i've tried to show youhere today, it's okay for a browserto go ahead and come up with a new feature that might not yet beon the other browsers, because you have waysto degrade, and there is a standards processfor the other browsers to adopt those standards, too. and--and it's also the factthat you're on the web.
you've got that contentsitting on the web, so you've already got a lotof your search, uh, problem already solved and the ability of making itaccessible as well to things like screen readers. the actual technology of the web is becoming more and more,um, popular. it's very much alreadyfor a few years now-- it seems to be what peoplelike to think of
as a lingua franca,a language that-- just by its privileged placein the browser, everyone has to knowsome javascript and some html5. there are now huge communitiesof web developers who consider it their firstand favorite language. there are other people whostill prefer other languages, but they still knowa lot of these technologies. and we even haveserver-side technologies
like node now, that let you writethe entire app on the server and the browser in the same, uh,set of core technologies and the same programminglanguage. so you can see why peoplelike this. this is a quotefrom "the onion" here, but it is actually serious,i'm told. um, it is basically--they're making the point that they've got the ipad app,
and they're doing it in html5,because they already know it. they already have a web site.they have to have a web site. they haveto have things running as apps on the web. so they're just leveragingall of that existing skill and--and resources. and finally, html5 is a very well-supportedtechnology now. it's been aroundfor a long time.
and you've got some greatlibraries that have evolved since the whole ajax revolution, libraries like jquerythat you hear a lot about. um, there's greatdebugging tools. there's chrome dev toolsfor instance, that make life a lot easierfor developers. and there's a whole communityas well. so there's a lot of, uh--it's very easy to--to get on boardwith html5
you just open up a text editorand write something and run--run it in your browser.everyone can do that. and just to actually skill upfrom there is a lot easierthan it used to be. and there's just thishuge community of blogs and tutorialsand everything around it. so i thinki will leave it there and give it to reto. meier: all right,thanks very much, mike.
[applause]mahemoff: thank you. meier: he'll be back later,but, uh, i'm sure he... mahemoff: appreciated anyway.meier: appreciates the applause. um, so he's madea good point, right? um, there's some reallyinteresting stuff there, some really compelling reasonswhy, you know, building applicationsfor mobile phones on the web is a really good idea. uh, what really appeals to meis this idea
that you have thiscross-functional approach, that you have an appyou write once, and it works acrossall the smartphones, or at least all the modernsmartphones where you want your appto be used. so why would you risk--why would you risk losing that? you know, why build an appwhich is only one platform? well, there's100 million reasons, in one instance,why you might want to.
there's a lot of android appsout there. and we want to tryand create something that's optimizedfor those users. before i get into the details,i want to talk a little bit about the terminologywe're using. so we've thrown the word"native" around quite a lot already. um, if you're androiddevelopers, often when we're talkingabout native apps,
we talk about somethingslightly different from what we might beconsidering. so for today when we'retalking about native, it's really anything built specifically forthe android platform. 'cause there's actually a fewways that you can do this. it's not just aboutwriting things for the java virtual machine. that is the most common wayof doing it.
so most of you guys,if you're android developers, are probably writing thingsusing java syntax, which is going to be runningon the dalvik virtual machine. and that's certainly the, uh,the majority of apps. we also have a numberof different alternatives. and one of those is actuallywhat we call native development. um, so that's usingthe native development kit. and you can actually build appsusing c or c++. and that takes you one levelfurther down.
so rather than running on topof the virtual machine, you're actually runningmuch closer to the metal underneath that. uh, we also launched somethingcalled renderscript, which is a way that youcan write even faster, um, graphics code. and that's how thingslike the, uh, google bookspage turn animation works, the youtube dynamic gallery.
all of that stuffis written in renderscript, uh, which is actually--the coding language there is a variation of c--c99 and we also have the ability of using the androidscripting layer to be able to write thingsin scripting languages, things like python, perl,those sorts of languages. you can actually build apps using those languages as well,though they'll have to run on--
on top of an additionalinterpreter. so when i say, you know,i want you to build native apps, i can mean any of these things. i don't really mindhow you do it, but i do want you to focuson android specifically, and on the hardware layer. so what are the advantages? why--why are we wantingto build native apps? it's really because it gives youa much richer experience.
you're able to build thingswhich have much broader access to the underlying hardware. and it's not just that. you also havea closer integration to the system features. you have this abilityto create apps which are optimized specifically for the hardwarethat they're running on, specifically for the systemsthat they're running on
and with the other softwarethat's gonna be running on those systems. so it gives you the abilityto write something that's not just an app,which is running on a screen, which could be runningon any hardware. it lets you create somethingwhich is optimized for the things beyondthe screen size, with the hardwarewhich it's running on as well. so why--again, why develop?
so for me it's all about power. it's the abilityto write something that's faster, smoother,more efficient, and that was a key elementin one of the presentations i gave yesterday around how to buildgreat mobile apps for android. and it's all about tryingto make things as smooth, as fast,and efficient as possible. the thing about mobiles
is that they areresource-constrained devices. they're gettingincreasingly powerful. they're great with tablets,dual-core, all of these things. but it is fundamentally still a resource-constraineddevice. manufacturers are gonna tryand make the devices smaller, and they're gonna try and makethe batteries last longer. and that's gonna comeas a priority above making them run faster,
which means that every ounceof efficiency that you can pullout of a device to make your app work betteris going to be valuable. and so when it comes to the ideaof building something natively or building somethingon the web, you--you're basically askingthe question can you afford to losethe additional efficiency and power requirements by sticking another layerin between your app
and the devicethat it's running on? the thing isall of that is true, and even if the functionalityof html5 was exactly the sameas native, then that--that's already a reason to think about buildingnative instead. but there's a whole bunchof additional functionality which you can take advantage of, which is why i really think
if--if you can't improveon a web app using some of the native--the android sdk apis, then you're probablyjust not trying hard enough. and so that's a laughfrom the android part-- part of the crowd.i thank you for that. but no, seriously, there is-- there are so many thingswhich you can do now using the, uh,the native apis. and it's--it's reallyall about innovation.
so the--the great thingabout the web is that it'sstandards-based, right? the whole advantageis that you write it once, and you can optimize itfor a number of platforms, but fundamentallyyou can write it once and run it all across the web. and that's fantastic. the way that works is becauseit's all standards-based. and the problem with standards
is that they necessarilyhave to trail innovation. you can't--you can tryto set a standard before a pieceof hardware exists. it doesn't generally workreally well. a much better approachis to find out what's happening.what are people innovating with? what are people using?and then create standards to be able to make thatmore broadly available. that's fantastic.
but what we're seeing isa lot of the most popular apps, a lot of the mostsuccessful apps are right at the leading edgeof that innovation trail. and that goes both in termsof hardware and software. if you're lookingat hardware itself, the rate at whichmobile hardware innovation has been travelingover the last few years is phenomenal. if you think--compare thatto netbooks, notebooks,
any sort of desktop computer, it's been pretty muchthe same thing for decades. right? once the joystickfell out of favor, it was screen, keyboard, mouse, and then different waysto, uh, to connect peripherals. but fundamentally it wasthe same user experience. with mobilesthat's completely changed. it's only a few years agowhen the first iphone came out that we started to havemulti-touch on mobile devices,
accelerometers for being ableto do game control. and then, you know,android comes on the scene, we get accessto the video apis, compass. background apps start to appear. and then every yearthat's improved. so next was bluetooth,multiple screen sizes. then last year we hadgyroscopes, front-facing cameras. and these things have reallyrevolutionized a lot of apps.
think about some of the appswhich you use which are only possiblebecause of these innovations. and the leaders were the oneswhich were able to get in there and take advantageof those new apis as soon as they were released, without having to waitfor everyone else to be able to, uh,to do it as well. this year we've seen barometerson the motorola xoom. i haven't seen anyone use thatvery constructively yet,
but i am looking forward to it. nfc--huge. it's a staggering technology,which is starting to roll out. you can wait until every phonehas nfc, or you can start building appswhich take advantage of it now and be a market leader for when everyone doeshave, uh, nfc. tablets, usb accessories,uh, android@home-- all of this great stuffwhich we've seen launched
over the last couple days. all of that is an opportunityfor you to create something new,something innovative, um, to be at the real forefront of that market. what we're seeing these daysis the device manufacturers-- they're using hardwareas a way to differentiate. and that's one of the advantagesof android. they all have the samesoftware platform,
so they need to buildcleverer hardware. they need to come upwith new features. so this is what we've seen overthe last three or four years. imagine what we're gonna seein the future. i think it's gonna continueto innovate and continue to grow. we've seen exactly the samething on the software side. right? so alongwith that hardware, we've also seen greatinnovations in mobile apis.
and these are some examplesof some apps which have really takenadvantage of this and become market leaders, whether it's google maps usinglocation-based services, which we all totally takefor granted now, right? we all know that our phonesknow where we are. uh, you know,this is just assumed that every mobile devicecan do this, but it's actuallya relatively recent thing.
uh, shazam using audio input, goggles using video input to do video recognition--image recognition. "angry birds"--touch screens. the way games are playedhas changed. it has been totallyrevolutionized by smartphones with accelerometer input,um, compasses, video, all of these sorts of things. so really what i'm saying
is leverage the hardwarethat's available, particularly when new platformsare coming out. so we've all been usingsmartphones for a long time. it's been, what, three years,so it's passã© now. what we're looking at nowis tablets. and all of you guyshave tablets, so there's no excuse for notgetting into tablet development. and--and it's more, right? there's google tv--that'saround the corner as well--
i mean literallyaround the corner. it's actually out. um, and we're seeing things-- we're seeing android really,you know, populate a much broaderspectrum of devices, whether it's carsor, you know, whatever else. we're seeingthis single platform as a place where you can reallytake advantage of the hardware. we're gonna build the apis tomake it easier for you to use.
and that's what the android accessoriesdevelopment kit is all about as well. it's trying to give youas developers access to be able to programfor more things. i mean, this isreally revolutionary. we're now livingthrough a time when we're making it possibleto write code which runs specifically ondifferent hardware platforms.
it wasn't that long agothat it was very difficult to actually get a pieceof software you wrote to run on an actual phone thatsomeone would go out and buy. and now that's somethingthat you can do right now. if you get bored during oneof the presentations, you can write an app,launch it on market, and it'll be there. and what we're seeingis that this is now propagating acrossa whole variety of hardware.
so one of the key messagesi want to take away from you-- or give you guysto take away from this is think aboutthe actual hardware that your softwareis running on. if you're building somethingfor google tv, you should think about the apisthat are specific to that. how can you integratetv guide information or, you know, whatever elsemakes sense for that hardware? and it's the same with tablets.it's the same with smartphones.
and that--and that's whatnative gives you is the ability to startusing that hardware as soon as it's available,rather than having to wait until it becomes ubiquitous. and so this is some--some of the stuff which is available,uh, right now for native development. um, so obviously you can developfor smartphones, tablets, and tvs.
audio input is ubiquitous. video input from front-and rear-facing cameras is all there today. uh, 10-finger multi-touch input,um, which i will grant you, mike, is now also availableon, uh, on many mobile platforms forweb-based development as well. and things likea generic sensor api, so that as new hardware sensorsget added to, uh, pieces of hardware,
you're able to integrate thatinto your applications really easily. and that's where we're seeingthings like orientation, accelerometers, barometers,a variety of new hardware. i think there's gonna be a lotof growth in that area as well. one of the key things as well, which isn't as common, is this ability to getright to the low levels. so having accessto the telephony, bluetooth,
sip stacks, usb-- all of these things make it--make it possible for you to create apps which fundamentally interactwith hardware. and in fact, it goesthat one step further, because your native appsaren't just something which sits in a sandbox,in an application sandbox, or within the browser. they become part ofthe ecosystem on the device.
so that meansthat you can do things. you can actually workwith the system. you can listenfor system events. so if you want to build an app which is going to, uh,listen for incoming calls, do a reverse number lookup,and display who the caller is, you can do that. you can register an intentto listen for incoming calls. you can do the same thingwith other apps.
so if you want to have an app where you want to displaya location, you're able to make a call, again usingthe intent framework, to say have something displaythis on a map. and if google maps is installed,it'll do that for you. you can do the same thingin reverse. so if you have an app that can,uh, book hotels, and you say, "well, look,any app which wants
"to be able to do this,just send me the name of the hotel,and i will book it for you." so it's a way that you can haveall of these apps interacting with each other, as well as interactingwith the citizen-- uh, with the system itself, because they areall first-class citizens, which means you can replaceany of the apps on the device as well.
if you think you can builda better home screen, build it, launch it,put it in market, and people will be ableto use it-- same with dialers,same with contact managers. anything which is on the phone you're able to createan alternative for. another thing which i reallylike about native apps is that they can betruly background. and obviously the most--
the most common use casefor this is a concurrent app, like, have a music playerin the background, and then you can continuebrowsing at the same time. but it's really more than that. native apps let you be ableto have much fresher data by being ableto continue to update in the background,even if the app isn't running. so you don't havethe associated battery drain of having somethingwhich constantly runs.
you can set an alarm and say when connectivityreturns, do this. or if, uh, if an incoming callcomes in, that's when i want my appto be started up and to be active. and for all other timesit can be completely stopped. it can be not running at all. you can also do thingslike a server-side push... so cloud to device messaginglets you transmit a message
from a server to your appto say you have new information, so start upand download something or notify the user of something. you can actually dothe same thing on the device. uh, so again, you can have theserecurring background alarms, so your device--your appcan be completely off. in fact, the devicecan be on standby. and you can say, look,every hour,
i want you to wake up, pull downthe latest news headlines or tweetsor whatever it is you want. and then as soon as the appgets launched, it's able to have that fresh,up-to-date data. and the advantage hereis twofold. not only do you getfresher data without having to doan exclusive reset. but you also saveon battery life, because your app doesn't needto be constantly running
in the background in orderto get those updates. full offline support,i mean, this is something which again is coming to html, but it's somethingwhich is really rich on the native platform. so not only can you have,you know, your app data cached, you can actually downloadthe entire contents, store them on the device, and have them availablefor things like search.
i use gmail every morningon my way into work. i triage my e-mail-- constructive use of my time. the thing is i commute to workvia the london underground, which means i haveno internet connection for most of that journey,but it doesn't matter. i open up gmail.i read all of my messages. archive, reply to--put it in my pocket. and then as i walkto the office,
it gets a 3g connection,and everything is synced. by the time i sit at my desk,everything is up to date. and it's that richoffline support without ever really needingto be online at all, uh, which creates a really greatuser experience. one of the other things--and this is something which i really likeabout android specifically-- is the fact that your appsbecome more than just, uh, an icon in the launcher.
you can createhome screen widgets, live wallpapers. uh, you can have notificationswhich get triggered to-- to tell you of things like, uh,you know, incoming e-mail or instant messages. and because all apps are createdequal on the platform, you can do anything which anyof the native apps can do. and so this isa really great way of being able to makeyour content much more engaging.
so someone doesn'thave to remember to navigate to your siteor look up a bookmark or even start your appin the launcher. by having widgets,notifications, you're able to pullmore traffic, more engagement,more users into your app. 'cause that's ultimatelywhat you want is for people to useyour app more. downloading it is reallyonly the first step.
so this is a little summaryof all of the things that you can dousing native apis across allof the android devices. and there are additional things, which limit itto some of the newer versions, but this is prettyfundamentally everything that is there. so, uh, i'm gonnahand back over to mike. mahemoff: okay, so i just wantedto really summarize
our two arguments, and then we'll shift gearsa little bit towards making this practical. so to sum up,really what i'm saying here is that html5 is a technology that's here nowon the mobile devices as well as any other--many other types of hardware. it's a capable platform as well, so it's got these events,ui capabilities i've shown you,
and beyond that. and it's an open technology.it's something that many people in your organizationsprobably already know. and you have to haveweb apps anyway. people will use the browser. so it's got all those benefits. on the other side of things,reto's pointed out native apps tend to bemore integrated, with the--the deeperhardware integration
that tends to stay a step ahead, um, as well as the fact thatyou've got the user experience that's, like, built intothat native look and feel for each of the platforms. um, so really the next pointreally is just to say, like, what can we actually doabout these things? meier: how many of you guyswere hoping that we would give youone answer so you would be ableto come out knowing?
[laughter]meier: yeah, a few of you? it's--it's really not thatstraightforward, right? it's not as easyas which should i do? if--if it was that easy, then google would just do one. but we don't.we do both. and fundamentally,that's the answer, right? you--you can't just be focusingon one thing. it's--it's pretty clearat this point
that the web is the future, so you cannot ignore thisas a platform. and if you want real reach, then building a mobile app, um, which is web-based, is--is kind of a no-brainer. you can build one app,and it's gonna run all across all of these devices. and for a lot of content,that's gonna make perfect sense.
you should be building somethingwhich everyone can use. but at the same time,there's all these native apis, all of these native advantageswhich can let you build something really great. so fundamentally,i guess what we're saying is maybe build a web appfor everyone, and if you've already gota web site, then it kind ofshould already be a mobile-optimizedweb site as well.
that's increasingly how peopleare trying to access web content is on mobile browsers. so that's kind of a gimme. beyond that you wantto then create an optimized versionusing those native apis to build something better. one of the ways you can do this while leveraging the workyou've already done is by using webviews.
most of the smartphone platforms have something equivalentto a webview, but i'm gonna talkabout android specifically. but this is a way that you canembed web content into your native applications. it--it's kind of an obviousthing to do here. if you've got content whichhas already being formatted, looks beautiful,you've got your ux people building stuff in html,why not use that
to display the contentwithin your applications? what you do then is that becomesthe mainstay of your app, and then everything elsebecomes chrome. so you then--you know,all of the action bars, all of interactionwith accelerometers, with the native hardware--you can do all of that stuff, but then just displaythe content specifically using a webview. and in fact, if you've beenusing the google i/o app
throughout the conference, you've already been using an appwhich does exactly this. so all of the, uh,the maps are actually done not using a mapview, but by using a webview, which using the google maps api. and you can see we've gotthe real-time stream of tweets, i think. um, and that also is goingto be just a webview,
um, which has a particularamount of content put into it. everything elseis purely native. so all of the action bar stuff,all of the things which are optimizedfor tablets or smartphones is all done natively. but we have this abilityto just wrap the content, um, for specific partsof the app using a webview. mahemoff: and i just wantto finish off
with just a few tipson just html5 and javascript in general when you're dealingwith mobile devices and going acrossthe various platforms. firstly, there arelibraries available. i already mentionedthat you've got these libraries that are now very powerfuland very widely used, like jquery, that are just usedfor general web applications.
those things also work. they work quite nicelyin most cases on the mobile devices as well. and at the same time,there are more and more mobile-specific html5frameworks and libraries that you can hook into. so there are things like--um, we've got sencha touch here. this is an example of an appthey've created that worksright across the board,
showing a conference schedule. sproutcore--it's a touch app. you can see the same kind of app running in the chromeweb store as well. so it's that experience,or that--that philosophy of writing the same app. in the case of the mobileor the tablets, you can swipeand just go across. otherwise you use the mouseon the desktop.
um, it's an npr app, actually. and--and jquery mobile is kind of the new kidon the block here and--and already very popular,because it's based-- or it's the similar sortof concept as jquery with the same team. um, it's--it's actually very, um, sort of more ofa micro kernel approach, um, and it's gotthe ability to theme,
so you can coverthe different devices, and a very permissive licenseas well, being mit based. think aboutprogressive enhancement, the idea that you haveyour raw, basic web site, uh, a traditional web site,just some markup, again, something we showedin the previous session on--on mobile developmentfor the web is--you know,this actually does work.
we showed this workingin your basic browsers like opera mini. and many people doactually still access the web from very traditional, uh, from very traditional devices, you know, that have very basicweb capabilities on the mobiles. and if you do your app right,you can actually get it working for those as well.
and then you go aheadand you enhance it, so you're actually-- in this case we're basically"hijacking" these links to actually sayif we do have javascript here, we're gonna go further, and we're gonnaactually not go ahead and click to reload the page. instead we're gonna dosomething dynamic. we can do fallbacks.so i already showed you,
you can do fallback withsomething like
um, very important thingnowadays-- based on the premisethat you can't try to detect every sort of different device. it's just not practical. and even if you could, you wouldn't wantto create separate apps for all these different devices. so rather than havingthis whole, uh, combinatorial explosion
of--of appsyou have to deal with, just put a little bitof intelligence into your appto make some decisions as the app is actually runningabout what to do and then perhaps downloadsome extra content or some extra typeof application logic, depending on what arethe capabilities of the current device? like i said before,html5 is not perfect.
it's not a magic bullet. you still have to do somedifference of logic and so on to reach all thesedifferent devices. but the benefit you getis a vast amount of reuse. there's library supportfor this sort of thing, too. so we've got a librarycalled modernizr that's becomingextremely popular, um, which actually doesthe detection for you. on a previous slide, i showedthe kind of low-level detection
you can do, sort of doing thingslike creating something and seeing if itactually was created or setting an attributeand seeing-- reading it back to see if the browseractually recognized it. you don't really have to dothose low-level things anymore for feature detection, because there are librarieslike modernizr
that do it for you. there's also a slightlyhigher-level layer on modernizr that will actually-- uh, it doesn't haveto be modernizr, but it--it's basically, uh,around those kind of use cases for people who are usingmodernizr, called yepnope. and basically just--basically it says, you know, if you've got this feature,we're gonna download an extra layerof javascript and css.
if not, we'll usesomething else. polyfills is the idea that you don't necessarilyhave to fall back. i've already talkedabout graceful degradation. but what if you could actuallyjust fake it, right? and actually say we don't havethis particular feature. we might not have svg in a browser like ie 6for instance, so we'll just fake it.
we'll fake itwith something else. um, so in this case we can saythere's a library called canvg, um, which will actually fake svgusing canvas for things that have canvasbut not svg. um, storage--so i've alreadyshown you a little bit about local storage to makeyour apps work offline. really old browsers,uh, don't have even the basiclocal storage support. so for those browsers,you can resort
to everyone's friend,the old cookie, and store a very minimum--minimal amount of data, but you can still do somethinguseful with that, and likewise geolocationand so on. and the point about these isyou can use them yourself, so you can talkto that more modern api. and eventually whenthose devices and browsers become deprecated, you can just switch off the--any kind of checking.
but also forthird-party libraries, these are really powerful, because the third-partylibraries might be taking advantageof those newer features. and you can sort of jump in. javascript'sa very dynamic language that lets you do these thingslike what's called "monkey-patching"or "hijacking." so you can sort ofintercept things
and say, actually, no,the object you're talking to-- do this instead.use this object. and finally, i wantedto share with you-- i spoke to roman, who actuallycreated the i/o app that you have seen-- just the sort of techniquesthat you can use and he's using there to actually communicateback and forth between the native componentsof android
and--and the html5 components. so if you are creating oneof those sorts of hybrid apps that reto was advocatinga moment ago, you can go in both directionswith android. you can basically havea native part, um, talk tothe--the javascript part, basically making callsusing that loadurl command. so, um, if you've got a webview, instead of actually loadurlopening up a new web site,
as you'd expect, you can just pass it javascriptcommands the same way. some of you might know you can write those kindsof javascript commands on--on the actual browser,like the way bookmarklets work. and in the opposite direction, html5 can actually talkto the native components, using this pretty cool method that's addjavascriptinterface.
so it lets you kind of,uh, send in a native componentinto the javascript app, and you basically providean interface for that. that gives you fullcommunication between the two and lets you writes--write one of those hybrid apps. i think that's about all. we've got some resources thereto help you with. and i think that's it. i think we can takequestions now, yeah.
great, thank you.meier: thanks. [applause] man: um, one of the technologies that you didn't talk about, and they also have a--sort of a similar message is, um, adobe flex and air, uh, because that's available on android, on blackberry,playbook, and also there is a wayto get it onto ios.
um, what would you suggestthe strategy-- like, adobe air versus html5...mahemoff: okay. man: versus native? mahemoff: yeah, i thinkit's an interesting sort of third situationwith, uh, the flash and air and so on. um, i guess the wayi see flash-- people always ask meabout flash. um, i think it's beena good technology on the web
for actually going, uh,a step ahead, like the same sort of wayreto's talked about native technologiesgoing a step ahead. i think flashhas always done that. it's now gonna be a challengeto see if it can keep on going in that direction. i think the webhas some obvious advantages. um, the fact that peopledo just have to have normal web sitesas an open technology
without any oneparticular vendor controlling its destiny,if you like, so i think that's wherethe challenge for that whole setof technologies is, like to keep stayingahead of the game. so you can have those kindof native technologies, um, but actually go acrossthe different devices. meier: yeah, i thinkthat's the big challenge for the adobe stuff,
or really anything otherthan sort of web or native, which are the two extremes, is not getting stuck withthe negatives of both worlds. you know, it doesn't workon everything, and it doesn't have a full rangeof native support. i think that's wherethe challenge is gonna be. mahemoff: and there's also--in some respects, there's been better tooling,traditionally, for flash as well.
so that's where the advantageover the web has been, but now there's starting to bea lot more tools for-- and actually not justthose sort of libraries i've talked about, but people arejust starting to write sort of animation toolkitsand so on as well. yeah. man: thank you.man: uh, yeah, if you're developingone of these hybrid apps, uh, you've talked aboutthe javascript bridging,
is there also a waywhere you can manipulate or take over the cache or the loading of subresourceswithin the webview? you can do that on iphone. is there an analogous wayto do that on android? meier: uh, i'm not sure. it's not an area whichi've looked at too closely. i believe that you havepretty much full control over what happenswithin a webview,
but, um, don't takemy word for it. i think they're still doingandroid office hours upstairs. it'd be a good questionto ask someone there from the browser team,if you can find one. man: is there a particularperson you'd recommend? meier: i'm not surewho's around, so no. man: okay. thanks.meier: no problem. man: the, um,tabbed view you had that included the html5 photos,
was there a urlfor that whole thing? mahemoff: uh, i haven't gota url for the whole thing. um, i can put it on twitter,i guess, afterwards, after this talk...[speaking indistinctly] man: okay, but there wasno helper app to get that photo? it was just lookingfor a file... [voices overlapping] mahemoff: sorry, the urlspecifically for the photo app-- man: well, that washtml5photos.appspot.
mahemoff: yeah.man: and my battery died. excuse me. um, but that thingwill trigger the camera without a helper app? mahemoff: uh, triggerthe camera is-- oh, well, that's juston the slides, so i've got the--there's no url. i mean, it's just"input type=file"-- man: right, but you hitthe button. you got a photo. mahemoff: yeah, that's justa special kind of input type.
man: okay.mahemoff: so i've done "input type=file"with a special except. you'll see that on the slideswhen they come out. it's just a single line,basically. and then i'm using,uh, reader, so you can actually-- there's also file apis,basically-- this is on html5 rocks,actually, how you can actuallymanipulate--
man: oh, it is all there, okay.mahemoff: yeah, once you've got the file, you usefile input with that except to actually put the filein that--that element. and you can then read itusing filereader api. man: okay, thank you.mahemoff: okay. woman: hi, uh, first of all,awesome talk. i actually was gonnaask a question based on the factthat i'm sure you actually get more of this input than i do.
so i didn't see thison your list, but do you think securityand transparency is actually a factor? so what i mean is, like,when i look at an html5 app, i can pretty much kind of lookat the html source. i can figure out the javascript.i can figure out what's happeningbehind the scenes. and i can use user scripts.i can use extensions. i can kind of manipulate stuffin there.
native apps don't let youdo that. and you know, even backin the jtime days, you wanted to kind ofdo things to hide stuff from your competitors. so are you seeing developerssee that as one of the reasons for picking one over the other?just curious. meier: uh, well,from the native side, it's not somethingthat i've come across. i mean, certainlythere's certain industries,
particularly around banking,but to be honest, they are very comfortable with the way things workon the web now. the advantage of the web--it'sbeen around for a long time. and there's somereally great security things built into it, and there's a certain levelof comfort. um, so as far as obscurity goes, i haven't seen anyonedevelop a native app
in order to make their codemore obscure. um, but i would imaginethat from a user point of view, i guess, turning that round. so a lot of the banksare more comfortable with a web app,because they are-- they understandthe security model. they know that the usersunderstand the security model. um, so for users, yes.developers, probably less. mahemoff: and yeah--one the web side of things,
it's a little bit different. we've seen this at the chromeweb store, for instance. people tend to be concernedabout two things. one is the application,so people actually potentially stealing the applicationbecause it's open. and the other isthe content, right, so actually, uh,digital rights management and people actually being ableto lift movies and music that those are actually serving.
um, there's a couple of thingsto say about that. firstly, there wasa really good comment yesterday in the web store panel by the chapfrom "new york times" who just made a point that people who tendto be really good, the people that you haveto worry about as competitors, don't tend to be the kindof people who would actually considerdoing that anyway.
um, but beyond that, it's--i think the way i like to see it is that these technologies are-- have sort of a standard defaultthat you can vary. so the web tends to beopen by default, but if you want, you can applyobfuscation and so on to--to close it off. and likewise, uh,native technologies tend to be closed by default.they're sort of binary. but if you want, you canalways put the source up on...
woman: yeah.mahemoff: you know, on a repository or something.so it kind of works both ways. and it's really downto the developers to... woman: thank you.mahemoff: my pleasure. meier: yeah.man: right. so i have two or three comments. the first one isyou talked about, um, i guess, on this side,uh, about-- sorry--
the fact that, you know,one of the advantages of native is--is, you know, less stress on the power. and you didn't address thison your html5. i think that's a huge,important thing, because power is so critical. um, the other thing is--and i guess i'll just summarize itby this-- is why--why not talk--
why not tinker just, like,gwt instead? which is, you know,write it for android and then compile itfor html5. you know, and i'm sure there'sgonna be cases where you're talking advantageof the hardware, and that compilationwouldn't work. but at least a lotof the skunk work that you would do in html5 can be done for youby the compiler.
mahemoff: i don't understandhow you can write it in android and then compile it in html5.man: you write it in java-- like, right now,if you write it in gwt, you can compile itand it works-- mahemoff: oh, okay, using gwt.man: yeah, so now you do an android version of that.mahemoff: yeah. and that's--that'sthe "angry birds" strategy that's working in gwt,so there is a possibility there. meier: yeah, absolutely.
i think part of--if i understand your question or comment correctly--i think one of the risks if you're usingsomething like gwt, it's the same sort of issuethat you may have with somethinglike the adobe solutions, which is you build somethingwhich is generic. then you may as well build itusing web technologies. and certainly gwt is a great wayto build web technologies, but i don't think that wewould get to a scenario
where we would want thatto output android code. man: no, i'm sayingthe other way around. meier: the other way around.man: no, you write... meier: write android code.man: just in android, and then you tweak the compiler,the java compiler, so that it generates html5. meier: html5. okay.so again, it's-- man: because you havethe code already. [voices overlapping]mahemoff: it can work.
it's another strategy, dependingon where you come from. i actually had a partnerwho did this who actually--with the chrome web store. they already had an android app, and they were ableto really quickly-- actually, i was really surprisedabout how quickly they could use gwtto actually turn it into a very capable web app. so it is definitely a strategy,
if you've already gotthe code base and all the understandingabout how to do that, yeah. man: what aboutthe power thing for-- mahemoff: yeah, it's a goodquestion, actually, 'cause reto was talkingabout this. um, chrome now actually hasthe concept of background apps. and it is just chromeat this stage, but a lot of the thingsthat chrome introduces
are intended to eventuallybecome standards. and so--and it does actuallyhave this concept that you'll see-- "new york times"is one, uh, company. there's quite a fewthat are starting to use it. um, so it can actually runin the background. um, and actually, it kinda goesagainst your point, too, because it's actually usingmore battery while it's in the background.
um, so, yeah, i mean, it's-- i don't know--why would you saythat it's using more battery? man: well, i mean,i know ios quite well, and i can tell youthat ios you get events, and you have to putyour app to sleep. mahemoff: right. i see.man: and i think in android you have similar events.i'm exploring them now. so you--you essentiallyare participating as part of the platform...mahemoff: yeah.
man: which is tryingas hard as it can to, you know,maximize battery life. mahemoff: so that's in contrastto keeping a web app running... man: yeah, that's right.mahemoff: the whole time. and that's wherethe background apps do help, because with chromeyou've got the ability to launch thesebackground windows, which are invisible windowsthat can just wake up. you know, we'll just run a timerand just wake up every hour
or whatever and just do a poll. so it's just startingvery early to get there as far as the standards go. meier: i think what we'regonna find is that one of the advantagesbehind android is that it's ultra optimizedfor mobile-- like least power,most efficient, et cetera. the reality is--is that the web browsers which are runningon these platforms
are gonna have exactlythose same things. so chrome originally was notdesigned as a mobile browser. that wasn't the focus. the focus was aroundall these other cool things, which everyone usesand wants to be able to do in the most efficient way. as we see things now, more developers creatingbrowsers for these platforms, that's gonna have to betheir focus as well.
and so there'll be solutions to thingslike the background stuff, but also, um,also just more efficiency, generally speaking. mahemoff: yeah.man: so my question's around if you do the html5 apps or take a chrome web appout of the web store, can you put itin the marketplace, too-- android marketplace?
mahemoff: you canusing some technologies. so there's ways, actually-- ways of actuallycompiling it down with some frameworks, but there's also waysof actually doing it yourself, like what reto was suggesting,the kind of thing that the i/o-- man: so hybrid--hybrid apps,you can-- then you can putit in marketplace. mahemoff: yeah, and there are--there are also frameworks,
and there are waysof actually not just taking the kind of approachwe've done here, but actually compiling it. so there are starting to besome technologies that people are doingto actually take, um, like, something that talksto canvas on the desktop, and then it will go to openglon--inside an android. man: and then that would qualifyto be in marketplace, too. okay.mahemoff: well, you still
have to wrap itas a native app, but yeah. man: my question is relatedto this one. uh, the waythat chrome web store connects apps to users, which are pure web apps, uh, doesn't it make senseto have a similar store that connects mobile web appsto the users where people can discovermobile web apps in some kind of a store?
meier: yeah,that would make sense. um, i think the questionof how you put, um, chrome apps designed for mobile,and make them more discoverable, uh, on mobile devicesor android devices... man: and don't haveto wrap it up just so that they can bediscovered, so they can be first-classcitizens on their own, being mobile web apps. meier: so i'm not sureinternally
of what the plans are--two separate teams. so i have no idea.personally, my preference would be to see search becomethe way that you discover it, so that you have search,which is much better at discoveringboth native android apks and web-based apps as well, rather than sort of havingdifferent markets or indeed any market. but i have no ideawhat the actual plans are.
man: all right, thanks.meier: last question. man: uh, this is really moreof a comment than anything else. i guess one thing is that,"a," if you guys are building kind of a hybrid appin this case, you should probablyremind people that the actual rendering engine is not the same as whatthey would have in a browser or whatnot,
like for instance,what the gentleman said there about ios--you know, the--people are very surprised when they get a ui webviewand it doesn't have, like, jit compilation on like mobile safarior something like that. um, two, for the, uh, html5 portion of it, remember, too, that the networkis the most expensive thing when dealing with mobile,
less so thanthe power consumption and all that other stuff, so if you're dealingwith lots of, you know-- i know that android 2.0 and 2.1 supports html5 web workers, and 2.2 and 2.3 do not anymore. thanks.[laughter] meier: you're welcome.man: um, if you're doing that, you're, like, you know,pulling up a couple threads
in the background and spittingoff extra resources-- that's very expensive. um, and then three,your solution doesn't always workin certain situations, um, it's appearedin an html5 web app, because, say, you're european, and you use somebodylike vodafone or, um, you know,orange or something like that, that use things likecontent transformers actually
at, uh, the--in the network operator level. your app is just toast. and yours actually works. meier: it's definitely, uh, there's definitelyno easy solutions. and i guess that'san important takeaway is that you really need to lookat your market, look at the devices,and look at the technology, so you can figure out somethingthat works best
for the what you'retrying to create. man: yeah. and, like,i guess what the gentlemen was saying before about gwt-- it was that it would greatto be able to take gwt itself, have it export out html5. um, it does a little bitof the exploratory on the device,sends it back to the server, and actually optimizesfor that device, so that you wouldn't haveto have that back-and-forth
that you would with modernizror those other tricks that you introduced. meier: all right then.mahemoff: good points. thank you.meier: all right. thanks very much, everyone.[applause]
