Android Notebook, page 4

Probably not a coincidence, but all this lifecycle stuff reminds me of applets, albeit with somewhat more complicated argument lists and fancier names. There are certain patterns that show up again and again. Event listeners are one. Event loops are another. And life cycle methods are a third. Sometimes the trick to learning a new system is recognizing the old patterns in new language. Of course, this can trip you up badly when the pattern is something truly new, and when you try to fit it into old mental models. You can also get tripped up by assuming that certain contingent details are the same in the new instantiation of the pattern as in the old one.

The tab key doesn’t work like you’d expect–it doesn’t advance from one field to the next. I’m not sure if this is a limitation of the framework or just the sample app. This is completely irrelevant on a phone, but may become important if third parties start using the Android platform as a base for netbooks.

Too much copy and paste , and not enough thinking in the tutorial. I should try to work backwards from the sample app on the screen to understand where the different fields are coming from. Let’s see there are:

Two screens, one with a list, one with two text areas and a button.

The list screen comes from NotePadv3 which extends ListActivity. I thought this was the main part of the app but it’s not. It’s just another screen class.

The text area screen is from the NoteEdit class, which extends Activity. This class is apparently the default for a screen you want to layout yourself. So for every screen I want, I should add one more subclass of Activity or one of its subclasses.

(By the way, don’t take any of this as gospel. I’m seriously just jotting down notes here as they occur to me. I’m almost certainly wrong about a lot of this.)

How is the layout setup? The design of these screens is defined by the XML files in res/layout: note-edit.xml, notes_list.xml. How are these files attached to the Java code? There’s a lot of autogenerated framework there, but all I really need to know are the naming conventions. It can’t be class name, because one screen is Notepadv3 and there’s no XML file by that name. Plus between Notepadv1, Notepadv2, and Notepadv3 the XML file names remained the same. How does note_list.xml get mapped to Perhaps AndroidManifest.xml? Nope, that doesn’t mention note_list.xml. Ah here, it is. You call this.setContentView(R.layout.notes_list); in the onCreate method:

    public void onCreate(Bundle savedInstanceState) {
        mDbHelper = new NotesDbAdapter(this);;

(The R.layout.notes_list field is autogenerated from the notes_list.xml file.)

The rest of the layout is all organized neatly in the XML files. Looks like an android:id attribute in the XML turns into an field in the Java:


		<EditText android:id="@+id/title" 

mTitleText = (EditText) findViewById(;

So per screen I have one Activity subclass and one corresponding XML file. (It’s a little inconvenient that they’re in separate directories.) Edit the XML to change the positions and layout of what’s on the screen. Edit the Java to attach behavior to the items on the screen. Read-only widgets (Labels in Java parlance) don’t even need to be mentioned in the Java source code.

Finally, an application is defined as a collection of screens/activities in AndroidManifest.xml.

To switch between screens:

  1. Create a new Intent with the current screen/activity object source and the target screen/activity class.
  2. Pass the intent and the ID to startActivityForResult.
        Intent i = new Intent(this, NoteEdit.class);
        startActivityForResult(i, ACTIVITY_CREATE);

Hmm, what does that ACTIVITY_CREATE field do? Just launch the onCreate method in the target class? Can an activity get started without the onCreate method being called?

OK. I think I’m getting the hang of this, but I think I have some more reading to do.

Leave a Reply