ThemeListener Refactor & Disposal

[XAML-Knight]

Fixes #3555

The ThemeListener Sample Page uses it's own ThemeListener, when in reality it could just use the Sample App's Sample Controller ThemeListener instance, instead. This PR also includes some extra disposal/clean-up, when navigating away from the ThemeListener sample page.

PR Type

What kind of change does this PR introduce?

Refactoring (no functional changes, no api changes)
Sample app changes

What is the current behavior?

ThemeListener Sample Page uses it's own, extra copy of a ThemeListener, and also does not clean-up after itself (Bad 🐶 !).

What is the new behavior?

ThemeListener Sample Page now utilizes the Sample App's Sample Controller instance of a ThemeListener. ThemeListener Sample Page now also implements some clean-up, in the override of OnNavigatedFrom event.

PR Checklist

Please check if your PR fulfills the following requirements:

• Tested code with current supported SDKs
• New component
  • Pull Request has been submitted to the documentation repository instructions. Link:
  • Added description of major feature to project description for NuGet package (4000 total character limit, so don't push entire description over that)
  • If control, added to Visual Studio Design project
• Sample in sample app has been added / updated (for bug fixes / features)
  • Icon has been created (if new sample) following the Thumbnail Style Guide and templates
• New major technical changes in the toolkit have or will be added to the Wiki e.g. build changes, source generators, testing infrastructure, sample creation changes, etc...
• Tests for the changes have been added (for bug fixes / features) (if applicable)
• Header has been added to all new source files (run build/UpdateHeaders.bat)
• Contains NO breaking changes

Other information

[ghost]

Thanks XAML-Knight for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌

[michael-hawker]

We should just need the one event here. Not sure why we expose the ThemeListener publicly on the SampleController as we expose everything via methods. For instance the SampleController.Current.ThemeChanged is invoked the same as the ThemeListener:

WindowsCommunityToolkit/Microsoft.Toolkit.Uwp.SampleApp/Pages/SampleController.xaml.cs

Lines 41 to 43 in bdd1d84

	_themeListener.ThemeChanged += (s) =>
	{
	ThemeChanged?.Invoke(this, new ThemeChangedArgs { Theme = GetCurrentTheme() });

If we make the ThemeListener on SampleController private what else breaks (once we fix this sample)?

[XAML-Knight]

I added the public ThemeListener property to the Sample Controller (see above).

Since we're just interested in returning the data of a property, and not performing any computation, a property seemed more natural, as well as heeding advice from the Choosing Between Properties and Methods section of Design Guidelines for Developing Class Libraries (note: online doc is in VB, not C#, so shield your eyes accordingly):

In general, methods represent actions and properties represent data. Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects. When it does not violate the following guidelines, consider using a property, rather than a method, because less experienced developers find properties easier to use.

[XAML-Knight]

For consistency in the Sample Controller, I can convert the public property to a method, instead

[michael-hawker]

We have a SystemTheme method as well:

WindowsCommunityToolkit/Microsoft.Toolkit.Uwp.SampleApp/Pages/SampleController.xaml.cs

Line 74 in bdd1d84

public ApplicationTheme SystemTheme()

(Not sure why this isn't prefixed with 'Get' like CurrentTheme is, probably something else we should clean-up.)

[XAML-Knight]

Renamed