Trying to get finder to open Spotify links…
In Applescript, it’s dead simple:
tell application "Finder"
open location "spotify:album:5UQo0dIJc9nfkt2HWd2GCp"
end tell
But I can’t figure out the equivalent in Obj-C with the scripting bridge. Anyone done this before?
What do you mean by that? Do you want to do it in Objective-C or in applescriptObjC? Also, what kind of an address is spotify:album:5UQo0dIJc9nfkt2HWd2GCp? That doesn’t look like a complete URL.
Ric
Sorry I thought they were one in the same. I want to do it in Objective-C using scripting bridge. So I have a Finder object
FinderApplication *finder = [[SBApplication applicationWithBundleIdentifier:@"com.apple.finder"];
And I want to use it hopefully to launch a URL using the appropriate app. Spotify uses special URLs that Finder understands, similar to how it knows to launch a browser with “http://”. So the solution would apply to regular URLs as well.
Hi,
consider, that the Finder is not needed at all to open an URL.
open location is part of Scripting Additions which works without any application tell block.
The usual Objective-C method to open an URL is openURL: of NSWorkspace.
PS: Since Snow Leopard is providing AppleScriptObjC forget ScriptingBrigde !
Why? I can imagine why someone uses scripting bridge:
Not really. Assuming you’re using it to send Apple events to applications, the speed difference, as a percentage, will be negligible. The main time is going to be spent in the sending and receiving (and processing by the target app).
Then good luck understanding scripting dictionaries and conventions. And then understanding why scripting bridge doesn’t understand them.
Can you give any real-world examples?
There are prizes for this? 
That is true.
Now for the cons: www.cocoadev.com/index.pl?ScriptingBridgeCriticisms
But maybe some people will enjoy having all their AS errors turned into NSExceptions…
The AppleScriptObjC questions on MacScripter indicate that there is much much more AppleScript experience than ObjC
Yes, and it leaks memory (at least in Leopard)
In pre Snow Leopard times I’ve tested Scripting Bridge a lot and then I switched to the third-party AppScript.framework for several reasons.
I’m not an avowed fan of AppleScriptObjC, but for scripters it provides the best integration of AppleScript language in an ObjC environment
I was only referring to ‘forget scripting bridge’ comment, I don’t agree with that in general. I know AppleScriptObjC is better in most ways but from the Objective-C point of view (which I use AppleScriptObjC the most) it comes with more drawbacks than when you write the application visa versa (loading cocoa objects into AppleScriptObjC objects). I agree that when you want to write a lot in AppleScript you should definitly use AppleScriptObjC but when you write Objective-C applications and need a few lines of AppleScript, scripting bridge can outperform AppleScriptObjC. You’re true about the memory leaks in Leopard.
@Shane: An experienced Objective-C programmer has more than enough from the header file. I don’t need documentations much I use the ‘jump to definition’ feature much more to understand what’s happening or to look what the return value of that method was. Header files are so much easier to read than documentation.
It is on the site of Apple itself, it’s not something I made up. As for the example returning data try to return properties of a document from application QuarkXpress. Try to make iTunes for example fully scriptable in Objective-C by creating an AppleScriptObjC class to act as a bridge. You will neeed hours and hours of programming, with scripting bridge you can create in a blink of an eye an useful header file for you.
@all: When you don’t turn save exec-only on you’re vulnerable against programming hi-jackig and insertions… you don’t have that with scripting bridge. So in some sort of way it is much more secure. I could replace the AppDelegate script inside the application bundle and replace it with my own. Because it’s a delegate class you can add any kind of line to that file and therefore AppleScriptObjC application can be turned easily into bad applications and shared to third party servers.
Scripting bridge can be used without garbage collection on, according to Apple"s documentation they’ve solved the memory leak problems. If you want to track down memory leaks, don’t use xcode 3 because it’s inaccurate (singletons are considered as memory leaks as well).
Again, I wasn’t saying AppleScriptObjC is bad, i think it’s good actually, but SB is has it’s pro’s and can be used in some situations pretty well. I never recommend to use scripting bridge as a substitution for AppleScriptObjC nor Studio but like I said when an application needs a few lines of AppleScript, scripting bridge can be used well today.
But they don’t solve the problem for scripting bridge. Unless you know how AS works, a header file is just as likely to mislead you. The scripting bridge headers make all sorts of assumptions that (unfortunately) you just can’t make about how apps respond to various commands.
But it’s dreadfully misleading. The reference to uncompiled AS is irrelevant, and the other ignores the real time taken by scripts. I haven’t done any timings, but my guess is that ASObjC is also quicker than a standard precompiled NSAppleScript – but big deal, we know where the real time is spent.
Except iTunes is one of the apps scripting bridge is actually broken with lists.apple.com/archives/Applescript-implementors/2007/Nov/msg00047.html. II’m afraid I don’t understand the reference to using an AppleScriptObjC class “to act as a bridge”. You write AS handlers to deal with iTunes, and you call them from your Objective-C. No big deal. (I actually did an example app with iTunes of this very thing for a presentation on using ASObjC from Objective-C.)
But who doesn’t turn it on?
ASObjC can also be used with garbage collection on, if you really want to. And we’re talking here of basically adding a class to drive an app, so there’s not much memory management involved.
ASObjC has plenty of short-comings, for sure. But IMO they pale in comparison with those of scripting bridge.
And as the link I posted earlier shows, that’s not just my opinion.
I didn’t refer to you links on purpose because they are old posts using the older version of scripting bridge (november 27 2007 while apple has updated scripting bridge in 2009 for the last time).
We can of course go endless about the cons and the pros. My first statement was that scripting bridge shouldn’t be forgotten. It has quite some improvements since Snow Leopard. And the funny thing is that we’re all the time on the same side. I mentioned several times that AppleScriptObjC is good but it isn’t superior to Scripting Bridge in every context but it is in a lot. Some things can AppleScriptObjC do but not everything AppleScriptObjC can means it does it better.
Hey guys, just checking in to see if anyone had a solution but it’s turned into a battle of conventions. I’m using Scripting Bridge simply because I wanted to do the whole app in Objective-C from top to bottom. StefanK’s suggestion to use openURL on NSWorkspace is good. However I also would like to be able to do this on a remote machine.
Again this is very simple in AS…
tell application "Finder" of machine "eppc://whatever.local"
open location "spotify:album:5UQo0dIJc9nfkt2HWd2GCp"
end tell
That’s why I thought using a FinderApplication object would be the way to go. It seems though that open location is part of Scripting Additions and I don’t know if that’s available via Scripting Bridge. Any other thoughts?
I suppose if all else fails I can just create an AppleScript object…
NSAppleScript *as = [[NSAppleScript alloc] initWithSource:@"tell application \"Finder\" to open location \"spotify:album:5UQo0dIJc9nfkt2HWd2GCp\""];
[as executeAndReturnError:nil];
Can’t you include the eppc://whatever.local in the URL?
I’ll try that, but I have a feeling it won’t work. In this case, “spotify” is the protocol that it’s using to identify the app to open. Whereas including the “eppc://” would indicate a local area Mac machine.