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.

Thanks
Videoguy
--~--~---------~--~----~------------~-------~--~----~



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

--~--~---------~--~----~------------~-------~--~----~



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?

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
--~--~---------~--~----~------------~-------~--~----~



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 <puri_mall...@yahoo.com> wrote:



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

--~--~---------~--~----~------------~-------~--~----~



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?

/Nowb
--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. Handle long click on ItemizedOverlay

Hello i've created an ItemizedOverlay and putted on my OvertlayItems.Now i
want to able to manage long tap on item, what i need to do?

Regards

--~--~---------~--~----~------------~-------~--~----~

2. WHY is there a NULL POINTER EXCEPTION? Been confusing me for a while.

I have two methods, one reads files and one writes the given string to
a file.
For some reason, the first time the write method works fine, but after
it writes the first file, any files after that makes it throw a
nullpointerexception. No idea why. The problem is in the writeData
method for sure.... why is it throwing null???

Stack dump:
08-10 23:04:43.309: WARN/dalvikvm(687): threadid=17: thread exiting
with uncaught exception (group=0x4000fe70)
08-10 23:04:43.319: ERROR/AndroidRuntime(687): Uncaught handler:
thread IntentService[TheDaemon] exiting due to uncaught exception
08-10 23:04:43.357: ERROR/AndroidRuntime(687):
java.lang.NullPointerException
08-10 23:04:43.357: ERROR/AndroidRuntime(687):     at
org.myApp.ThePreferences.writeData(ThePreferences.java:39)
08-10 23:04:43.357: ERROR/AndroidRuntime(687):     at
org.myApp.ThePhone.savePhoneToDisk(ThePhone.java:33)
08-10 23:04:43.357: ERROR/AndroidRuntime(687):     at
org.myApp.ThePhone.refreshStatus(ThePhone.java:82)
08-10 23:04:43.357: ERROR/AndroidRuntime(687):     at
org.myApp.TheDaemon.onHandleIntent(TheDaemon.java:62)
08-10 23:04:43.357: ERROR/AndroidRuntime(687):     at
android.app.IntentService$ServiceHandler.handleMessage
(IntentService.java:29)
08-10 23:04:43.357: ERROR/AndroidRuntime(687):     at
android.os.Handler.dispatchMessage(Handler.java:99)
08-10 23:04:43.357: ERROR/AndroidRuntime(687):     at
android.os.Looper.loop(Looper.java:123)
08-10 23:04:43.357: ERROR/AndroidRuntime(687):     at
android.os.HandlerThread.run(HandlerThread.java:60)



write Method

public boolean writeData(String filename, String contents)
        {
              try {
                        FileOutputStream fOut = context.openFileOutput(filename,
Context.MODE_PRIVATE);
                        OutputStreamWriter osw = new OutputStreamWriter(fOut);
                        osw.write(contents);
                        osw.flush();
                        osw.close();
                } catch (IOException e) {
                        e.printStackTrace();
                        Log.e("fmi", "fmi throws ioexception in WRITER");
                        return false;
                } catch (java.lang.NullPointerException e) {
                        e.printStackTrace();
                }
                return true;
        }

Any idea why it's throwing a null pointer exception?
--~--~---------~--~----~------------~-------~--~----~

3. Calling setContentView() more than once in method onCreate() ?

4. Incredible bug reading a network stream

5. Using Android on "old" palm and dell handhelds

6. Using ExpandableListView inside a Dialog

7. Does the DEBUG tag in Logcat have any special significance?