Introduction

The Android Development Platform is largely based on Java.  Many of the features of the Java language are present in Android.  In fact, it seems to be far more complete than the J2ME (Java 2 Mobile Edition)!  Of course, this does not mean that things are done the same way.  One such example is building graphical user interfaces (GUIs).

Once you get the hang of things, Swing is very easy to use.  But Android does not use Swing...and the paradigm is a little different. This article will forgo the description of how to build GUIs for Android.  There are many tutorials on how to do just that.  This article is going to focus on building dynamic GUIs - GUIs that change with data.

Inflator!  Forget about it.

Android uses this really cool mechanism called an inflator to compose the actual GUI from XML.  This is one of the ways that android allows for very flexible layouts.  Some of the blog entries relating to dynamic GUIs insist on using the inflator.  While it is certainly possible to build the XML, inflate it, that is not my objective.

Beware the EDT!

In Swing, a developer can often get away with making calls on GUI elements at any time.  The results may not be what is desired, but the application tends to keep functioning.  This is not so for Android! 

What is this all about?

Briefly, all GUI updates are done by the Event Dispatch Thread (EDT).  Although some of the Swing elements allow updates from other threads, many do not.  To address this problem, Java has a couple of methods (invokeLater() and invokeAndWait()) to allow blocks of code to run at the correct time.

Android is a little more heavy handed in enforcing these rules.  When a View is modified, the current thread is checked.  If it is not the EDT (or equivalent), it Force Closes.

Android provides a mechanism similar to Swing to ensure the calls are made on the appropriate thread:

runOnUiThread(Runnable runnable)

which can be inlined as follows:

runOnUiThread(new Runnable() {
     public void run() {
          // do something interesting here
     }
});

Layouts are the Key

Eventually, I might learn to stop doing things like they are done in swing.  Adding a new element to a JPanel is as simple as:

jaxax.swing JPanel mPanel = new javax.swing.JPanel();
 
mPanel.add(new javax.swing.JCheckbox());

This is grossly incomplete, but it shows the simplicity of adding a checkbox to a panel.  In Swing, that's it.  With Android, it is a little more complicated.

Go ahead and use the Graphical Layout tool and select the panel you intent to populate.  Right-click on it and set the layout.  (Linear Layout is a good choice for some simple testing.)  Right-click, and set the ID of the Linear Layout to ViewLayout.

Now you can get a reference to the Layout:

LinearLayout layout = (LinearLayout) findViewById(R.id.ViewLayout);

The rest is easy.  From here you can any anything new views to the layout.  A complete example showing how to add a checkbox follows:

runOnUiThread(new Runnable() {
     public void run() {
          LinearLayout layout = (LinearLayout) findViewById(R.id.ViewLayout);
          layout.addView(new CheckBox(getApplicationContext());
     }
});

Where did the Context Come From?

I suspect someone out there is not going to be too happy that I just popped a getApplicationContext() call in there without additional explanation.  The context comes from the current Activity and each new View element needs a reference to it.  If you are working in a class that is not part of the current activity, you probably need to pass a reference to the Activity in to the class.

Comments: