[Feature] Consistency of URI usage

[cz-dev-ge]

Describe the problem this feature would solve

In some classes like ToastContentBuilder::AddButton URIs are expected to be of type System.Uri, in others like ToastButtonDismiss::ImageUri it has to be a string.

Describe the solution

Change all to the same type - preferably System.Uri.

Describe alternatives you've considered

Always provide two setters.

Hello, 'georg-eckert-zeiss! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[Kyaa-dost]

@georg-eckert-zeiss Thanks for the idea! Going to open this up for discussion and see what other community members think 🤔

[michael-hawker]

FYI @andrewleader. 7.0 seems like a good time to clean this up with the other changes we're making. :) Thoughts?

[michael-hawker]

@andrewleader wanted to make sure you saw this before we close down on the release, now that we're past the holidays.

[andrewleader]

I'll hopefully get this coded up today!

[andrewleader]

Hi @georg-eckert-zeiss, what do you think of this? As part of 7.0 we have new builder API patterns for buttons, and you can use that to build a Dismiss (or Snooze) button too. The SetImageUri APIs take a URI rather than a string.

new ToastContentBuilder()
                
    .AddButton(new ToastButton()
        .SetContent("Delete")
        .SetImageUri(new Uri("delete.png"))
        .AddArgument("action", "delete")
        .SetBackgroundActivation()

    .AddButton(new ToastButton()
        .SetImageUri(new Uri("dismiss.png"))
        .SetDismissActivation());

We'd leave the old ToastButtonSnooze and ToastButtonDismiss APIs as-is.

The only other API I think that still uses string is AdaptiveImage, but that's less commonly used within toasts (only needed if you're using AdaptiveGroup and AdaptiveSubgroup), so I'll leave that as-is. We have long-term aspirations of taking all of these APIs and bringing them into Project Reunion (like two years from now), at that point we'll have even more opportunities to clean up all the APIs, right now I think this change should be sufficient enough without introducing any breaking changes.

What do you think?