Well, my ‘attempting’ to learn Cocoa goes okay, though the most creative thing I’m managed so far is changing the names of buttons
But anywho…
A question I kind of raised to myself was this: Is there any definate advantage to writing an app in cocoa, vs writing that same app in AppleScript? I understand that AS is pretty much a frontend for cocoa methods (Which would mean it’s a translated, not direct language, wouldn’t it?). But is there any obvious performance increase, (I mean… on small scales. Obviously you’re not writing the next big FPS in Applescript) or perhaps a difference in memory usage?
The other thing, unrelated to Applescript, is for those who are familliar with Cocoa here. Is there any difference between creating/hiding your objects in IB, vs creating them programatically? (Smaller memory usage, etc?) I refer to more of a simple app. One window, maybe some buttons, and a NSView or two.
I apologize that this isn’t entirely on-subject for here, but there are really no active mailing lists that I can find that really speak ‘english’ for the learner
For the most part, you’ve already answered most of your questions yourself, but I’ll add a bit more.
It all depends on what you’re creating. In many simple cases, you can get away with using either. ASStudio was born from the desire to add interfaces to applescripts… a legacy which is often hard to shake. I think most developers who start with ASStudio and then eventually find themselves asking the questions you’re asking know exactly why. You realize that you want to do more than add an interface to a simple script. You want to build a real application, something with depth and flexibility. Something that requires a prowess that ASStudio just doesn’t have. Applescript has many real limitations, and once you begin to find them I think it is realistic to start looking to other alternatives… such as cocoa. Yes, applescript studio is really just a “front end” for cocoa. And, when you finally take a long, hard look over the fence, it’s easy to see all that you’re missing on the cocoa side.
To it’s advantage, ASStudio is a rare breed in that it has a user-centered approach to pretty much every aspect. It’s language is easy to learn, it is fairly intuitive, it offers great power (relative to plain applescripts), it is very accessible, and it’s abilities can be extended using a bit of creativity. Many of us here got our first taste of developing real applications thanks to ASStudio, and it offers a great learning ground for people to get some experience developing apps. I have never been one to see ASStudio as an end to the path, though. For some reason, I’ve always cringed at the thought of people releasing ASStudio apps publicly… even my own. I’ve always felt like developing apps in ASStudio was kind of cheating. For large-scale commercial apps, developing in ASStudio is probably not the route to take. I think progress is born of necessity, and most people come to realize on their own when it’s time to move on to something more powerful. I got to the point where I was either trying to somehow integrate vast amounts of obj-c into my scripts or force applescript code into cocoa-based apps, and came to realize it was easier to officially make the switch and write it all in obj-c instead of hanging on to applescript just for nostalgia’s sake.
Yes, there are often performance and memory issues with applescript vs. cocoa. It’s not uncommon to have weird issues with speed and reliability in ASStudio apps. This can be attributed to a lot of factors, but it’s often largely related to how ambitious your project is. Simply displaying a bit of info and making little interfaces is usually not too much of a challenge and doesn’t have much overhead. Developing a full-blown app that has lot’s of bells and whistles can really slow things down. Also, in cocoa apps, you rarely call on other apps to do things for you. You can handle data, images, file operations, etc. all in native cocoa methods… rather than calling on the finder, scripting additions, etc to handle simple tasks. And to be fair, both AS and cocoa have their own memory issues. Applescript does have some memory things you have to watch out for, and I’m still not convinced that there aren’t some major flaws in how ASStudio apps manage their memory “automatically”. Cocoa, on the other hand, can be a major chore to manage memory in. One of the most tedious parts of building apps in obj-c is making sure to keep track of your memory usage. You must consciously and manually be in charge of every bit of memory you allocate, which, in the case of a major application, can become a job in itself.
As far as memory goes, it doesn’t sound like it would make much of a difference for an app of this complexity. An object is an object, and it has to live in memory regardless of how it’s created. It’s usually more complex for you as a developer to manage objects created programmatically than by setting them up in IB. I rarely create interface objects dynamically… and usually only do so with good reason. In most cases it’s best to create the interface in IB and find ways to disable or hide objects when they aren’t needed.
I’ve made the switch, and encourage other who have come to the crossroads to do the same. While ASStudio does have a place, I think you know when it’s time to move on to something bigger and better. While it’s a bear to learn obj-c, it’s worth it in the end if you have plans to make development a more significant and lasting addition to your life.
Studio-based applications depend on the AppleScriptKit framework to provide an AppleScript-Cocoa bridge. That bridge has various limitations, e.g.:
It isn’t a full two-way bridge - only part of the Cocoa API is natively bridged, and while there is a ‘call method’ command you can (tediously) use to call into other ObjC/Cocoa classes from AppleScript, there’s no way to call into AppleScript directly from ObjC (although there are various ugly hacks you can use to sort of fake it). So Studio programming has a limited comfort zone, and anything outside of that zone (e.g. distributed notifications, scriptability) is effectively impossible, or at least far more trouble than it’s worth.
Its built-in support for writing document-based applications is fairly lousy. While you can ‘attach’ separate script instances to individual document objects, there’s no way for one script to communicate with another short of more kludges. The only alternative is to use a single script and write all the code to manage your document controllers yourself, which works fine but is a chore to do and requires more expertise than it should considering the target market. (FaceSpan does this stuff much better, BTW.)
It’s relatively inefficient.
There are other problems too: the AppleScript language itself is slow and underpowered, and its lack of threading support means you can easily end up with an unresponsive GUI when performing time-consuming tasks (unless you farm those tasks out to other processes, which introduces various hassles of its own due to the other limitations of AS and ASK).
For simple tasks, Studio is fine. For more sophisticated work, you’ll soon find yourself butting into various AS/ASK limitations, at which point you should seriously consider switching to a better language and bridge - e.g. Perl + PerlObjC/CamelBones, Python + PyObjC, Ruby + RubyCocoa - or to ObjC. Obviously there’s a greater learning curve with using the Cocoa APIs proper - partly because they’re so much more extensive, partly because they’re a bit more abstract, and partly because they require a degree of competence in object-oriented programming - but once you get over that it’s a very nice, powerful API to work with.
FWIW, I tend to use Python+PyObjC myself, and it’s a very nice combination - you get a good dynamic interpreted language (lots of great libraries and quicker write-test-debug cycle than ObjC) and an excellent full two-way bridge with automatic memory management and the option of dropping into C/ObjC should you need to write performance-critical sections of code in a faster language.
heh, thanks for the responses. I agree with your ‘releaseing a cocoa vs Studio app’ bit, J
I’ve begun work on an app I’d like to release, and already notice a difference in performance vs it’s applescript counterpart, and with some success. I’ve got it loading the WebView sucessfully, which is the huge hurdle that I was having trouble with. (All this [webView mainFrame] stuff shiver Well, I’m learning :P)
But I still have to figure out the one major thing I want to do that made me attempt this again in Cocoa. Handling JavaScript links from within my WebView. I’ve discovered a tutorial that outlines how to open those links by creating a new webView window, using a Document-Based project, which I got to work fine. However, I cannot find any, nor have I been able to modify the information the tutorial gave me, to open those links in the default browser, which is the prefered behavior. (And I’m not using a document-based project) Ah well, I’ll keep searching
I’d almost suggest that even though this is MacScripter, that maybe an Obj-C section could be added? A good percentage of the people here know what they’re doing with that, and I’ve never found a more helpful bunch.
But to avoid clutting this section up with another topic, I guess I may as well ask here. Is anyone aware of a method that catches Javascript link requests in a WebView?
I.E- I click a javascript link inside my WebView that, in a browser environment, attempts to open a new window. Obviously, without the appropriate methods, my WebView can’t do that. Which is fine, actually, as I want to open that link inside the default browser.
All I’m attempting to do is catch the link that it’s requesting, so I can send [[NSWorkspace sharedWorkspace] openURL] (Hey! I actually recalled that from memory!) to open that URL in the default browser.
I’ve tried several different methods that are listed in the WebView class header, but none seem to do what I’m looking for. (They return a webView, when I’m looking for an NSURL, for example) Google searching doesn’t seem to turn up anything, either. (All of them refer to opening new WebView windows)
Garbage collection in ObjC is a welcome new addition, but as far as Python and Ruby go, all they’re doing is including the existing PyObjC and RubyCocoa bridges as standard (OS X already includes the Python and Ruby interpreters, btw) and hopefully providing better Xcode integration.
Meanwhile, there’s nothing to stop folks downloading those bridges today and building their own completely self-contained applications with them. e.g. See the latest ASDictionary release for an example of a PyObjC-based application. (Note that the GUI is a little crude in places, but that’s because I’m lazy, not because PyObjC is lacking.) The advantage to developers of using Leopard’s built-in frameworks is a smaller distribution, as including the interpreter and bridge adds maybe 4MB to the download size. OTOH, a completely self-contained build is more portable (not automatically restricted to Leopard) and can take advantage of the latest releases (OS X’s Python and Ruby installations lag behind the current versions somewhat).
Again, you can already use appscript to script applications from Python, Ruby and ObjC, so while it’s nice to see Apple trying to promote application scripting to folks outside of the AppleScript community, it’s nothing that you can’t do already. (And FWIW appscript is almost certainly better than SB anyway.
So there’s no need for the OP to wait for Leopard for an alternative to Studio as all these technologies are available to use today. Personally I prefer Python+PyObjC, but you can’t really go wrong with any of them.
You should take this to Apple’s cocoa-dev mailing list or similar discussion forum more appropriate to these sorts of questions.
BTW, it’s also a good idea to check out the existing Cocoa documentation and other online resources first (Google is your friend) before posting to a high-traffic list like cocoa-dev in case there’s already a known solution.
