Re: Get the current displayed NSAlert
Re: Get the current displayed NSAlert
- Subject: Re: Get the current displayed NSAlert
- From: "Brad O'Hearne" <email@hidden>
- Date: Tue, 04 Dec 2012 08:49:12 -0700
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.
Thanks for the replies everyone, they are greatly appreciated.
Cheers,
Brad
On Dec 4, 2012, at 12:54 AM, "email@hidden" <email@hidden> wrote:
>
> On 4 Dec 2012, at 06:26, Kyle Sluder <email@hidden> wrote:
>
>> I think you're thinking about the problem too generally.
>>
>> The workflow manager is probably going to need to understand that the
>> plugins it's running can have encounter exceptional conditions.
>> Therefore, there should be a mechanism by which your processing plugins
>> can inform the workflow manager of these exceptional conditions.
>
> I would implement an alert controller that would accept prioritised alert requests either from the app or a plug-in.
>
> I would also ask myself whether a simple alert sheet is the way to go.
> Alerts are asking for the user to attend.
> If a plugin alert is displayed and then inexplicably replaced by another it looks as if the software is conflicted.
>
> Perhaps the alert controller displays a single dismissible window that contains a scrollable prioritised list of active alerts.
>
> Jonathan
> _______________________________________________
>
> 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
_______________________________________________
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