Overlay HUD + Alert

[nikola-milicevic]

Issue: https://radixdlt.atlassian.net/browse/ABW-1151

The base for showing HUD and Alerts in single/centralised place.

• Created a separate Overlay Window, with HUD and Alert components.
• Created an OverlayWindowClient to be medium through which the Main Window and Overlay Window communicate.
• Hooked errorQueue to show an error alert anytime there is an error.
• Hooked pasteboardClient to show Copied HUD anytime something is copied.

RPReplay_Final1688027790.MP4

[GhenadieVP]

Quite neat, a good solution.
left some comments for clarification.

[kugel3]

This is very important and useful functionality, but I think it should be implemented differently. First of all I don't think it's desirable that the view controller is responsible for dismissing itself through animation completions. Architecturally it makes sense for the client to handle this, especially when we start considering a queue of notifications of different types, including errors.

This also removes any reason to keep this in UIKit. When the client is in charge, this can easily be done in SwiftUI. Starting out it can just be a transition, later, with a queue, we might need to look at TimeLineView.

[nikola-milicevic]

I don't think it's desirable that the view controller is responsible for dismissing itself through animation completions. Architecturally it makes sense for the client to handle this, especially when we start considering a queue of notifications of different types, including errors.

Agreed, and that's how it is implemented - view controller is not dismissing itself. If you take closer look at the code, BannerView knows nothing about animation, BannerViewController displays BannerView (in viewDidAppear) and dismisses it. After dismissal of BannerView is complete, BannerViewController notifies the parent - the client - that the dismissal animation is complete, and then it's the client's responsibility to take the next step.

Currently it simply removes the window used for presentation. I would expand this feature further so the client actually encapsulates an array of notifications, each notification contains presentation animation type, which is propagated one by one to the child, implemented in UIKit or SwiftUI, whatever gives better result overall. Each notification has unique ID, and upon animation completion relevant notification element is removed from the notification queue. When there's nothing left in the queue, the client removes the presentation window.

So we would have to think a bit what do we want to display, how do we want that to look, and how do we interact with it. This is out of scope of this PR, and more importantly it's not something that would make the current implementation irrelevant.

This also removes any reason to keep this in UIKit. When the client is in charge, this can easily be done in SwiftUI. Starting out it can just be a transition, later, with a queue, we might need to look at TimeLineView.

The client is already in charge, it doesn't have anything to do with UI framework.

[nikola-milicevic]

Blocked by #450

[kugel3]

BannerViewController notifies the parent - the client - that the dismissal animation is complete,

This is what I'm referring to. I didn't mean that it physically removes itself.

[nikola-milicevic]

BannerViewController notifies the parent - the client - that the dismissal animation is complete,

This is what I'm referring to. I didn't mean that it physically removes itself.

Dismissal of banner view (the child) is separate from dismissal of the parent (view controller) which is controlled by the client. It's pretty standard parent - child relationship.

How would you design this feature?

[kugel3]

Like I wrote above, I think it's fine to have a view model/reducer control this, especially when the time comes to present a queue of notifications, some of which may be errors, and they may have different priorities. Then it will no longer be reasonable to listen to animation completions, it has to be centrally controlled. But it sounds like your argument against SwiftUI is that you want to use animation completions.

[GhenadieVP]

Probably need a better name than Overlay..., couldn't make something better.

[CyonAlexRDX]

maybe Foreground?

[CyonAlexRDX]

#if canImport(UIKit) ?

[GhenadieVP]

Let me double check if it actually is needed, was brought in from the old implementation.

[CyonAlexRDX]

await .... finish()?

[GhenadieVP]

This task is never meant to finish, the OverlayView is always shown, never ever dismissed.

[CyonAlexRDX]

#if canImport(UIKit)

[maciek-rdx]

Cool stuff and a lot of good code 👌

Let me know what do you think about the suggestions that I raised in comments though 🙏

[maciek-rdx]

Awesome! I'm particularly happy aboyt that one 🎉

I left you a small comment, cause it seems that the unsafe subscript is still there.