Application got crash when load the PullToRefresh and Expander controls within different layouts.

[SanjaySF4372]

Bug Description
1.Application got crash when load the PullToRefresh controls within different layouts.
2.When setting the PullTorefresh API in GlobalStyles exception occurs.
3. Application crashes when setting the API's using Global Styling in Accordion and Expander control. Adding the Unit test cases for the Expander and Accordion.

Root Cause
1.The Layouts will have infinite width or height when it is measured in the control.So,it returns the infinite value because of that exception occurs.
2.When setting the PullTorefresh API in GlobalStyles the ProgressCircleView is null it is not loaded.So,that issue exception occurs in the layouts.
3.When setting the API in global styling ,while loading it calls the its API property changed methods first so in that items were not loaded .So items become null then the exception occurs.

Is Breaking issue?
No

Solution description
1.Manually added the height as 300 if the height is infinite and added width as 300 if the width is infinite for windows.For other than windows added the DeviceDisplay width and DeviceDisplay height for it.
2.Added the null check condition ProgressCircleView is not null for the API PropertyChanged methods.
3.Added the condition if the IsViewLoaded is false then it should return in the propertychanged methods.

Output screenshots
Windows:

Screen.Recording.2025-07-15.114653.mp4

Screen.Recording.2025-07-23.144743.mp4

Android:

Screen.Recording.2025-07-23.145601.mp4

Unit test case Image:

Areas affected and ensured
No areas were affected.

Test cases
Tested the Styles cases in all platforms.
Tested the Layout cases in all platforms.

Does it have any known issues?
No

MR CheckList

• Have you ensured in iOS, Android, WinUI, and macOS(if supported)? Yes
• If there is any API change, did you get approval from PLO through JIRA Tasks? No
• Is there any existing behavior change of other features due to this code change? No
• Did you perform the automation / manual testing against your fix?
• Did you record this case in the unit test or UI test?
• Have you suppressed any warning or binding errors? No
• Is there any existing behavior change of other features due to this code change? No
• Does it need localization? If so did you ensure the cases mentioned in this link? No
• Whether the new APIs and its comments are added as per standard? No
• Did you ensure the cases mentioned in this link? Not Applicable
• Did you ensure the fix (if applicable) met accessibility requirements? Not Applicable
• If you added any interaction related code, have you used touch and gesture APIs from core project? Not Applicable
• Does it contain code that reflects any internal framework API? Not Applicable
• Did you ensure the cases mentioned in this link? Not Applicable
• Did you ensure RTL? Not Applicable
• Did you test the memory leak with the fix? Not Applicable
• Did you ensure the ? Check this link to know more about performance optimization and how to automate? Not Applicable
• If you use a third-party package, did you get approval to use it? If not, please get approval before merging. Not Applicable

[RasikaPalanisamy]

This is fine.

[FarjanaParveen]

This is fine

[bricefriha]

nit:

Suggested change

	var scaledScreenSize = new Size(DeviceDisplay.MainDisplayInfo.Width / DeviceDisplay.MainDisplayInfo.Density, DeviceDisplay.MainDisplayInfo.Height / DeviceDisplay.MainDisplayInfo.Density);
	var scaledScreenSize =
	#if WINDOWS
	new Size(300, 300);
	#else
	new Size(DeviceDisplay.MainDisplayInfo.Width / DeviceDisplay.MainDisplayInfo.Density, DeviceDisplay.MainDisplayInfo.Height / DeviceDisplay.MainDisplayInfo.Density);
	#endif

IMO it reads better and it would be easier to scale if we adapt it to more platforms in the future

[FarjanaParveen]

@bricefriha - Thanks for the suggestion — we have updated the code accordingly.