Mark Murphy - Beginning Android

new DatePickerDialog(ChronoDemo. this, d,

dateAndTime. get(Calendar.YEAR), dateAndTime. get(Calendar.MONTH),

dateAndTime. get(Calendar.DAY_OF_MONTH)). show();

}

});

btn = (Button) findViewById(R.id.timeBtn);

btn. setOnClickListener( newView. OnClickListener() {

publicvoid onClick(View v) {

new TimePickerDialog(ChronoDemo. this, t,

dateAndTime. get(Calendar.HOUR_OF_DAY), dateAndTime. get(Calendar.MINUTE),

true). show();

}

});

dateAndTimeLabel = (TextView) findViewById(R.id.dateAndTime);

updateLabel();

}

privatevoid updateLabel() {

dateAndTimeLabel. setText(fmtDateAndTime. format(dateAndTime. getTime()));

}

}

The “model” for this activity is just a Calendarinstance, initially set to be the current date and time. We pour it into the view via a DateFormatformatter. In the updateLabel()method, we take the current Calendar, format it, and put it in the TextView.

Each button is given a OnClickListenercallback object. When the button is clicked, either a DatePickerDialogor a TimePickerDialogis shown. In the case of the DatePickerDialog, we give it a OnDateSetListenercallback that updates the Calendarwith the new date (year, month, day of month). We also give the dialog the last-selected date, getting the values out of the Calendar. In the case of the TimePickerDialog, it gets a OnTimeSetListenercallback to update the time portion of the Calendar, the last-selected time, and a true indicating we want 24-hour mode on the time selector.

With all this wired together, the resulting activity is shown in Figures 10-1, 10-2, and 10-3.

Figure 10-1. The ChronoDemo sample application, as initially launched

Figure 10-2. The same application, showing the date picker dialog

Figure 10-3. The same application, showing the time picker dialog

If you want to display the time, rather than have users enter the time, you may wish to use the DigitalClockor AnalogClockwidgets. These are extremely easy to use, as they automatically update with the passage of time. All you need to do is put them in your layout and let them do their thing.

For example, from the Fancy/Clockssample application, here is an XML layout containing both DigitalClockand AnalogClock:

android:orientation="vertical"

android:layout_width="fill_parent"

android:layout_height="fill_parent"

>

android:layout_width="fill_parent"

android:layout_height="wrap_content"

android:layout_centerHorizontal="true"

android:layout_alignParentTop="true"

/>

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:layout_centerHorizontal="true"

android:layout_below="@id/analog"

/>

Without any Java code other than the generated stub, we can build this project (see Figure 10-4).

Figure 10-4. The ClocksDemo sample application

If you need to be doing something for a long period of time, you owe it to your users to do two things:

• Use a background thread, which will be covered in Chapter 15

• Keep them apprised of your progress, or else they think your activity has wandered away and will never come back

The typical approach to keeping users informed of progress is some form of progress bar or “throbber” (think the animated graphic towards the upper-right corner of many Web browsers). Android supports this through the ProgressBarwidget.

A ProgressBarkeeps track of progress, defined as an integer, with 0 indicating no progress has been made. You can define the maximum end of the range — what value indicates progress is complete — via setMax(). By default, a ProgressBarstarts with a progress of 0, though you can start from some other position via setProgress().

If you prefer your progress bar to be indeterminate, use setIndeterminate(), setting it to true.

In your Java code, you can either positively set the amount of progress that has been made (via setProgress()) or increment the progress from its current amount (via incrementProgressBy()). You can find out how much progress has been made via getProgress().

Since the ProgressBaris tied closely to the use of threads — a background thread doing work, updating the UI thread with new progress information — we will hold off demonstrating the use of ProgressBaruntil Chapter 15.

The general Android philosophy is to keep activities short and sweet. If there is more information than can reasonably fit on one screen, albeit perhaps with scrolling, then it most likely belongs in another activity kicked off via an Intent, as will be described Chapter 24. However, that can be complicated to set up. Moreover, sometimes there legitimately is a lot of information that needs to be collected to be processed as an atomic operation.

In a traditional UI, you might use tabs to accomplish this end, such as a JTabbedPanein Java/Swing. In Android, you now have an option of using a TabHostcontainer in much the same way — a portion of your activity’s screen is taken up with tabs which, when clicked, swap out part of the view and replace it with something else. For example, you might have an activity with a tab for entering a location and a second tab for showing a map of that location.

Some GUI toolkits refer to “tabs” as being just the things a user clicks on to toggle from one view to another. Some toolkits refer to “tabs” as being the combination of the clickable button-ish element and the content that appears when that tab is chosen. Android treats the tab buttons and contents as discrete entities, so we will call them “tab buttons” and “tab contents” in this section.