4 things puppenspieler likes Explore more popular stuff on Tumblr →

Update: Since writing this, I’ve discovered an easier way to install Xcode 3.2.6 on Lion.

Today on Twitter I noticed a conversation between @ccgus, @rbrockerhoff and @radiofreelunch concerning running Xcode 3.2.6 on Lion. The consensus was that if you had it installed before upgrading to Lion that it seemed to work alright but it wasn’t possible to install it while running Lion. If you try, you will see that the Xcode Toolset component is disabled and can’t be selected. Back when the first Developer Preview of Lion was released I was working on a product built using Xcode 3.2 that needed to run on Lion and had issues on that Developer Preview. At the time, it wasn’t desired to migrate all of the projects to Xcode 4 but we wanted to fix the Lion issues, so I decided to see if I could get Xcode 3.2 to install. It turns out that you can, it’s relatively easy to do.

• Convert the Xcode 3.2.6 disk image to a read-write disk image with Disk Utility
• Mount the new read-write image
• In Finder, right-click on the Xcode and iOS SDK package and Show Package Contents
• Inside the package, locate Contents/iPhoneSDKSL.dist and open it in your favorite text editor
• Search for isDevToolsCompatible
• Change 10.7 in that function to 10.8
• Save the file
• Run the installer package
• The installer should now allow the dev tools to be installed

There are a few of caveats that I need to add to this post.

First, it should be very clear to anyone reading this that Apple does not support Xcode 3.2.6 on Lion. If there are problems, they won’t be fixed. You are on your own.

Second, back when I first figured this out it was with the Xcode 3.2.5 installer. I’ve double-checked with Xcode 3.2.6 and it appears to work the same so these instructions should be fine but I’m not guaranteeing any miracles here. I’ve done no testing of the actual install of Xcode 3.2.6 on Lion. Just that the installer can be modified to allow the dev tools to install.

Finally, I don’t know what will happen if you try to run this and you already have Xcode 4.1 installed. I’ve only tried it with no other dev tools installed.

I’m interested in hearing if anyone has success or failure with these modifications.

Let’s begin with the basics. In iOS there is a watchdog process - a watchdog that checks if an App takes more than about 20 seconds to start without getting back to the OS it will be killed. In the crash reports this killing is indicated by an exception code of 0x8badf00d - Ate Bad Food. Getting back to the OS more or less means that your delegate call of  application:didFinishLaunchingWithOptions: needs to return control to the runloop in time. If you don’t: you are killed. The user experience of this is that your Default.png is shown for about 20 seconds, and then the iPhone/iPad returns to the home screen.

Fun Fact: On iOS Devices that support multitasking the watchdog can be confused by pressing home and go back to the app again in intervals slightly less than 20 seconds. So if an App is showing this behavior, you might get it to work again using this stunt.

This is all good and well, the user should not have to wait for more than 20 seconds for an App to actually do something that the user can see or interact with. This is where Core Data comes in.

Core Data is a great framework that provides developers an abstraction to a local database. You do so by specifying a data model in Xcode, and provide classes for your database objects. In code you usually initialize your Core Data infrastructure very early on, because you rely on the data in the database for almost everything your app does. Usually that step takes little time - if the app is new you maybe want to copy an existing database as a first step, otherwise it just opens up the database files and returns.

However, if you want to store additional information in your database, you need to update your model. And if you do so, you need to migrate your data once to accommodate the new model. This happens in that early on initialization step. As migration goes there are two kinds of migration: Lightweight migration and manual migration. Lightweight migration is fast and can be done by just issuing SQL statements to the underlying database. Manual migration causes every object to be loaded and be updated. If you can achieve your changes with lightweight migration, especially on iOS devices you should do so. However, sometimes it is necessary to do some manual work in the migration process.

This is where the shit can hit the fan: Consider you are initializing Core Data before the end of  application:didFinishLaunchingWithOptions: because you want to use some of the existing data to prepare badges and UI state in the first viewWillAppear: methods of your top view controllers. Consider further that you are making a major update to your App and the database needs a manual migration. Now what easily can happen is that the watchdog literally bites your app in the ass.

And even better, during development you probably won’t notice. Why? Because of many reasons, I try to list many of them:

• The watchdog is inactive if you are running in the debugger. Your App Start may take a while, but your app will always start up.
• The migration step only happens once, unless your specifically testing for it over and over again. And it is most likely that that step is done while you are running in the debugger to check if everything goes right.
• The data you need to test needs to be big. In most test and development scenarios you have realistic data, with a wide variety of items being in there to catch most cases, but you won’t do very big data because that slows down overall roundtrip time.
• Your test devices most probably will be the fastest you have most of the time, again for roundtrip reasons. And faster devices migrate faster. Probably fast enough to not show the problem.

When you look at the customers that will have that problem out there you see another problem: They are probably your best customers. If they store a lot of data in your app, they use it a lot. If there is a lot of data, migration takes long. Tada! Horrible.

So now that we have established that this problem is a real turdball coming your way, how do you prevent/fix it?

Solution #1: do lightweight migration. If you can do that. This will be fast enough to not call the wrath of the Watchdog.

Solution #2: if you can’t do lightweight migration, make sure your migration step won’t be caught by the watchdog. E.g. your initialization of Core Data needs to be done after the app has returned from the application:didFinishLaunchingWithOptions: callback. A really good way of testing this is adding a simple sleep(25) in the code that actually creates your persistentStoreCoordinator. That way without having all test data, migration always takes long enough to trigger the watchdog. And again be sure to not attach the debugger, or the watchdog won’t bite.

Lessons learned:

• Beware of the watchdog.
• Core Data is great, but migration can really hit you quite unexpectedly.
• If you use Core Data - put in that sleep(25) call now and test if you get bitten. If so fix it so it won’t bite you unprepared in the future when you update your model.
• Prepare feedback for user migration. As it turns out users don’t make a difference between an app that appears frozen for a long period of time and an app that actually crashes. Even if migration will only happen once for each major model update, that moment can be crucial.

After another long period of radio silence, we’re back with news. Yeah, I know, finally. ;)

Here’s the gist: We just sent an update to Apple that - as promised - brings Game Center support. It’s probably going to be available for download within a week. Carcassonne now has achievements, more leaderboards and it has become way easier to just play with your friends and invite them by using Game Center.

We initially released Carcassonne before Game Center was available and had to build our own multi-player experience, so it’s great to now be more tightly integrated with existing games and friends by supporting Game Center as well.

There’s also news about the long awaited expansions: We have made good progress laying the foundations for all expansions and getting the game to a point were it can be played in a more modular fashion to support cherry-picking rules and features of expansions in the future. After the Game Center update, we now will concentrate on polishing the first two of the expansions we’re going to release. Namely “Inns and Cathedrals” and “The River II”. It will still take us a few months to make them as good as we want them to be, however.

Yeah, it sure takes us a lot of time to get these things done. We’re sorry for making you wait. We love the game and think it deserves the time to make it truly great, instead of doing a quick but sloppy port, like it unfortunately happens so often on other platforms and to others of our favorite board games. We want to do better. Thanks for having the patience to let us do so.

One of the great treats in picking up your BMW in Munich is your chance to visit BMW Welt (BMW World, if your German is rusty). BMW Welt is an extraordinary example of modern German architecture and a sight to behold.

For any car enthusiast, this is a trip to the Holy Land. A return to some long forgotten world where quality, craftsmanship, and solid engineering mattered. Few automakers in the world (are you listening, Detroit?) could pull off an experience quite like BMW Welt. Moreover, even fewer could pull it off and actually mean it.

What some would refer to as “German engineering” is really just old fashioned attention to detail and pride in craftsmanship. But the attention to detail belies an important distinction: It’s not sufficient to pay lavish attention to your work when you’re producing something for someone else, you need to pay lavish attention to the problem you are trying to solve. Considering the user’s needs throughout the entire design process is of paramount importance. The features, bells, and whistles don’t matter if they don’t actually meet a need. Moreover, your design needs to become a seamless part of the user’s experience.

A well designed solution feels effortless, often obvious. It’s so simple and elegant you ask yourself, “Why hasn’t it always been this way?” A great designer anticipates the problems his users encounter in the real world and tailors his solution to specifically meet those needs. This mantra applies to everything in life: From the report you prepare for your boss so he can present to his superiors, to the software you write for Mac, iPhone, and iPad, to the car whose every inch and surface you’ve agonized over for months. This attention to detail in conjunction with consideration of the end user is something everyone could benefit from adding to their personal and professional lifestyle.

For many of us, this pursuit of simplicity is what drives us to the products we use. Braun did not manufacture appliances with the most features, they stuck with solving basic needs with elegant, beautiful simplicity. Apple does not cram every bell and whistle into their products, they focus on elegantly solving important needs while keeping common tasks simple and straight-forward. BMW does not produce cars that out-feature the competition, they create cars that are tailored to the driving experience in every way.

Each of these companies made a very distinctive choice and ingrained it in their DNA. They chose to focus on users, not on tech specs, feature lists, or product comparisons. That the products are often full of features is delightful. That each of these features is naturally and cleanly expressed to be most useful is great design.

And so, for anyone who appreciates the above, visiting one of the few places in the world where a company focuses on this so intently is a religious experience. In a world of quantity over quality and “we’ll make it up on volume”, finding a place that values what they produce is a rare gem. That you get to immerse yourself in that atmosphere is like a breath of fresh air.

Your trip to BMW Welt is completely tailored to your experience. From learning about the exact car you’ve purchased, to exploring BMW’s history of automotive innovation, and seeing first hand what goes into the design and production of each vehicle.

BMW isn’t about flashy looks or being pretty (though they certainly make attractive vehicles), BMW is about the ultimate driving experience. Visiting the Welt is meant to remind you of this in every way possible.