[BLANK_AUDIO].

Do we have any PhoneGap developers in the room?

Oh, shit, that's awesome.

There used to be zero, so, I'm stoked about that.

All right, so let's dig in.

The, thing I hate the most about software conferences, is that you'll

have someone come here and they will talk to you for an hour.

And they won't show you a single line of code.

I'm not gonna do that.

I'm gonna try and show you guys, like how

this stuff works and so, let's build an app.

Anybody here building apps?

Right on.

Native apps, like iOS?

Android?

Okay, Firefox OS?

Nothing?

It's sweet, dude.

You should check it out.

Okay so I, I work on the PhoneGap project.

We've got a bunch of toys to play with today.

I just bumped my phone a little bit.

So, PhoneGap is at the moment a command line utility.

That you download and install.

It's a node module, and so if I, if I need it, I need to have node.

And then to install it I just do MPMI G PhoneGap, and I'd get it.

That would download the Internet and eventually install PhoneGap.

And then I can run it, on the command line by typing in PhoneGap.

This in itself is not all that exciting.

The command line isn't all that scary either.

Something that's interesting about PhoneGap once you run it once

it's gonna give you this little grid as a helper.

So you know which platforms you can build for.

On your current situation.

And you'll see, it's like local, environment and remote environment.

If you want, you can configure PhoneGap to work remotely.

I'm not gonna do that.

And then it gives you like all the

various, you know, commands that you can run.

So, cuz I'm lazy and hung over, I'm gonna do PhoneGap create, Foobaz.

And would I create a project called FooBaz.

So we're gonna jump into FooBaz, and we're gonna take a look at, I use Bem.

I'm old, you don't have to, it's not a prerequisite to doing this stuff.

I think Bem's useful, You know, pick your

text editor of choice, it doesn't really matter.

PhoneGap.

Super does not care.

This is just web development.

And so, one of the, big things that we wanna first

take note of is a PhoneGap project has a www folder.

Very much like Apache, this is where your web assets go, so

you can put HTML, CSS, JavaScript in here to your heart's desire.

We've got a couple of other folders, I'm gonna get into those later.

You don't have to look at them right now and in fact none of these are mandatory.

This is the only one that counts and so if you, walk away

from this situation knowing anything you know we can deal with web stuff.

So, let's take a look at this.

We're an Apache software project.

I'll talk more about that in a bit.

Right now I'm just gonna totally fodge a license.

I'm gonna get rid of this because I don't care about iOS7.

And let's take a look at like what we got here.

So we've got some really basic markup, you

know, typical title, we've got these two, Paragraph elements.

One says, connecting device.

The other says, device is ready.

You'll have to take my word for it but the CSS in this

will, blank out device is ready until the device itself is actually ready.

We've got some hyper enthusiastic JavaScript developer in

here who decided that they would add this type.

I just wanna let you know that that is no longer necessary.

And, it's HTML5.

So I don't give a fuck about these quotes.

They can go away.

I totally just ruined everything.

Okay.

[SOUND] So now I can go PhoneGap Run iOS.

[LAUGH] Really?

[SOUND] I think I had a

demo project there.

So now I'm gonna jump into, under the hood into Xcode, do a bunch of crazy stuff,

in a compiler application and then we're gonna

launch it and we're gonna see the device's ready.

So, I type two commands, I'm on, iOS, that's kind of neat.

Everyone's like is Brian full of shit or not.

Let's just, go take a look back at that code.

I think I was editing, a sub project at that time.

So let's just change this to [SOUND]

says device it's ready, let's go like,

[SOUND] I have a Vegas level hangover.

All right.

[SOUND] Same business, kicks out the Xcode.

Under the hood.

We're trying to install our own device.

No device exists.

So then we find that we've got a simulator.

We launch it and I have a Vegas level hangover.

Cool.

That's interesting.

We're not quite living up to the promise of PhoneGap at this point.

So, I'm gonna plug in my phone.

Which is a Nexus 5.

[SOUND] and,

[SOUND] oh, no.

That's super uncool if you don't work.

[LAUGH] I

swear to God the phones plugged in.

Why Android why?

It's like it can detect when I'm presenting.

it's like I'm gonna screw with you.

Okay.

Does anyone have a, a mini USB cable, on them, by any chance?

This has to be the cable.

[BLANK_AUDIO].

You're a good man, I owe you a beer.

To your peril.

[LAUGH] All right, let's see if this works.

If this doesn't work, I even.

Oh, it did.

It was the cable.

That's super crazy.

Okay, so we'll, launch Photo Booth.

So you know I'm not a liar, I'm gonna go back

to my command line, and we'll do PhoneGap > Run Android.

[SOUND] And so, PhoneGap's gonna detect that I've got an Android device here.

It's gonna compile.

It's gonna dump a bunch of Java bullshit to my terminal.

Once that's done, [SOUND] it's gonna try and install it on the device.

Hm.

And

so, we're on.

Two platforms now with a grand total of three commands.

[SOUND] So there you go, there's your Hello World.

That's kinda how it works when you're

looking to build for multiple platforms with PhoneGap.

I'm

Aging, open source software developer.

And one of the things when.

So, open source is sorta like adopting kittens.

They're beautiful and you love them at first.

And then you own a cat.

And so [LAUGH].

It's the same thing.

I mean when you're, when you're adopting a technology

eventually you're gonna have to deal with it right.

And so, in order to understand whether or not

you think this technology is appropriate for your business,

your business drivers, you have to understand where it

came from and you have to understand where it's going.

Everybody jumped on, the rails bandwagon and they were super stoked.

Rails was great.

And then Rails went through a lot of change over time.

So understand where open source comes from helps you understand where it's going.

PhoneGap just like every other open source project

has a lot of weird mythology surrounding it.

So, I wanna clear some of that up.

In 2008.

Oh, actually it started in 2007, so in

2007 I used to work at this software company

in Vancouver called Nitobi, and we did a

lot of Blackberry development because we're Canadian, I guess.

I don't know why and we, we were really stoked

like the, the early I think it was called the Curve.

It was the first device with a GPS.

And we're like, this is, this is gonna be something.

This mobile thing.

And then Steve Jobs comes out and he walks on the stage, and

he holds up the iPhone, and he says you're gonna build web apps.

And we squealed like little girls, and we jumped in our cars, and we

drove down to Seattle because they didn't sell them in Canada at the time.

And we bought a shitload of iPhones, and we started building apps.

We love that model, that was, that was the right model,

Apple was like, you're going to build apps, we're like yes!

Exactly that, one year later, he's like sike!

You're building objective C apps.

We're like, oh, okay.

[LAUGH] And we checked it out, objective C is actually a pretty cool language.

I totally recommend learning it by the way, I'm not gonna tell you that you

shouldn't learn a new software language or

how to program a particular platform, you absolute.

Should be a better programmer, and you need to learn multiple languages.

That said, objective C is horrific.

So.

[LAUGH] We jumped in and we're like, okay, you know, there's probably some merit

to this ancient language, with, array syntax for accessing properties.

Maybe, maybe it can be useful.

And then we discovered that it's, it's got a web view.

And we were like oh, okay, well that's interesting,

so we can substantiate a web view, but can

we create some kind of like, binding where we

can call, you know, the JavaScript code from native?

And it turns out you super can.

With terribly named syntax, it's like execute string by evaluating string,

you can call in, but can you call back the other way?

And, it turns out that this just wasn't a supported

thing, at all, and a couple of our dudes went

down to, ironically, Adobe at the time, and they went

to this thing called iPhone dev camp and they're like.

They met some app developers and, hey, can

we call from the JavaScrip to the native site.

And this Apple developers are like, nope, not possible.

Well, I mean, you could pull the URL, that'll be crazy.

So, that's what they did.

So, PhoneGap ultimately creates it's bridge between

native code, and the web view that you're

sitting in, and then we do it in very of different ways for every single platform.

But, the original way we did it, and we don't do this any more, but you.

Could still do this if you wanted to.

Was polling on what the URL.

So we pass a message in the URL and we then set that protocol

handler and we'd be like, oh, okay, I'm actually looking for a native call.

And we'd execute some native code.

And then we could call into the JavaScript the other way.

Now everyone's thinking, oh my God that must be super slow, and you're right.

We only get about 400 hertz which would be

400 operations a second on that particular type of call.

Slow but I ask you do you need to get your geolocation 400 times a second?

Probably not.

So [LAUGH] it's really good for doing a lot of stuff.

Not everything.

So in 2008 we figured this out Rob and Barack, guys I used to

work with, and they had an iPhone and they had Super Mario on it.

And they would, tilt around this phone.

That big thick old first version iPhone, and

he would, Mario would react to the accelerometer.

At the time there was no device motion API.

This was, this was a big deal.

We're like, oh my God we figured out how to do this.

And then we didn't care.

We, went to the bar and got drunk like good Canadian kids do.

Dave Johnson, one of the guys that we work with,

was like hey wait guys I can do it with Blackberry.

Still, no one cared.

And then [LAUGH] another dude that we work with, Joe Bowser,

and do you remember that old, that first generation Android, that big

brick phone, the thing with the keyboard that made like a

fucking sound when you were, like, dealing with credit cards, like [SOUND]?

So he had that, and he's like, hey guys,

check it out, this is Android, this is the future.

And we're like [LAUGH] yeah, right, that's bullshit,

that thing's a piece of shit, there's no way.

So we were wrong about that.

But [LAUGH] he got, PhoneGap working on that.

And then we realized, we're like, oh my God, actually, wait a second.

We've got something that could be cross-platform.

So we threw it on GitHub and it really didn't matter.

Thousands and thousands of people started using it, and it still didn't matter.

No one cared.

It was kind of just a thing, it was a hack project.

And suddenly Apple started rejecting PhoneGap applications from the app

store, which was the best thing ever to happen to us.

[SOUND] We didn't care.

We thought, whatever.

We were building apps, and we liked them.

And they got into the app store sometimes.

And all of a sudden, boom, we're getting rejected.

And we had no idea why.

And we actually we're, like, well, you know?

Maybe this was like, dodgy on the acceptance rules or whatever.

So, it turns out [LAUGH] so the ReadWriteWeb

did an article, and they're like, PhoneGap being rejected!

Apple hates the web!

[LAUGH] And the internet like, rallied,

and they're like, help those PhoneGap guys!

None of this was true.

So what actually happened was, when you used to

create a PhoneGap project, it would name it PhoneGap.

Which made sense for us at the time.

And so Apple is getting thousands of apps submitted

to them called PhoneGap and they thought we were spammers.

So when they, when this article blew up and we finally talked

to them, they're like, oh, well can you just call it like, untitled?

And we're like yeah, we could do that.

And so, since PhoneGap in 0.8 in 2009.

We've been okay with Apple.

That's actually what kind of probably launched us.

In 2010 we were at OSCON cuz it's in Portland which is super close

to Vancouver and we would go there just cuz Portland's awesome.

They've got good craft beer and single origin coffee.

But we'd also go fo the open source stuff.

And we were hanging out with IBM guys.

And they're, like, hey, we're gonna throw a big team on PhoneGap.

And we're like, why [LAUGH] would you do that?

We had no idea what was going on.

They were like, no, no, no.

We think this is a legit project, and we wanna contribute to it.

And they started to teach us a lot about how open source probably should work.

Not how we thought it worked.

At that same time I started to you use PhoneGap as a vehicle to get

myself to travel to different places like Las

Vegas and [LAUGH] I ended up in Amsterdam.

And I was at a coffee shop and, we had

done a long day of training with all these different people.

And, basically, a PhoneGap training means that I have to teach you how, the

iOS SDK works, how the Android SDK works, how the Windows Phone SDK works.

And we're gonna install all that junk, and then we're gonna install Node.

And then hopefully, if we've got that Rube Goldberg machine

of things working, you're gonna be able to compile an app.

But it's a huge starting process.

So, literally [LAUGH] at a coffee shop while

I'm hanging out, I coded up a thing that,

we now call PhoneGap Build, which is a hosted

service where you can upload HTML, CSS and JavaScript.

Either a zip file or give us a Git repo and we'll compile

an app for you and give you a QR code to install it.

So, I wrote that, and we thought that was kind of funny and awesome.

Now we didn't need to install a bunch of SDKs, all you

needed was a, machine that was interconnected and you could build apps.

And we had like 80,000 sign ups in the first month,

so it went, it went pretty viral and people were stoked.

In 2011, we hit 1.0.

We finally started to find, kind of, our stride, and we were acquired by Adobe.

At that time, PhoneGap had what's called a CLA or a contributor license agreement.

CLA, it's open to debate if this thing matters or not.

Generally what it is, it's a license agreement where you say that the

outbound license, the license that everyone uses

your code, is the same as the

inbound license so you as the creator of some code, you then copyright that,

you would assign that copyright to, the

project that you're, you are contributing to.

So we had a CLA and that's a really normal thing to have in open source.

Most, probably almost all open source projects

have it, short of the Linux Kernel.

So, we had a CLA, but, it named named a

company called Nitobi Software, which just got acquired by Adobe.

And suddenly a lot of other companies that were contributing to

PhoneGap, including IBM, were like oh well so, I'm completely cool

you know, assigning my copyright and IP over to a small

company called Nitobi, totally not cool doing that to Adobe, weird.

So, [LAUGH] we decided at that time the best thing we could do

was to donate the source code of PhoneGap back to the Apache Software Foundation.

And I'm gonna talk a lot more about that.

Apache's a huge project and so in 2012 We started working

at Adobe full time on PhoneGap and it, it got a lot of adoption after that.

2013 I say optionally opinionated because we started

to carve PhoneGap up into two different pieces.

So there's the Apache Cordova project and then there's PhoneGap.

So PhoneGap is the thing I'm talking

about, it's a, thing for creating native apps.

Apache Cordova is the guts of that, it's the open source project.

Now, the difference between these two things

is actually nothing, they're the same thing.

Why is there something like that?

Well it's the same as like WebKit versus Safari or Linux versus Red Hat.

It's a downstream distribution.

I'm gonna, I'm gonna hold off on telling you what happens next.

Okay so, what, what is actually the difference between these two things.

So PhoneGap CLI, the thing showed you earlier

to build apps, has a remote build capability.

And that remote build capability hooks into.

PhoneGap build.

This thing here, so.

[SOUND] I can get

PhoneGap remote

build, iOS.

If I didn't have the iOS SDK installed.

It would default back to this.

[LAUGH] Oh, no.

Terrible demo.

Do I have connectivity?

[SOUND] PhoneGap

remote, run Android.

[SOUND] Cool, okay.

So, I'm not sure what I did wrong there.

More of the story being you can build, for

what ever platform on what ever computer your on.

So if your on a netbook.

You know, on a potentially, better connection than I have here.

[LAUGH] You'll be able to, build for iOS say, from a Windows machine.

That's kinda the point and this is our fun parlor trick.

Possibly the only cool use of a QR code ever is to dump that into your terminal,

using Antsy also.

It took us, like, months to do properly.

[LAUGH].

We super didn't care because we're like, this is rad.

>> So Apache Cordova.

>> Apache Cordova is phone gap that is the same thing.

>> And Apache Cordova is a little bit different and interesting.

>> So, let me show it to you.

>> I showed you a phonegap.

>> And all I had to was run phone gap on the command line and I got you know?

The sort of output where I can do stuff.

That's cool.

Cordova.

Really?

Well, we get to see the whole experience then, I guess.

Oh.

I'm going to install Cordova.

Totally to plan.

So NPM is the package manager for OJS.

Right now I'm downloading in the internet and possibly installing Cordova.

And at the bottom here we're linking into an

executable that's globally available which was that -G flag.

Cool.

So if I run Cordova, I get this output which is kinda nasty and big and weird.

Cordova's really low level.

Cordova is what we compose phone gap out of.

That's how we build phone gap.

You don't have to ever use Cordova if

you're not interested in it, it's just a tool.

So I can do Cordova create fubar.

And the first time I do this, it's going to have to download.

The platforms that I'm building for.

Cordova's lower level and so everything is kind of composable and you

can cut and paste little bits and pieces of it, treat everything differently.

So,

oh, fubar.

So again, totally the same thing, I've got an index.html, a www folder.

I have got these completely unnecessary type declarations.

So I am gonna go at HTML5 and kill that.

I hate that.

I don't know why.

But if I do, like, Cordova run ios, it's gonna yell at me.

It's gonna be like, oh, you can't do that.

So Cordova doesn't have any knowledge or try and help you.

Again it's low level and you can pose apps

out of it so I have to do Cordova platform.

Add IOS Android Firefox OS, whatever.

And it's gonna install and create those projects for me.

And in case of phone gap it just does that stuff automatically.

So these are the subtle differences between the two.

A lot of people build on top of Cordova and we didn't really

wanna like lock Cordova into a particular work flow because it's an upstream.

It's kinda like a gnarly, composable situation.

Now you as a developer, you may want to utilize that, though.

So earlier I glossed over this but there's this www

folder and we've got index.html in there and some assets.

We also have this platforms folder.

So inside of platforms you noticed earlier that I added Android Firefox OS in an IOS.

Each of these is a native project to that platform.

And this is sorta one of the others misconceptions about

PhoneGap people are like, oh, PhoneGap projects they are not native.

Yeah, they super are.

That's how we do it, that's how it actually works.

So this is a native Android project with native code and everything.

You can instrument if you would be so interested in doing that.

This is a part of your project we don't dictate whether or not you

wanna get in there and do native

development but it's your option to do that.

And that's how it works.

So I added those platforms whatever and then I can do like cord overrun IOS.

For example, and very much like phone gap,

it's gonna run that command for me eventually, probably.

Dump a bunch of ex-code garbage out to my terminal.

Try and find a simulator, didn't find one, some ugly guy,

not my company, slack.

There we go.

So, Cordova, different branding, same gig, if that makes sense.

So Cordova's at the Apache Software Foundation.

Apache is this non-for-profit open source foundation where code can live happily in

a neutral territory free of legal woe from other companies or any company, really.

Apache owns the trademark to Cordova.

That means that all the source code of Cordova is free and will remain free.

That's kind of important.

Apache came from the Apache web server, so it's got good web roots.

Apache claims that individuals compose the ASF.

I am inclined to believe this because you have to sign

an individual contributor license agreement or

the contribute code back to Apache.

However truthfully, a lot of organizations work with Apache.

So, the ASF, as we like to call it has a lot of

different principles and these principles are sort

of interesting and we are talking about.

The ASF believes in collaborative software development.

We believe in a commercially friendly license.

This is hugely important and different than most other free software foundations.

We believe in high quality software and we

try and get there by having continuous integration.

We believe in respectful, technical, honest based interaction.

At least that's what we say on this slide.

And we believe in a faithful implementation standards.

This was one of the reasons that we ended up at Apache.

The Apache web server was obviously instrumental

in the net as we see it today.

And phone gap in Cordova had an initial goal of ceasing to exist.

Sounds contrary and weird.

Why would we want that?

Well actually we don't want to build native apps.

We don't wanna dive into proprietary traps.

We really want is to build web apps.

Unfortunately, mobile isn't going that way and

so that's why there's something called phone gap,.

And ultimately, the reason we chose the Apache Software Foundations is

because it was a web believer, security is a mandatory feature.

And that comes back to how we do things.

Apache has all these sorta arcane and weird

rules about incubation and is actually, like, a

22-year-old organization believe it or not and so

open source has been happening for a long time.

To get into Apache is one thing and then to actually

become called a Top Level Project is another thing all together.

So when we first joined Apache we had to

go through an incubation process, which thankfully we survived.

So earlier I said individuals compose the ASF and that's totally true

but actually a lot of organizations sponsor software development at the ASF.

And the big reason for that is

the Apache software license is very commercially friendly.

And so all these company's can collaborate and donate code back to the

Apache software foundation ultimately Cordova without

any kind of legal ambiguity around patenting.

And so we've got Adobe, BlackBerry, Google, Microsoft,

IBM, Intel, Mozilla, and believe it or not LG, all working towards this end.

Which is great.

I think there's 67 sponsored full-time developers now

working on the thing called phone gap, ultimately Cordova.

So we used to have this sort of bad habit where we were shipping a lot of software

all the time but we weren't versioning it, we

weren't doing proper releases really and that was okay.

And it went on for a long time.

We actually sat on 0.8 for, I shit you not, almost a year and a half.

And so people would file bugs and we'd be like, oh it's weird, it works for me.

What version?

Oh, right, you're on the same version I am.

And so versioning we realized was actually just creating a window for bugs.

And so we adopted some people call this rolling releases or some I don't really

it, but some people call it like the agile release train, I just hate the word agile.

It sounds really like I'm trying to sell you something, but I'm not.

So, I like to call it the heartbeat of the cadence and

by the way, these slides are all online and this is a link.

Or I did a long probably kind of boring blog post about

why we ship software the way we ship it, a few years back.

Effectively, we try and ship it every month.

And so, we close the window on where the bugs could possibly be.

Sometimes, people don't love this.

So they go, you guys ship too much.

Like, I have actually heard that.

Shipping is the actually the only goal that open source project.

And by closing that window for bugs that means

that we can get consistently higher quality software releases.

If you're in one of those projects, where you're shipping once a year.

You've just created a one year window of bugs.

That's totally not actually helping your ultimate goal of

getting out there and having consistently high quality software.

Shipping more often is a good thing.

We've got rules about how to contribute effectively.

We're a GitHub project.

I'm gonna show this to you just for morbid curiosity.

If we go to github.com/apache.

You're gonna see that there's a buttload of Apache projects.

But if I filter in on Cordova you can see that we've got a lot of reposts.

I think we're at something like 50 or more reposts of good software so.

How do you contribute.

Well, you use GitHub basically.

Contributing's different than committing.

So commit rights are when you can

contribute without basically someone else merging that commit.

To become a committer is an honor in an open source project.

And it's not very hard and so, some projects have a high

bar of entry and we didn't really see the point in that.

You could have certain projects where you have to have multi-years of contributing

before you can become a committer and get commit rates and get that trust.

We sort of figured this whole internet thing's got legs and you

know, there's an audit trail built in, so we don't really care.

If you land a single commit we will

eventually give you commit rights to the entire project.

What that means is, you get a shiny Apache

e-mail address and then you can just write code.

And lowering up our entry is actually just enabled us

just to move even faster and we've got a bunch of

rules about how that works, so Apache's is cool because once

you get a commit rights at Apache you don't even need

commit rights then you become a part of bigger family and

there is a whole lot interesting projects at work in Apache

not just phone gap there's couch TO, Dupe, OpenOffice and many

many more including the web server so once you get involved

in this sort of open source community.

You really open up your opportunities as a software developer.

You can learn a lot of different stuff and you

can contribute back to the commons which is kind of cool.

Probably not a surprise, we really do love Apache and

things have worked out quite well by us being there.

So Cordova is low level and kind of hard to use,

it's not really for the faint of heart and this is

getting into the guts of how software projects work and we

also have this sort of concept of project level versus platform level.

So project level would be this guy.

Where I've got this project.

And platform level would be one of these guys.

Where I'm building a project right on the middle.

In the case of Android, I've got this assets www

folder, in the case of iOS it's in the root.

In the case of Firefox I believe it's in the root as well.

So that's the thing that they all have in common.

We don't stop you from working at the platform

level if you want to.

If you just want to build an iOS project,

you can super do that and it's totally cool.

You can even go so far as to ignore our command line tooling.

And do a painful search to find Cordova iOS and inside of Cordova

iOS we actually have what's called these bin scripts.

And so these include the ability to create

projects, emulate them and do whatever you want.

This is another kind of, interesting thing.

We, we initially built PhoneGap as this fancy web view that we stretched to

100% width and height but truly it's become more of a workflow tooling thing.

And so, it probably doesn't come as a surprise but building

projects for iOS is semantically completely

different than building projects for Android.

Like creating a project is totally different.

Android we need ant or possibly gradle.

In the case of iOs we have to use

XCode which is sort of like iTunes but it's Eclipse.

And it doesn't really matter once you

learn those things, but moving between those platforms

becomes this massive, kind of cognitive overhead

where you're like, how do I compile again?

Oh I've got to run ant.

And so, one of the things that we ended up doing was painting over the

differences so compiling emulating and logging is all

a bit normalized into a set of scripts.

We have another tool called plugman aptly named awesome

dude, plugman gives us the ability to deal with plugins.

And so this is where we get into kind of

the guts and the interesting things that phone gap can do.

Phone gaps not just a thing to create a fancy

web view that stretches to one hundred percent width and height,

it also gives you access to all of the native

features of the device that you happen to be running on.

So if you got our docks we used to have these like long API docks and.

Nowadays we don't, we just have what are called plugin APIs.

I'm sorry if this is hard to read.

But there are all these various plugins like,

I don't know, let's go to something fun.

Dialog, sure.

So.

If you go to plugins.cordova.io, you can see the current listing of all

the plugins that we've written, and other people in the community have written.

And these plugins expose native features, whatever they might be.

We turn the web view into something more powerful.

In the earliest versions of Phone Gap, when

we figured out that we could actually hook

up the web view to native events, one of the first things we did was Accelerometer.

One of the later things we did was Geolocation.

But we made up an API.

And we were like, well that's cool except that it's

not really scalable and it's not going to last, right.

If we make up some API from version to version it's not going to go anywhere.

And so we started to look through the W3C and how they built things.

And anything that has word Apache in its namespace will be an API that

probably has been sort of blessed by the W3C in some way.

Dialogues is a bad example but a good example would be geolocation.

So in Phone Gap 0.8 we implemented the GeoLocation spec.

We were the first implementors of it, we did it before the browser did it.

So early Phone Gap, you could get your geolocation.

And now that's not a normal thing to have in an

app but at that time that was exciting and new and different.

Having, like, the ability to access, you know, GPS was huge.

Interestingly, apps built for Phone Gap 0.8 run today

in your web browser because we targeted those standards.

And so implementing web standards turns out to

be a really good thing for all of us.

It ran on iOS, it ran on Android and now it runs on the regular web.

And that was kind of the goal.

That was sort of what we were going for.

So Plugman allows us to find these plugins, install them and remove them.

And you know what actually I should probably show that in action.

So I'm gonna go back.

Let's take a look at this registry.

So actually what I'll do, we'll do some fun live coding.

I'm in my app ready for Firefox OS.

Everyone's excited.

Is anyone, has anyone even seen a Firefox OS phone here?

Cool.

If anybody wants to see one I've got a few.

They're pretty rare.

It's a phone that's HTML, CSS and

JavaScript, so you can't be bummed about that.

So I'm a web developer and I'm going to do some debugging.

Hardcore Java developers would laugh once I

did that but this is how debug sometimes.

And you'll notice that I'll

phone gap run it, oh, really?

Huh.

Fubaz?

Well.

No!

Okay.

Okay, let's try that again.

Okay, I'm gonna alert, cause I'm a

JavaScript developer and that's how I debug.

PhoneGap run iOS.

Find it, we're gonna compile.

Eventually, it's gonna try and find a simulator.

It does.

Okay.

So cool.

I alerted which is a totally normal thing to

have to do to send a notification however you

may notice that there might be a giveaway in

this alert that I am not a native application.

And that super bums out your client, right?

He's not gonna be stoked about that.

Index HTML also probably doesn't build confidence in

your security of your app, whatever it might be.

And there's a good reason for that.

So PhoneGap applications run on the file protocol.

So file:// that's how we run everything.

We just look a www folder and we load what's in there.

And that's totally sweet.

Except for alerts are going to tell us that they're running from index.html.

Not all is lost cause we can run this little puppy here cordova.plugin.add.

You can also do phonegap.plugin.add.

To install our dialogue's plugin.

Which, I shit you not is going to install Native Code for Native Dialogues.

Do not look at my slack.

So I've got this, slightly different interface.

[BLANK_AUDIO]

Just gonna copy and paste cause I'm a

lazy bastard, software developer like the rest of you.

And underneath this hi, we're gonna create an alert.

We're gonna give it a message.

We are going to just.

Not allowed to call back.

Oops.

Give it a title and a button name.

Let's see if that works [SOUND].

A recompile.

Remember, we alerted once already.

[BLANK_AUDIO]

[SOUND] Macbook Air's, not super sweet for memory.

Let's try that again.

If

you're compiling stuff.

A lot, on these machines.

It's not always, compassionate to that.

There we go.

So index html.

The first time, oh, oh no.

My

demo failed.

Hm, did I save?

Nah we'd get a notification blurb, oh,

you know what it is.

Document at [INAUDIBLE] [LAUGH].

[INAUDIBLE].

>> So, yeah?

>> I think [INAUDIBLE] semicolon [INAUDIBLE].

>> Oh, no, that's not it.

That's totally fine.

It's because I forgot to, bind to a callback on device ready.

So, phone gaps asking for device ready.

Semicolons actually don't matter that much.

Douglas Crockford hates me for saying that, but it's true.

So, what are you gonna do?

I think you might have misspelled [INAUDIBLE].

>> Did I?

It's very

possible.

I did.

Add Event.

List.

[LAUGH]

[BLANK_AUDIO]

[LAUGH].

>> Wait a second.

Did I get that right?

[LAUGH] Yeah.

That's right.

Okay

[BLANK_AUDIO]

Sorry, it was a long night at the casino.

[LAUGH]

[BLANK_AUDIO]

Maybe.

Yeah.

So what happened there.

Let's take a look at that code.

If you go to GitHub.

Actually you can look in the browser, it's a, it's a

different plugin but it'll give you the same sense.

So [UNKNOWN] plugins are just like regular [UNKNOWN] kind of

apps in that we have a www folder where we put.

A little bit of JavaScript.

And that's where we define our interface, ultimately.

For the platform we might happen to be running on.

Most of this is totally uninteresting, except for this little bit right here.

Where you have this thing called exec.

And exec is how we do the binding back to the native code.

And so.

Oops.

Whoa, that was crazy.

If I take a look at this plugin code, I've

got a ww folder but I also have a source folder.

And in that source folder I have all the different platforms I support.

Including Amazon Fire OS, which is a phone you can't quite get yet.

And Firefox OS in other phones.

And if I jump into each one of these, I have native code.

Oh my God, super crazy!

And so, phone gap provides us plugin API, where

we can write native code, and we can plug

it in to any particular platform that we're dealing

with, and we can abstract that away and hide it.

And yes, this is how much code in

Objective C it takes, to show a fucking alert.

[LAUGH] [UNKNOWN] it's, it's an awesome language.

[BLANK_AUDIO]

So real talk.

I, I've shown you a whole bunch of hello worldy type of stuff.

Like I've shown you how to, basically just build something really quickly.

But is it actually possible to build an app using HTML, CSS, and JavaScript.

It is and we, we had doubts too.

Let's be really clear about this, it's not easy.

It takes, takes work and it's hard.

Your first inclinations gonna be to grab Twitter Bootstrap which

is terrible for mobile honestly, it's not designed for it all.

It's a megabyte of CSS for fuck's sakes, it's huge.

[UNKNOWN] pretty good.

And so, it's a better answer.

We created a top code as a way to look

at this problem, and to look at it very discreetly.

If we look at things like Twitter Bootstrap and

[UNKNOWN] Foundation, these are all in one, [UNKNOWN] massive frameworks,

with a ton of CSS and a ton of JavaScript, and a ton of images and a ton of fonts.

And you probably only use it for buttons.

And [LAUGH] it doesn't load well on mobile.

Weird.

So we decided to create something that was just

discreet and just CSS and addresses particular performance consideration.

When we look at performance.

You know, the network is bad.

We don't know, if we're online or offline even.

If we look at the execution runtime, it's kinda bad, you know?

We're on like, now we, we, we see quad-core phones, it does happen.

But, they're crummy.

[COUGH] >> Quad-core phones.

Layout and the Rendering, with the web.

I mean, we can't even fucking, vertically center stuff, it's terrible.

And so you look at the web and you go like wow, this totally sucks, so [UNKNOWN]

who I believe is doing a talk tomorrow, and is brilliant and is

worth your time to listen to and to learn from proposed the idea of Mobile First.

And we love this.

We're like, yeah, built for Mobile First.

And then everything's gonna be super easy.

Except, we don't even know what the fuck mobile means anymore.

It's mobile, like a computer that's on my face.

Is it like a watch, actually, there was a [UNKNOWN]

image on Twitter the other day, when someone, was like,

I invented a new smart watch, and they just drew

a watch on a wrist that said, you always have email.

Which I liked a lot.

[LAUGH] >> So what's mobile?

We don't know, and so I was throwing out the

idea that we, what we actually need is performance first.

What we need to do is think about

performance as like, kind of your fundamental idea.

When you're building your applications, we need to be fast.

Except if, if we really take performance first to its absolute

conclusion, we're gonna start writing assembler, she's not actually efficient.

That's not what people wanna do, so I was like you

know, performance first is actually kinda, not, not a cool way to

look at it, and what we, what we really need to think

about is like the people building applications, like who are these people?

Like, we need to think about the developers, is it maintainable?

Is it reuseable?

You know, can we build apps truly?

And that wasn't actually tenable either, and I

wanted all this goals and so I took all

of my new founded Adobe management experience and I

brainstormed really hard, and I came up with this.

What we need is mobile performance people first,

until [UNKNOWN] with you I didn't actually think that.

So it was productivity is an important part of this and reuse is an

important part, when you're building the applications,

you end up with, a dogpile situation.

You end up with a bunch of CSS that you included from a framework.

[LAUGH] Come on in.

It's cool.

So, so you use Twitter Bootstrap, great.

But you need a button that's slightly different in the Twitter Bootstrap button.

So, what do we all do?

We copy and paste the old button and then we change it a little bit.

Maybe we'll throw an important on there in a zed index of 999 just to be safe.

And then somebody else needs a button and so we end up with

this dogpile that is totally not actually productive, for what we're trying to do.

Lyza Danger Gardner wrote an amazing article on

a list apart called, Do as little as possible.

And being a burned out stoner skateboarder,

I am super stoked on this philosophy.

I think doing as little as possible is not

actually a way of saying I don't wanna do anything.

It's saying let's do what counts, right?

Fastest code is no code.

We had a client come to us once, by Toby, and they were

like imagine Facebook, but with like ten times as many features, on your phone.

Wouldn't that be awesome?

I'm like no, [LAUGH] that's terrible.

That's an awful idea.

We don't want that at all.

We want like the simplest thing that could possibly work.

A part of building performing apps is also measuring absolutely everything.

So these tools are now maturing a, a while ago this

was not really possible but now we can get into actual.

Performance and window timing metrics.

So, we are looking like okay, we hear everyone has performance problems.

We know that the maintenance of these things is terrible because everyone

dogpiles CSS and we also found that between Twitter, Bootstrap and three.

Did anyone do that upgrade?

No you didn't, because it sucked.

You just built other apps.

It's really [LAUGH] hard to do.

We also had other motivations in Adobe, where

we wanted to see if we could build apps.

We built a thing called reflow and a thing called brackets using

HTML, CSS and JavaScript and we wanted to build discreet small reusable components.

So our first cut at topcoat was the CSS library that gave us

lists and buttons and that sort of thing we built the Adobe MAX

application, but we didn't tell anyone that we built it, and everyone was

like, man this thing is awesome, you guys should have built a PhoneGap app.

We're like no it, it is.

And they're like no, no, this is really fast.

[LAUGH] We're like no it really is.

So Top Code's got some basic design goals.

It's discreet, it's modular, it's

extensible, it's friendly, it's open source.

I don't have time to show it to you but you can check it out at topcode.io.

If you're interested there is zero prerequisite to even try it out.

It's kind of interesting.

We built it with benchmarking in, in mind where we would take every commit and

we would measure the speed of that commit

on frames per second, layout and execution time.

All that code actually is now kinda in the browser and reusable.

And then we generate a style guide for you.

Depending on like what platform you're on and

we give you a bunch of reuse, reusable components.

We give you little code snippets where you can copy and paste from.

We had some good advice from a software developer who is much smarter than me.

He's like listen Brian, everyone is copy and pasting anyways, so

you may as well give them something good to copy and paste.

Which is, probably really smart.

So the question that I've asking lately if you look at Chrome OS, Win JS,

Firefox OS, Samsung and Intel's Tyzen and even WebOS which is owned by LG.

All of these are web based operating systems.

We think about it, Google, Microsoft, Mozilla, Intel, Samsung, and LG are

all betting on the future, of operating systems being a web based kind of future.

In the meantime, you can hit all these bad boys with PhoneGap if you want to.

Interestingly also, all these app stores are embedded web views themselves.

There's some perceived competition out there.

I don't think that's actually useful, it's an

open source project, we learn from each other.

That's sort of my take away on that one.

But we've got a bunch of tools and

outputs that you can check out if you're interested.

We're very empirical, we have the idea of performance built into what we're doing.

You can use all of it or none of it.

And, you should just go and build a kickass app.

[APPLAUSE]

We maybe have like a minute for questions, or you could just buy me a beer later.

Or I'll buy you a beer really.

And I owe Cable guy a beer.

So thanks.

Does anyone have a question?

Do like one or two.

Yeah.

>> I already have an app.

How much work.

I wasn't planning on going mobile, but I want to know

how much work will I have to do to get ready

>> Is, is it a single page web app?

>> It's, it is.

It's a media app.

>> Yeah, it will work.

You'll have to be responsive to a handset form factor or

possibly tablet if that's what you're going for, but that's it.

Yeah, one of the interesting fun things

that we learned by stretching that web view.

Whereas, you know, a web view that stretches

so any kind of responsive design programming style will

work inside a PhoneGap the same way it would

work as you were building for a regular browser.

Yeah, it's, it's, it's literally ten minutes to figure it out.

We have an app in the app store which

I should have mentioned If you go to app.phonegap.com.

And you install, one of these apps for one of these platforms.

You compare it to your local machine and try PhoneGap without installing anything.

It'll take you like two minutes.

So, maybe you can figure out if it works.

Yeah.

>> If you have a mobile website like.

[INAUDIBLE] our app in the mobile.

Is there any [INAUDIBLE] in using PhoneGap to make [INAUDIBLE].

>> It depends.

I, I don't like people doing that truly but my opinion is extreme and

harsh, but I know, I think these app stores are an aberration and a mistake.

I don't like the idea that I have to pay $100 to

Apple to build something to a device I already fucking own, but.

You know, the app store is a discovery channel.

So, is, is it worth it?

Probably we've got examples of PhoneGap apps that I, you know, I would preferred

they didn't exist but they, they do like 5,000 downloads a day or more.

So, yeah.

It's probably worth wrapping.

It's a discovery channel.

I don't like it, but that's how it works.

I used to, I used to say device APIs

and offline were important, but the web has caught up.

Sorry.

Yeah.

[INAUDIBLE].

>> Yeah.

So we, we work with all [UNKNOWN] earlier I was sort of joking about how

Like, here's my project fubar, and I've got platforms

iOS, I can jump in there and launch Xcode.

If you haven't seen Xcode, it's basically

like, imagine if Eclipse looked like iTunes.

It's just a native project so you can totally

use all the native tools that you want to use.

There's nothing stopping you.

And we can compile from here.

>> Nothing?

>> Debugging, everything, yeah.

[BLANK_AUDIO]

>> Yeah, Eclipse, or Android Studio if you hate yourself.

You can use all those tools.

[LAUGH].

>> Yeah?

[INAUDIBLE].

>> Sorry?

[INAUDIBLE] >> yeah, yeah.

So there's, there's plugins to do that for various platforms.

Totally.

In fact PayPal uses PhoneGap.

So [INAUDIBLE].

[INAUDIBLE].

>> You would, and you would have to do that

if were writing native code too, so, there's no difference there.

Yeah.

[INAUDIBLE].

>> We have an upgrade command it's not always compassionate, truly we play

cat and mouse right, like we are, we are always chasing whoever updates last.

And iOS 8 is, you know, our latest bug bearer that we are dealing with.

we, the upgrade command probably will work between

versions of an operating system, but in a major

upgrade, like iOS 7 to iOS 8, you'll

probably just be able to reuse the ww folder.

The platform folder you will probably have to blow away and re, re-add.

[INAUDIBLE]

>> Again, we keep those all updated, and it's the same situation.

You'll have to blow them away and add them again.

But I, we try and treat platforms and plugins as build artifacts.

We let people still modify that because we don't wanna get too, into it.

Yeah.

You can, keep those around and upgrade them if you want to.

Oh, I'm getting kicked off.

Thanks everyone.

[LAUGH].

[APPLAUSE]