I'm trying to implement a "check for software updates" function in my ASObjC app.
I'm more or less there, except I'm not quite sure how to query the current version number in my info.plist from within my application's script.
Suppose I have the newest version number in an html file which I call using curl. I display a dialog prompting the user to update if the version number curl returns is higher than the version number of the calling script.
How do I get the bundles current version number into a property in the script to test against what's returned by curl?
I discovered the constant "CFBundleShortVersionString" but my attempts to use it have been thwarted.
This doesn't work, for example:
set myVersionNum to current application's CFBundleShortVersionString
I tried coercing to string and text to no avail.
EDIT: it appears the following works:
set myVersionNum to current application's version
The NSBundle class does have an method objectForInfoDictionaryKey: which is an method to get the value of the given key of the bundle's info.plist file. So when we use the application's main bundle (itself) then we could easily get the value with the following method:
set appBundle to current application's class "NSBundle"'s mainBundle()
set shortVersionString to appBundle's objectForInfoDictionaryKey:"CFBundleShortVersionString"
note: I use the new Mavericks (AppleScript 2.3) AppleScriptObjC syntax.
Related
Getting a bundle display name length too long when trying the validate the archive to upload to the App Store.
Where is the Bundle Display Name stored? Unless I am confused I think my display name is only 8 characters long???
Here is the info.plist entry.
You are showing the wrong Info.plist. There are two types: the app has Bundle OS Type Code APPL and Bundle Creator OS Type Code ????, while a framework has Bundle OS Type Code FMWK and Bundle Creator OS Type Code ????.
So apparently what you've found is some framework Info.plist. Moreover, have now lamed it by changing the Bundle Creator OS Type Code to a wrong value.
You need to fix this one so it work again, and then go find the real one, the one belonging to the app. My guess is that you have lamed that one in some way too.
Having some trouble calling Cocoa methods from within AppleScript. For example, running the following snippet of code produces an error when ran using osascript:
set sharedWorkspace to call method "sharedWorkspace" of class "NSWorkspace"
Here's the thrown exception: Expected “,” but found identifier. (-2741) Should this code be nested under a tell statement? If so, what application should I be talking to?
Thanks.
call method looks like something out of the old AppleScript Studio, which was deprecated in 10.6 Snow Leopard and has since been removed.
There are a couple of prerequisites for calling Cocoa methods - a regular script needs to declare that it uses the desired framework(s), and the various classes and enums are defined at the application level and thus need to be prefaced with current application, or an object needs to exist to send the message to.
With that said, Cocoa methods can be called in a few different ways - using your snippet, for example:
use framework "Foundation"
set sharedWorkspace to current application's NSWorkspace's sharedWorkspace
-- or --
set sharedWorkspace to sharedWorkspace of current application's NSWorkSpace
-- or --
tell current application's NSSharedWorkspace's sharedWorkspace
set sharedWorkspace to it
end tell
The first form is what you will normally see used, as it is the closest to the Objective-C form. The appendix in the Mac Automation Scripting Guide has more information about translating from the Objective-C documentation, which is what Apple expects you to use.
This should work :
set sharedWorkspace to current application's NSWorkspace's sharedWorkspace()
I've read all the tickets about this issue, but I still don't get it right. I have a non-document OSX app (for OSX Lion and MountainLion). I want this app to export and import custom data, associated with a custom file extension ".iobs". Internally, these files are just data archived with [NSKeyedArchiver archivedDataWithRootObject:], and saved onto the disk with the "iobs" extension.
So, my check list is this:
1) Export mechanism: checked. My app create correctly .iobs files. If I run "file <filename.iobs>" in the Terminal, I get "iObserve_exportedItems.iobs: Apple binary property list"
2) Declaration of an exported UTI, checked. As shown in the image below. I did NOT declared a custom Document type, since it I never use NSDocument inside my app, and there is no point. Anyway, I already tried and failed. I've tried also different combinations of "Conforms To" entries, but with no success.
3) Is there any 3rd point??? Do I need to start my app once to let the system know? I just ran it in Debug from Xcode so far, and this has no effect. So I guess my Info.plist is wrong, but I filled it from within Xcode4 interface, so???
Thanks for any help, hint, question, suggestion.
Ok, so apparently, I do have to declare a document type even if I don't specify a document class. See the attached screenshot. Note that leaving only the Document UTI doesn't work. I do need the two (exported UTI and document type). Note also that if I say it conforms to com.apple.binary-property-list, I don't have the right icon.
And for those who wonder, there is nothing to do to "register" a type (and its subsequent changes) apart from launching the app once.
I have a Xcode project for a mac app that contains another project for a helper app to launch the main app at login. Is there a way I can base the bundle identifier of the helper app off of the main app with a project variable like ${PRODUCT_NAME} but something like ${ROOT_PRODUCT_IDENTIFIER}?
So the main app's bundle identifier would be:
com.mydomain.app
and the helper app's bundle identifier would be:
${ROOT_PRODUCT_IDENTIFIER}.Helper → com.mydomain.app.Helper
My goal with this is to create a really easy to use generic launch at login helper app that any mac app can use, I've got it working in this repo but it requires a couple values to be changed: https://github.com/kgn/LaunchAtLoginHelper
I'm afraid the variable you're looking for doesn't exist, have a look here or here
But I can think of one workaround by creating your own environment variable, which isn't difficult. In order to achieve what you want, create a build script for your main project that extracts the identifier and saves it to an environment variable.
Go to your main project's target and click on Add Build Phase -> Add Run Script.
In the shell box that appears, type this in:
ROOT_PRODUCT_IDENTIFIER_PLIST=`/usr/libexec/PlistBuddy -c "Print :CFBundleIdentifier" $INFOPLIST_FILE`
export ROOT_PRODUCT_IDENTIFIER=`eval echo $ROOT_PRODUCT_IDENTIFIER_PLIST`
Now go to your helper's project and reference $(ROOT_PRODUCT_IDENTIFIER) in its plist/build settings.
Remember to add your main project as a dependency for the latter, so that variable is always set by the time its needed.
I'm making use of install4j's auto-update feature for an application I'm working on. I was wondering how exactly it determines whether an update is required?
I'm not sure whether it's based purely on the application version number being compared to the newProperty value in the relevant entry in updates.xml. Or, does the Application ID (in the installer configuration screen) come into play somewhere?
The update detection logic is customizable.
Look at your updater installer application on the Installer->Screens & Actions tab and locate the action named "Update descriptor entry". That action is just a "Set a variable" action with a script of
((UpdateDescriptor)context.getVariable("updateDescriptor")).getPossibleUpdateEntry()
The method UpdateDescriptor#getPossibleUpdateEntry() compares the version number of the installed application to the version numbers in the downloaded updates.xml file. More precisely, it locates the entry in updates.xml for the media file ID matching the media file ID of the installer that was used to install the current installation and uses the version number of that entry.
You can replace this logic with your own logic, for example using custom attributes in the updates.xml file that were configured on the Installer->Auto-Update Options tab.