It's a good introduction. I hope that the next presentations be more detailed
>>Tor Norbye: I think we're live. >>Xavier Ducrohet: Hello, welcome to our session
on Android development tools. I am Xavier Ducrohet. I am the tech lead for the Android
development tools at Google. >>Tor Norbye: And I am Tor Norbye. I work
on the Android development tools and I work for Xavier.
>>Xavier Ducrohet: Before we start, I want to mention this is live streamed, and so we
will take some questions from Google moderator at the end of this session, and also some
live questions. So you have the link here to go onto moderator and post some interesting
questions and vote down the bad ones, please. So today we are going to give you some demonstration
of some of the latest feature that we have worked on for the last three to six months.
Unfortunately, we can't really show you everything because there's just too much.
We'll show you how those feature can appear with best practices when doing Android development.
And we will also show you some other feature that we notice some developers don't really
know about but are very useful. And we will also show you some upcoming new features.
So let's get started. So that's the agenda. So the first thing I want to mention, I know
as a quick introduction to the tools, first thing, they are completely developed in the
open. We work directly in the repository and we accept contribution if they are good. So
if you are interested, feel free to talk to us.
When we work on the development tools, we are pretty agnostic in terms of environment.
We want to make sure you guys can work whether you use Linux, Mac or Windows. And in terms
of IDE, also we are very flexible. So there is support for general Android support for
Eclipse, NetBeans and for IntelliJ. And of course there is support for command line tool.
We have an end-based built system where you can just build your application from the command
line, and it's very useful if you want to do automatic build. And there's even support
for instrumentation so you can do automated testing from the command line, or of course
through a server. I mentioned all those IDEs. And we started
with Eclipse, really, because we can't really focus on all of them. But we are very happy
that other people are actually dock support for other IDEs, like IntelliJ has native support
for Android. And when we work on the tools, we try to make sure that we don't just code
directly for Eclipse and just embed everything there and it's one big application. We actually
do a lot of small libraries that are reusable so third-party tool vendor can actually do
that and reuse them and reuse our code, and it's under Apache so it's very easy to reuse.
And of course some of those libraries are reused also in the stand-alone application
so if someone compiles with the end tool and they don't want to use IDE, they can use some
standard application to do debugging, profiling and those kind of things.
So on the Eclipse integration part, we are trying to be as integrated as possible to
be a good citizen to the Eclipse ecosystem. So mostly, if you know how to use Eclipse,
you should know how to use the tools for Eclipse. We have basic project support, build, launch,
debugging, all of that is directly integrated. We don't have to care about all the plumbing
that goes inside for you. And we also have support for editors. As you
may know, Android does a lot of different XML files and we do provide some support for
that, and we will talk about that a little bit later.
Some of the standard tools I talked about, we tried to merge them into Eclipse so make
sure they are integrated directly. And some of them, like the Draw 9 Patch, is actually
not there yet. We are working on it. At some point.
I mentioned editors. It is something where we have gotten a lot of feedback that there
are a lot of XML files and they are complicated to know. There are a lot of attributes, a
lot of specific values that need to go into the attributes. And so in the past few months,
really, we have really focused on improving those editors.
There are several different types. Some of them, like the Android manifest, will show
up like a form-based editor where you have mostly some forms to just fill some values,
text fields and things like that, but we also try to make sure that there's always an XML
version for that. And the original version of the XML was just the basic Eclipse XML
editor which is good but not really advanced. And so we have done a lot of progress recently
on that regarding content assist, quick fix, quick assist, and all those features that
you expect when you are an Eclipse user. The other part -- The other type of editor
really is WYSIWYG editor, and it's mostly the layout editor.
And I know a lot of you want to have a full, high quality UI builder, so let's talk about
that a little bit. When you think about WYSIWYG editor, there's
two different things. There's the interactivity part, which we didn't really have until like
six months ago, so we have been focusing a lot on that and Tor will show you some things.
The other part is the rendering. So we see a lot of people who receive a new version
of ADT, ADT 9, AD T10 and they say the rendering is still broken, and that is completely normal
because the rendering code is not in ADT at all.
So what we have is, each SDK component, for example, the 1.5 SDK component, the 2.1 SDK
component, the 3.0 SDK component, all those come with their own rendering engine, and
we do that for two reason. The first is there is a lot of resource in Android. When you
want to draw a button in Eclipse, you want it to be drawn the same way as it's drawn
in the device in terms of using the 9 Patch that actually match that device.
In fact, in Gingerbread we changed the look of the buttons, and they changed again in
the holographic theme in Honeycomb. So you want to make sure whether you are rendering
with 1.5 or 2.0 or 3.0, you get the right button. So all the framework resources is
packaged with each SDK component. So that's the resource part.
And the code part, where we actually -- So we actually run part of the Android View framework
inside Eclipse, or the view class, the widget class, the pane canvas, all of that, we run
that inside of Eclipse. But below that, in Android on the device,
there's actually a lot of native code that we didn't want to bring into Eclipse, so we
replaced that. And so it's been a very long process. Before
3.0, we had some version of replacing those code and there's some issue when you have
a class like paint or Canvas, it is half native and half Java so replacing it completely was
kind of difficult. So we have done a lot of improvement in 3.0 to really try to be much
better in terms of supporting a lot of different type of rendering, a lot of classes, like
the path class was not supported at all in previous version. It refused it inside your
custom view or inside some widget that uses it by default. It would just crash inside
Eclipse. We have done a lot of progress inside 3.0,
and even more progress in 3.1 that released yesterday. We are planning to keep improving
that and then to go back and rerelease new versions -- new revisions, actually, of earlier
SDK to port back those improvements so the rendering in Eclipse will look good in Eclipse
no matter what version of the rendering library you select.
And with that, we are going to give you a demo.
Log in to save your progress and obtain a certificate in Alison’s free Fundamentals of Google Android Development online course
Sign up to save your progress and obtain a certificate in Alison’s free Fundamentals of Google Android Development online course
Please enter you email address and we will mail you a link to reset your password.