Android Background Information

Creating UI Widgets

A widget is a UI component like a button or a text box. While they can be created in code, most often it's simpler to create them through the Eclipse UI. Using Eclipse, you can create widgets, arrange them on the screen, and set some of their properties. An XML file is written that describes the screen layout. Android uses that XML file to create the screen when the application is launched.

To do all that, you manipulate a layout resource in Eclipse. Expand project AndroidApps, then res, then layout. Double-click on pingtcpmessagehandler_layout.xml.

Two views are available (as tabs at the bottom of the view of the file). "Graphical Layout" is just that. It shows you the UI as it will appear on the phone. You can drag new widgets onto the UI from the palettes on the left. Having added an element, you can right-click on it and, for instance, set its id. Your Java code locates existing UI elements by searching for them by their id's. For example, PingTCPMessageHandlerActivity.onStart() initializes the UI text boxes this way. You want to do similar things in your application.

The other view of the UI is the XML view. The UI is actually defined by an XML file, whose content controls rendering of the UI graphically. It can be helpful to look at it to understand how the Java code and the XML layout file are connected, but it's not usually intended that you try to edit the XML directly. (Despite that, I personally find it easier to edit the XML file than to use the graphical editor.)

If you really want to know how the UI works, or how to do things beyond what project 2 illustrates, full documentation is available online. If you're interested just in UI aspects, I suggest starting here. If you really want to know about Android programming, you should start at the beginning.

It is not the intention of this assignment that you should have to read this documentation. Looking at what is already implemented in the project code you have, plus a little experimenting, should let you implement the new UI element. On the other hand, our Android needs will become a bit broader as we go through the quarter, so reading now may prove helpful later. (Plus, the documentation is surprisingly well written and informative; you could read it for fun.)

To simplify the Eclipse setup, all our Android applications live in one project, AndroidApps. From Android's point of view, our code is only one Android application (and will stay that way even as we add additional Android "applications"). That application, called CSE461 Apps, is set up so that execution starts with a screen that lets you choose a configuration file to be used. (That way you can load more than one configuration file on your phone and choose which one to use each time you launch our system, allowing your phone to take on many identities.) After that, a kind of shell runs that lets you choose individual applications (e.g., echo or ping). This infrastructure is designed so that any online documentation, blog entries, or forum posts you might read about Android programming will still apply to your code - your app works exactly the same as it would were it a stand alone Android app, and not a component of our one app.

The Android application framework associates a block of code, known as an activity, with a screen. When an activity launches, its onCreate() method is invoked. Thus, execution of your code begins in your onCreate() method. Among other things, it's typical for onCreate() to call setContentView(layout) telling Anroid what screen to display.

Unlike your typical main() method, you return from onCreate() long before program execution is over. Your code is structured as a set of callbacks, calls from the Android infrastructure to your code. The actual main() method is supplied by the Android infrastructure. It consists primarily of a loop that waits for an event (something interesting) to happen. When it does, it invokes your code. This callback scheme is virtually the same in all GUI systems. If you've used any of them (and the course assumes you haven't), it will be familiar. If not, you're learning about how they all work now.

You generally tell the infrastructure what code to invoke (if any) when some specific event occurs by registering a handler (a callback method) for it. When the infrastructure's main loop sees an event, it checks if any handlers have been registered. If so, it invokes them. If not, it goes back to waiting for interesting events. onCreate() is a handler associated with the create event. For widgets, you need to explicitly register handlers for the events you're interested in. Each kind of widget defines its own set of events. For instance, there are events corresponding to the user typing in a text box, and events corresponding to clicking on a button (and many, many more).

You can register handlers in code or as part of building the layout object in Eclipse. The project takes the latter approach. For instance, if you look at the XML view of the layout object, you'll be able to see that the method onGoClicked is registered as a handler for the button's click event.

A thread of control is an execution context. It's basically a pointer to a line of code where it's executing now and a stack containing the method call history that got it to that line of code and the values of all local variables created by those calls. The programs you wrote in your introductory programming course (and likely beyond) had a single thread of control. A multi-threaded program has many, each acting just like that one you're used to, and all executing at the same time.

The thread of control that runs the actual main() loop, and that called onCreate(), is called the main, or UI, thread. Your code cannot "hijack" the main thread to do something that might take a long time. If you do, the main "wait for an event" loop isn't being executed, and if it doesn't execute the UI doesn't respond to user events (like touches).

You application uses the network. Waiting for responses on the network can take a long time, and therefore you shouldn't use the UI thread for that. If you look at method onGoClicked() you'll see that it creates and starts a Thread object (Java's implementation of a thread). onGoClicked() is itself an event handler, and so is executed by the main thread. The main thread returns from the call to Thread.start() almost immediately, and then returns from onGoClicked() back to the main loop. The newly created and started thread begins executing in its run() method. There you perform the work required to implement ping.

You're encouraged (in Android 2.3.x) or required (in Android 4.x) to create background threads whenever you want to go near the network, or do anything else that might take a good long time.