On Dec 4, 2012, at 7:49 AM, Brad O'Hearne <br...@bighillsoftware.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
