How can I check from my cocoa Mac application whether an application (for example: Preview or iPhoto) exists on Mac?
I basically want to give the user an option to open an image using Preview, iPhoto but before doing that I would like to check whether these applications are present on the user's Mac.
Instead of checking for specific hard-coded applications, it'd be better to get a list of all applications that can handle the type of document you'll be passing to them. That way, if the user has installed, say, Acorn, it'll automatically show up without your having to add it to your hard-coded list.
There is also a way to do what you specifically asked for, but that is an inferior way to do what you really want to do, which is show the user all of their applications that can open the document.
Related
I am trying to create an accessibility app that will type in multiple windows at once, neither of which are owned by my app. For instance, let's say you have two Microsoft word documents open. When you hit a keystroke I want the command to go to both windows.
I have tried using Quartz events services, but it looks like it will only allow you to post to events either on a global or process level. But if two windows are running for the same process, how do I post to a specific window?
There's also the issue of the person typing in one window, while the content is being copied to the next.
Is it possible to post to a single window?
PS I know it's possible to do this in Windows
MacOS X includes a few tools which may be helpful. You should look into the Accessibility framework, Automator actions, and AppleScript. You should also be aware of application-specific solutions; in the case of Word, for example, you might look at VBA (Visual Basic for Applications). All of these tools provide ways that you can modify the content of other applications. Unfortunately, the level of support for each one varies from one application to another, and the way they're used also varies. So, it's unlikely that you'll find a single solution that works for all applications.
It's unlikely that you'll find a way to insert events directly into another process's event queue. That'd be a huge security hole, for one thing. Even if you could do that, you really wouldn't be able to target specific windows with your events. Mac applications use a responder chain that sends keystrokes to the "first responder", usually a component of the active window.
I'm in the process of planning out the infrastructure for a Mac App, and we have a startup screen with many user files listed. We want the App to be iCloud-compatible (thus the need for Document-based (key-value won't cut it since they aren't nested - correct me if I'm wrong here)). Essentially, we don't want to have the user keep track of each individual file themselves as that would be irritating, but rather store it in the App's folder until the user needs it (i.e. Email, Export, etc). It would eliminate a lot of the friction in the app, we think. I guess my question is:
Is it possible to store files automatically in the App's installation folder (or somewhere locally?) without bothering the user - in a Document-based app - and still be App Store compatible? Seems like the ideal solution - user opens app, App knows it's save location and automatically saves documents there when a user creates one, and pulls them to share if needed. Any help?
Yes, it's possible. You won't want to store document's in the application's installation folder. For one thing that'll violate the App Store rules, but it's bad behavior anyway, since Applications are normally installed in /Applications, which shouldn't be cluttered up with other files. So storing things in ~/Library/Application Support/YourAppName is the way to go.
To actually implement this, take a look at NSDocumentController and NSDocument itself. You'll basically want to override/modify any UI that allows users to choose a location to save/open documents. Instead, just let them name the documents, and then automatically save them with the given name in the app support folder. Then create a UI that allows them to browse and open those files within the app.
Is it possible to load up another application when the first application enters the background?
Say I have application 1 and application 2 installed.
When application 1 enters the background, the method is called to invoke the loading of application 2, but application 2 is never loaded.
Is it possible that Apple have disallowed this sort of thing?
I am 100% sure that the custom URL schemes I'm using are able to be called as I have done testing within MobileSafari to make sure they work.
Should mention this is for an iPad application and not iPhone application. Albeit, I don't think there should be much difference between the two when it comes to this issue...
EDIT
Let me explain. The application itself is for a specific purpose. What we want to do is allow our clients to set a setting that will allow the application to "bounce" back via another installed application.
We want to limit the users of the application to only be able to use the application in question. This is due to the fact that the iPad's using this application will ONLY be using this application. Hence why we want to lock it down as best we can.
This will not work, simply because the application can only have the system open URL schemes while in the foreground. Think of it like this, if your application is not in the foreground can it, say, present a modal view such as a UIAlertView or a simple Modal View Controller?
Also, you would be horribly breaking Human Interface Guidelines and would most likely be rejected. URL schemes, especially custom ones, should only be called when the user prompts.
Sounds to me like you want a lockdown/kiosk iOS system. There's simply no way to do this and make it work like they want without breaking out of apple's sandbox. Jail breaking. Or, write one application with two halves. The initial half with authentication or whatever, then the secured half. Maybe we need more context, but as you describe it, URL schemes are incredibly easy to circumvent or fail altogether. What happens when they just delete the goto app?
Now why would you do that? Say the user is getting a call and he proceeds to take it. He definitely wouldn't want to go to another app in between. Other case considered, he would actually leave your app to go to another app he wants to attend to without being taken to another app in between.
Hi I am new to MAC OS development and I want to send an email programmatically trough an application, but without using Mail app like in SBSendEmail from apple's site. I dont want to attach any attachments, just a plain text email. What is the best and easiest way to do this? is it possible to use the basic functionality from SBSendEmail and automate the last step of sending mail through MAil app? Is there no easy way just like in C# to create a mail object and just send it?
Thank you.
There's no way to do this in pure Cocoa, except to use one of the three or four email libraries available (Pantomime is one I know of off the top of my head). The main problem with all of these is that they're designed for implementing a full email client, not just sending email, so they're probably more heavyweight than you need.
For Growl's MailMe display, I wrote a command-line mail-sending tool in Python. The Xcode project bundles this into the MailMe display plug-in bundle, and MailMe runs the tool using NSTask, passing the SMTP info it finds in the user's Mail preferences. Growl is also open source, so you can read the source to the MailMe display.
Things that won't work:
The Message framework, which has no public API in 64-bit.
The mail(1) tool, which requires the user to have the local SMTP server running (simple-mailer uses another SMTP server, whose name you pass in on the command line).
Note that MailMe currently does not understand how to look up MobileMe passwords, so it isn't yet able to send using MobileMe accounts. If you amend the code to do this, we'd appreciate a patch!
Another patch opportunity is that MailMe currently only looks in Mail's preferences for mail-sending settings. It could look in other clients' preferences, but does not yet know how to do that. If anyone who uses Thunderbird would like this capability, again, we'd appreciate a patch.
I would suggest you make use of /usr/lib/sendmail if present. Open a pipe to /usr/lib/sendmail and send the mail on stdin. This should be available the OS.
I would like to be able to change the OSX services that my application provides based on the current user's preferences (like adding more, changing the name,...). This basically means modifying the Info.plist (NSService key), but I don't think it is a good practice when an application modifies its own Info.plist while running, right? (At least based on few searches here). Is there any other option how to get this functionality?
I guess it should always be an external entity who does modify the Info.plist? So far I can only think about providing a system preference bundle which will do the modification in the actual app? Do you have any ideas?
Thank you
One way would be to install a service in ~/Library/Services that provides the services, and edit that application's Info.plist from your main application.
Of course, that should be an explicit action, so the user (hopefully) knows to delete the service if they delete your application. And you should document that procedure on your product's support web page, just in case they don't.
Here's a small twist to the previous recommendations, create a separate app that handles the service and bundle it within your Resources. When you want to enable the service, instead of copying the file over to ~/Library/Services, create a symbolic link within the ~/Library/Services folder that points to the app you bundled in your Resources.
This way if the user deletes your application, all that will be left behind is a symbolic link pointing to an invalid location. Does less arm than actually leaving the app behind and will have the added benefit that the service will no longer be available (since the info.plist will have been removed when the user deleted your app).