We have a cross platform application. The application has a feature to autostart it once the user logs in. How to do this in mac? from within the application. Manually adding it Login Items works but I am looking for how to do it using an API or something similar.
If it's a GUI app adding it as a login item is the best way to go. Apple's dev note on the subject lists 3 ways to do this: with the Shared File Lists API, via Apple Events, or with the CFPreferences API.
You have to create a launchd property list file and place it in ~/Library/LaunchAgents or /Library/LaunchAgents, depending if you want the change system-wide or only for the current user.
This guide from Apple will help you accomplish that task.
Related
I have found that "Services..." a very useful place to add functionality via AppleScript.
I have written a small OS X app that uploads documents to a web based service (it requires OAuth2) and thought it would be great to add this functionality to the "Services" submenu. For example, when I am viewing a pdf in Preview to upload directly from a Services item.
I have tried wading through Apple's documentation on "Services", but I don't see how to add one outside of the Automator. I would be happy to use that but:
Do I need to make my app AppleScript-able? If so, how?
Is there another way to add Services outside of the Automator?
Thanks!
AppleScript/Automator are not needed, there's a couple steps involved (Info.plist entry and handler in your app). See the Services Implementation Guide for details.
I have an application which I'm now sandboxing. I do automated acceptance testing using the accessibility API from a different process. Before sandboxing, the test suite used CFPreferencesSetValue and friends to set certain default values for the application.
After sandboxing, the defaults are read from ~/Library/Containers/BUNDLEID/Data/Library/Preferences but the CFPreferencesSetValue functions only writes to ~/Library/Preferences as far as I understand.
Is there a way to programmatically write preferences to the sandboxed preferences without e.g. hardcoding the location and modifying the plist directly, or using the defaults command line utility.
One solution is to add an "Application Group" to your sandboxed app, thereby allowing other apps of this group to share its preferences, see: Reading NSUserDefaults from helper app in the sandbox
Actually, there is a better way, see the answer to my own question here: How does OS X's defaults command get access to prefs of sandboxed apps?
The trick is to use the full path to the preference file in the sandbox container, minus the ".plist" extension, as the application ID.
Is there a way to make my winRT application as a screen saver in xaml?
As Jerry says, there's no straightforward way to make a Windows Store app screensaver. However, there's a roundabout solution that might work for you on Windows 8, but not Windows RT. I have it nearly working. I'll share what I have so far.
A screensaver is just an executable with a .scr extension that's kept in C:\Windows\System32. For example, look at C:\Windows\System32\Bubbles.scr. The solution I have in mind is to create a .scr screensaver whose only purpose is to launch your Windows Store application, which you say will use XAML.
You can't launch a Windows Store app from the command line directly, so you'll create a launcher app. Take a look at a blog post called Automating the testing of Windows 8 apps by Ashwin Needamangala. Partway down the article, look for the section called Automating the activation of your app. It contains a sample C++ application which can launch Windows Store apps in the following way:
C:>Win8AppLaunch.exe Microsoft.BingNews_8wekyb3d8bbwe!AppexNews
The sample launcher on that page needs to be modified, but before you do that just copy the code into a C++ console app:
You're almost ready to test it out from the command line, but you need to specify the name of the app as an AppUserModelId. The details are in Ashwin's post, but to paraphrase you first want to allow the execution of PowerShell scripts on your system with:
PS C:> Set-ExecutionPolicy AllSigned
Then run this PowerShell script:
$installedapps = get-AppxPackage
foreach ($app in $installedapps)
{
foreach ($id in (Get-AppxPackageManifest $app).package.applications.application.id)
{
$app.packagefamilyname + "!" + $id
}
}
You might like running it in the Windows PowerShell ISE. It's pretty slick. Find the AppUserModelId of your app and then test Win8AppLaunch.exe from the command line, as shown above. This should launch your Windows Store app from command line.
Next, modify the C++ launcher to hard-code the AppUserModelId of your application instead of parsing it from a command line argument. I created a Gist of this. The important part is the line where I declare myApp.
Build the new executable, rename it MyScreenSaver.scr and put it in C:\Windows\System32. It will then appear in the Screen Saver Settings Control Panel. You can preview the screensaver there, and it works. However, if you wait for the screensaver to launch, it will briefly bring up a console window and never fully launch. I'm not sure why. I tried disabling the creation of the console window by switching the project to a Windows app, but that didn't help. You can try that yourself by changing Properties | Configuration | Linker | System | SubSystem to WINDOWS. It's a little more involved, as you'll also need to change the entry point from _tMain to _tWinMain. Contact me through my blog if you want the details. My StackOverflow profile lists it.
At this point it's almost fully working. You might try starting with a blank C++ screensaver that you know works, and then copy in the above code. If I get more time, maybe I'll try this myself.
Cool idea. But, no.
If you want your application to really do something for Windows other than run as a simple app, then you write an extension app. Here's the official word:
Extensions An extension is like an agreement between an app and Windows. Extensions lets app developers extend or customize standard Windows features primarily for use in their apps and potentially for use in other apps.
There are these types of extension apps right now:
Account picture provider (extension)
When users decide to change their account picture, they can either select an existing picture or use an app to take a new one. If your app can take pictures, you can use this extension to have Windows list your app in the Account Picture Settings control panel. From there, users can select it to create a new account picture. For more info about this extension, see the UserInformation reference topic. You can also check out our Account picture name sample.
AutoPlay (extension)
When the user connects a device to a computer, Windows fires an AutoPlay event. This extension enables your app to be listed as an AutoPlay choice for the one or more AutoPlay events.
Background tasks (extension)
Apps can use background tasks to run app code even when the app is suspended. Background tasks are intended for small work items that require no interaction with the user.
Camera settings (extension)
Your app can provide a custom user interface for selecting camera options and choosing effects when a camera is used to capture photos or video. For more info about this extension, see Developing Windows Store device apps for cameras.
Contact picker (extension)
This extension enables your app to register to provide contact data. Your app is included in the list of apps that Windows displays whenever the user needs access to their contacts.
For more info about this extension, see the Windows.ApplicationModel.Contacts.Provider reference topic. You can also check out Managing user contacts.
File activation (extension)
Files that have the same file name extension are of the same file type. Your app can use existing, well known file types, such as .txt, or create a new file type. The file activation extension enables you to define a new file type or register to handle a file type.
Game Explorer (extension)
Your app can register with Windows as a game. To do this, you must create a Game Definition File (GDF), build it as a binary resource in your app, and declare that resource in the package manifest.
Print task settings (extension)
You can design an app that displays a custom print-related user interface and communicates directly with a print device. When you highlight the features that are specific to a particular make and model of print device, you can provide a richer, more enhanced user experience.
Protocol activation (extension)
Your app can use existing protocols for communication, such as mailto, or create a custom protocol. The protocol activation extension enables you to define a custom protocol or register to handle an existing protocol.
SSL/certificates (extension)
Digital certificates are used to authenticate one entity to another. For example, certificates are often used to authenticate a user to web services over SSL. This extension enables you to install a digital certificate with your app.
cite: http://msdn.microsoft.com/en-us/library/windows/apps/hh464906.aspx
Unfortunately, nothing has to do with screen savers. The technical reason, at this time, you cannot write a Windows 8 app that functions as a screensaver is because Windows 8 apps are fundamentally tied to run inside the WinRT execution environment. That shell does not extend out past the Start menu in this current version of Windows. So, there's no way to execute outside - like as a screen saver. Screen savers are still built the "old fashion way".
I have an app which needs to preserve data between times it runs. I had been using NSUserDefaults for this, but I've had a few users point this out to me: this causes different users to end up with different data, which isn't the way the app should work. It needs a single directory that it can read/write from regardless of which user is running it.
So, I need a non-user specific directory that a sandboxed mac app can read and write to.
Thanks!
(Oh, and if this directory is persistent between updates of my app, that'd be helpful, too!)
Quick barely related question: Is there a way to have a user modifiable resource file in a Mac App Store approved app? I don't want it to be modifiable via my app; I just want to make sure that users modifying it won't cause the system to kill the app for not matching a code signature hash or something.
I don't think that you will be able to read and write in a directory outside of the App Sandbox container without prompting the user to select it using Powerbox and saving a security-scoped bookmark (see App Sandbox Container Directory). From what I've gathered about App reviews lately, you won't even be able to specify a default in the open dialog if you elect to have the user choose the directory.
As for the second question, as I understand it any verification of code signatures is left to the developer. So while MAS apps have a _CodeSignature folder containing a plist with all the hashes of the resource, in my experiments changing them had no effect on app launch.
I am wondering what limitations are imposed on the Mac app store. Can someone point me in the right direction? For instance, lets say I wanted to write an app that does incremental auto-backups of files on the Mac file system, is that possible with an app in the Mac app store, or would my only option be a standalone mac app?
On the iPhone, apps are self contained in their own "sandbox"? Does this same principal apply to mac app store apps?
Fellows, what the OP is really referring to is described here:
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html
It is all about
Containers
Entitlements
PowerBox (daemon)
Once an application is "sandboxed" its view of the ~ "home" directory is that of a Container (which happens to be created upon first start in $HOME/Library/Containers/appBundleID/Data). Therein it finds its "private copy" of config, cache and data files. And off course it can't read anything else, unless...
... you give the application the appropriate Entitlements in the form of a codesign-ed property file (in fact, codesigning is integral part of the sandboxing concept).
One of these Entitlements is the "com.apple.security.files.user-selected.read-write" which allows the application to read and write exactly those files which the user has explicitly chosen via the standard save and open dialog respectively.
The PowerBox (pboxd) daemon then renders the appropriate file dialog in its own process space and adds the selected file paths to the list of allowed files. This is transparent to the application, that is no code changes are required - as long as the application uses the standard NSOpenPanel or NSSavePanel dialogs.
"To facilitate application sandboxing, Mac OS X v10.7 provides a trusted system daemon that is tasked with presenting open and save panels on behalf of applications running in an application sandbox. That daemon is called Powerbox (its process name is pboxd). These Powerbox-presented remote panels appear fully indistinguishable from in-process panels in terms of user experience.
Any time an application running inside a sandbox invokes an NSOpenPanel or NSSavePanel dialog, rather than showing the panels directly, AppKit automatically asks the Powerbox to present the dialog. From a developer perspective, there are no code changes required in terms of how these panels are used; this process is fully transparent." [end quote from Apple docs]
Given all that, what the OP would need (for a backup solution) are "unmediated read/writes":
"If an application chooses to derive the user's home directory in a way that bypasses Cocoa APIs (by directly invoking getpwent, for example), the application sandbox prohibits it from writing to the paths it receives (unless the application has the unmediated write entitlement, which is strongly discouraged for obvious security reasons." [end quote from Apple docs]
However the closest Entitlements which would give "free access to the file system" I could fine would be:
"
Absolute file read-only—The ability to read the files or directories at the specified absolute paths. (com.apple.security.temporary-exception.files.absolute-path.read-only)
Absolute file read/write—The ability to read or write the files or directories at the specified absolute paths. (com.apple.security.temporary-exception.files.absolute-path.read-write)
" [end quote from Apple docs]
And I am not sure whether an application could simply provide the root directory "/"
Anyway, carefully note that these entitlements are marked "temporary": Apple might remove/deprecate those entitlements at seen fit!
I believe that starting in November, Mac App Store submissions must adopt the App Sandbox. There are specific entitlements that you can request when your app is submitted to the app store, along with an explanation of why you need those entitlements. More information can be found in WWDC Session 204 video on the Developer site.
Technically, there is sandboxing on the OS X. However, applicants started manually by the user bypass those sandboxing restrictions (sometimes requiring escalation / admin verification screens).
Take a look at:
http://techjournal.318.com/security/a-brief-introduction-to-mac-os-x-sandbox-technology/
The are changing or have changed with the Lion release. Mac Store apps used to be able to do anything within the filesystem that the logged in user privs could allow but I think you are now required to use the entitlements system and hence sandbox your App.
Read this for more ideas
https://developer.apple.com/library/mac/#releasenotes/General/SubmittingToMacAppStore/_index.html#//apple_ref/doc/uid/TP40010572
This will help. Take a good look at it.
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW16
You can currently find Hype or Pixelmator on the Mac App Store.
This proves evidently that you can save to disk and read from disk, which seems a basic feature of any serious application. Moreover, Apple is pushing developers to start using incremental auto-backups of files, it would therefore be very surprising if they forbade that in the App Store, wouldn't it?