Skip to content

Conversation

ghost1372
Copy link
Contributor

@ghost1372 ghost1372 commented Aug 7, 2025

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);
}

ghost1372 referenced this pull request Aug 10, 2025
…centralize settings keys (#1900)

## Description
- Replace `Windows.Storage.ApplicationData` with
`Microsoft.Windows.Storage.ApplicationData`.
- Centralize Settings Keys in a `SettingsKeys` Class.
- define key constants in `ScratchPadPage`.

## Motivation and Context
- Closes #1892
- Closes #1893

## How Has This Been Tested?
**Manually tested**

## Screenshots (if appropriate):

## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)

Co-authored-by: Niels Laute <niels.laute@live.nl>
Copy link
Contributor

@Zakariathr22 Zakariathr22 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@niels9001 niels9001 requested review from Copilot and marcelwgn August 30, 2025 13:00
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +67 to +70
catch (Exception)
{
HandleCorruptedFile();
}
Copy link

Copilot AI Aug 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[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();
}

Copilot uses AI. Check for mistakes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines 41 to 45
catch (Exception)
{
HandleCorruptedKey(key);
return default;
}
Copy link

Copilot AI Aug 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[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;
}

Copilot uses AI. Check for mistakes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like above

ghost1372 and others added 2 commits August 30, 2025 16:50
…ider.cs

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…ettingsProvider.cs

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
@marcelwgn marcelwgn self-assigned this Sep 8, 2025
Copy link
Contributor

@Zakariathr22 Zakariathr22 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

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

Copy link
Contributor

@marcelwgn marcelwgn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

private void SetWindowProperties()
{
#if DEBUG
#if DEBUG || DEBUG_UNPACKAGED
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is Debug_Unpackaged not also ifdeffing DEBUG?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Unpackaged Mode with the Debug profile, I always encounter COM registration exceptions.

image

However, if I use Debug-Unpackaged, the app works fine, but the 'Dev' text does not appear unless I add || DEBUG_UNPACKAGED

image

}

m_oldText = xamlStr;
m_oldText = GetDefaultScratchXAML();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it intentional we are no longer storing the xaml scratchpad content?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, more info here
#2014 (comment)

return (T)JsonSerializer.Deserialize(str, typeInfo);
}

return (T)Convert.ChangeType(value, typeof(T));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit suspicious, are we actually hitting this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since it’s been a long time since these lines were added, I don’t remember the exact reason (I am very busy these days.😅), but it was probably to prevent crashes and handle settings stored by the previous system. If you prefer, I can replace it with an InvalidCastException.

Renamed AddToFirst and AddToLast extension methods to AddAsFirst and AddAsLast for improved clarity and consistency.
Replaces usage of ProductNameAndVersion with ProductName
@ghost1372
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

UnPackaged Mode is Broken

4 participants