Just wondering why Android team decide to build GUI sub system not
based on java.awt framework. I understand Swing might be too big. But
underneath Swing, you got basic AWT framework that allows you build
your own  lightweight GUI frameworks.
The android.view classes could have been based off of
java.awt.Component (and Container etc). Instead they are built from
scratch without any reference to AWT classes.
I am wondering what the reason was behind this design.

Thanks
Videoguy

probably because AWTis pain in the but perhaps?

Because AWT was not suited for the needs of Android.

--
Romain Guy
Android framework engineer
romain...@android.com

Note: please don't send private questions to me, as I don't have time
to provide private support.  All such questions should be posted on
public forums, where I and others can see and answer them

But why?
The core AWT lets you create your own toolkit (with look and feel of
your choice)and has a framework for event bubbling etc. The android
View is like Component, ViewGroup is like Container. The AWT Graphics
class is an abstraction to interact with drawing surface.
We built our own light weight toolkit on top of JDK 1.1 base AWT (plus
heavy weight components Frame and Window) for an embedded device.
Just curious as to why you decided to drop it?
Does hardware acceleration has anything to do with it?

Romain
I used to follow your blogs (and Chet Hase's) about java graphics
acceleration and opengl. You guys rock! I have your book too.

Thanks for answering my question.

-Videoguy

Using AWT means you need to drag in a bunch of other stuff, from Bitmap and
elsewhere, that are not necessarily appropriate for Android.  Also the
implementation for Android is quite optimized for running on mobile class
hardware, in a multi-process environment.  (Just supporting the standard
core Java classes is often quite painful for us, because of how heavy-weight
they can be.)

Generally, using an existing API can have significant disadvantages as well
as advantages.  Especially for something like AWT, where you are in a
position where you would need to compatibly support whatever existing APIs
you use, having to work under that existing API can actually make it a lot
more effort and less efficient to implement your desired system.

For example:

- We acquired the Skia graphics library for use in Android.  Using AWT would
require significant work to expose that in the AWT API in a compatible way,
rather than directly exposing its actually rendering API as done in the
Android Canvas class.

- The AWT event model is fairly mouse-centric.  It has concepts like moving
a pointer over the screen without a button being down, which we don't care
about, and lacks information like pressure and size (and its coordinates are
integers instead of floats).  Likewise there is a slew of virtual key codes
we don't care about, and no standard definitions for ones we really care
about like search, home, back, call, hangup, etc.

- We have a lot of core concepts we want to have integrated into our view
hierarchy (contexts holding themes, layout inflation from xml, searching by
id, etc) that don't exist.

So what it boils down to, is we would be looking at implementing the generic
AWT, and them building our "desired" API on top of it.  This would make
things a lot more complicated, introduce a lot more overhead (casting to our
extended view class continuously as we traverse through the view hierarchy
looking for an id!), and be of questionable benefit.

At then end of the day, the view hierarchy is at the very heart of the user
experience, and we had a specific experience we wanted to achieve.  So it
makes a lot of sense for Andoid to define its own core UI model, designed
specifically to support its UI model, as the platform APIs.

And if you want AWT on Android...  well you can implement the AWT APIs on
top of the Android UI.  That's how AWT is supposed to work, right? ;)

--
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.

Thanks Dianne!

I suppose that can answer the question :

- AWT uses OS lib for drawing.  Android is mostly Java.  Of course
there should be some C lib for drawing on the screen somewhere...

- AWT, Swing and other are for desktop.  Mobile devices UI are a lot
differents : one app at a time uses the full screen, no resizing

- AWT is by default not nice.  I support Google wanted a nice Look and
Feel for all their devices.

- Event management on a PC and a small mobile device is different :
more interrupt (call, SMS, battery, no mouse...)

- AWT is only used for drawing.  Google needed to create a whole
Desktop (menus, virtual screens).  So they needed to write a lot of
code anyway.

But : I agree : it may be boring to rewrite the same app again and
again (C, .NET, Java/Swing, iPhone, Andorid, Symbian, etc).

agree with you

On 4月8日, 下午11时12分, Nanard <bsegon...@free.fr> wrote:

I just started looking in to the framework so this might me the
stupidest question...

in frameworks/base/awt you can find the java.awt package, first I
thought this was some kind of internal api but after reading this I
guess it's not. So, what is it doing there? Can it be used?

/Nowb