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? ;) On Sat, Apr 4, 2009 at 6:57 PM, Videoguy <[email protected]> wrote: > > 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 > > > -- Dianne Hackborn Android framework engineer [email protected] 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
