Re: Get the current displayed NSAlert
Re: Get the current displayed NSAlert
- Subject: Re: Get the current displayed NSAlert
- From: Kyle Sluder <email@hidden>
- Date: Tue, 04 Dec 2012 08:04:29 -0800
On Dec 4, 2012, at 7:49 AM, Brad O'Hearne <email@hidden> wrote:
> In general -- any alert that requires user attention (especially ones with multiple button alternatives) can be left on the screen indefinitely by a user. If you are monitoring environmental conditions (such as network, server, or Internet reachability) that arise, it is always possible that such an event that would necessarily need to supersede the displayed alert, as the global event (environmental condition) might prevent the normal course of action which the first alert would provide. For example:
>
> 1) Alert one displays:
> "This condition took place, would you like to proceed with option X or option Y". (Assume both X and Y require Internet connectivity).
>
> 2) The app detects a loss of Internet connectivity. Neither X nor Y are now appropriate until the Internet reachability issue is resolved. So what we need to do is redirect the user's attention to resolving the more important problem at hand, fixing the network issue, a second alert condition.
>
> The thing compounding the issue is that 1) and 2) occur in somewhat unrelated parts of the app which necessarily do not know what each other is doing (other than existing). That is actually a very good thing -- and we want to somewhat keep it that way. They do have a relationship, however, in that the managing entity in 2 actually controls the entity in 1 (though agnostic to its function). So the problem was resolved by having the managing entity in 2 issue a lifecycle message to the entity in 1, so that it could behave accordingly.
>
> Its working, but in any such architecture (an OS is a good example) there is the constant tension between managing resources globally vs. separating and hiding concerns within components.
Yeah, you're walking that fine line between “framework” and “application” that requires such attention to balance.
We use a lot of frameworks in our products. I constantly have to remind myself that the framework is not my product; the app is, and that might mean severely reining in the scope and generality of the supporting framework.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden