MessageView not hiding

[krakowski]

Calling SwiftMessages.hideAll() directly after showing a dialog won't hide it.

This should reproduce the issue:

var config = SwiftMessages.Config()
config.duration = .forever

let view = MessageView.viewFromNib(layout: .CardView)
SwiftMessages.show(config: config, view: view)
SwiftMessages.hideAll()

I know this piece of code effectively does nothing. In my case I wait for an event and hide the dialog afterwards. Unfortunately, this seems to happen too fast. It looks like some time has to go by before I can hide the dialog.

[TwinkyDaniel]

I have basically the same problem. I am showing a deferred message and want to replace it with another message. I think the problem is the invoke into the main dispatch queue when showing and not invoking when hiding. At the end of the day hiding will hide nothing because the show call is still inside the queue.

[wtmoose]

@filkra @TwinkyDaniel thanks for bringing this up. Would you mind taking a look at the head of developer and let me know if this works for you?

With this fix, calling show immediately followed by hide results in the message being displayed very briefly. This is due to the message queue being managed asynchronously on a background queue.

In order to have the message not display at all, I would need to eliminate the background queue, requiring all SwiftMessages calls to be made on the main queue. This is probably how it should have been done in the first place, but given that it's a backward incompatible change, I'm inclined to leave the background queue in place.

I'm interested to hear your thoughts.

[TwinkyDaniel]

The fix works for my issue. Thanks for the quick response! I was previously using CSNotificationView and switched to your library a few days ago. Your library is working a lot better and has better features. Thumbs up for that great work ;-)

Regarding the background queue: I wouldn't mind having to schedule all messages on the main thread since this is a concept that's present in the majority of ui libraries. But I can also see the reason to have the ability to send a message from anywhere without thinking about threading and queues. If you want to support both without breaking changes, maybe have 2 different sets of methods?

[wtmoose]

3.5.0