[Android] Fix DatePicker MinimumDate/MaximumDate not updating dynamically

[HarishwaranVijayakumar]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Issue Details

• Android DatePicker minimum/maximum date constraints don't update properly when changed dynamically. In a dependent DatePicker scenario (LEFT picker's date sets RIGHT picker's minimum), the RIGHT picker fails to respect the updated minimum date constraint.

Behavior:

• First time setting MinimumDate/MaximumDate → Works correctly
• Second time (or subsequent times) setting MinimumDate/MaximumDate → Fails to update

Root Cause of the issue

• Android's DatePicker internally caches MinDate/MaxDate values and ignores subsequent setMinDate()/setMaxDate() calls unless the values are first reset.

Description of Change

Android DatePicker Constraint Fixes:

• Added logic in DatePickerHandler.Android.cs to force dialog recreation when MinimumDate or MaximumDate are updated, ensuring Android's internal cache is invalidated and constraints are reapplied.
• Updated ShowPickerDialog in DatePickerHandler.Android.cs to always apply minimum and maximum date constraints to newly created dialogs.
• Introduced a ResetDialog method to safely dismiss and recreate the dialog when constraint properties change.

UI Tests for Regression Verification:

• Added Issue19256 UI test page and NUnit test to verify dynamic updates to minimum date constraints in dependent DatePickers.
• Added Issue33583 UI test page and NUnit test to verify updates to maximum date constraints after dialog is shown.

These changes ensure that Android DatePicker controls now correctly honor updated minimum and maximum date values, with comprehensive tests confirming the fix.

Issues Fixed

Fixes #19256
Fixes #33583

Output

Before	After
Before_fix.mov	After_fix.mov

[sheiksyedm]

/azp run maui-pr-uitests 

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This PR fixes a long-standing Android platform bug where DatePicker minimum and maximum date constraints fail to update dynamically after the initial setting. The issue manifests in dependent DatePicker scenarios where changing one picker's date should update another picker's minimum/maximum constraint.

Changes:

• Implements the established Android workaround by resetting min/max values before setting new constraints
• Adds ShowEvent handler to ensure constraints are re-applied after Android's internal dialog initialization
• Includes comprehensive UI tests with screenshot verification to validate the fix

Reviewed changes

Copilot reviewed 5 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/Core/src/Platform/Android/DatePickerExtensions.cs	Added reset logic (MinDate=0, MaxDate=long.MaxValue) before setting new constraint values to force Android to invalidate cached values
src/Core/src/Handlers/DatePicker/DatePickerHandler.Android.cs	Added ShowEvent handler to re-apply min/max dates after dialog initialization, working around Android's dialog reuse caching issue
src/Controls/tests/TestCases.HostApp/Issues/Issue19256.cs	Created UI test page with two dependent DatePickers and buttons to reproduce the issue scenario
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue19256.cs	Created NUnit test with two-screenshot verification approach to validate dynamic MinimumDate updates
src/Controls/tests/TestCases.Android.Tests/snapshots/android/DatePickerMinimumDateShouldUpdateDynamically_*.png	Reference screenshots for automated visual verification (2 files)
.github/agent-pr-session/pr-19256.md	Agent session documentation tracking the fix development process

[PureWeen]

/rebase

[PureWeen]

/azp run maui-pr-uitests, maui-pr-devicetests

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[PureWeen]

/rebase

[jfversluis]

Code Review — PR #33687

Thanks for this fix! The dialog recreation approach is a clean and correct solution to the Android DatePicker caching bug. I verified that PureWeen's earlier concerns (ShowEvent handler leak and disjoint date range crash) are both fully resolved by the new approach — the ShowEvent is no longer used, and fresh dialog creation means both constraints are applied atomically with no ordering conflict.

The core fix logic is solid. There are a few items to address before this can merge:

---

🔴 Blocking: Missing snapshots for Issue33583 on Windows/MacCatalyst

Issue33583.cs test compiles for #if !IOS which includes Android, Windows, and MacCatalyst. However, only the Android snapshot is committed:

✅ TestCases.Android.Tests/snapshots/android/VerifyMaximumDateInRuntime.png
❌ No Windows snapshot
❌ No MacCatalyst snapshot

VerifyScreenshot() will fail on Windows and MacCatalyst CI because there are no reference images.

Recommended fix — since the bug and fix are Android-only, the simplest solution is to restrict the test:

// Change this:
#if !IOS

// To this:
#if ANDROID

Alternatively, run the test on Windows and MacCatalyst and commit those snapshots.

---

🟡 PR description is outdated

The description states:

"In DatePickerExtensions.cs, both UpdateMinimumDate and UpdateMaximumDate methods now reset the underlying Android values (MinDate to 0, MaxDate to long.MaxValue) before setting the new constraint"

But DatePickerExtensions.cs has zero changes in this PR. This describes the earlier "reset-before-set" approach that was replaced with dialog recreation. Please update the description to match the current implementation.

---

🟡 Agent session file describes abandoned approach

.github/agent-pr-session/pr-19256.md still documents the old ShowEvent-based approach and even lists "Recreate dialog each time" as an approach to ❌ Avoid — which contradicts the current (correct) implementation. Consider removing this file from the PR or updating it.

---

ℹ️ Pre-existing bug (not introduced by this PR)

Found a pre-existing copy-paste bug in DatePickerExtensions.cs line 56:

public static void UpdateMaximumDate(this MauiDatePicker platformDatePicker, IDatePicker datePicker)
{
    platformDatePicker.UpdateMinimumDate(datePicker, null); // ← Should be UpdateMaximumDate!
}

This doesn't affect your fix (the handler always passes the dialog parameter), but worth noting for a separate PR.

---

Summary

Aspect	Status
Core fix (dialog recreation)	✅ Correct and well-designed
PureWeen's ShowEvent leak concern	✅ Resolved (ShowEvent removed)
PureWeen's disjoint range concern	✅ Resolved (fresh dialog, no conflicts)
Issue19256 test (Android-only)	✅ Good
Issue33583 test (cross-platform)	🔴 Missing Windows/Mac snapshots — change to #if ANDROID
PR description	🟡 Outdated — describes old approach
Agent session file	🟡 Outdated — describes abandoned approach

[sheiksyedm]

/azp run maui-pr-uitests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[HarishwaranVijayakumar]

Code Review — PR #33687

Thanks for this fix! The dialog recreation approach is a clean and correct solution to the Android DatePicker caching bug. I verified that PureWeen's earlier concerns (ShowEvent handler leak and disjoint date range crash) are both fully resolved by the new approach — the ShowEvent is no longer used, and fresh dialog creation means both constraints are applied atomically with no ordering conflict.

The core fix logic is solid. There are a few items to address before this can merge:

🔴 Blocking: Missing snapshots for Issue33583 on Windows/MacCatalyst

Issue33583.cs test compiles for #if !IOS which includes Android, Windows, and MacCatalyst. However, only the Android snapshot is committed:

✅ TestCases.Android.Tests/snapshots/android/VerifyMaximumDateInRuntime.png
❌ No Windows snapshot
❌ No MacCatalyst snapshot

VerifyScreenshot() will fail on Windows and MacCatalyst CI because there are no reference images.

Recommended fix — since the bug and fix are Android-only, the simplest solution is to restrict the test:

// Change this:
#if !IOS

// To this:
#if ANDROID

Alternatively, run the test on Windows and MacCatalyst and commit those snapshots.

🟡 PR description is outdated

The description states:

"In DatePickerExtensions.cs, both UpdateMinimumDate and UpdateMaximumDate methods now reset the underlying Android values (MinDate to 0, MaxDate to long.MaxValue) before setting the new constraint"

But DatePickerExtensions.cs has zero changes in this PR. This describes the earlier "reset-before-set" approach that was replaced with dialog recreation. Please update the description to match the current implementation.

🟡 Agent session file describes abandoned approach

.github/agent-pr-session/pr-19256.md still documents the old ShowEvent-based approach and even lists "Recreate dialog each time" as an approach to ❌ Avoid — which contradicts the current (correct) implementation. Consider removing this file from the PR or updating it.

ℹ️ Pre-existing bug (not introduced by this PR)

Found a pre-existing copy-paste bug in DatePickerExtensions.cs line 56:

public static void UpdateMaximumDate(this MauiDatePicker platformDatePicker, IDatePicker datePicker)
{
    platformDatePicker.UpdateMinimumDate(datePicker, null); // ← Should be UpdateMaximumDate!
}

This doesn't affect your fix (the handler always passes the dialog parameter), but worth noting for a separate PR.

Summary

Aspect Status
Core fix (dialog recreation) ✅ Correct and well-designed
PureWeen's ShowEvent leak concern ✅ Resolved (ShowEvent removed)
PureWeen's disjoint range concern ✅ Resolved (fresh dialog, no conflicts)
Issue19256 test (Android-only) ✅ Good
Issue33583 test (cross-platform) 🔴 Missing Windows/Mac snapshots — change to #if ANDROID
PR description 🟡 Outdated — describes old approach
Agent session file 🟡 Outdated — describes abandoned approach

@jfversluis, Updated the PR description, added the base snapshots, and removed the session file.

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).