I am looking at using AquaticPrime for my key generator for a Cocoa shareware app. For those of you who don't know about it, you can check it out here: http://aquaticmac.com/. However, I am running into a problem when I attempt to implement it. I don't want my users to have to copy and paste a whole dictionary into my app (or select it from a file browser), I just want them to have some code like: 1111-1111-1111-1111-1111 that will unlock the app for them. Is there some way to do this in AquaticPrime? But assuming that it can't, is there some other framework that does do this or would I just have to hard code it?
The reason it uses license files is to make it cryptographically hard to make up licenses—you can't just write a keygen like you can with license numbers.
You can make this easy by making a custom file type for license files in your application's Info.plist. (This must be app-specific. When you begin your second product, you'll need to make a new type.) This type will have a custom, app-specific filename extension with it.
Then, when the user double-clicks on the license file (possibly in Mail), the OS will open it with your app. You'll handle this, probably in your app delegate, by feeding the license file to AquaticPrime to validate.
This way, the user does not even have to summon a dialog box, copy the license number, and paste it. All they have to do is double-click on the license file.
Thus, the license file makes it easier to register your application, not harder.
If you have a trial version of your application that is unlocked then you can do the following.
1) Create a custom url scheme.
Follow the instructions on this posting but instead of http and https make your application respond to something like activate-com-mycompany-myproduct.
Once the user has run your application once any link in a browser like activate-com-mycompany-myproduct://somedata will automatically open your application.
2) Provide a product activation link in your final buy page of your web store and your email receipt. To make it simple for the user and not for you, append a unique id to the URL. Map the ID in a database, generate a license plist on the fly and push it to the user seamlessly.
In case someone else stumbles on this question: you might also want to take a look at CocoaFob. The keys it generates are rather long, but closer to the format you were after and still easy enough to cut and paste.
Related
I have an App Store app in which the free version is not scriptable, but the premium version is. AppleScript support is one of the key differences. I know the App Store reviewers are pushing more and more towards free + in-app-purchase, which will help declutter the App Store. Fine, I'll play ball.
Now I need to do something programmatically that I've always just worked into the build.
Is there a way to disable AppleScript if my OSAScriptingDefinition and NSAppleScriptEnabled are set in my Info.plist? This would still allow people to open the dictionary, and maybe they'd like what they see and consider activating the upgrade. Or,
Is there a way to enable AppleScript after the fact? Obviously with code-signing, I can't do things like modify Info.plist, or add my SDEF to the bundle later. But maybe if the SDEF were in a non-standard location, I could load it from the bundle and tell the system about it manually.
Does the SDEF have to live in my bundle? If not, I'm not sure how to point to the user's Application Support directory in the sandbox. I've also considered xinclude an SDEF I can install after the fact, but again, the SDEF and plist require actual directory paths and not functions.
I've tried a couple of things such as attempting to set NSScriptSuiteRegistry's singleton to nil, to no effect.
Because OSAScriptingDefinition and NSAppleScriptEnabled enable "automatic" support, surely there must be a manual way to make them to effect if not in the plist, and hopefully with a public API.
Any ideas here? Thanks!
A few points, for orientation:
All AppleScript commands are subclasses of NSScriptCommand
All AppleScript objects are represented by subclasses of
NSScriptObjectSpecifier
The scriptability of an app is controlled by its shared instance of NSScriptSuiteRegistry
This gives you a few options. You could try, for instance, overriding NSScriptSuiteRegistry setSharedScriptSuiteRegistry: and setting it to nil for the free version. You could also write a category on NSScriptCommand and/or NSScriptObjectSpecifier that does a version check. That would give you fine-grained control: you could call it from any methods that handle a script command or returns a script object, and decide on the fly which you want to allow and which you want to block; maybe even pop up a 'Pay for Full AppleScript Access' dialog.
CocoaScripting is a black box and not very adaptable. Simplest (kludgy) solution would be to wait until CS has installed its Apple event handlers then call -[NSAppleEventManager setEventHandler:andSelector:forEventClass:andEventID:] to replace those with a dummy handler that always sends back a "requires in-app purchase" error. (Don’t replace the standard open, quit, etc. handlers obviously.)
I am distributing my OS X application on individual USBs and, for this reason, everything must be self contained.
The app itself lets users input information and then saves this information to an existing text file (specifically an ObjectDB database). Herein is my problem.
I'd like to keep this text file inside the app itself (i.e. inside the Content folder) so it's out of the way and can't be deleted by the average user. But once the app is signed, it seems the text file can't be altered with any new information without getting flagged by Gatekeeper. Is this really the case? There's no way to store data files within apps now?
I'd appreciate any suggestions. Thanks.
Yes, you are correct. If you modify the application package, the signed package is no longer valid. That's kind of the purpose of signing a package.
Your options are to store the text file in a temporary folder on the user's computer, or to instruct your users to disable gatekeeper (don't do this).
I've been playing around with an app I want to submit to the Mac App Store, and part of the functionality is simply grabbing a file the user chose by dragging or opening, and saving a modified of it to the same directory as the original file (but with a different file name).
I don't want to use a 'Save' dialog box, as that destroys the utility of the application I'm building, but it looks like that might be the only way the app would be allowed—under sandboxing requirements—to write a file to an arbitrary location (arbitrary, in this case, being in the same folder as the existing file) on the disk as a new file.
Is there any way I can approach this without disabling sandboxing? Also, if I submit the app without entitlements/sandboxing turned on today, will it be approved by Apple (supposing it passes all the other requirements), or are they already turning down non-sandboxed apps?
For your first question, no, I don't believe there is any way to write to a file the user didn't specify, unless it's either in your app's container, or (as of 10.7.3) in a directory you have a security-scoped URL for. See the documentation here. If the user specifies a file, I doubt you get permissions to the enclosing folder, but it's worth a shot.
Answering your second question, as of today, Friday April 27th, 2012, the App Store does not require sandboxing. The latest deadline given was June 1, 2012.
I'd like to create a program which format signature in Outlook 2007.
The user will only have to lauch Outlook. It will search informations about the user, then will create automatically the signature.
The user wouldn't have to open any menu, the program will do it for him.
I'd like to know what language will be easy to use to create this kind of program ?
Thank you
I'd say you shouldn't be simulating clicks, instead you should just generate an automated signature file which the user could then load.
Edit:
The file formats for windows signatures are.txt, .htm and .rtf. All of these are very well documented formats and should be easy to generate. They should be saved in c:\Users\username\AppData\Roaming\Microsoft\Signatures. Outlook saves each signature in all three formats, presumably for portability to other apps and individual email settings (for instance if the user uses HTML or not).
I want to copy the current selection, even if it's in another application like Mail, when the user hits a specified hotkey like Cultured Code does it in Things when you create a new task. I got the hotkey working and I know how to place and get stuff on and from the pasteboard. But I have no idea how to get a current selection.
Anyone? Thanks!
You do this with a Service Provider. See the Service Implementation Guide. For what you're talking about, it should work very well. You don't need to do your own hotkey code; it'll do that for you. You don't even have to be running; it'll launch you.
To #Josh Caswell's point about OmniFocus, they're doing stuff fancier than just "the current selected text." They also copy the message itself into the inbox item as an attachment. That's what the plugin is assisting with.
This is a job for AppleScript, which is why applications that do clipping like this only support certain other applications to clip from -- those other applications have to support AS.
You'll have to take a look at the Mail AS dictionary and figure out how to get the selected text, and I believe that unfortunately you'll have to do the same with each application from which you want to clip.
Another possibility: it sounds like OmniFocus uses a Mail plugin for this functionality -- from http://forums.omnigroup.com/showthread.php?t=13906:
Starting in 10.6, Mail.app will refuse to use plugins... install the Clip-o-tron from that updated release... "OmniMailMessageEnabler...".