I'm building an application in C, which is a client/server sharing app. This application is command line based which uses TCP sockets, libcurl and some fork(). It should run in an infinite loop without any input.
My professor at the university said that we have to implement a GUI, and because I'm on Mac, I learned Object-C and I have done it in cocoa.
Now I'm asking myself if could be possible to merge the two applications, the cocoa GUI and the real application written in C. Of course I need the two "apps" to run in parallel.
Can I add it to my cocoa app? Where I have to put the code in order to have it always running? Not in awakeFromNib right?
I know that the question is kind of vague.
Thanks.
You could run the command line app as an NSTask and write the appropriate code so that they can commnicate via pipes. This way they will run asynchronously.
Alternatively you could definitely 'merge' them as c code will run just fine in an ObjC progam. The infinite loop could live in a different thread. Although this solution may require more re-writing than the previous solution.
Related
TLDR; is it possible to send/receive objects between an app and a 3rd party launch agent?
I'm writing an extension for an existing app (A). It's packaged and I do not have access to the source - but I can write simple plug-ins that can do some basic Cocoa and host a UI. Read: very limited options.
Ideally, what I'd like to do is have the plugin in app (A) message an external service (B) [sending objects], have (B) do some heavy lifting, then respond back to (A) so the UI can update.
I've been reading up on Launch Agents and they look promising, but I noted the examples all use basic types - no objects. I found one post discussing how to use Distributed Objects, but that's about it. It looks great, but what worries me is I'm not seeing a whole lot of current information on DO and I can't tell if it's something Apple will continue to support going forward.
Does anyone have any suggestions on options for a scenario like this? Maybe I'm just approaching this the wrong way?
Another option is I just completely split this out - write a separate full app and have (A) open it up with AppleScript. The UX wouldn't be as nice, but it would also work.
Thank you,
Eric
NOTE: I can't use NSTask. Or at least I've failed utterly to get it to work in this specific situation. Due to issues with app (A) it breaks when some of the methods run within the process. If I could somehow spawn NSTask so it was executing completely outside of (A) that might be an option. Which is actually what prompted me to look at Launch Agents...
I am developing an Applescript application using X-Code and I'm having the hardest time finding answers to questions. It's tough because I'm struggling to understand how the UI elements work, etc., and most answers to those questions are written in Objective C. I have learned a little bit about how to convert Objective C code into Applescript, but in most cases I'm still not sure.
For example, this answer shows some ObjC code, but I don't know how to make use of it in my Applescript application.
Is there a resource or guide that can help me to a) understand how to use Objective C code in my Applescript app, and/or b) how to rewrite Objective C code in Applescript?
In general, Applescript can be used to automate tasks (especially repetitive ones) for any MacOS application that exposes an Applescript dictionary.
One can compile and execute Applescript from within MacOS applications written in Objective-C (via the NSApplescript class, but the other way around, one would use Applescript to call into an already existing app (or one that you created yourself) that was written in Objective-C.
It sounds like you should write the lowest level stuff natively in Objective-C and see if you can automate that from within Obj-C, or expose an Applescript dictionary (via an sdef file that gets included in the Xcode project) and then you can use Applescript to do things via your native app.
Makes sense?
I am working with the QuickTime API and need to perform a few lengthy (as in hours) operations in the background. Unfortunately, it is not multi-thread friendly, so I am falling back to perform the tasks in a separate process, so all QuickTime related calls can happen in its main thread.
After launching it, I need a way of getting feedback on its progress, since the operations can take very long.
I am unsure of how to do this, specifically:
Should the separate process be compiled as another cocoa app or a command line tool?
How to launch it from the main cocoa app?
How to periodically get an object from it to get status information?
How to determine when it finished?
How to avoid showing a window/console when called?
How to have it part of the .app bundle so that it does not appear as a separate executable to the user?
These are really 6+ questions, but they are very related and very specific, and I think anyone needing to launch external processes (instead of spawning worker threads) can benefit from their answers. Generic code examples would be very helpful.
If it is possible, then implement the functionality in a command line tool, or another form of GUI-less application. For Cocoa applications it is possible to prevent them appearing on the Dock or in the Force Quit dialog, however a command line tool is a single binary file which does that anyway, so that would probably be a better way.
In terms of launching the tool, NSTask & NSPipe are your friends in this endeavour. The tool can definitely be kept inside your main Application's bundle, inside the Resources directory or some such, and then launched when needed. You can use the pipe to communicate back and forth.
I don't have any example code to hand, and its been a long while since I've had occasion to use either of these classes so the information I can give is limited, but it should be enough to point you in the right direction.
I'm about to write code for Windows that has somewhat similar functionality to the one existing in already written application for iPhone. I'm thinking of separating common functionality to form a component and compile it to both to iPhone and to Windows. This code is written in Objective C and uses RestKit and Core Data (and probably sqlite). Is compiling it for Windows a viable task? As I understand it GCC could compile Objective C on Windows but I'm unsure about the RestKit and Core Data api availability on Windows. I have seen two names that could be of use: GNUStep and Cocotron but I don't know if they will play well together with RestKit.
Note: I have no idea about iOS development so I might be confusing things. Any help is appreciated.
You will not easily be able to share this functionality between your applications. CoreData uses a custom opaque (not documented) format for the sql store. You would be hard pressed to reverse engineer this.
You will probably save a lot of time by rewriting that part for windows, rather than trying to get it working. There really isn't much iOS code that can be reused under windows, unless you have written pure C or C++.
For the application I am writing, I need to access some other applications' items, for which Applescript seems the best way to go. I have been using the Appscript framework, which worked well, because it allowed me to thread it and not make my app lock up when an Applescript was taking a while. However, now I am attempting to make my application 64 bit compatible, and it seems like the Appscript framework does not support 64 bit. Is there a "good" way to use Applescript in Cocoa that will not lock up my application, but still give me the full control I need?
--firen
It seems like SBApplication should work, but I haven't used it before.
According to #cocoadevcentral:
SBApplication: use to make cross-application scripting calls with Objective-C instead of AppleScript. Ex: get current iTunes track.
Here is is the excerpt from the documentation:
The SBApplication class provides a mechanism enabling an Objective-C program to send Apple events to a scriptable application and receive Apple events in response. It thereby makes it possible for that program to control the application and exchange data with it. Scripting Bridge works by bridging data types between Apple event descriptors and Cocoa objects.
Although SBApplication includes methods that manually send and process Apple events, you should never have to call these methods directly. Instead, subclasses of SBApplication implement application-specific methods that handle the sending of Apple events automatically.
For example, if you wanted to get the current iTunes track, you can simply use the currentTrack method of the dynamically defined subclass for the iTunes application—which handles the details of sending the Apple event for you—rather than figuring out the more complicated, low-level alternative:
[iTunes propertyWithCode:'pTrk'];
If you do need to send Apple events manually, consider using the NSAppleEventDescriptor class.
Hope that helps!
As Blaenk mentioned Scripting Bridge may well be the way to go, although it can prove somewhat inefficient if you have to iterating through large arrays etc.
The simplest way to run an Applescript in Cocoa is using NSAppleScript.
Apple has some pretty good examples, which I found useful when I needed to do something similar. There are three articles you might want to take a look at. They all contain some sample code, which I always find very useful.
A Few Examples of using Scripting Bridge
Performance & Optimisation with Scripting Bridge
NSAppleScript Technote/Example
I created a gist with the full URLs as I can't post more than one link, what with being a newbie and all.
http://gist.github.com/130146
it seems like the Appscript framework does not support 64 bit.
Should work. Make sure you set the correct architectures and SDK (64-bit requires 10.5) in the Xcode project. File a bug report if you have a specific problem.