I have a fairly straightforward question about using droplets for my mac application. My app is not a document based app.
Is there any way to get the path of the item that was dropped? How would I go about implementing this if that was the case? I have looked into this, and it doesn't look like I can do droplets at all without making my app document based, which I really don't want to do.
Thanks ahead of time!
You don't have to use NSDocument at all to make a droplet. Just include CFBundleDocumentTypes in your Info.plist (see Storing Document Types Information in the Application's Property List for details) and implement application:openFile: in your app delegate (there are variants of this method for multiple files etc.).
Related
I wanna control 'Finder' in my app, so I can minimize Finder. I tried ScriptingBridge, but it doesn't work in Sanboxed. But it works when the app is not sandboxed. So I check the Apple's developer documents, seems that I have to set com.apple.security.scripting-targets in entitlements when I need to use ScriptingBridge in sandbox. But it doesn't say anything about the setting, so what should I do in the setting in order to control finder? Thanks in advance.
here is entitlements :
com.apple.security.scripting-targets
???????
????
Finder does not have any scripting access groups. You could add the temporary exception com.apple.security.temporary-exception.apple-events as documented here.
To find scripting targets see here: How can I know the Apple Event Access Groups used by an application?
If you'd like to distribute your app in App Store, however, you're out of luck. By scripting Finder, your app will not pass the review into the App Store.
Finder does not have any scripting access groups on purpose, because it lets you dodge sandbox file system restrictions. (As the other answer mentions, you could use the old temporary-exception.apple-events entitlement to script Finder anyway, but it won't pass store review.) Try using NSWorkspace instead, in particular the -openFile, -launchApplication, and -selectFile methods. If by "minimize" you really meant "hide", then see -[NSRunningApplication hide].
Is it possible to get a handle on a file which is opened by any external app via my application?
Using Cloud-Storage Apps as an example, I would like to track changes to a file opened via the Storage-Provider App, so the manipulated file can be uploaded again afterwards.
There are two possible answers here, depending on what kind of app you're implementing.
For general tracking purposes, you can try using the ContentsChanged event of the StoreFolderQueryResult/StorageFileQueryResult classes within Windows.Storage.Search. That is, you create a file or folder query for what you want to watch, and then register an event handler. Generally speaking, this works well for stuff on the local file system; it's not guaranteed if you're trying to run a query on files/folders whose backing store is elsewhere.
The subject is too detailed to be described here, but you can refer the "File and Folder Queries" in Chapter 11 of my free ebook Programming Windows Store Apps with HTML, CSS, and JavaScript, Second Edition, page 607. Even though I focus on JS as a language, the discussions of WinRT APIs like this are useful when working in any language...plus the ebook is free so there's nothing to lose.
The other mechanism would be useful if you're implementing an app that provides the interface to a cloud storage backend, like the OneDrive app that's part of Windows. In this case you'd want to use the CachedFileUpdater contract. See Appendix D, page 1288, of my aforementioned book.
I know that there are some restricted api's or code that are not allowed to be in your app when you submit it to the app store.
How do you know what they are? Is there a way to check your app before you submit it to ensure you have not used such api's?
It is probably better to avoid this problem at the design stage, than trying to fix it later, so I was wondering if there is any tool in Xcode, or document to determine this.
The way Apple intends for you to do this is to use XCode's Validation feature. When you're submitting an app, you build for achiving (or Archive from the XCode menu). Then, you open up Organizer to see the archive you just created. At this point, you can press the Validate button in Organizer. That will perform a validation, without actually submitting the app. It will tell you if you're using Private APIs. Depending on how you use them, it might identify what the violation is:
There's definitely ways that code can fool this validation step, and "get away" with using Private APIs until the reviewer looks at the bundle. But, as far as I know, those ways would all be intentional methods of hiding Private API usage, and it sounds like you're trying to discover accidental usage.
If you fail this Validation test, then you might want to use something like AppScanner, mentioned in alan duncan's answer. But, for completeness, I wanted to make sure people knew that this Validation step is available in XCode, and checking for Private API usage is one of the things it's doing before you submit (and have to wait a few days to be told what you did wrong). Also, even if you don't use the Validate button in Organizer, but just use Submit, the tool is performing a Validation for you. The only difference is whether the bundle actually gets uploaded to iTunes Connect.
If you stick to documented interfaces as suggested above, you're fine. The only issue is with third-party libraries whose implementation may be opaque to you.
There is a Mac app called AppScanner that scans from private API usage. I have no experience with it, though.
You will get more information on Apple approval process from
App Store Review Guidelines for iOS apps (You must be a registered iOS developer for accessing this data).
iOS Human Interface Guidlines.
get the private API list.
use class-dump to process the Mach-O file, and get the processed string.
use regex to get the interface, class, or method in the string.
match the API to private API list.
then GOT it~
I opened a porject to do this, but because the reason of my company, canceled. very sorry for this.
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.
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).