I am working on a simple Disk utility type application. I would like to add a feature that lists which running application's are currently accessing a particular disk. I'm not really sure which Cocoa Class implements this.
Just to elaborate, the closest description of what I'm looking for is the alert that appears when trying to unmount a disk in use. The alert goes something like "Disk so and so can not eject because application so and so is using it." How do I check which applications are currently accessing a specific drive.
Hope someone can point me in the right direction.
Related
I've created a simple Mac app that gives you statistics on your working behavior over time. For example, your average words per minute, what language you are typing in, usage of the delete key, etc. Interesting stuff! However, some test users have said they wouldn't use the app if they didn't know me personally, since it collects keystrokes like a keylogger.
Is there some certification I can get to show that I'm not doing anything nefarious? (I never keep more than one word in memory!) Or will it be enough to have my app signed? Or open-source that part of the code? (Other parts I know I cannot make open source.)
Distributing through the Mac App Store will help, since users can see that Apple has tried your application and found nothing nefarious in it. [Added:] Also, sandboxing your app means that your app is restricted to an explicit set of abilities, which technically-skilled users could inspect. Anything not listed, you're unable to do, so this would be an easy way to prove that you don't send anything back over the internet.
Another thing would be to save all data in user-readable files. No binary plists, no Core Data stores, etc. (Whether the XML variants of either of those should count as user-readable would be more arguable, but for this purpose, I think at least an XML plist would be readable enough. Not sure about Core Data.)
If the user can read all of the raw data you store using applications that they trust (such as TextEdit), and not just your usual fancy in-app presentation of it, then they can check for themselves, and eventually trust, that you're not storing anything they wouldn't want you to.
If any concerned potential users email you about whether you report their keystrokes to your own server via the internet, and assuming that you don't make any internet connections at all (not even an update check), you can recommend that they should install Little Snitch, which pops up a confirmation alert anytime any app tries to connect to something. When they don't see such an alert about your app, they know that you're not phoning home.
You might also, on your product webpage, include a link to a tech profile. Here's Jesper's article proposing them, and here's one example of such a document, for one of his products.
I would think that Gatekeeper would be adequate for most users. If it turns out an app is doing bad things, then Apple could pull the plug on a malware developer. So that and maybe some time live should establish your program as 'safe' to those who are not technically inclined (e.g. cannot understand your source).
Simply distributing it in your or your company's name can do a lot to build trust in an app (provided of course your other products/programs have not violated users' trust).
If you can get the application onto Apple's App Store, then that means they will have checked it for such problems. There's no way they'd knowingly allow a key-logging app on there. Also, signing the app with an Apple certificate ensures that if it has been downloaded from the App Store and later is found to be nefarious, they can black list it.
Open-sourcing code would also be a good idea. I assume you can't Open Source all of it because it doesn't belong to you? If so, then make it clear what technologies it uses and be as open and honest about what the application does and how it goes about doing it.
Is it possible to sort of emulate a hard drive, utilizing Cocoa? I have a backup application, and I want my users to be able to browse their files outside of the app, in Finder, for example.
So, how would I be able to accomplish this? I know that some apps (Transmit) do it, but I have no idea how they do it. My best guess is that they add a folder somewhere in /Volumes, and then somehow mount it.
you should read about MacFuse. Read its Objective-C API here
I'm currently working on a Backup Application, and I have received a lot of requests for features to be added recently, and the top one of them is adding a checkbox like "Back Up when on Battery Power" like Time Machine has.
So, is there a way I can get the status of the Power Adapter (plugged in and plugged in)? I assume that if one had a Desktop Mac, like iMac, etc, I would probably just get Plugged In all the time. Therefore, I need means of detecting if the computer is a portable or not.
I assume IOKit would be a library to look at, but I simply could not find anything in the docs, that are barely existent anyways on that Framework. Then, since it is an older Carbon Framework, is there a way to register a callback that gets called when that power state changes? That way I can properly implement this checkbox's functionality.
I'd appreciate help in clarifying this subject.
IOPowerSources.h has the functions you need. Start with IOPSNotificationCreateRunLoopSource() to create a run loop source and in your callback interrogate the power source info starting with IOPSCopyPowerSourcesInfo() and working your way down. There may be better examples, but this file appears to be a reasonable demonstration of how it's done; enough to get you started.
I recently had a look at the Google Data API. Its looking good.
What I want to do is create a "G Drive" Type application. This will basically come up as a drive in explorer with its own icon. From there you will be able to drag and drop operations to and from Google Docs, and create folders. Yes I've heard of Gladinet and Memeo, but both are not great solutions. I've decided to build one from the ground up, and release it as open source, once its in Alpha.
Anyways to get started I need some advise.
Clearly I need a way to mimic a drive in explorer. Is it possible to create some kind of virtual drive then have its contents list from an XML file, rather than a folder on the HDD?
So if the XML file (for example) contained a collection of elements, would it be possible to have these elements (with some work) show up in an explorer window for the drive. Almost like changing the data source for the explorer view from file system to contents of a file?
Hack or not, elegant or messy, has anyone found some way to go about doing this?
The Dokan project may be what you're looking for
Instead of creating a drive look into creating a namespace which is how the Google Drive works
Just as a reference: virtual drives can be created using our Callback File System product, which is a supported, documented and maintained solution.
So I have this program that I really like, and it doesn't support Applescript. I'd like to automate it a little bit. Now, I know that I could use applescript to tell the program to tell the menu to tell the submenu to tell the menuitem to activate or whatever, but frankly I don't like applescript very much anyway.
When I open the NIB file in IB, I can see the messages that are being sent to FirstResponder; for example, the Copy menu item sends "copy:". Is there any way for me to invoke this directly from another program?
No. It's called protected memory for a reason, you know. The other program is completely insulated from your application. There are ways to put code into other apps, but (a) it's very inadvisable (b) requires root privileges, which means the rest of your app needs to be ROCK SOLID AND IMPREGNABLE, and (c) writing such code is a black art requiring knowledge of the operating system kernel interfaces, virtual memory management, the ABI, the internals of the linker/loader, assembler programming, and the operational parameters and other specifics of the particular processor upon which your app happens to be running.
Really, AppleEvents and other such IPC mechanisms are there for a reason.
Your other alternatives (all of which are a bit hacky, to be honest, and give you the fairly significant burden of ensuring the target app is in the state you want/expect) the access the data you're looking for are:
The Accessibility APIs from the ApplicationServices framework, through which you can traverse the UI tree to grab the text from wherever you need it directly, or can activate the menu item. Access for your app has to be explicitly granted by the user, however (although this is much the same as the requirement for UI scripting).
You can use the CoreGraphics APIs (within the ApplicationServices framework again) to send keyboard events to the target application (or just to the system) directly. This would mean sending four events: Command-down, C-down, C-up, Command-up.
None of these are ideal. To be honest, your best approach would be to look at your requirements and figure out how you can best engineer around the problem by changing those requirements in some way, i.e. instead of grabbing something directly, ask the user to provide some input, etc.
You might be interested in SIMBL or in mach_inject. SIMBL is a daemon (in my fork based on mach_inject, in the original version based on injection via some ScriptingAdditions hack) which does the injection for you, so you just need to put a bundle with your code into the SIMBL directory and SIMBL will inject it for you into the target application. Or you can do so yourself via mach_inject. Or probably more convenient, mach_inject_framework which injects and runs code which just loads some framework.
I think Jim may overstate the point a bit; he's not wrong, but it seems misleading. There are lots of ways to cause a Cocoa program to execute its own code under you control (Carbon is harder). The Accessibility API is very commonly used this way (so commonly that I expect it to be repurposed eventually). Fscript can give you all kinds of access to the innards of another Cocoa program. While Input Managers may well exit the scene at some point, SIMBL is still out there today to do this kind of stuff.
Whether you like Applescript or not, Apple Events are the primary way Apple provides for inter-program control. Have you double-checked Script Editor's Open Library function to find out if the program really does have any Applescript support? You can code Apple Events entirely in Objective-C these days using Leopard's Scripting Bridge. I wrote up a tutorial if you like (it's still under-documented by Apple).
Cocoa is a reverse-engineer's dream. The same guys who host SIMBL have a nice intro to the subject. "Wolf" also writes a lot of useful information on this.
Jim's right. Many of these approaches can completely destabilize the system if done incorrectly (sometimes even if done correctly). I don't do much of this stuff on my production systems; I need them to work. But there are a lot of things you can make a Mac app do, and it's a good part of a Mac developer's training to understand how all the pieces really work.