🧪 [Experiment] StackedNotificationsBehavior for InfoBar

[michael-hawker]

Approved from Toolkit

See previous work here:

• [Feature] Prevent InAppNotification from disappearing when hovered WindowsCommunityToolkit#4194
• InfoBar StackedNotificationsBehavior WindowsCommunityToolkit#4399

FYI @vgromfeld

Problem Statement (copied from Discussion):

The InAppNotification control is automatically hidden after the expiration of the notification duration. The durations we are hardcoding in our applications may not be long enough to allow the users to fully read the message. We should have a way to keep the notification visible for a longer time if the user wants/needs it.

Overview

This experiment adds the following components:

• StackedNotificationsBehavior a behavior for the WinUI InfoBar control that provides a message queue.

Using

You can try it out via the NuGet Packages here:

• UWP: https://dev.azure.com/dotnet/CommunityToolkit/_artifacts/feed/CommunityToolkit-Labs/NuGet/CommunityToolkit.Labs.Uwp.StackedNotificationsBehavior
• WinUI 3: https://dev.azure.com/dotnet/CommunityToolkit/_artifacts/feed/CommunityToolkit-Labs/NuGet/CommunityToolkit.Labs.WinUI.StackedNotificationsBehavior

Read more about Preview Packages here.

CommunityToolkit members can also try it out with Codespaces.

TO DO

• Do we need an option to change ordering behavior of incoming messages (i.e. show newest ones before older ones vs. in received order?)
• Replace button in example (see Add more Sample Option Attributes #207)
• Show duration example (see Add more Sample Option Attributes #207)

Implementation Requirements

Not all these items are required to submit a PR. This list is here to help track what is remaining to implement before a technical review and discussion of moving into the main repository can occur.

• Working Prototype
• Feature Complete
• Documentation
• Samples
• Tests
• Community Feedback / Usage Testimonies

Tested Platforms

• UWP
• WinAppSDK / WinUI 3
• Web Assembly (WASM)
• Android
• iOS
• MacOS
• Linux / GTK

Technical Review

These items can sometimes be done ahead of time, but are usually started and completed after all implementation details are finished.

• Accessibility Audit
• API/Naming Review
• Code Quality/Style
• Dependency Review
• Design/Style Review
• Final Approval

[michael-hawker]

Oops, we need to make sure not to accidentally close our experiment tracking issues (well until they end up in the main Toolkit that is). I didn't think we had a 'fixes' keyword in the PR... @Arlodotexe did you close this manually?

[Arlodotexe]

Looks like the issue was closed automatically by the linked pull request