Click on any phrase to play the video from that point.
[sound effects]
[ADOBE] [DEVELOPER CONNECTION]
Hi, I'm Adobe Developer Evangelist, Kevin Hoyt.
One of the big pieces of news coming out of Adobe MAX this year
was Adobe's intention to acquire Nitobi.
Nitobi is largely the spearhead behind the project, PhoneGap.
Now, if you're wondering why that's exciting, let me explain.
When you develop for mobile devices today,
you have to consider a number of different options.
If you're developing for iOS, chances are you're going to want to learn Objective-C.
If you're developing for Android, you're going to want to learn Java.
And these are already going to present for you 2 different code bases
to cover the majority of mobile use cases.
If you're going to use and/or develop for a Blackberry device,
your going to use Java again, but it's actually a completely different API,
and, rather, a different subset of Java so you have yet another code base.
And this kind of goes on and on and on for all the different devices you want to reach.
One of the interesting things about all these devices, though,
is that they have a modern version of WebKit.
And WebKit is the rendering engine behind Safari, Google Chrome,
and has a lot of the latest and greatest in cutting edge--and bleeding edge--features
of the HTML5 Web Standards, CSS3, and so on.
So why is that great?
Well, what PhoneGap does is it lets you take that WebKit rendering instance
and use it as a captive view for an application.
So you develop with Web Standards, HTML, CSS, and JavaScript,
but yet, are able to actually package that up and deploy it to the application storage
as though it were any other native application.
Now, along the way, you get lots of different benefits from this.
First off, the most obvious one is the capability to use skills you already know,
capability to use that code for 1 code base and be able to reach many devices all at once,
and potentially even be able to reuse many of those assets and code base features
for your Web presence, whether that be a desktop or mobile Web browser presence.
So that really enables you a high degree of productivity in producing
all kinds of Web Standards-based content--
so being able to reuse that content across multiple screens.
Now, you might say well--why do I want to use a native application
and have a Web Standards view.
Isn't that really just what the browser is?
And to some degree, that's true.
In fact, if you're thinking about building an application for these various devices,
leveraging PhoneGap, 1 of the things to consider is
is whether or not maybe the browser would be a better place.
Now there are certain instances where having a native application
provides different features that may be more compelling for your use cases.
So as an example, if you need to provide offline support.
A browser is really going to rely on you being more connected.
A native application is going to really allow you to leverage a lot of local features,
to be able to use that data offline,
the capability to use certain native APIs.
So if you want to record audio or capture camera or video feeds--
those types of things that are generally available to native applications
become available to you as a PhoneGap application
that are generally available in the browser.
So those are some of the different situations.
Another situation, obviously something that you should be considering is modetization.
If you're building it for the browser, you're modetizing those traditional formats.
If you want to be able to sell an application, and put that in the various stores
and market that application and then modetize it,
then that's something that PhoneGap will enable you to do as well.
Now, before you get started with building any PhoneGap applications--
and we'll take a look at that in this series--
it's important to consider the actual devices themselves.
So the first thing to think about is that when you're a developer,
you're going to be looking at your computer screen and you have a user interface
that is--if you're in a darkened office, for example, isn't going to present any glare.
But as soon as you take 1 of these guys out into the world,
you've got the sun, you've got clouds--
maybe you're in an office building where there's
a foyer, there's all kinds of different reflections coming off of the surface.
So that makes it very difficult to use.
So be considerate of your users--don't put small fonts in there; be careful of the contrast
to make sure that that's very clear for your users, and so on.
It's also important to remember that different devices come in different sizes.
So, as an example, this is a Samsung Galaxy Tab 10.1
and across the top here, it's 1280--it's 1,280 pixels.
This is a little bit older--a Motorola Droid X--
and this guy--across the top here, if I lay it landscape, just like the tablet,
is 854 pixels across the top.
So how can this guy be just a little over half, and be 854 pixels,
but this entire width be 1280 pixels?
And that gets into the pixel density or how tightly packed those pixels are into the screen.
So you need to consider both the device you're targeting and the pixel density for that device.
If you put something on this guy that's 40 pixels by 40 pixels,
it's going to look different on this guy if it's 40 pixels by 40 pixels.
So it's important to test.
And yet another example of these different devices is how they get used.
So this Samsung Galaxy 10.1 is designed to be held in a kind of a landscape mode,
but the original Samsung Galaxy Tab is definitely aimed at more of a portrait use case.
So how will your user be holding the device,
how will they be using the device,
and what will they be using it for--when, what time of day, will they be using it outside?
Will they be using it inside?
All kinds of different form factors, and then, you know--this Samsung Galaxy Tab 10.1
is a kind of a letter box form factor.
By comparison, the iPad is definitely more rectangular, more of a square form factor.
It's a different aspect ratio to consider there, as well.
So not all of the devices are the same,
and you need to be very considerate of that for your users.
Now another thing to consider is that when you're developing on your desktop,
and you say oh, yeah--I'm clicking on this button in my user interface, that's great.
But on this guy, if I click, I'm using my finger--
and my finger is not as accurate as that mouse is.
Additionally, my finger comes with a whole hand, right?
And that's going to block out certain portions of the user interface.
So you need to be very careful about where you position the various values
you're displaying to the user, and how they're going to interact with that user interface.
I always like to judge--say, a finger comes with a hand, as they say.
It's also important to remember that this guy, as an iPod touch, runs iOS
and this guy--this Droid X---with Android.
iOS is not Android.
Your users actually go out of their way to learn
the different mechanics behind the different user interfaces.
So on an iOS device it's very typical to find a Title Bar at the top,
and usually, as you navigate deeper into screens, there's a Back button
on the different applications in that Title Bar that lets you go back into the different views.
That's what you find here.
But on an Android device, there is no Title Bar,
and there is no Back button on the actual Title Bar--because there is no Title Bar--
or in the application itself.
In fact, here there's actually a Back button that's a hard button--a physical, actual button
to depress--to go back.
So your users have figured that out.
But if I'm an Android customer and I'm using this device,
I know that I'm going to click that Back button.
When you present to me a different user interface--one that you designed for iOS
because you think iOS is great and fancy and shiny, which--that may be your preference.
But, as the Android user, I'm going to get kind of upset because you're telling me
that I have to learn an entirely different user interface now.
You see this, actually, in a couple of different form factors.
You can see it in, for example, a lot of the JavaScript frameworks
will actually present Title Bars and Back buttons as iOS, even on Android.
So you need to be aware of that and be very careful of that.
Even within the kind of context of the hard buttons that the Android devices have,
they're not all the same icons, and they're also not all the same order.
So again, your user has really gone out of their way to figure out how to use that device.
Respect that, and present them with the user interfaces appropriate for their device.
So that's a little bit about thinking about these devices,
a little bit about PhoneGap,
and what we're going to do next is actually tell you how to take PhoneGap
and get them on some of these devices,
and start enabling you to think of Web Standards and deploy mobile applications.
We'll see you in the next session.
[ADOBE] [DEVELOPER CONNECTION] [sound effects]
