On Aug 22, 2013, at 9:00 AM, Kyle Sluder <[email protected]> wrote: > On Aug 22, 2013, at 8:00 AM, Jens Alfke <[email protected]> wrote: > >> >> On Aug 22, 2013, at 1:34 AM, Uli Kusterer <[email protected]> >> wrote: >> >>> The notion of one of these being ‘more correct’ than the other is >>> ridiculous. The second case is simply a performance optimization from the >>> classic MacOS days that was carried over to OS X. >> >> Nope. (And not to pull rank, but I was on the AppleEvents/AppleScript team >> at the time we figured this stuff out [1991] and added the seemingly-useless >> ‘oapp’ event in response to developer complaints.) >> >> Many apps have a different behavior when launched with no docs/URLs (e.g. >> the app itself is double-clicked). For example, Apple’s iWork apps open a >> new-document assistant. The only reliable way an app can tell whether it was >> launched without a doc/URL is if it gets the ‘oapp’ event instead, and the >> way that event gets sent is when LaunchServices is told to launch the app >> but not given any other AppleEvent to launch it with. Thus there is a >> valuable semantic difference between the two cases. >
Jens -- this is exactly the scenario which I had expected, which it appears is not always the case. > In your example, the difference doesn't matter. If the app is sitting at the > new doc assistant, or has a default blank document open, it should close that > assistant or document and open the one requested via URL. Apps have been > doing this for decades. Kyle -- understood that it can be done, and understood that apps need to be prepared to open (or respond) to a registered handler, even if the app is already running. But visually there is potential for weirdness on launch if your app has to complete loading while being completely deprived of the way or reason it was launched, and having no knowledge of whether that info will ever be delivered to the app. During loading, you have to assume the app was launched independently by the user (not by an open event), which likely will cause you to load and present some UI to address where a user likely will start their use of the app (like the new document assistant Jens mentioned). Then if you receive the URL handler callback, you immediately whisk that away and present the opened document. That is going to be perceived as some kind of malfunction by the user -- I've fixed more than one of those launch flickers, almost always considered bugs (despite whether they were otherwise logically correct). While this may well be true that there is no sequence, this one developer's view is that while an app should be able to respond to any downstream open event while running, it makes no sense to arbitrarily deliver or delay information about how an app was launched to the app sometime after the launch loading is complete. That effectively suggests having to poll and eventually timeout in order to get the initial UI display right, which seems really unnecessary if the proper protocol is just to tell an app when loading how it was launched. Brad _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
