Categories
Popular Tags
2.0 2.1 2.1.5 2.3 app store china demo design die Flash die help book improvements iPhone itunes nspreferencepane palm pre performance piracy release reviews tips trial ui XcodeArchives
- October 2011 (1)
- October 2010 (1)
- September 2010 (1)
- August 2010 (1)
- May 2010 (1)
- April 2010 (8)
- October 2009 (1)
- September 2009 (1)
- March 2009 (2)
- January 2009 (4)
Recent Music
Over the past year or so, I’ve received the occasional email asking about Automatic’s development status. Understandable, since only two minor updates were released in that period. The reason was simple: between serving my country and completing my dissertation, development was put on the back-burner – it was both a matter of time and focus.
I’m very happy to say that now, with the former over and the latter wrapping up, it’s time for Automatic to get some love. So, next week will see the release of a new beta, which will include the 2.3 version of the engine. Highlights include: resumable downloads, magnet link support, smart subscription refreshing, and more. It won’t have any of the front-facing changes, since the point is to test the considerable engine changes with as many different configurations and feeds as possible.
If you don’t already, you can follow @automaticapp to be notified when it’s available.
In previous versions of Automatic, the matching engine was a bit dumb when it came to duplicate items. If the option “Download every episode once” was enabled, it would discard all older duplicates and only match the latest (the reasoning being, the latest item was likely to be the best). However, matching a single item meant that if the link proved to be bad, there was no recourse (it kept trying the same bad link).
To improve this situation, the 2.1.5 engine will group up duplicate items, and will try to download them in succession. So if a link fails for whatever reason, it will try the next alternate, then the next, and so on, until it either downloads successfully or runs out of alternates. Note that this only applies when the “Download every episode once” option is enabled.
One of the challenges while designing Automatic was the variety (and unpredictability) that exists in feeds. Although their structure is rigid, whether it’s RSS 1.0 or 2.0, or Atom, there is no “minimum set” of tags that must be included – meaning, there can be very little to no assumptions about the content. For Automatic, the decision was made to use the date tag to drive the matching and filtering engine. While it worked quite well, it eventually became apparent that it didn’t work when a feed “backdated” items (this usually occurs when a site allows users to create feeds “on-demand” by adding items, and an item that was added later might actually have an earlier date). It also didn’t work with feeds that have no date tag, which admittedly, are a small minority.
So, in order to support these 2 scenarios, the engine in 2.1 has been redesigned to be largely date-agnostic. The result is better support for feeds that backdate, and of course, support for feeds that have no dates.
For some subscriptions, depending on the rules set up and the previous matches, you may notice a one-time download of old items. These items were not previously downloaded by Automatic, but were ignored by the old engine. Going forward, the behavior should be the same.
So far, the most frequent feature request for Automatic 2 has been the ability to customize the TV Show subscriptions in some way (alternate feeds, download folders, etc). The presets have been so popular that many previous users of Automatic used them to replace their own subscriptions, but then realized they wanted to tweak them.
In all honesty, a lazy solution was easy: the flip of a switch in the code could allow any TV subscription to be edited in the Custom interface. But that solution didn’t really address the question: “Why did users so strongly prefer the presets, even over their own, already configured Custom subscriptions?”.
Apparently, the answer lies in the TV data. Every preset has information attached about the show, such as the banner and episode list, and is presented in various areas. So in 2.1, it will be possible to attach show data to Custom subscriptions as well. Not only for shows that Automatic already knows about, but for any show. Also, episode data will be presented in the Subscription pane as well: you’ll be able to toggle between the subscription history or the episode list.
In light of the improvements to presenting show data with Custom subscriptions, converting a TV Show subscription to a Custom one now makes sense. Presenting a special interface for customizing TV Show subscriptions would be a bad idea, considering there is already a very powerful and robust rule creation interface in place. So in 2.1 you will have the ability to convert a TV Show subscription and tweak it to your heart’s content. The only difference between a TV Show subscription and a Custom one with show data attached will be the section they appear in (TV Shows vs. Custom).
This solution covers all the bases: it leaves the TV Show interface intact, allows users to customize TV Show subscriptions without losing the show data, and even enables subscriptions with show data that was not previously available in Automatic.
While System Preferences.app generally makes it very easy for users to install and update prefPanes, it has some idiosyncrasies. Foremost is the fact that when it comes to comparing two prefPanes, apparently only the names are compared: make a copy of an already installed prefPane, rename it and double-click; you’ll be offered to install it, rather than replace the existing one.
The second weirdness is a bit more complex, and can present problems when replacing a prefPane with one that is significantly different: on the one hand there is the installed prefPane, and on the other the new one, with the same name but a different bundle identifier. As mentioned above, System Preferences.app considers these two to be the same, based on their shared name.
When installing the new prefPane, System Preferences.app presumably calls unload on the old bundle and then load on the new one. This causes the new bundle’s executable to be launched, but for some reason the bundle is still set to the old one. So for example, initWithBundle is called with the old bundle. Also, any resources fail to load, since they presumably didn’t exist in the old bundle.
The best-case scenario in this case is that the prefPane will load, but no images will be displayed. Image loading is non-fatal, so System Preferences.app will complain in the log about not finding the image resources, but otherwise continue normally. However, if there are any vital resources that need to be loaded, such as Core Data models, the prefPane will probably crash.
This scenario only affects the first launch, when the new prefPane replaces the old one. Afterwards, everything loads and works properly. But it’s hardly the best first impression to give to a user who’s upgrading.
So how to fix it? Since there’s no way to modify the way the prefPane is loaded, one viable solution is to skip that first load, quit System Preferences.app and launch it again. For the user, the process is seamless: after accepting the prefPane update, System Preferences.app will briefly disappear and reappear in the dock and the prePane will load. Apart from the dock icon, the rest of the process is unaffected in the eyes of the user.
Quitting and relaunching the prefPane has to be done with a small tool, which is located in the Resources folder of the new bundle. This is the code that does the magic, somewhere in initWithBundle (preferably the first item of business):
if ([[bundle bundleIdentifier] isEqual:OLD_BUNDLE_IDENTIFIER]) {
NSString *reloadPath = [[bundle bundlePath]
stringByAppendingPathComponent:@"Contents/Resources/reload"];
NSTask* task = [[NSTask alloc] init];
[task setLaunchPath:reloadPath];
[task setArguments:[NSArray arrayWithObject:
[[NSBundle bundleForClass:[self class]] bundlePath]]];
[task setStandardInput:[NSPipe pipe]];
[task launch];
[NSApp terminate:nil];
[task release];
}
The path of the reload tool has to be manually set, rather than via NSBundle’s convenience methods, since they will give the wrong Resource folder. The reload tool takes one argument, which is the path of the new prefPane to launch. So essentially the prefPane sets up a task to launch itself, and then terminates.
The tool is very simple, all it does is launch the prefPane:
int main(int argc, char **argv) {
char dummy;
read(STDIN_FILENO, &dummy, 1);
CFURLRef url = CFURLCreateFromFileSystemRepresentation(
kCFAllocatorDefault, (UInt8*)argv[1], strlen(argv[1]), FALSE);
CFArrayRef url = CFArrayCreate(kCFAllocatorDefault, (const void**)&url,
1, NULL);
FSRef ref;
OSStatus status = LSFindApplicationForInfo(0,
CFSTR("com.apple.systempreferences"), NULL, &ref, NULL)
if ( status == noErr) {
LSApplicationParameters parms = {0, kLSLaunchDefaults, &ref,
NULL, NULL, NULL, NULL};
LSOpenURLsWithRole(url, kLSRolesAll, NULL, &parms, NULL, 0);
}
CFRelease(url);
}
In Xcode, the target that builds the prefPane should have a dependency on the tool so that it is also built, and also copy the build result into the Resources folder.