Swiss Developer Immigrated to Germany

I wanted to play music in the background on my iPhone. To make the transition between two songs smooth and nice they should overlap and fade.  To achieve this I used the AVPlayer class: created an instance of it and started playing it. After some time it starts fading out, creates a new AVPlayer instance with a new song and starts playing again. This works perfectly well as long as my app runs in foreground. But when it is in background. It just fades out the old AVPlayer instance but does not start playing the new AVPlayer instance.

So I looked around what I was doing wrong. Along that I figured out that I’m doing this completely wrong. Using multiple AVPlayer instances was a bad idea. Instead a AVMutableComposition should be used. That’s designed for exactly that purpose. Maybe I’m not the only one struggling with this, so I put up this blogpost about it.

Read the rest of this entry »

A few days ago this site: http://fixradarorgtfo.com/ came up on my twitter stream. And shortly after that some people complained about it, that it is disrespectful. I don’t agree with that. Maybe it’s not the nicest way to say it. But I think we can all agree on that there has to change something. Here are a few things I would like to see there because I don’t agree with all the points on the “Fix Radar or GTFO” text.

  • Open: By default a radar bug should be viewable by everyone. So if I have an issue, I can search for it and see if that bug is already reported. Then I don’t have to do all the work which might include creating a new Xcode project and write some case to reproduce the error in a vanilla environment etc. etc. This would be a win-win situation. So apple does not have to search for duplicates and we can save a lot a time spent on writing duplicates. (now that I’ve wrote it down the status quo sounds even more ridiculous) For people who have to share some secret bug reports, a simple “private” would still do.
  • Rewards: Every accepted bug report should give some reward. Then that reward can be traded into support incidents. That would be a fair trade. We help apple finding bugs, they help us fixing our problems. This would motivate a lot a people to write bug reports. Just look how well stack overflow does with exactly that motivation!
  • Interface: As “Fix Radar or GTFO” already said. That interface is so 90′s and we’re now in 2012! In my opinion putting the bug reporting into Xcode is not such a good idea. There’s too much stuff in Xcode already. But make a new nice app and putt all the bug reporting in there. And if that’s too much, at least build a proper web app for it that’s state of the art.
  • Feedback: Please apple communicate with us some time. Right now most of the time it feels like your bug reports are going straight to /dev/null. If you’re lucky you gets a “This is a duplicate GTFO” response. But most of the time you get absolutely no response for months if not years. This brings us back to the first point. Make it open and then communicate with us about what’s going on. So we know on what we can really on and on what not.

These are my four main points about radar. Any other improvement welcome too. But there have to be some changes in the near future! Developers among many others made apple the most valuable company in the world, now they should show the necessary respect by improving bug reporting.

Kony 2012

Today when I woke up and looked into my twitter stream I saw this video (thx to @notch). It made me donate some money to them, hopefully it will make you too.

http://www.kony2012.com

Good article about the project: http://blog.zeit.de/netzfilmblog/2012/03/08/joseph-kony-2012-social-media-uganda-film/ (in german)

SopCast for Mac OS X

Using SopCast on the mac was always very hard. You had to use it with Windows in a virtual machine. Which made it very inconvenient. But lately I discovered that with the WineBottler.app you can build a SopCast.app with just a few clicks.

Read the rest of this entry »

Zucchini Pitfalls

Since I’ve been playing around with the Zucchini Framework. I discovered a few pitfalls. Maybe someone else stumbles upon the same problem. So I thought I make a short blogpost about it.

1. Weird “The operation could not be completed.” error:

I’ve got this error message: The operation could not be completed, No other information's available about the problem.

and the console says

-[NSAlert alertWithError:] called with nil NSError. A generic error message will be displayed, but the user deserves better.

In this case, most likely the path to your .app bundle in the confing.yml is wrong. Double check that that path is valid!

2. You get a “doesn’t define a screen context” message in the log:

The log sas something like

None: Script threw an uncaught JavaScript error: Line ' Type "Zucchini" in the username field' doesn't define a screen context.

Most likely you’ve added a new line in your .zucchini file where you shouldn’t. You should only add new lines before a “Then on the” line and nowhere else. But if you want to structure your code a bit better. You can use “#” for comment lines.

3. When running in a CI environment the test hangs and instruments endlessly leaks memory.

I described this problem before in this post. The only workaround I could find was executing zucchini from my Jenkins over ssh.

ssh user@server "cd /path/to/checked/out/repo/ && rake"

4. Unspecified “No such file or directory” message in the log

The log shows something like /Library/Ruby/Gems/1.8/gems/zucchini-ios-0.5.4/lib/feature.rb:49:in `initialize': No such file or directory - with no useful further info. In my case it was always the missing empty folder “run_data”. When running zucchini it expects this folder to be there. But because you don’t want some run data in your repository you normally don’t add it to the repository at all. So you have to add an empty file like “.gitkeep” or “.hgkeep” so the empty folder is added to the repository created when cloning/updating.

Tasty Zucchini

Wether you like to eat zucchini or not, you have to take a look at this tasty testing framework for iOS. Over time I’ve looked at a lot a testing frameworks for iOS. Now I came across this new framework for interface testing.

It’s not some completely new fancy way to test, you still have to write tests and run them. But it splits the tests in two very useful parts. In a part where you write what you want to test in a more or less natural language. And in another part where you define screens and what features every screen has. So these screens are reusable for every test.

Read the rest of this entry »

New Blog

Hi Folks,

This is my new blog and it will replace my old blog at blog.v1ru8.net. I won’t migrate the old posts over to this blog. Just look there if you miss something.

It’s a long time since I’ve posted my last blogpost. Actually I haven’t blogged since I’ve started working at equinux. It’s not that I wasn’t allowed to blog. But all interesting stuff that was going on was too close to unreleased products etc. Which left me with nothing interesting to blog about. Now that I’ve quit my job at equinux and going back to university I’m back in “business”.