It just hit me that Apple probably switched the alert UI API from UIWindow to UIVC to simplify their multi-app iPad UI implementation.
Conversation
the problem with UIAC is that it requires the code displaying the alert to know the current frontmost VC, which it may not relate to.
2
sure, but that's not necessarily a bad thing: it requires code with the side effect of presenting UI to have that injected.
1
but if you consider the typical use case for alerts - e.g failure of an async network task - there's no clear injection point for that
1
the network layer should just NEVER present UI. It should never be coupled to UIKit. Even the more reason now with watchOS.
1
5
I agree, but if I start a network request, which piece of UI can I delegate to that'll know the frontmost VC at some point in future?
2
2
whatever piece of UI the user performed an action in that fired that request.
1
1
that doesn't work. If I send an email, then return to the inbox, the composer VC will be long gone by the time request succeeds/fails.
2
3
so the composer needs to know this and use its presenter, or delegate the responsibility to the presenter.
1
1
I think the problem is that only UIKit knows what is presented (and how to present). Your app needs to know.
2
1
Replying to
The view controller stack should be a deferent function of Truth—your application’s state (a data type).