Refactor Application Settings and Support for Packaged/Unpackaged Mode #1924

[ghost1372]

This PR replaces the legacy ApplicationData-based settings system with a new SettingsHelper class. It adds support for both packaged and unpackaged app scenarios.

Closes #1924.

Old Settings System:

appData.LocalSettings.Values[SettingsKeys.IsLeftMode] = true;
New Settings System:

SettingsHelper.Current.IsLeftMode = true;

Note

Settings are automatically saved when changed.

SettingsHelper Architecture:

Uses an ISettingsProvider abstraction.
In packaged mode: uses ApplicationDataContainer.
In unpackaged mode: uses JsonSettingsProvider.

Adding a New Setting:

public bool IsEnabled
{
    get => GetOrCreateDefault<bool>(true);
    set => Set(value);
}

[Zakariathr22]

Just a few points that I think are important, but of course after hearing @marcelwgn’s opinion about them.

[Copilot]

Pull Request Overview

This PR refactors the application settings system by replacing the legacy ApplicationData-based approach with a new SettingsHelper class that provides type-safe property access and supports both packaged and unpackaged app scenarios.

• Introduces a new SettingsHelper class with an ISettingsProvider abstraction
• Replaces string-based settings keys with strongly-typed properties
• Adds JSON-based settings storage for unpackaged apps while maintaining ApplicationData support for packaged apps

Reviewed Changes

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

Show a summary per file

File	Description
SettingsHelper/SettingsHelper.cs	New settings class with type-safe properties and update methods
SettingsHelper/Providers/*	Provider abstraction with ApplicationData and JSON implementations
SettingsHelper/ObservableSettings.cs	Base class providing property change notifications and storage operations
SettingsHelper/Internals/*	Support classes for JSON serialization and list operations
SettingsKeys.cs	Removed legacy string-based settings keys
Various pages/helpers	Updated to use new SettingsHelper.Current API instead of legacy methods

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

[nitpick] Catching generic Exception can hide unexpected errors. Consider catching specific exceptions like JsonException or IOException for better error handling.

Suggested change

	catch (Exception)
	{
	HandleCorruptedFile();
	}
	catch (JsonException)
	{
	HandleCorruptedFile();
	}
	catch (IOException)
	{
	HandleCorruptedFile();
	}

[ghost1372]

Having multiple specific exceptions can be useful for clarity, but in this case, it may not be necessary. We could handle multiple error cases with a single exception type, which would allow us to catch all errors uniformly instead of only the predefined ones.

[Copilot]

[nitpick] Catching generic Exception can hide unexpected errors. Consider catching specific exceptions like JsonException or InvalidCastException for better error handling.

Suggested change

	catch (Exception)
	{
	HandleCorruptedKey(key);
	return default;
	}
	catch (JsonException)
	{
	HandleCorruptedKey(key);
	return default;
	}
	catch (InvalidCastException)
	{
	HandleCorruptedKey(key);
	return default;
	}
	catch (FormatException)
	{
	HandleCorruptedKey(key);
	return default;
	}

[ghost1372]

Like above

[Zakariathr22]

Looks like there’s an issue when running the app unpackaged:

• Navigate to App notification page
• Click Show notification button

The app crashes with an unhandled exception.

[ghost1372]

Looks like there’s an issue when running the app unpackaged:

• Navigate to App notification page
• Click Show notification button

The app crashes with an unhandled exception.

The AppNotificationManager throws an "Element Not Found" exception and is not related to this PR!
This crash can be easily fixed but should be addressed in a separate PR.

As described here, we need to register it. I tested it, and it works fine in the unpackaged scenario. So, this requires additional work and should be done in a separate PR (we can keep the current logic for packaged mode and add a registration/scenario for unpackaged mode). Here are the Microsoft docs and samples for unpackaged scenarios.
https://learn.microsoft.com/en-us/windows/apps/develop/notifications/app-notifications/app-notifications-quickstart?tabs=cs
https://github.com/microsoft/WindowsAppSDK-Samples/tree/main/Samples/Notifications/App/CsUnpackagedAppNotifications/CsUnpackagedAppNotifications

[marcelwgn]

Thank you for working on this! There are some comments and one issue surrounding lists.

Previously, we used a string and comma separated the entries in there to represent that. The new code doesnt account for that which results in people losing their favorites and recently viewed as the old field (string) does not match the expected type (list of strings).
We need some conversion code for those so we can migrate users.

[ghost1372]

Hi @marcelwgn
Thank you for your review.
I’ve addressed the suggestions you made earlier.
I’ve added migration methods to preserve the user’s Favorites and Recently Visited items.

[marcelwgn]

Nice, didnt know that existed!