Archive for the ‘Development’ Category

Default Folder X 4.4.7b1

Sunday, November 6th, 2011

We’ve put up a quick public beta just to make sure there are no lingering problems with Default Folder X 4.4.7. I finally tracked down the issue that’s been dogging us since Lion’s release – the beta should cure any remaining compatibility problems (namely with Bias Peak and Apple’s Keynote, but there may be others, including GraphicConverter and System Preferences).

Please take the time to download a copy from the Default Folder X Testing page and put it through its paces. Your feedback will really be appreciated.

Thanks!

– Jon

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Get your permissions right!

Wednesday, March 30th, 2011

Thought I’d post about this little developer experience because it was incredibly frustrating and not at all obvious. Maybe this will save someone else the headache that I’ve been through.

Background: When preparing an application for release on the Mac App Store, you code sign your application, then bundle it into an installer pkg which is also code signed (using either Xcode organizer or the productbuild command line tool). When the application is installed, it gets extracted from that .pkg file, the user runs it, and it checks for a Mac App Store receipt. If there’s no receipt, OS X checks to make sure that the application is signed correctly, then contacts the Mac App Store to get your receipt.

Problem: This would all work for me as advertised except that when the receipt check failed, OS X would complain that my application wasn’t code signed, and therefore wouldn’t contact the App Store to get the receipt. From a user’s perspective, the app would just fail to launch.

I’d followed all the instructions. I double- and triple-checked to make sure the application was signed before I built the .pkg file. I tried building the .pkg using both the Xcode organizer and productbuild – they both worked with no problems or error messages. Yet when the application came out of the .pkg file on the other end, it was always unsigned! I deleted all of my certificates, regenerated them, and redownloaded them from Apple’s developer site (several times). I checked every step along the way in my build process – they were all working. It was incredibly frustrating because the signed app went into the ‘black box’ of the .pkg file just fine, but came out on the other end without its code signature.

Solution: After tearing my hear out for a while, googling for answers, and checking the developer forums, I finally tracked down the solution. I had a single image file in my application’s resources that had its permissions set to 640 instead of 644, meaning that it was not readable by everyone. That threw the entire game off – apparently when the installer unpacked the .pkg file, it ran into this problem file and either stopped short of installing the code signature, or invalidated the signature.  Either way, the application it installed was useless.  Simply changing the permissions on that one tiff file fixed the problem I’d been fighting with for days.

Soooo….  If your app builds and runs fine UNTIL you package it, and then comes out unsigned on the other end, check the permissions on the resources in your application.  And Apple, please emit some kind of warning when hapless developers feed productbuild a file with the wrong permissions that’s gonna screw up the whole process.

Tip: There’s a really cool developer utility called Cong, written by Stephane Sudre.  It checks your application for all kinds of minor errors, from localization goofs in .strings files to incorrect Info.plist entries to missing files in your package.  I’ve contacted Stephane and checking file permissions is now on his To-Do list for Cong.  If you’re a developer, get a copy of Cong – a simple drag-and-drop could save you a lot of time and trouble!

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

App Tamer almost finished!

Friday, September 10th, 2010

So I’ve been working on this little application that fixes an annoying problem in OS X.

You may have noticed that the remaining battery life on your MacBook Pro (or whatever laptop you have) often plummets if you leave Safari displaying an ad in the background. That’s because most web browsers, as well as a number of other apps, continue running tasks or animations even when they’re sitting idle in the background. This can be pretty frustrating if you’re actually trying to conserve battery or use that CPU power for something useful.

I wrote App Tamer to fix this.  It pauses apps in the background to prevent them from chewing up CPU time (and battery life). I know, I know – you’ve probably seen some utilities that do this already. BUT – here’s the cool part – App Tamer stops and starts applications automatically. You don’t have to distract yourself by manually stopping and starting applications – it just magically works.

Have a look at the App Tamer page for details.  It’s in the final stages of beta testing, and you’re welcome to download a copy of the latest beta and try it for yourself. Let us know what you think at AppTamer@stclairsoft.com.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Being careful with LSSharedFileListAddObserver

Friday, November 6th, 2009

So, Apple added this cool little capability to the Launch Services API in Leopard: LSSharedFileListAddObserver will call your observer function whenever there are changes in a number of different file lists maintained by Launch Services. One of those lists is the “Recent Documents” list in the Apple Menu. ”Great!” I thought, “I’ll roll this into Default Folder X to ensure that it doesn’t miss any recently used folders.”  It’s a simple API – what could go wrong?  As a long time developer, I should have known better – if you EVER say this (even if you never even say it out loud), you need to poke yourself with something sharp and realize that the consequences will probably hurt quite a bit more than that. “What could go wrong?” indeed.

So yes, here I am apologizing for not having poked myself after I used LSSharedFileListAddObserver without asking more questions – or at least without testing more.  Here’s how Default Folder X ended up using 60% of some users’ CPUs while doing nothing useful:

  1. DFX added itself as an observer for kLSSharedFileListRecentDocumentItems.
  2. The observer function got called by Launch Services because the user double-clicked a document in the Finder.
  3. DFX looked at the list, took the most recent entry in it (the first one), asked Launch Services for the URL of the document, and added the folder enclosing that document to its Recent Folders list.

Pretty simple, right? Yeah, I thought so too. This was tested thoroughly on Snow Leopard and performed fine, and all my Leopard testers reported that it worked well for them too.

So what’s the problem then?  Well, there’s this little “issue”…  If a user has a Windows server mounted on the Desktop, things get a little more interesting.  Normally, when Launch Services calls your observer function, it hands you the file list and you ask for a copy of the list.  The list itself is just a series of ID’s and references – to see what’s in an entry, you have to call LSSharedFileListItemResolve().  And that’s where the interesting part happened.  On Leopard, if the shared file list item lies on a Windows server, the act of calling LSSharedFileListItemResolve actually results in the item being changed, so your observer function gets called again the next time you hit your event loop.  The result of this is that you get called over and over again if you naively use LSSharedFileListItemResolve to get more info about the items that Launch Services is handing you.

So – the warning:  If you use LSSharedFileListAddObserver to watch the list of recent documents, keep a copy of the ID’s from the previous call and ONLY call LSSharedFileListItemResolve if there’s a new ID in the array.  Otherwise do nothing, or work off cached information – otherwise you’ll end up in an infinite loop, sucking down lots of CPU time.  And if you’re doing anything that interacts with the filesystem, make SURE you test with SMB shared volumes too.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Default Folder X high CPU-usage and responsiveness problems

Thursday, November 5th, 2009

Well, there’s definitely a bug in Default Folder X 4.3.2.  When running under Leopard and accessing SMB file servers, DFX will start consuming 20-60% of one CPU and will start to lag or become completely unresponsive.  This may also affect Snow Leopard and / or other types of file servers besides SMB.

I’ve got a test build available with a fix:

http://www.stclairsoft.com/download/DefaultFolderX-4.3.3b1.dmg

If you’re having any trouble with Default Folder X, please download and install it.  It should fix your problems.  If you run into any problems, please let me know as soon as possible at DefaultFolder@stclairsoft.com.

Thanks, and I apologize for the bug (I’ll post the gory details in a few minutes, since it’s an interesting little ‘gotcha’ in the Launch Services API).

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]