I’m working on an app where I want to signal iTunes at certain times to play single tracks from whatever playlist happens to be active. I’ve just started studying Scripting Bridge, I’ve used the command-line tools Apple references to create an “iTunes.h” file, and I’ve got this and ScriptingBridge.framework in my project. Now I thought all I would have to do is
iTunesApplication *iTunes = [SBApplication applicationWithBundleIdentifier:#"com.apple.iTunes"];
and when I want to cue whatever track is up next:
[iTunes playOnce:YES];
iTunes does respond, but if I understand Apple’s sample code, the YES parameter should compel it to play one and only one track. In fact, it doesn’t seem to matter whether it’s YES or NO: iTunes always plays from the selected track to the end of the playlist, however many tracks that may be. Am I missing something? And since I need to send only one very simple Apple Event, is there a simpler way to do this than going through the whole Scripting Bridge framework?
In Mac OS X 10.6 Snow Leopard Apple introduced the AppleScriptObjC framework which provides a much simpler bridging between AppleScript and Cocoa. No more ugly header files.
In the script classes you can mix AppleScript with an Objective-C like syntax.
There is an AppleScriptObjC template in Xcode, but you can add ASOC to an existing Cocoa project by adding the AppleScriptObjC framework and call in main.m
[[NSBundle mainBundle] loadAppleScriptObjectiveCScripts];
The Apple documentation is quite poor, there are some resources on macosxautomation.com, a comprehensive book written by Shane Stanley is available there, too.
Related
I imagine the Swift language has gotten the attention of a boatload of iOS programmers - many of whom never wrote a single line of Objective-C in their life.
For example I have dozens of apps on the app store, written in Titanium.
In the Titanium world every property and event available is documented, for example like this for UILabel:
http://docs.appcelerator.com/titanium/3.0/#!/api/Titanium.UI.Label
Is there an Apple equivalent? I read the Apple iBook on Swift - it discusses the core language, it doesn't list out the methods available in the Cocoa touch framework, and leaves it to the programmer to intuitively guess based on their Objective-C experience.
Is that a fair assessment, that that you have to learn Objective-C first and then use that as a bridge language to Swift - or is Swift intended to be stand-alone? If so, where is the documentation of Cocoa Touch, in swift?
The documentation is included in Xcode6 (or can be downloaded). You can currently access it by going to Window -> Documentation and API Reference. (or by pressing shift, command & 0)
You will then have full access to search and find resources here. You can also option click on something in Xcode to pull up the docs for that specific thing.
As you will see it shows you the declarations for Obj-C and Swift together. This technically isn't Swift documentation (it is the iOS8 library documentation) but it should be similar to what you were looking for.
Note: this post originally included screen shots but I removed them as developers are not supposed to post screen shots of pre-released software.
The Cocoa Touch APIs and frameworks are the same between Swift and Objective-C. There are only minor syntax differences used when you call the APIs. The framework documentation is currently pre-release, so if you aren't a registered developer then you can't see it yet.
Hello All
In my application , i need to enable voice communication over IP,i.e. need to capture the Audio buffer and send it over the Internet, through secure socket,
In the Lower layer everything is ready, I need the entry point to start Voice Communication, but not getting any pointer in the Apple documentation, so far i have done following,
1 -- In the Apple documentation going through CoreAudio programming guide, is this right place to start,
2 -- if yes, somewhere it says, i need to download CoreAudio SDK, will it not come along with standard XCOde and Cocoa framework,
Kind Regards
Rohan
1: CoreAudio programming guide is the right place to start.
Also there are very good samples in Mac Dev Center and perhaps some iPhone examples are portable/useful as well (since CoreAudio in the iPhone is basically a sub-set of CoreAudio for the Mac)
2: You don't need to download anything else. If you have Xcode then just add CoreAudio.framework to your project and add #import <CoreAudio/CoreAudio.h>
Nacho4d is right. You don't need to download anything. The CoreAudio.framework is included in XCode.
As for learning how to work with Core-Audio in general Apple's documentation may be painful to use if you are not a seasoned programmer. Only one book has been written on the subject so far: It's called Core Audio (Rough Cuts) and it's written by Kevin Avila and Chris Adamson on Addison-Wesley Professional. It should help you with the basics.
I want to update my developing knowledge from iOS to Mac for distributing my apps to Mac App Store.
What are the differences? What are the limitations?
For example, if I want to port my iPhone app that syncs contacts with social network the various NSRequest or ABAddressBook are the same? It changes only views and corresponding view controllers?
Does exists some sort of "adapters" from iOS to Mac to easily convert iOS apps to Mac?
In general, what challenges Mac apps arise respect to iOS apps?
Thanks
If you've gathered some experience you will get along with mac development in no time. Mac and iOS have many things in common, however there are some gotchas, not all of which are visible at first glance.
The most obvious difference may be the use of viewcontrollers - cocoa for mac knows viewcontrollers, however they play a different (and less important) role.
I think the best approach for you would be to take a quick look at the Cocoa Application Tutorial and the Cocoa Fundamentals Guide. Most of it will appear familiar to you. Other than that I'd suggest to not port that project over, but use it as a opportunity to learn mac dev and recreate it from scratch (if it is not too complex). Of course you can copy paste many of the logic stuff, no need to reinvent the wheel.
By the way, I started out developing for iOS too and I found it to be very easy to get used to cocoa mac.
As to your question regarding NSURLRequest (I think that's what you meant, theres no NSRequest in either platform), they are almost the same. Just look it up in the reference library. I found it very helpful to have the iOS and mac os reference library available at the same in my browser, so I could look up differences quickly.
I'm dying to know how I can make a GUI for ffmpeg and jhead in OSX. I've been looking for a solution for a while and thought you, stackoverflow's users, could help me. Maybe you know some document I haven't come across of or, better, a tutorial to make a GUI.
I love those two tools but I like the simplicity of drag/drop operations.
Note: I don't need a GUI for them, I want to make one.
There is a tutorial for wrapping command-line tools using NSTask, on the Cocoa Dev Central site:
Wrapping UNIX Commands
Wrapping UNIX Commands Part II
It's a few years old now, but should get you started.
If you are asking "How do I create a GUI application in Mac OS X that interfaces to a command line tool" the answer is NSTask. Although, if the command line tool provides a programming API, using that would be preferable to invoking the command line tool itself.
If you are asking "How do I create a GUI application in Mac OS X" the answer is to read a book about it and look at the Apple tutorial docs. Cocoa Programming on Mac OS X by Aaron Hillegass was my starting point.
You can use a scripting language like Tcl, Python or Ruby with a toolkit like Tk which uses native widgets on the mac.
First create a Modal Dialog NIB with the needed GUI.
When called in C , create an NSReleasePool, and then the magic sauce.
[NSApplication sharedApplication]
ProcessSerialNumber psn;
GetCurrentProcess( &psn );
TransformProcessType(&psn,kProcessTransformToForegroundApplication);
SetFrontProcess( &psn );
Later after you load the NIB from the Bundle, issue
[NSApp runModalForWindow:[controller window]];
[[controller window] close];
Without the TransfromProcessType(), the Terminal app will get keystrokes, not the Modal Dialog.
This may not be the best answer but in the book "Xcode unleashed" is a chapter how to embed a Command Line Tool inside a Cocoa Application. Maybe you should have a look. Nice book anyway.
On your Leopard/Snow Leopard disk you can find XCode, but you can also download it from the Apple Developer Community. XCode comes with the Interface Builder, which lets you build GUI's and you can rig to your commands using the Cocoa framework.
You are too late, there is already a GUI frontend for ffmpeg called ffmpegX, but anyway, you would create a model that either wraps or uses the library or executable.... if it uses the executable you can use popen to invoke the executable, write to its STDIN, and read from its STDOUT. The view and controller would be basically the same as you would design it for any other GUI application. Since this is a Cocoa post, you could use Objective-C and Cocoa to the make the GUI, but it really can be implemented in any language.
In the wikipedia article on Cocoa it says:
There are also open source implementations of major parts of the Cocoa framework that allows cross-platform (including Microsoft Windows) Cocoa application development, such as GNUstep, Cappuccino, and Cocotron.
Yet when I looked into whether Mac application Tweetie was available for windows the developer had ruled it out:
Windows doesn't have Cocoa, the programming environment that Tweetie is made in, as such, it seems like a poor possibility.
I'd like to have an answer to point the Tweetie developers (and as a resource for other cocoa developers) which would tell them:
Which implementation is the most suitable for getting a cocoa app running on windows?
How much work is it likely to take to get the app running under windows?
How easy/hard is it to maintain a common code base for Mac and Windows?
(any other considerations I've missed?)
Of course if it would be too much work I'd like to know that too before suggesting it and potentially sending someone else on a fruitless search.
Don't forget:
“Major parts of the Cocoa frameworks” is not the same as “the entirety of the Cocoa frameworks”. Tweetie could be using something that's missing.
Tweetie could be (very probably is) using APIs from the non-Cocoa frameworks, such as Core Foundation, Core Services, Core Graphics, and Core Animation. A port of the Cocoa frameworks alone won't include any of these APIs, and even a more complete Mac-API-emulation framework will not include all of them.
These frameworks are eternally chasing Apple. Even if they catch up, they'll be instantly behind again as of the next Mac OS X release. Mac developers already put off using new APIs in new Mac OS X releases while they wait for users to upgrade to those new releases; now you're asking atebits to also wait for the other-framework developer to catch up to Apple again.
Any second implementation of an existing API will have bugs that the first implementation doesn't, and vice versa. These differences will cause development and support problems.
You're asking atebits to add a third platform to an application that already exists on two. Supporting one platform is a lot of work. Supporting two platforms is a hell of a lot of work. Supporting three? Now you're getting into big-company territory.
So, even with these Cocoa-like frameworks, the answer is: Hard.
Among GNUstep, Cappuccino and Cocotron, Cocotron is only possible choice to port a Mac application to windows.
Cappuccino is for web and GNUstep only runs on top of cygwin or mingw, which means the GUI looks nothing like native windows apps.
It is theoretically possible to build cocoa windows apps using Cocotron. However, the reality is that it is still very hard to use, and it is still quite limited in the Cocoa API.
Therefore, two possible solutions:
Try hard to remove the codes that are not supported by Cocotron in the original code base and do the cross compilation. Maintaining common code base will be painful.
Start a new GUI at all, no common code base. two choices here
Start a cross platform project with cross application framework such as Qt, or Java.
Start a windows only project. There are a lot of choices here, .Net WinForm application, MFC, etc.
There are Windows compilers for Objective-C (the programming language used to write cocoa apps). However, Cocoa includes the frameworks for presenting the GUI. These visual frameworks are specific to Mac OS X because they use OS X only windows and other controls. So someone would need to re-implement the controls in Cocoa to use Windows controls.
Also, I am fairly certain that Tweetie uses Mac OS X only technologies like Core Animation. This does not exist on Windows, so the nice animation effects present in the apps would have to be implemented in a completely different way.