I am writing an app for Maverick.
The app creates a folder under /user/document, named "folder.db".
All the user related files will be in a folder "folder.db".
I would like to associate my app with "folder.db" directly, so that clicking on it would open my app and not the Finder.
How to achieve that?
Note: I tried to play with the UTI settings in xcode but not luck...
First .db is generally used for databases. So probably not a good idea. What you are looking for is a package or bundle in Cocoa terms. In Cocoa you want to look for the fileWrapper methods. Those create package/bundle files that are folders with a special flag bit set to make it act like an opaque file in Finder
You might want to study NSWorkSpace, NSFileManager, NSBundle, NSDocument and NSOpenPanel and NSSavePanel.
Those will get you on the path.
Related
I am trying to build an alternative file manager that works similar to the default Finder in Cocoa.
As you can imagine, the app needs to show a list of files/subfolders in certain directory, and when the user click on an item, it checks whether it's a folder or a file that a user has clicked. If it's a folder, the app simply shows the content of the folder. If it's a file, it will be opened with the default application.
I used NSFileManager.fileExists(atPath:isDirectory:) to determine if an item at certain path is a folder. This works well in most cases, but for things like something.app or project.xcodeproj, they are also considered as directories according to the method.
I know it's true that technically they are just folders, but is there a way in Cocoa to distinguish them from actual folders?
Use (NS)URL.
Get the values for resource keys isDirectoryKey and isPackageKey via resourceValues(forKeys.
In case of bundles isPackage is true.
I am working on a Mac app. I ultimately want to use default app icons within my app. From the Info.plist and the Resource folder of an app I can get the .icns file and convert that to the image format I need. But I need to know the default application associated with the particular file extension, if any.
So how to get the default application that the system currently associates with a given file extension?
Don't go digging in other apps' bundles. It's always best to work at the level of abstraction that suits the question you want to ask. If you want to get the icon that the Finder (or a Mail attachment, etc) would display for a file of a particular type, use the NSWorkspace iconForFileType: method.
I think what you're looking for is part of the OSX Launch Services: LSCopyDefaultApplicationURLForContentType API. This returns the info on apps that can open specific Uniform Type Identifiers. There's also a similar API called LSCopyDefaultApplicationURLForURL to check which app opens a specific known file.
In my Mac app I have an NSMetadataQuery to watch the app's iCloud directory. When the user decides to enable iCloud from within the app I do the following in this order:
Call [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil] to establish access to the iCloud container
Start a NSMetadataQuery to find all files (pattern: "*") in the iCloud container
Now I iterate over all files in the local container and move them to iCloud by using [fileManager setUbiquitous:YES itemAtURL:fileURL destinationURL:targetURL error:&error]
I have two types of documents that I move to iCloud:
The actual documents stored as file packages
For each document I have a .preview file as simple binary file
My problem is that the meta data query only returns my binary preview files, but not my actual documents until I relaunch my app (or open a Finder window of the app's iCloud folder from the Terminal - in this case my app gets another query result with all files).
So is this some weird caching issue? Is this because the documents are file packages and not simple binary files?
I don't see why that should be a problem. If I restart my app the query does return all files correctly.
Could this be a problem with the way my custom document type is exported in Info.plist?
Could this be a problem with the way my custom document type is
exported in Info.plist?
I suppose so: the issue you are describing is most likely because your document format is a file package (I assume written with NSFileWrapper). Remember that the package bit is set when writing the file, so if you have other apps writing to iCloud, that could make the issue much more confusing as it's not about interpreting a file bundle but writing it in a correct manner.
NSMetadataQuery unfortunately ignores folders, so your files will never be reported back unless you have correctly registered your filetype as bundle in the application that writes the file to the iCloud container.
There are a lot of similar and potentially confusing settings in the info.plist, so many things that can go wrong. I experienced an issue when I registered my document filetype correctly on OS X, but failed to do so on iOS: https://stackoverflow.com/a/14993694/388412
The first thing you should do is to go to https://developer.icloud.com/#documents and see if you're looking at files (correct) or folders (problem).
Work on your info.plist document types until you see the documents as files, then it should work.
Is there any way of getting folder path (any folder and can be at any location in mac) programatically, in a native cocoa application?
What exactly are you trying to achieve? Did you have a look at NSFileManager? To let the user choose a directory have a look at NSOpenPanel.
I am wondering how an application like appzapper can detect the files related to an application?
All ideas are welcome.
Thanks for your help,
Regards,
By looking into the standard locations that usually are used by applications to store preferences (like Library/Preferences/ , Library/Caches, etc., both in your home directory ~/ and under / ) I couldn´t find any file or folder that isn´t using either the applications name (eg. ~/Library/Application Support/Firefox) or it´s bundle identifier (eg. ~/Library/Preferences/org.mozilla.firefox.plist) in its name; so I guess they´re just using that.
In the case of AppZapper you can go ahead and try for any (not currently running) Application to rename the ~/Library/Application Support/AppName folder for example to ~/Library/Application Support/111AppName - AppZapper doesn´t find it anymore. If you change it to ~/Library/Application Support/AppName111 it shows up as a related file.
Out of this you can conclude that there isn´t any magical linkage between a folder full of preferences and it´s associated application that AppZapper is reading out, it´s merely checking for folders starting with the Application´s Name.