I/O BootCamp 2011: Beginner's Guide to Android

Uploaded by GoogleDevelopers on 10.05.2011

>> BUTCHER: Okay. Let's get it started then. So, welcome everyone to Boot Camp and this
is the Beginner's Guide to Android talk. I hope you guys are on the right place. As Tim
ably said in the--in the introduction. This--today is all about kind of getting you up to speed
so you kind of know everything you need to know. So, you can get the most out of IO.
So, this talk is really pitched for someone who kind of knows what Android is but has
never developed for it. My name is--my name is Nick Butcher. I'm a developer advocate
out of the London office and I work on Android. And I love writing Android apps and I hope
by the end of this you will too. And--and we will also put in some hashtags here so
you can join the conversation and chat about what's going on. So, this is the speakermeter.
So, as Tim said, this is a kind of experiment this year, we really will hope you--you can
use it. So I’ll leave it up there for a minute. This is a short code, just there so
if you haven't QR [INDISTINCT] camera app, you can tie that in. And also for this link
up at the end, if you want to wait to the end, to leave your feedback, that's absolutely
cool. So while people are snapping that picture, just want to get a quick idea of who is in
the room. So, could you put your hand up if you have written an Android app before. Okay.
Cool. And put your hand up if you've kind of--had an idea for an Android app but never
had the know-how to actually write and execute it. Excellent, so you guys just--is going
to get the most out of this talk, I hope. For some of the people that are more experienced,
I hope you pick up a few tips and tricks along the way. But I'd really recommend you go to
the Android best practices lab later on today, which is really going to teach you some--some
really good techniques. And also we're going to be running an introduction to honeycomb
lab later on. So, if you can see if you're getting up to speed with tablet development
then that's the place for you guys. Okay. So, today I'm going to talk a little bit about
what Android is and what the Android platform is and how you develop for it. I’ll talk
about writing your first app. So, what is an app, I'll go through the anatomy of what
it is that makes up an Android application. I’ll talk about the ways you'd go about
building it. And then go and to talk a little bit about some of the unique ways that Android
lets you surface your content, access hardware sensors, and then how to make, you know, not
just a good app but a great app. And then go into--talking about the tools you can use
to build these applications and finish up by going through the process for publishing
your application on the Android Market. So, Android, it’s a bit of a juggernaut, it's
in the kind of newspapers and tech press all the time; 170 plus devices, 100 countries,
and shipping 350,000 devices a day. That's kind of a [INDISTINCT], kind of staggering
number to me, I feel. My colleague would sit here last year, saying you know, proudly at
60,000 devices a day and now we're up 350,000. So, you can think about the--the slant of
the graph and the trajectory they're on. A little bit of mental arithmetic for you, that's
over a million devices every three days. This really speaks to the opportunity out there
and the reach you can have in writing an application and shipping it. The same thing, that got
kind of a size of opportunity can seem a bit daunting as well, when you think of the variety
and number of devices out there. But the great thing about writing for a platform rather
than through a device is that every device which has the Google services--so, that's
like Android Market, and Gmail, and Maps for example, and everybody wants those--has to
pass a compatibility test suite. This guarantees that any app written against RSDK will run
on those devices. So, it's our way of kind of making it easy for you to write to the
platform rather than have to worry about individual device characteristics. So, we build in tools
to help support many different screen sizes and resolutions and font factors and hardware,
and variety, and the system that you take advantage of those where they're available.
Android Market also helps you out by filtering based on what their phone--the applications
running on and supports--so yeah, if you write to work to the platform, you don't have to
worry so much about the underlying phone. With that said, the platform isn't a static
thing. You are probably aware that Android team’s hard at work, releasing--new platform
releases every kind of three to six months, so we've just had--Honey Comb came out for
tablet not long ago and the end of last year it changed a bit for phones. And we'd advocate
always kind of targeting the latest and greatest so you can take advantage of all of the new
shiny APIs that get released. But we can teach you techniques to gracefully degrade your
application. So, if certain functionalities aren't available in an older platform, you
can greatly degrade and perhaps use another technique. So, for example a multi-touch got
introduced at some point. So you can detect at run time in the application if the device
you're running on supports that, and if so, enable a multi-touch kind of control or else
you can pull back and perhaps offer buttons or something to offer the same functionality.
So writing your first app, so an Android application is really kind of a series of components,
it's all about kind of loosely coupled components of an android and the thing which holds them
all together and makes them into an application is the AndroidManifest file. So I'm going
to take through what are these components that make it up so the four major ones being;
the activity, service, content provider, and broadcast receiver. And I'm going to take
through what intents are and why that it's so key to the Android system and then comeback
around to the manifest and how you string these things all together. So first up is
the activity. This class is how you write your user interface. So a single activity
defines a single screen. Activities are kind of independent and you string a series of
these together to form a cohesive whole, for a whole application. And it's possible to
invoke these activities from within your application but also from within other applications. So
in that way, you could expose functionality from your app to other applications and you
can borrow functionality from other applications of from the system within your app. Every
class that you write for an activity should extend the activity class and you get a bunch
of methods there to help you do your UI. The next major component I talk about is the service.
So a service is the--what is the heavy lifting or the major--the majority of your processing
in your application so it's going to run all your kind of long range tasks or so on. So
a service doesn't offer any user interface but it kind of--is the kind of logic behind
that. And other components combined and interact with your service. So a great example of this
is if you're going to write a music player application for example. You might write the
user interface as--well, you will write the user interface as an activity offering, you
know, skip, play, pause controls for example. But then you’d use a service to actually
control the music playback itself. So if you use the start playback in the activity and
then leaves and goes and checks their email or browses the web, the service carries on
running the background and keeps on playing the music. The next component is the content
provider. So a content provider, it says here, manages a shared set of application state.
So it's really kind of a façade in all of your persistence of any data. It provides
a consistent interface to the Android system and to the rest of the world on how to interact
with your data so there'll be that querying, storing, updating. So it eases, sorry, exposes
CRUD type operations. It's also a restful interface so every unique entity has a URI
associated with it and then you can perform operations upon those URIs. So underneath
this façade you can back it with any kind of store so commonly it'd be a SQLite database
but equally, you could back your content on the file system or on the web, it's up to
you how you implement it. And you just expose this consistent interface so the system knows
how to talk to other apps and know how to talk to it. Content providers allow you to
expose data from within your application to other applications into the system. So for
example the system makes extensive use of content providers in this search infrastructure.
So when the Android finally hit search and you can search for your data on the device,
it's because of this consistent interface that it knows how to search an application
you've just installed for market and how to query it. Equally the systems exposes its
data to you as a content provider so in your applications that you write, you can do things
like query the contact system or the call log or the music in the device, or the pictures
on the device because of this consistent interface. And the next major component is the broadcast
receiver. So as I mentioned then, Android applications are kind of loosely coupled components
talking to each other. The way they listen to things, to messages between each component
is the broadcast receiver. So you can respond to system-wide messages. So if a text message
comes in or a phone call comes in, a message will be broadcast to the system and apps can
respond and offer functionality based on that. There are two major types of message that
can be broadcast; first one being the normal broadcast which is delivered kind of asynchronously
to all receivers in no guaranteed order or there's an auto broadcast which you can say
set a priority in which the messages will be sent out. So an example of this is if you
want to write your own message for handling an SMS for example, URI application for handling
an SMS. You might want your application to handle it rather than the systems built in
one so you can register with a higher priority, catch the message that a new SMS has come
in and say it's handled so it doesn't carry on propagating. Broadcast receivers can be
registered to listen for certain messages either statically, so you define it in the
Android manifest or at runtime so you can dynamically start and stop listening if you
wish. BroadcastReceivers are just that, they're just listening in for messages. They shouldn't
really be doing lots of heavy lifting and processing. So once you've kind of listened--listened
out for message, you want to hand off any long running tasks to a service to process.
So there's four major--the four major components. Now, intents are the magic that kind of glues
this all together really, if you will. There's always an intent for--for launching and talking
to different components in your application. So when we say BroadcastReceiver listens for
a message, that message itself is an intent. Now these intents can be explicit or implicit.
So an explicit intent is like an explicit message. You just kind of--it says exactly
who I want to deliver something to. So if I have an application made up of two screens,
screen A and screen B, and in screen A, I click a button which should take me to the
second one. I can explicitly address it to launch screen B. So clicking that invokes
screen B and it launches. More interestingly is the--interesting is the implicit intent
system. So just by describing something you would like to achieve, so an action you'd
like to perform upon some data with some extra Metadata, and then handing out to the system
and asking is there anything installed on this device which can handle this action on
this type of data. So by standardizing on a set of common actions, so you know, I want
to view this data. I want to send this data. I want to edit this data; you can have lots
of different and unforeseen applications handling a standard message. So a great example of
this is photo sharing. If I had it write an application and which kind of, can take photos
and then share them, you know, I could think about all the possible ways, you know, places
I want to share that photo to. You know, I could write in Facebook sharing, Twitter sharing,
Buzz sharing, but more interestingly I could just say I have this data or type and photo
and the action I want to perform on it is share, and hand it over to the system and
say, "Hey, what's in store that can handle this intent?" And then, you know, the user
could install you know, obscure or kind of different social network or whatever the site
that they want to share it to, and that application can then say, "Hey, I know how to handle a
share action on that picture. Let me do it." So by doing this and kind of standardization
on actions, you kind of can have this unintended and the uses of your data is great. One of
my favorite examples of this is an out patient called barcode scanner, so barcode scanner
had said, "Hey, I got this kind of great use case of scanning barcodes and it's really
helpful," but what--wouldn't it be even greater if I can offer up this functionality to other
applications? So what they did is they standardized on an action and published this action out
on their website. And now, other applications are free to invoke this application. So the
way they do that, and so for example, this is one of my favorite greater apps in the
U.K. called [INDISTINCT]. So [INDISTINCT] wanted to offer the ability to add groceries
to your basket by scanning a barcode, but they didn't have to write their own barcode
scanning software, which is quite complex. They simply click on the barcode button and
this will invoke the barcode scanning application which will do the work of scanning the barcode,
and then hand back to the grocery app to add it to your basket. So it is a pretty complex
task, I guess, scanning a barcode. But it can be achieved very simply through the coding
application. So the grocery apps, this has to include some very simple, you know, not
huge amount of code for quite a complex interaction in order to accomplish it. So going through
this, this is one of these explicit intents I mentioned earlier. So when we create the
intent, we know exactly the action we're trying perform to this Android.scan action. And we
set the package which we know we will perform it. We can then send some extra Metadata,
so we're saying here that we want to do a QR code type scan. We then do a code to start
activity for result passing in that information we just set up. So what this does is it's
going to start a component written in an entirely separate application and run it. Now to the
user, this is completely transparent. So I just think I'm in my grocery app. I just hit
a button and the barcode scanner comes up. I've got no idea that the developer or the
grocery app didn't have to write this barcode app. It's kind of seamlessly integrated. So
the user just to work, it takes a photo of the barcode and--and finishes scanning, and
the result gets returned back to the coding application. So here we can check some things
like make sure that it completes successfully by checking for the result, okay. And then,
grab back from the intent, the results this is the actual code that they scan. So in very
few lines of code, you've got this quite complex interaction all powered by intents. So, wrapping
this back up together and coming back to the Android Manifest, so, the Manifest declares
all of the components within your app. This is where you're talking to the systems. When
the user installs your apps, you're saying, "Hey," this is what my application is actually
made up of. I have this many activities, this many services, this many [INDISTINCT] for
example. It's also an opportunity to declare the features that your application requires.
So, if you need Internet, for example, or if you require GPS hardware, then you can
use the Android Manifest to declare there and then what your application requires to
run. So, the system knows how to run you as well. You can also state what versions of
the Android System you require for your application to run. More interestingly, you can actually
say the lowest version you require to run but you are also aware of a high version.
So, you can say a target SDK or say the latest and greatest, say, Gingerbread. But I also
run incompatible all the way back to say, cupcake. So, by doing this, you're essentially
completing a contract saying I won't use any of the newer APIs when I'm running on an older
version. So, when you're writing an app, it's really important to remember that you're running
on a multitasking environment. Mobile phones and tablets are kind of multitasking devices
with lots of things going on at once and often quite memory constrained. So, users will switch
between new applications all the time. The system is going run low of memory; calls are
going to come in. So, your application, when you're writing it, you need to be aware that
you're in this kind of busy environment and be able to handle it properly. The system
will call into your application at a series of kind of callback events to let you know
when these events happen. So, it's really key to remember that at some point, the system
will kill your application. When we were writing our amazing apps, it's kind of really kind
of nice to think that the user is going to sit there in full concentration just use the
app as you kind of intended, and then happy days, finish, and they're done. But in reality,
there's going to be 101 things going on at the same time. So, the key thing, I'm going
to walk through this activity lifecycle in a bit more detail. But the key message is
to respond and work with the system activity, the system lifecycle. And make sure you save
your state, for example, so that if the user comes back your application that has been
killed by a system, they don't get surprised and say, "Hey, where's my data? I was in the
middle of something“ So, when you launch your--an activity for the first time, and
the activity is created, you'll get a callback into your applications onCreate. This is kind
of similar if you've done some Java programming to kind of your main method. It's the first
entry point and it's your first chance to do any kind of set up and initialization logic.
You then get a callback into the onResume method, which is just before you're about
to become foreground and then you’re activity to be running. So, if while your activity
is running, say, a call comes in or they switched to another application, the system will them
let you know that that's happening to your application. It's no longer going to become
foreground. So, we get a call back to--your application's onPause. This is key like in
onPause, you definitely want to be saving all your state so if a user comes back to
your application at some point, it's still in the state that they thought it was in.
There's nothing worse than kind of, you know, I was playing a game or something like and
then the call comes in and then I forget I was playing the game and I surf the web. And
I come back to the game, and it's kind of I've lost all my progressing, I have to start
again. I mean, that's an example of someone not using onPause properly to save the state.
So, if after the calls come in and user just comes back to your app straight away, you
going to get a callback to the onResume so then you can just make sure that the application's
in the right place. But if they don't come back to it, so they go off and stuff [INDISTINCT]
whatever and the system and--starts running low on memory; t's going to kind of kill your
application, it's going to reclaim some of that memory, it's going to stop you. So, the
user should be completely unaware that this happening. So, if your activity gets destroyed
and then the user later comes back to launch your application, it should be like it was
just sitting in the wings waiting. So, when they go through the onCreate again and onResume,
you need to be grabbing the state that you saved in onPause and just set it up like it
was just waiting for them. So, the next step, I want to talk about something unique ways
that Android lets you surface your content to the user. Android’s got a really great
notification system. So, you can throw up notifications up into the top bar as I've
highlighted here. And if you show like an icon, you can buzz the device or flash a light
if it has one and you can also have some scrolling text going across, or if you pull the tray
down, you can get some expanded information. So, these unobtrusive notifications are a
fantastic lifeline for kind of these busy lives that we lead with 500 apps installed
and things. I don't want to be going into my apps and to check it, I want the app to
let me know whenever that happens. So it lets you kind of create invent-driven and kind
of models so that the user can come back whenever something interesting has happened. You can
also provide quite a lot of information for them. You can provide custom views in this
expanded tray so if you want your happy application show up progress bar or something to let these
and know that something is going on. You can also deep link to a place within your application
with setting one of these in 10 objects--a pending intent onto the notification. So it
doesn't have to take them just to the front screen of your application. It can take you
right in there. Widget. It's another strong feature of Android. So many times, I'm using
my phone and kind of, you know, you're bored on the bus and you just kind of playing around
on the homescreen. And by letting you put your applications data right there on the
user's homescreen, it stays kind of forefront in their minds. You can have the data on there
widget updates regularly so it doesn't have to be just static information, you can update
it when events happen and--or just on time basis. You can also offer multiple widgets
for your applications. So one application can have, you know, a large widget, a small
widget, a widget to show this type of information--this type of information and have interactivity.
So this music play widget example lets the user can of kind of play the music or just
skip the track, go right from the homescreen. So it's a great way to drive user engagement.
We find applications which have--widgets included in them have high use rate, people kind of
keep on coming back to them and then [INDISTINCT]. And people love them, they're fun. And next
I’m going to talk about cloud to device messaging. So this lets you reach in from
your service, kind of--right down to the Android application and kind of send it timely messages.
You can send, like, tickles. It's got a very small payload but it's very timely and a very
fast [INDISTINCT]. So you can use this to kind of push messages down to the device.
So your application doesn't even have to be running when you want to send a message to
it. If it's not running the system, it will wake up your app and deliver the push message
straight to your application. And then it's up to you how you respond. There's no, you
know, pre-defined UI. You don't just get a model dialogue popping up or whatever saying
something is updating. It's up to you. So if, for example, you're writing a messaging
app or, say, a news app, you can have your service, ping the Google cloud to device messaging
services which will reach on to the device and wake up your app and let it know there’s
some new content. Your application then wakes up and it can then retrieve that content straight
down from the Web server and let the user know, perhaps using notifications. Because
it's built on top of the existing Google messaging services, so the same thing that Gmail and
Google Talk uses, there's minimal effect on the battery. You're not keeping other kind
of persistent channels of communication open between the device and the cloud so you're
not going to be hammering the user battery. Okay. So we've talked about some of the cool
features in Android. I'm going to talk about how you can go about building them to create
your app. So building your apps UI is kind of very important so the user interface is
a hierarchy of widgets which extend the view and view group classes. So you can define
this in code, and create them all in code but it's much cleaner to define your layouts
by XML. So on the left here; we have an example of a layout. So this has got linear layout
which includes a label and a button. So a very simple, very clean to define your layout
and then the system will kind of inflate that layout into a series of these hierarchy of
these objects. So Android, by default, comes with a pallet of widgets which you can use
to like delineate out the text in the button. You can also create your own components to--if
you need some richer controls or combine existing ones into kind of custom component. So once
you defined your layout, you can then tell your application how to use it. So in an activity
below, we're calling the method set content view and pausing it, identify it, so it says
here [INDISTINCT] main. So imagine the XML file above was called main.XML. Then the code
below is telling the application, this is the layout that I want to use for my display.
So we're without [INDISTINCT] so anything that's not codeless in a res folder in your
Android project. So in here, we have a folder for layout and there's a main.XML. So, right
there, you can define your applications layout. More interestingly, the resource's folder
lets you provide qualifiers to provide different versions of resources for different configurations
or device. So just beneath that layout photo here you see there's a layout-dash-port. What
this means is allowing—we’re specifying a completely--a different layout for a device
when it's running it in portrait mode. That means rather than the default one in layout
mode. So at runtime, the device will know that--what configuration it’s running in
and grab the right resource appropriately. This is really powerful when you think about
all the different--and so when you look at the different qualifiers that you can use
so as well as orientation, you can use the density of the screen that you're running
on. The size of the screen so if you're running on, say, a small device or an extra large
device, you can have different lay-outs or different image assets or even if you have
a--you're running on a different language of device then you can provide different strings
for example. So looking how--out there what devices on the market, there's a huge variety
and kind of sizes and shapes and capabilities. So you've got, you know, your tiny little
phones to regular phones to tablets. Even to apps who kind of Google TV. So you have
to think about these devices and how your applications will run on them. So supporting
multiple different screen sizes, there's lot of techniques built into the Android platform
that will help you out with that. So one technique I definitely advocate using is the relative
layout, so doing kind of a slice things in exact, like, pixel dimensions. Using relative
layouts you can say, "I want this kind of to the left of this component, on this right
of the component and this taking out the rest of the room." So you're not going to constrained
by fixed dimensions. You can use attributes such as wrapping content and matching the
parent and weights. Say, this one is take up a third of the screen and this is to take
up two-thirds of the screen and this will help to keep your layouts to scale appropriately
and no matter what the device. Another great platform feature is the DP or the density
independent pixel. This lets you say, "I want this to be a hundred pixels when it's running
on a medium density screen for example." If I'm running on a super-high density screen,
I want it to be sized slightly larger. So the physical size of it will be the same even
though the pixel size is larger. So techniques like this kind of think web style development,
so you have kind of fluid layouts that will scale no matter what the size Window it's
running in. You can provide--using the resource framework that I talked about in the last
slide, you can provide specific density assets. And so, on a high density screen like, say
the Nexus S, you can provide a higher resolution image, so it looks great on that screen whereas
on an older G1, you might want to provide a lower res image, so it's not taking as much
size. You can use then the resource qualifiers provide specific layouts for different devices.
So, if I--if your application is running on a Motorola Xoom for example, you can use a
layout-xlarge to provide an optimized layout for that larger device. Another great technique
is a 9-patch drawable which is a system of specifying which parts of your image assets
can be stretched and which should be rendered as is. So this lets you say, you know, create
a [INDISTINCT] by saying the corner should be rendered exactly as they are but the middle
bit can be stretched out. And what I'm here I’d say if you're interested in learning
some great techniques about this, you should go along to the best practices, Android best
practices code lab later on today that--which you're going to look much in more detail about
how to use these techniques. So, one of the most interesting things about writing Android
applications at the moment is the devices that run on have these fantastic hardware
sensors. So, you know you have access to cameras, to accelerometers, G meters and light meters.
So all this kind of like really fancy kind of sensors that haven’t been available to
us in software development on desktop devices, enable all kinds of interesting applications
to be written. So, using the Android system you can use the sensor manager to find out
what sensors are available to you to your application at runtime. You can then register
listeners to listen up for updates so you can get hold of a G meter and listen for changes
in orientation for example. So, yeah, and really think about what sensors are available
in devices now and what's coming and how you can really use that to make a really kind
of compelling application. Another Android strength is its ability to do background tasks.
And when I talk about background tasks, I don't just mean kind of multitasking. I'm
not talking about listening to music and reading your email. I more mean then system's ability
to accomplish a task without any interaction from you. So you can use the alarm manager
to schedule your application to wake up and perform an update without the user having
to interact with it. So think about if you write a news application or something which
grabs content from the web. There's nothing worse than like putting out your phone, opening
in application and seeing, you know, a model loading dialogue or nothing's happening. Or
if I pull up my phone and I have no an out coverage, you know, and it doesn't let me
even get access to any items, it's so frustrating. There's no--especially because there's no
reason for it. Using kind of background tasks and periodic updates, your application can
wake up in the back--in the background, grab content so it's right there ready to go fresh
for the user to use when they want to. So this is great. So it's available offline and
it's always kind of up to date. There's another point, it’s one of my favorite features
of the system that you also use; inexact alarms. What this means is you can, you know, you
might be worried if you have 50 Apps installed in your device all doing this kind of waking
up in the background and checking content that your device is going to be awake most
of the time, it's going to have harm your battery. But the system gives a system called
inexact repeating alarms which will actually phase shift your alarms to all coincide and
go off at once so that it has minimum--it minimizes the effect on your device so be
kind of friendly to the user. Next step, Android makes it really easy to make an accessible
app. So using things like setting the content restriction--description on your content and
works well with the kind of screen reader technologies, it also--Android also fully
supports and navigation by dbol and trackpad, so as a developer, you have to be aware of
how to implement this. So setting appropriate drawables that respond to the states when
a control is selected by the D pad to kind of indicate that selection. I definitely recommend
you go to the new best practices on accessibility section and read up on how to make your app
accessible or better yet, try it. If you install the talk back application, you can try to
navigating the application in kind of accessible mode and see how it is for a kind of vision-impaired
user. Next, I will say that there is over 150,000 applications in the Android market,
150,000. And so how do you stand out, I mean, the way to do that is to single quality. And--so
using the techniques we talked about before, this is how you kind of like get users to
realize your App is well made. So work with the activity life cycle. Make sure your App
isn't kind of dumping the user state when it kind of gets killed off by a system. Offload
any long running tasks into the background so that using the service, so that they--the
user interface stays buttery smooth. Users have very low kind of tolerance for any latency
in the user interface so make sure that any kind of long running task or processing isn't
happening on the UI thread that you handoff to the background. What's more, listen to
your users, have a conversation with them. The Android market offers them feedback on
your application so you can leave comments on your application to they let you know what
they think of them, sometimes they're quite colorful. And better the yet, you can offer
your own feedback mechanisms so if you set up your own kind of forums or kind of stock
exchange or some kind of technique for having a feedback mechanism so your users can say
what's working for you. You know, as the writer of the App, you know exactly where functionality
is and how to use it, but you might not realize that it's not obvious to some of your users.
And to that end, work with the design otherwise advocate. As developers, sometimes we're very
keen to run 100 miles an hour and get as much cool functionality into an application, but
if your application isn't usable or aesthetically pleasing, your users might not find it or
keep coming back to it so it might be wasted. Also to put skin to wonderful applications,
here's the tools you can use. First up, you want to go and grab the Android SDK. So this
SDK will have all the kind of tools you need for building your applications as well as
things like the emulator which will let you run the application without the device and
tools for your signing your application when you come to apply them. There's a very polished
tool changers built around Eclipse which is going to make your development life really
easy. So if you install Eclipse and then grab the Android Development Tools plug-in, this
is an Eclipse plug-in which will make it really easy to build your code against the SDK to
deploy it onto a device or onto the emulator and interactively debug it. With these four
other tool changers as well, so IntelliJ or just using an [INDISTINCT] for example to
build these completely fine and lots of people like that. But for new people who are getting
up and running, Eclipse is definitely going to be kind of at least--path of least resistance
to getting going. Once you have the ADT installed, you can use the SDK and AVD Manager to kind
of grab all the latest versions of the platform. So when we're releasing a new version of the
platform, so when Gingerbread came out for example. Or we're releasing an update to the
SDK so you can build against these new APIs that's just been released. And--again if you're
getting started, these slides will be online, I'd advocate you go to--towards the full guide
to getting going, I'll walk you through the process of getting up and running. Cool, so
you’ve built your amazing application, implemented your idea, and you now want to share it with
the world so here's how you publish your app on an Android market. It couldn’t be simpler,
you just develop your application, register, and then hit publish. So you go to market.Android.com/publish.
You can create a developer profile and sign in with a Gmail account. And then there's
a one time $25 fee to gain access to the market. This is just to kind of prevent spam applications.
So when you sign up, you agree to the Developer Distribution Agreement, which kind of sets
out the agreement between you just--yourself as a seller and Google. And then if you want
to sell your applications, you can also create a Checkout Market Account, which will enable
you to sell the apps and get the--get the revenue for it. So once you've signed up,
you just log in and it's a self-service process to upload your application. There's no review
process at all. You're going to hit upload and your application is live to the world.
Google just performed a, kind of, retrospective take- down on some applications. So if you're,
for example--or if someone infringes on a copyright and that gets reported back to us,
we will take down the app. But there's no review process. So, you know, as soon as you
decide to listen to the user's feedback and like, kind of fix a bug they experience, you
hit publish and within minutes it's live and updating for all your users. So the maximum
application size you can set is 50 megabyte and that's entirely hosted by us. And then
the downloader will be accessible both on the device and on the recently launched Android
Web Market. So the web market, if you've not used it, is a fantastic tool. Not only does
it, kind of expose all the--all the great application you can see on your device, but
it's also good for using traditional advertising techniques. So you can drive any existing
web traffic you might have to this place on the web, so they can then, kind of, discover
your app and install it straight from the website. To this end, we'd like you to provide
like, kind of, high-res promotional images and videos onto your listing so that users
can see immediately how high-quality your application is and get an idea of what using
it will be like. In addition as a publisher, you can log into your publisher account and
see any application crash supports. So if your application encounters a bug on a certain
device and the user hits report, you can see their complete stat trace right in the web
browser. So you can immediately keep on top of any, kind of crashes or stability issues
you might have. We also launched lots of application statistics for your applications so you can
see what platforms your users are running their application on and also what languages
they're in. So, you can use this information to improve your app. Let's say if you've find
out that you have lots of users in a certain country, you might want to localize into that
language. When uploading your app, you can also target quite specifically your audience.
So in the publisher site, you can set countries or languages you want to target. So say, my
UK grocery app is only available to UK users, so they can restrict it to only be available
to people using Android Market in the UK. Similarly, you can target based on hardware
availability on the device. So if you write a application which requires GPS or Telephony
or a level of OpenGL, in your Android Manifest, you specify for the users feature tag that
you require this attribute. And then Android Market will know not to offer your application
to devices which don't have that functionality. So that was a crash course in what an Android
Application is, how you go about writing it, some of the unique features that you have
available to you on Android, and how to make an awesome app. And I hope that was useful
to you and I do advocate you to kind of go along to some of the code labs today where
you'll get a chance to actually get your hands dirty and try out writing applications for
the first time. Do please fill out the speakermeter and let us know what you think of the sessions.
All right. So, we have a bit of time at the end, if anybody has any questions about writing
an Android app? Okay, [INDISTINCT]. >> [INDISTINCT]
>> BUTCHER: Yes. We're going to be on the IOB campsite after the event. Anyone else?
Cool. Well, thank you very much.