DatePicker, TimePicker, ProgressBar

📖 Theory

The date field that accepted 32-13-2026

FestConnect Mobile's booking screen asked for a visit date in a plain EditText. The harvest, day 1: 32/13/2026, kal, Garba day, and one emoji.

You know the cure from BCA404's MaskedTextBox philosophy: make invalid input impossible to type. Android's version for dates and times is to not let users type at all: a calendar pops, they TAP a date, and only real dates exist. Meanwhile the save that follows needs a third widget: something honest about waiting.

📖 Theory

DatePickerDialog: the calendar in a box

The standard pattern: a tap on the date field opens a DatePickerDialog:

new DatePickerDialog(this, listener, year, month, day).show();

• the last 3 arguments preselect a date, usually today's, fetched from Calendar.getInstance()
• the listener (OnDateSetListener) is the callback receiving the choice: (view, year, month, dayOfMonth)

And here stands Android's most famous small trap: month is 0-based: January is 0, December 11. Chosen 15 March arrives as month = 2; display it as month + 1.

⌨️ Practical

Pick date, pick time, show both

public class BookingActivity extends AppCompatActivity {

    void pickDateTime() {
        Calendar now = Calendar.getInstance();

        new DatePickerDialog(this,
            (view, year, month, day) -> {
                // month is 0-BASED: March arrives as 2
                txtDate.setText(day + "/" + (month + 1) + "/" + year);
            },
            now.get(Calendar.YEAR),
            now.get(Calendar.MONTH),
            now.get(Calendar.DAY_OF_MONTH)).show();

        new TimePickerDialog(this,
            (view, hour, minute) ->
                txtTime.setText(String.format("%02d:%02d", hour, minute)),
            now.get(Calendar.HOUR_OF_DAY),
            now.get(Calendar.MINUTE),
            true).show();               // true = 24-hour clock
    }
}

📖 Theory

ProgressBar: honest waiting

Booking saved to the server takes 2 seconds: 2 seconds in which a silent screen feels frozen. The ProgressBar buys patience in 2 styles:

• indeterminate (the default): a spinner: "working, duration unknown"
• determinate: a filling bar for measurable work: set style="?android:attr/progressBarStyleHorizontal" in XML, then setMax(100) and setProgress(n) as work advances

The usual choreography: progressBar.setVisibility(View.VISIBLE) before the slow work, View.GONE in its completion callback: the same async bookkeeping as every callback this year.

🧩 Quiz

The user picks 15 March 2026 in a DatePickerDialog. What does the OnDateSetListener receive as (year, month, dayOfMonth)?

1. (2026, 3, 15)
2. (2026, 2, 15): month is 0-based, so March is 2
3. (2026, 3, 14): days are 0-based
4. A single Date object, not 3 numbers

💭 Think first

Which ProgressBar style, and where does GONE go?

Two waits in the booking flow: (a) saving the booking to the server (unknowable duration), (b) uploading the 5 photos of your fest pass, one by one. Pick the style for each, and state precisely WHERE in the code the bar must be hidden again, before tapping.

⚠️ Watch out

Picker and progress traps

Displaying the raw month: 15/2/2026 on the ticket for a March visit: always month + 1 for humans (and minus 1 when feeding a picker from stored text).

Midnight formatting: %02d pads 9:05 to 09:05; without it, times look broken.

A bar that never leaves: hide the ProgressBar in every outcome path; an eternal spinner reads as a hung app: users kill it.

Widget vs dialog: the XML <DatePicker> embeds a full calendar in the layout; the dialog pops on demand: know both exist, use the dialog by default.

📖 Theory

Constraints beat corrections

Step back and see the design principle these widgets share: the picker CONSTRAINS input (only real dates exist), the progress bar CONFESSES state (working, not frozen): both remove the need for scolding error messages later. BCA402-02's UI/UX subject will name these ideas; you are already practising them. Next lesson: when content outgrows the screen: ScrollView, and its one-child law.

✅ Summary

Key takeaways

• DatePickerDialog(context, listener, y, m, d).show(): calendar pops, listener receives the choice.
• MONTH IS 0-BASED: January 0, March 2: display month + 1. Year and day are human-normal.
• TimePickerDialog returns hour and minute; the last argument true means a 24-hour clock.
• Initial values come from Calendar.getInstance().
• ProgressBar: indeterminate spinner by default; horizontal style + setMax/setProgress for measurable work.
• Show the bar before slow work, hide it in EVERY completion path.
• Memory hook: pickers forbid nonsense, months start at zero, spinners must die.