Question about Android GUI system

by Videoguy » Fri, 03 Apr 2009 21:17:31 GMT

Sponsored Links
 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.


Question about Android GUI system

by Fred Grott » Fri, 03 Apr 2009 21:29:21 GMT

 probably because AWTis pain in the but perhaps?


Sponsored Links

Question about Android GUI system

by Romain Guy » Fri, 03 Apr 2009 22:14:18 GMT

 Because AWT was not suited for the needs of Android.

Romain Guy
Android framework engineer

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


Question about Android GUI system

by Videoguy » Sun, 05 Apr 2009 01:57:34 GMT

 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?

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.


Question about Android GUI system

by Dianne Hackborn » Sun, 05 Apr 2009 03:33:15 GMT

 sing 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? ;)

On Sat, Apr 4, 2009 at 6:57 PM, Videoguy <> wrote:

Dianne Hackborn
Android framework engineer

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.


Question about Android GUI system

by Videoguy » Sun, 05 Apr 2009 15:45:43 GMT

 Thanks Dianne!


Question about Android GUI system

by Nanard » Wed, 08 Apr 2009 15:13:11 GMT

 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).

Question about Android GUI system

by tom » Thu, 09 Apr 2009 15:36:52 GMT

 agree with you


Question about Android GUI system

by nowb » Mon, 13 Apr 2009 20:57:55 GMT

 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?


Other Threads

1. Drawable is not drawn after setDrawableByLayerId


I'm having a problem with displaying a drawable. I have a ImageButton
and a LayerDrawable. I set up an array of Drawable that has one
Drawable for the background (index 0) and one for the image (index 1).
The button would display different background on different states of
the button. What I've done is when the button state changes I replace
the background Drawable like:

        elements[0] = <background drawable object>
        elements[1] = <image drawable object>
        layers = new LayerDrawable(elements);
        layers.setId(0, 0);
        layers.setId(1, 1);

        LayerDrawable ld = (LayerDrawable)button.getDrawable();
        boolean result = ld.setDrawableByLayerId(0, <new

The problem is the initial old background is gone but the new one is
not displayed. What have I done wrong or missed?

Thank you!


2. How to put resrouce files into a jar package?

I want to write a SDK  which will be used by other devs, but one thing
i haven't resolved is make a jar package with all images and strings i
used in the SDK (like android.jar). How to do that, please help,
thanks a lot!


3. No route to host issue, but Browser application works fine

4. How to create a spin wheel kind of animation ... in android?

5. Download Latest Software's and Books about Developers topic

6. Call for Paper The International Journal of Computer Science (IJCS)

7. use Android to read com port data under eclipse?