We had a little problem* with our server. That’s why we migrated to EC2. Now everything should work as expected.
* = Someone in our rack had his/her server (mis?)configured so that it would hijack the default gateway. Leading to all other servers not being able to connect to the internet.
It’s an audio recorder for the Mac:
One could assume such a trivial task like setting a BOOL (which is all that setNeedsDisplay does) would be thread safe. Well, it isn’t as I found out after a rather long debugging session. (With individual debug runs going up to 2 hours till the bug showed up).
If you get really unlucky and set the flag to true when the Cocoa drawing thread is doing its work the drawing thread will hang/crash. Event dispatch, your main thread, everything else will work – only your interface won’t get updated (your views’ -drawRect: methods won’t get called). A rather weird bug.
So call -setNeedsDisplay: only on the main thread. Luckily GCD makes that pretty straightforward:
The current SVN snapshot can be built under Lion but it has some quirks you have to fix first:
1. Edit include/pa_mac_core.h and uncomment the #inclusion of AudioToolbox.h (around line 49).
2. Run ./configure with your options.
3. Edit the Makefile and remove ‘-wError’ from the CFLAGS line.
Now you can type make and everything should build. (Don’t forget to strip PPC code from the generated fat lib (man lipo) if you’re planning to submit to the Mac App Store!)
ARC is fine as long as you don’t do fancy stuff. Luckily you can disable ARC on a per file basis so that most of your code can benefit from ARC and the more complex stuff can be manually handled by you.
To disable ARC for a file (or a group) select your project in Xcode 4, go to the “build phases” tab and select the files you want to disable ARC for. Add then the -fno-objc-arc compiler flag to these files.
ARC will be now disabled for the chosen files and you can retain/(auto)release as you desire 
This is a little reminder about iOS/OSX app localization for myself. I don’t localize apps too frequently so I always forget the details and have to google around. This shall be a quick reminder for myself:
To localize sourcecode strings
Add a new .strings file to project and call it “Localizable.strings”. Click on it and add a desired target localization. Let’s take german (de).
Then in the terminal (for our german example):
To localize interface builder files (nib/xib):
First make the desired nib localizable. Then create a strings file for translation. Do this by firing up the following command in the terminal.
Then translate the generated “SomeXibStrings.strings”.
To create a translated nib:
It’s good practice to save the translated files into the lproj folders so you have them at hand when you need to regenerate the IB files.
After I had finished the 1.80 update of Tune Buddy I had to upload it to Apple for app review. So I did it and went to bed.
The next morning I got an rejection mail from Apple:
|
Unsupported Architecture - Application executables may support either or both of the Intel architectures:
Other architectures may not be included in submitted binaries. Confirm that your Xcode project’s build settings include those architectures and no others. Specifically, we found the following unsupported architectures in your binary:ppc |
Clearly this had to be an error on Apple’s side as I had made sure I wouldn’t generate any PPC code. So I re-uploaded my binary and got the same rejection message. What was going on?
After a few hours of “debugging” (actually it was more like cursing and swearing) I found out what was wrong: Apple now checks the frameworks you bundle with your app for PPC code. And I had bundled the Growl framework with Tune Buddy.
So to fix this problem I had to get rid off the PPC code in Growl. Which is pretty easy using lipo. Just open your terminal, go into the depths of Growl.framework and when you’re at the location of the Growl binary (watch out that you are manipulating the binary and not the file links!) do the following:
$> lipo Growl -remove ppc -o GrowlNoPPC
$> cp GrowlNoPPC Growl
This will get rid of all PPC code in Growl. (The alternative would be to get Growl’s source and rebuild it – something I was not in the mood for).
Do this for all your bundled 3rd party frameworks and you’re ready to upload your app.
First the good news: The 10.6 drivers for those modems are compatible with 10.7.
Now the bad news: They only work in 32bit kernel mode. So you will have to reboot your Mac holding the 3 and 2 keys during boot to make your e220/e270 work again under Lion.
As far as I know Huawei is working on native 10.7 drivers but they are not available yet.
Btw. if you prefer to dial in with the native OS X tools and not use manufacturer bloatware you know the problem with PIN enabled SIM cards. I’ve built a small utility that will allow you to enter your PIN without the need for any bloated manufacturer software. You can read more about it here.
Many users complain about Tune Buddy submitting the “wrong” Artwork to Facebook. Well, the problem is known and there’s no solution in sight.
Because: It’s not a technical problem but rather … gasp … a licensing problem.
We (and probably you) don’t have the rights/the license to distribute Cover Art found in your iTunes library on the internet. If you post a ton of copyrighted artwork on your Facebook account bad things can happen (like FB decides to close down your account).
We came up with a solution to this problem that works … well … not well but well enough for the most popular songs: We use the last.fm API to retrieve cover art. And as Tune Buddy is a registered Last.fm app this gives us the right to use the art retrieved from last.fm in our app which has the feature of posting to Facebook. So it’s all ok – from the legal side.
Sadly Last.fm’s Cover Art repository is rather lacking and you get the results you get.
Sorry for that.
It took some time but Tune Buddy 1.80 is here. It’s mainly a feature release but it also fixes 2 critical bugs:
1. The Facebook authentication issue where users couldn’t authenticate Tune Buddy with Facebook.
2. A nasty crash under OS X 10.7 Lion.
The bugs are fixed, Tune Buddy is perfect again. 
So let’s take a look at the new features:
1. Spotify integration. As you know Spotify launched recently in the US and a dear Tune Buddy user requested support for Spotify’s player. So I did it. Now you can see what Spotify is playing. Tune Buddy recognizes automatically which player is active and playing so you don’t have to do anything to make this feature work.
2. Playback controls. Many users wanted this but I didn’t see any reason to built it in. After all we have shiny Apple keyboards with media playback control keys. So why include such a redundant feature? Well, because it rocks. After prototyping this feature out of pure boredom I couldn’t believe how useful it is. It’s not a replacement for my playback keys but it’s a nice addition
3. Scrolling songs. Instead of appending a stinky “…” to the trimmed song title Tune Buddy can now scroll long song titles.
4. Better support for small screen resolutions. Tune Buddy now tries to figure out how much free space you have in your menu bar and resizes itself to that maximum. Which should fix the Tune Buddy disappearing “bug”. (Which actually is not a bug but a limitation of OS X that hides too long menu items that conflict with too long app menus). The detection is not perfect yet and I’m working on improving it.
Also to celebrate the 1.80 release Tune Buddy is on sale now in Apple’s Mac App Store. Till August 1st you can get Tune Buddy for $4.99 instead of $14.95!