Archive for October 29, 2014

Wednesday, October 29, 2014 [Tweets] [Favorites]

AppleScript and Yosemite

Ray Robertson:

Apple introduced a great variety of new automation features and updates in Yosemite. I’ve written up a quick summary below with links to more detailed information.

Daniel Jalkut:

Unfortunately the progress feature of AppleScript has not been exposed to 3rd party developers, so far as I can tell.

AppleScript Release Notes:

AppleScript/Objective-C is now available to all scripts, not just library scripts.

I’ve been wanting this feature for years. You no longer have to create a special AppleScriptObjC application; you can use it from any script. This will be useful both for the powerful Cocoa APIs as well as the many basic data structures and operations that were never part of AppleScript.

Here are some examples:

use framework "Foundation"

-- Calling an Objective-C class method:
get current application's NSDate's timeIntervalSinceReferenceDate()

-- Use pipes to avoid conflicts with AppleScript keywords.
get current application's NSDate's |date|'s timeIntervalSinceReferenceDate()

-- Basically, you just use “'s” in place of “.”.
set _array to current application's NSMutableArray's alloc()'s init()

-- “count” is also reserved.
get _array's |count|()

-- AppleScript changes “_array's addObject_(1)” to the interleaved syntax:
_array's addObject:1

-- AppleScript changes “_array's insertObject_atIndex_(0, 0)” to:
_array's insertObject:0 atIndex:0

set _string to _array's |description|()
set _appleScriptString to _string as Unicode text

set _data to _string's dataUsingEncoding:(current application's NSUTF8StringEncoding)
set _tildePath to current application's NSString's stringWithString:"~/Desktop/test"
set _path to _tildePath's stringByExpandingTildeInPath()
set {_ok, _error} to _data's writeToFile:_path options:0 |error|:(reference)
-- Should return “{1, missing value}”.
-- The file will contain “(0, 1)”.

Unfortunately, it looks like the technology is not yet very mature. Script Editor beach balled and had to be force-quit half a dozen times while I was writing this sample.

Update (2014-10-31): Joris Kluivers shows that developers can get at the progress of a script—via NSProgress.

Update (2014-11-29): Mark Aldritt:

What is not explained is how a host application can access this information and display a script’s progress in its own UI. Here’s how you do it.

At intervals the script will call the OSAActiveProc. Within this callback function you can make OSA calls that access the running script’s state. You start by getting a reference to the ‘AppleScript’ object. From there you can read the value of the four progress properties.

Apple Features Then Forbids PCalc Widget

James Thomson:

Apple has told me that Notification Center widgets on iOS cannot perform any calculations, and the current PCalc widget must be removed.

and:

I would be allowed to make a widget that let you to “enter a formula” but it couldn’t perform the calculation in the widget.

and:

And yes, Apple is currently featuring PCalc in the “Great apps for iOS 8” section, under Notification Center widgets.

Jason Snell:

First there’s the maddening inconsistency: This is an app that was accepted into the App Store, and is even being featured in the App Store as I write this. And now, a few weeks in, someone at Apple has decided that the app is too... what? Too useful?

Then there’s the frustration about Apple reducing functionality. Why is doing basic math in a widget not okay, but running billing timers and calculating trip ETAs and any number of other tricky actions are fine? It can’t be the fact that it’s a widget that you interact with, because I’ve seen numerous widgets that allow you to tap and swipe and do all sorts of stuff.

[…]

Also, in the Yosemite version of Notification Center, Apple itself provides a calculator widget! So Notification Center can be used for different things on the Mac and on iOS? How does that make sense?

Federico Viticci:

Rather, what is disappointing is the persistence of contradicting signals from a company that many developers saw as “more open” after WWDC ’14. Developers like Thomson will keep finding themselves in the position of risking to implement a feature or create an app that may be approved, gain users, and be shut down by Apple for a sudden policy change.

Marco Arment:

Like the after-the-fact rejection of Launcher last month, this feels like the worst era of app review returning with a vengeance.

When decisions like this start happening, Apple needs to reevaluate the purpose of app review: to protect itself, its platform, and its customers from spam, fraud, abuse, and malware (and ensuring Apple gets its cut, which is reasonable).

David Barnard:

As I’ve mentioned in previous emails, I fear App Review. And that’s no small thing. So many decisions I make end up being filtered through whether or not I think something might get rejected. Which has a profound impact on my team’s entire development process — from what ideas we explore while brainstorming to how we implement specific features.

Nick Heer:

It’s not the rules themselves that are necessarily a burden on app developers. It’s Apple’s store, so they get to set the rules. But it’s seemingly-arbitrary stuff like this that makes developers lose sleep at night. Thomson clearly spent a great deal of time and care building this extension, and now that’s gone to waste with unfortunately characteristic indifference from Apple. And it’s not like PCalc was rejected outright — Apple allowed it in the store for the past month and a half before pulling it for violating a rule that doesn’t even exist.

Josh Centers:

I thoroughly read the Extensibility developer documentation while researching “iOS 8 Third-Party Keyboards Explained and Reviewed” (2 October 2014) and found nothing that would specifically bar a widget like PCalc’s. In fact, the developer documentation even hints that a graphics-intensive game might be allowable in the Today View, even if it’s not encouraged.

Update (2014-10-30): Sarah Perez:

But now we’re hearing that Apple is changing its course. The PCalc app and widget will remain in the App Store, and all calculator-type widgets will be allowed as well, an Apple spokesperson has confirmed to us.

From our understanding, the calculator use case was not one that Apple had anticipated, which is why an App Store reviewer originally explained to Thomson that he would need to adjust the app, or risk being pulled from the App Store.

It’s odd that Apple didn’t anticipate it considering that Yosemite includes Apple’s very own calculator widget.

Daniel Jalkut:

Incredible that TechCrunch was informed about PCalc’s widget being re-approved by Apple before its developer, @jamesthomson, was.

The core problem remains that App Review doesn’t follow the letter of its own written rules.

Gus Mueller:

I don’t have inside information, but I’m willing to bet that someone with veto power in Apple got a little upset or jealous about PCalc’s widget, and said “kill it”. James is lucky that he has lots of friends and folks who love PCalc, and also have a soapbox to stand on. So with the outcry and bad publicity, Apple changed it’s mind.