303

This is my last blog post here on blogger.com! You'll find my new thoughts, projects and development ramblings at http://dlinsin.github.com. I migrated to blogger.com in late 2005 and was always quite happy with it. More than 5 years and exactly 502 posts later it's time to move on to something new. Subscribe to my new blog feed, check my stuff on github or follow me on Twitter.

ShareKit Pimping

A couple of months ago, I improved Word Buzz' Twitter sharing feature significantly, by leveraging a tweaked version of an existing framework. Unfortunately, I had only heard of ShareKit at that time, that's the reason why I decided to implement my own solution!

In case you don't know about ShareKit or like me only heard about it:

SharKit adds full sharing capabilities to your App. It's a drop-in library, which supports services like Twitter, Facebook, Instapaper and many more. You can share links, text and pictures with a customizable user interface. It evens queues shared items until an internet connection is available.

SharKit is awesome and I really regret not using it to add Twitter sharing to Word Buzz. It has a well documented API and is really easy to extend, there's even a step-by-step guide on ShakreKit's website, which describes the process. I followed that guide to add TwitPic and yfrog capability to ShareKit for one of our next furryfishApps projects and that's what I'd like to write about in this post.

ShareKit comes with built-in Twitter support, which you can find in SHKTwitter and its authentication form SHKTwitterForm. It uses bit.ly to share images, which has a similar API as TwitPic and yfrog. I piggybacked on that implementation, however dropped oAuth support in favor of xAuth.

I know there are a lot of discussions on xAuth, however I found it the easiest way to provide the most benefit for iPhone App users, without compromising security in a hurtful way. In order to get your iPhone App ready to use xAuth with Twitter, you need to sign up at http://developer.twitter.com/. I described the process in a previous post.

The previously mentioned class SHKTwitter inherits from SHKOAuthSharer, which does all the heavy lifting in terms of authentication for you! All you need to do is hook into the API calls and customize your authentication screen:

return [NSArray arrayWithObjects:
[SHKFormFieldSettings label:SHKLocalizedString(@"Username") key:@"username" type:SHKFormFieldTypeText start:nil],
[SHKFormFieldSettings label:SHKLocalizedString(@"Password") key:@"password" type:SHKFormFieldTypePassword start:nil],
[SHKFormFieldSettings label:SHKLocalizedString(@"Send to Twitter") key:@"sendToTwitter" type:SHKFormFieldTypeSwitch start:SHKFormFieldSwitchOn],
nil];

So let's say the user wants to share a picture, taps on the share icon and select TwitPic. He authenticates after being prompt for his Twitter credentials. When the authentication was successful, you want to show some sort of form to your users, where they can enter a comment or in case of Twitter, their status. You can totally customize the UI, without any dependency to ShareKit. In fact SHKTwitterForm, ShareKits built-in Twitter form, is a simple UIViewController with its delegate set to SHKTwitter.

The actual sharing part of the code is as straight forward as the rest of ShareKit. It's a little verbose, but once your understood the concept, it's easy to extend:

- (void)sendImage {

NSString * oauthHeader = [self oauthHeader];

NSURL *serviceURL = [NSURL URLWithString:@"http://yfrog.com/api/xauth_upload"];
OAMutableURLRequest *oRequest = [[OAMutableURLRequest alloc] initWithURL:serviceURL
consumer:super.consumer
token:super.accessToken
realm:@"http://api.twitter.com/"
signatureProvider:super.signatureProvider];

[oRequest prepare];
[oRequest setValue:nil forHTTPHeaderField:@"Authorization"];

[oRequest setHTTPMethod:@"POST"];
[oRequest setValue:@"https://api.twitter.com/1/account/verify_credentials.json" forHTTPHeaderField:@"X-Auth-Service-Provider"];
[oRequest setValue:oauthHeader forHTTPHeaderField:@"X-Verify-Credentials-Authorization"];

NSString *boundary = @"a21ff70823f9";
NSString *contentType = [NSString stringWithFormat:@"multipart/form-data; boundary=%@",boundary];
[oRequest setValue:contentType forHTTPHeaderField:@"Content-Type"];

NSMutableData *body = [NSMutableData data];

[body appendData:[[NSString stringWithFormat:@"--%@\r\n",boundary] dataUsingEncoding:NSUTF8StringEncoding]];
[body appendData:[@"Content-Disposition: form-data; name=\"key\"\r\n\r\n" dataUsingEncoding:NSUTF8StringEncoding]];
[body appendData:[self.yfrogAPIKey dataUsingEncoding:NSUTF8StringEncoding]];
[body appendData:[@"\r\n" dataUsingEncoding:NSUTF8StringEncoding]];

[body appendData:[[NSString stringWithFormat:@"--%@\r\n",boundary] dataUsingEncoding:NSUTF8StringEncoding]];
[body appendData:[@"Content-Disposition: form-data; name=\"media\"; filename=\"upload.jpg\"\r\n" dataUsingEncoding:NSUTF8StringEncoding]];
[body appendData:[@"Content-Type: image/jpg\r\n\r\n" dataUsingEncoding:NSUTF8StringEncoding]];
[body appendData:[self imageData]];
[body appendData:[@"\r\n" dataUsingEncoding:NSUTF8StringEncoding]];

[body appendData:[[NSString stringWithFormat:@"--%@--\r\n",boundary] dataUsingEncoding:NSUTF8StringEncoding]];

[oRequest setHTTPBody:body];

[self sendDidStart];

// Start the request
OAAsynchronousDataFetcher *fetcher = [OAAsynchronousDataFetcher asynchronousFetcherWithRequest:oRequest
delegate:self
didFinishSelector:@selector(sendImage:didFinishWithData:)
didFailSelector:@selector(sendImage:didFailWithError:)];

[fetcher start];

[oRequest release];
}

As you can see most of the work goes into setting up the authentication headers for the request, as well as filling in the elements of the request body. There are APIs like ASIHTTPRequest, which handle this for you, however ShareKit doesn't use them and I didn't want to introduce a 3rd party library. If you take a look at Gurpartap's TwitPic engine, you can see how easy and simple the code would be.

Overall it's a breeze to develop with SharKit and I'm glad I digged in deeper. For our next project we'll definitely use it and you should at least take a look at it before rolling your own implementation.

UI Test Automation with Instruments

One of the most impressive talks for me at WWDC 2010 was session 306 - "Automating Use Interface Testing with Instruments". I've been wanting to check it out ever since iOS 4 was released. A couple of weeks ago, I finally had a chance to give it a test ride with "I think I spider", one of the Apps I developed.

All you need to get started is an App, Instruments and some basic JavaScript skills. Apple provides a set of JavaScript libraries, that you can use to drive your tests and simulate user interaction. Your custom test scripts are run using the Automation Instrument in Apple's Instruments App, targeting your App either in the Simulator or on an actual device.

You can test almost every aspect of user interaction, using Apple's JavaScript library. No matter if you want to test shaking, device orientation or the basics like tapping and swiping, you can do all that using basic JavaScript function calls. Apple's documentation is quite solid, as most of them are, and explains the process in detail.

For "I think I spider" I covered the basic use cases in terms of UI, to make sure it still works after adding new features. Here is a basic example of the JavaScript involved to test "opening" the book, after starting the App:



You can see that the JavaScript API is quite easy to use and yet very powerful! After setting this up in the Automation Instrument and running it, you can see the Simulator firing up and tapping the UIImageView with the accessibility label "startscreen" after it became available. It then tests, if the main screen of the App was loaded and either passes or fails the test.

In order to make our App testable, I had to set the accessibility labels on the elements we wanted to reference from the script. That was the only change I had to make in our code. Since you should take accessibility into consideration anyways, it was a reasonable effort.

Apple did an awesome job giving us developers the ability to catch regressions and make our life easier. However, there is room for improvement, which has been nicely summarized by Air Source. For us, a missing UIALogger.warn function in the JavaScript library was the biggest downside. Sometimes it's okay for a test to fail under certain conditions, but you still want to get a warning about it. I use UIALogger.logMessage for those cases as a workaround, but it's quite easy to miss those lines, since they don't stand out.

Overall, I think it's a huge improvement to have a UI testing tool for iOS Apps at hand. There is room for improvement, but the current state of UI Test Automation is already priceless!

5 Star Rating

A couple of months ago we release our first own App "I think I spider" at Synyx. It features German quotes and sayings directly translated to English. It doesn't make much sense to a none-native German speaker, but believe me it's hilarious for us.

The App let's you rate those quotes with a 5 star rating, which is directly incorporated into a ranking. Up until today the component in charge of the ranking is a simple bunch of UIImageViews wired up with Interface Builder and set appropriately when tapped. That means if you want to give a 3 star rating, tapping on the 3rd UIImageView would fill up the 2 previous one as well. Same goes for changing your mind and going from a 5 to 3 star rating. The logic would unhighlight the 4th and 5th star.

Now, this works great and it certainly looks beautiful, but have you ever rated an App in the App Store on your iOS device? This is how it looks like:



Apple did a great job of just getting everything right with this small little control. The way you can slide your finger over it and the stars light up is just great. Also notice that if you want to reset the rating and go down to 0 stars, you need to swipe your finger all the way to the left. Note, that you can also touch slightly below the star, in order to see the stars above your fingers.

All those little details were the requirements for the next version of the rating feature of I think I spider. However, having some spare time over the holidays, I though I'd write a little component, which does all of that and more: DLStarRating. You can find the code on github, along with a sample project of how to use the stuff in your next App.



DLStarRating consists of a configurable number of custom UIButtons called DLStarView. They have a different background image for their normal and highlighted state. Those buttons are wrapped in a UIControl called DLStarRatingControl, which does all the touch handling. The buttons are centered in the DLStarRatingControl so keep that in mind when configuring its size.

It's quite easy to use DLStarRating in your code. You can wire it up in Interface Builder (although you won't be able to configure it from there) or in your UIViewController subclass:



To customize the stars, you can replace star.png and star_highlighted.png in the images folder under DLStarRating with your own. The only requirement is that the two images must have the same size.

If you discover any bugs or have a great idea you want implemented, open an issue on github or fork the project and help me out!

Word Buzz Lite

When we first planned Word Buzz, we didn't want to release a free version. It has a more exclusive feeling to it, if you can't test before you try. However, to boost your user base, there's nothing better than a free version. So here it is: Word Buzz Lite.

It's a universal App with no limitation except for one: no Game Center! It's not our decision, but more of Apple's technical limitation to only allow one App (bundle id) per Game Center instance. Another difference is the number of free built-in themes. The free version comes with only one free theme and more available through in-app purchases.

When developing Doublemill, which is a separate App for iPhone and iPad, I decided to use different XCode projects for the lite, premium and iPad version, hence different source bases for the three Apps. For Word Buzz, we decided to use a different strategy. A multi-target project for full and lite version, which are both universal Apps.

Having different source bases has a couple of drawbacks, which I experienced the hard way. One of it is fixing bugs! It's is a copy-paste task, with all its pitfalls and pain in testing. In addition to that, XCode's support for handling multiple projects isn't exactly supporting you. However, evolving the 3 different Apps, was easy and didn't affect the others in any way.

Developing a multi-target project comes with its own set of challenges. You are basically programming based on a preprocessor conditional inclusion or exclusion, which I've explained in an earlier blog post. For Word Buzz is was quite easy to cut out the additional themes and the Game Center support. However, I can imagine it can become quite complicated if you want to exclude sophisticated features. XCode comes with awesome support for multiple targets and its Organizer can still handle releases for two different versions, although it's one source base. In order to get me started, I used Chris Fletcher's blog post on building a lite version for your iPhone App. It covers the basics and brings you up to speed.

When it comes to evolving Word Buzz, we needed to shift our minds from the source-based to a SCM-based evolution model. We needed to maintain different branches, which would get quite complicated from time to time. Thanks to Git and github, we never experienced any problems bringing the various versions (branches) back together. Once you've changed your mental model to a DSCM system, it's hard to switch back, at least for me.

We are quite happy to have used multiple targets. Everything is covered under the hood of one XCode project and fixes go right into both versions. Check out Word Buzz Lite and let us know what you think!

Why Word Buzz doesn't support iOS 3.1

Word Buzz supports 3.2+, which means it doesn't support iOS 3 on iPhone. Although, my software developer ego doesn't like the fact, that we don't support the older versions of iOS, it was the right decision to do so.

It was a business decision to not support iOS 3.1, that's the short story. Rumors have it, that there are less than 10% of iOS 3.x devices out there - including iPads. That's a small enough number, to justify locking out the folks, which haven't upgraded yet.

The long story is, that we simply didn't develop with iOS 3.1 in mind. The are so many new features in iOS 3.2, which we wanted to use, that we couldn't just port it back. Let me give you a few examples:

Since iOS 3.2 you can use custom fonts in an easy and simple fashion. You add an array to your Info.plist called UIAppFonts and each item contains the filename of the font you put into your App bundle. There has been no easy way of accomplishing this before iOS 3.2, so we didn't want to sacrifice design and roll-out the 3.1 version with a system font.

Another great new feature in iOS 3.2 are Gesture Recognizers. If you don't know what I'm talking about stop right here and go read up on it - you are missing out! Although, Word Buzz doesn't use Gesture Recognizers extensively, we didn't wanna g back to the 19th century and use those old UITouch event handling stuff.

Those were just the two most obvious examples out of many! We sat down and tried to make Word Buzz run on our iPhone 3G, which still runs 3.1.3, but after a day worth of coding, we gave up. We'd love to make it run, but we'll rather invest in future proofing Word Buzz, using Blocks and GCD! We can't wait to drop iOS 3.2 support!

Word Buzz to support Game Center

Today furryfishApps is proud to announce, that Word Buzz now supports Game Center. A lot of work went into making this happen and we learned quite a bit on the way. I won't go into technical detail here, but rather cover what we've implemented.

Word Buzz lets you share your highscore and achievements on Game Center. It comes with over 16 different themes (set of words) and a lot more available for download. Each of those themes gets its own score, which will be added to your overall highscore. The sum of all highscores is shared on Game Center.

Why didn't we just share the highscore of each theme? We couldn't! Game Center lets you only share up to 20 different highscores, which is probably reasonable. It might be a bit confusing to have 40 different highscore lists.

Word Buzz is available on all iOS devices. You can play on your iPhone as well as on your iPad or iPod touch. Unfortunately, there is no way with Game Center to sync more than 20 highscores between devices. That means, you cannot just pick up with your iPad, where you left off with your iPhone. We are working on a homegrown solution, but until that happens, it's best to stick on one device.

When playing Word Buzz, you can unlock over 10 different achievements. All of them are shared on Game Center automatically, as soon as you unlock them.

What happens if you are offline? Don't worry! Your achievements and highscores are safely stored on the device and uploaded to Game Center as soon as you sign in!

Go challenge your friends and enjoy Word Buzz with Game Center.

Game Center Presentation at Cocoa Heads Karlsruhe

On Wednesday, I'll be giving a presentation on Apple's Game Center at the local CocoaHeads Group, here in Karlsruhe.

Game Center is Apple's social gaming network, that lets you invite friends to play, share your highscore and achievements through leaderboards and it even auto-matches you with other players for online-multiplayer games.

If you are interested in Game Center, drop by RetroGames on Wednesday 24th of November at 19:00.

Universal App - Word Buzz goes iPhone/iPod touch

We have been working on bringing Word Buzz to iPhone and iPod touch for more than a month now. We started out with an iPad only version, because in the beginning we thought the concept of Word Buzz wouldn't work on a smaller device. After a none-stop coding weekend and a heavy testing session, we knew it would work and started hacking on iPhone and iPod touch support.

We decided to build a universal App, because of pervasive Game Center support and a unique selling point! The latter is a no brainer: you are willing to spend a couple more bugs, if you get an iPad version for free. The former is a technical limitation of Game Center. You can only hook up your leaderboards and achievements with one App Id.

Although it was easy enough to port Word Buzz to iPhone and iPod touch, we ran into a couple of pitfalls and one of them is worth sharing with you: the default device of your universal App! What does that mean? Well, if you want to have different xib files in your App for iPhone and iPad, you need to qualify them with a suffix -iPhone / -iPad. In your Info.plist, you configure your alternate main xib with NSMainNibFile~iphone / NSMainNibFile~ipad. Since we started out with an iPad App, we decided to make iPad the default, meaning my alternate main xib configuration in Info.plist was NSMainNibFile~iphone and point to MainWindow-iPhone.xib.

This works great for iPhone and iPads, but it doesn't work for iPod touches and it also doesn't work with iOS 3.x. Somehow iPod touches (even with iOS 4) and iPhones with iOS 3.x don't respect the NSMainNibFile~iphone configuration in Info.plist. They always use the NSMainNibFile config without any suffix.

We only found out about this after testing on an actual device, which shows how important testing on each and every device is. We decided to make iPhone / iPod touch devices the default and qualify every iPad resource with -iPad, just like Apple actually intended it to be done.

Word Buzz for iPad is available on the App Store, the iPhone / iPod touch version is coming in a couple of days as a free update. Let us know what you think about it in the comments or on Twitter.

Word Buzz getting a better Twitter integration!

If you follow our tweets, which you should, you might have seen that we have been working hard on a better Twitter integration for Word Buzz. When looking around on github, I found a lot of frameworks for Twitter and iOS, but only Stefan's was lightweight and easy enough to integrate it into Word Buzz.

Most of the frameworks are full blown Twitter engines, which is not what we need for Word Buzz. Our requirements are simple: share your achievements (maybe your highscore in the future) with your followers. In addition to that, Twitter is our support channel. We wanted to allow posting public messages to @WordBuzzApp from within the App. Sounds easy, right? No need to pull in a full fledged Twitter engine for that!

Stefan's provides an API, which is really easy to use and integrate. There are no 3rd party dependencies, no need to fiddle with your linker flags - just an API to use! It even comes with a reasonable UI in Twitter style colors. Unfortunately, there was no iPad UI, which we had to implement myself. However, it was easy enough to come up with a Xib for iPad. Stefan's API provides delegate protocols, which you can implement to handle events such as "authentication succeeded". This way it's easy to separate the Twitter logic from your own code. The UIViewControllers provided, handle the most basic tasks like checking if you entered enough information to process with authentication.

We are using xAuth for authentication, which Twitter has to enable for your App. It took a couple of days until they came around to let us in, but it was the best solutions. Stefan's API provides xAuth out of the box and it works seamlessly. We added a Keychain integration to save your credentials and a flag in Settings.app to reset them.

Overall, it took us about 1 days to natively integrate Twitter into Word Buzz - thanks to Stefan's API! If anybody is interested, we are happy to provide the iPad UI and the Keychain integration.

What's new?

For the past couple of weeks it has been rather quiet here on my blog and there's a reason for that, as you can imagine.

First of all, I'd like to announce our new company furryfishApps, which I've co-founded with my wife Sutini. My future private endeavors in terms of iOS development will all take place under the hood of furryfishApps. Sutini is in charge of all the marketing, social media and publicity tasks, which are so important, but we developers never have time for. I'm glad to have her on board!

We are still in the midst of figuring out what to put on our website, but we already have an awesome logo and you can follow us on Twitter.


Our first App is a fast and engaging spelling game called Word Buzz! It's your job to spell a bunch of words as fast as possible, without making any mistake. You'll be scored on how fast you can spell and there are a whole lot of achievements for you to unlock. Go grab it here on the App Store. We welcome any feedback on Twitter or Email.

Word Buzz is iPad only at the moment, but an iPod/iPhone version with Game Center support is underway. I'll have some posts coming up soon on how the development of Word Buzz came along. It was a pretty exciting ride, as you can imagine.

APN Device Tokens

I'm writing for the Synyx GmbH & Co. KG mobile solutions blog. From time to time, I'll cross post articles here, if I think they are of interest for you. If you'd like to read all of my other posts, subscribe to the Synyx Mobile Solutions Blog.


When you enable Apple Push Notifications (APN) for your App, your device generates a unique device token and pass it to the didRegisterForRemoteNotificationsWithDeviceToken method in your App delegate. Usually, you'll hand the token to your server in order for it to push notifications to your device.

There are different tokens for production and sandbox, depending on which provisioning profile you build/sign your App with. One more gotcha, you need to be aware of when it comes to those device tokens: don't mix production and sandbox tokens!

If you try to send a push notification to the production servers, using a device token meant for the sandbox, Apple's servers totally block all other notification, which you are trying to send with the same connection. If you have a scheduled push notification like we do with "I think I spider", one wrong device token ruins the fun for everyone!

We decided to separate our production and test environment and use preprocessor conditional inclusion to point to different urls in our App. Unfortunately, we had to learn the hard way how tedious this gotcha can be to track down!

Supported by:
Sherweb - Hosted Exchange Hosting
Vircom - Email Security Software

Testing Apps with In App Purchases in Simulator

I'm writing for the Synyx GmbH & Co. KG mobile solutions blog. From time to time, I'll cross post articles here, if I think they are of interest for you. If you'd like to read all of my other posts, subscribe to the Synyx Mobile Solutions Blog.


If you add a store to your app and use In App Purchases to collect your payments, there are a couple of limitations your have to live with. One of those limitations is not being able to fully test your App in the iPhone Simulator:

Store Kit does not operate in iPhone Simulator. When running your application in iPhone Simulator, Store Kit logs a warning if your application attempts to retrieve the payment queue. Testing the store must be done on actual devices.

Although, there is not way to test Store Kit itself, you can still test the parts of your App that use and build on the information retrieved from Store Kit. You can use a preprocessor conditional inclusion to determine, whether you are running on the simulator and then "mock" the Store Kit calls or don't execute them at all.



Keep in mind: this might not work for your App, however, it did work for my Apps and it's better than not testing your code at all. The optimal solution would definitely be to connect to the In App Purchase Sandbox environment from the Simulator.

Push Notifications in Production

Last year, I worked on a Nine Men's Morris (Mühle) implementation for Android, called Doublemill. Since I'm an iPhone user, I decided to port the game to iPhone/iPod touch and the iPad. There are 3 versions: Doublemill Premium, Doublemill Lite and Doublemill for iPad.

In a previous blog post I highlighted a couple of gotchas you need to be aware of when implementing Apple Push Notifications. Unfortunately, I didn't really pay attention to one of them myself:

The first problem I ran into, had to do with my provisioning profile for development. I enabled APN in my Provisioning Portal, installed the certificate and implemented all the delegate methods according to the documentation, but somehow the method

- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error

was called with error code 3000 - "no valid 'aps-environment' entitlement string found for application". I was pretty sure, I setup everything correctly. However, I missed one little thing:

After you have generated your Client SSL certificate, create a new provisioning profile containing the App ID you wish to use for notifications.

This bit me after submitting Doublemill Premium to the App Store and being rejected for promoting Push Notifications in my App description, but according to Apple, not implementing it. During beta testing, everything worked fine. I had a correct implementation and the App was asking me for permission to use Push Notifications.

However, I did forget to create a new distribution provisioning profile for the App Store, after enabling Push Notifications for production. So, it didn't work for the reviewer at Apple. Forgetting about something like this is very painful, especially since I'm waiting for the 3rd round of review for the next release of Doublemill. That makes it 3 weeks since the initial submission.

When asking about this on the Apple Developer Forums, Mike was so kind to point out a neat trick on the command line, which helps you identify, whether APN for production is enabled:

codesign -dvvvv --entitlements - /path/to/App

<key>aps-environment</key>
<string>production</string>

If you see aps-environment=production, you should be save. Push notifications should work. If the key is missing, then you should create a new provisioning profile and rebuild you App with that.

It would be nice if Apple built this kind of checks into XCode or at least invalidate the provisioning profiles as soon as you enable Push Notifications in your App ID.

UI Prototyping iPhone Apps

I'm writing for the Synyx GmbH & Co. KG mobile solutions blog. From time to time, I'll cross post articles here, if I think they are of interest for you. If you'd like to read all of my other posts, subscribe to the Synyx Mobile Solutions Blog.


Before flying off to WWDC last month, I watched a whole bunch of sessions from 2009. Among others a session on "Prototyping iPhone User Interfaces" by Bret Victor. If you haven't watched it and you've got access to the WWDC videos - stop right here and watch the video!

In his session, Bret shows how to prototype an interface only by interacting with screenshots! It's amazing that a simple screenshot on the device can show you so much more than by just looking at it in a document or print out. It inspired me to use his framework and the whole process for our own development.

Unfortunately, the code for the session isn't available and neither Bret nor the frameworks evangelist, mentioned in the presentation, got back to me about the code. After some digging, I found Michael Fey's blog, who was able to successfully reverse engineer the missing parts of source code, which were not shown in the presentation.

Michael's UIViewAdditions basically allow easy access to frame properties and give you a neat init method, which adds the passed UIView as a parent:



There wasn't much left to do for me. I only coded the class Root, which is the parent of all UIImageView instances. It provides a couple of methods to slide images back and forth:



With those two classes and a couple of screenshots, it is fairly easy to create an App that looks and feels almost real. I created a short demo video, which shows how easy it is to get a good feeling if your App is going to work or not:



Now don't forget those are only screenshots and the App might need to load stuff over the network or do some animation, hence it might not feel the same. However, this process of prototyping an UI is powerful enough to give you an idea, whether the workflow or the UI in general is going to "work" or needs some tweaking.

You can download the source code for the two classes, along with a sample project from github.

WWDC10

It was my first WWDC this year and I'm blown away in any aspect! In order to not sound like an Apple fan boy, I'll highlight 3 aspects, which every conference has and compare them to my previous developer conference experiences.

The speakers were all Apple engineers. They knew how to present and almost all of them were very entertaining and fun to listen to. Most important of all - they knew what they were talking about! This is something no conference I've ever been to can compete with - not even the Spring Source conferences! They were close, but mostly featured some pretty bad talks from none Spring Source consultants, which kind of ruined the experience!

This is one aspect that makes the conference worth attending. I could simply go up to the Core Animations guy and ask him why the stuff is not working as I expect it to. The best thing was, I got and answer that actually solved my problem!

Another aspect is the choice of topics and the quality of the presentations! Everything kind of fits in nicely to the whole App theme. You could listen to talks on Interface Design, followed by an in depth session on Core Animation and finish off with listening to the latest innovations on the new iPhone 4. The quality of each talk was amazing! This is the first conference ever, where I wasn't close to dozing off once! Every session was interesting and inspiring, although they sometimes overlapped in terms of content!

To be fair, I'm kind of new to the iPhone platform, so if everything was interesting for me. I don't know how that holds true for fellow developers working on iPhone Apps for a couple of years. Other conferences I attended had quality talks, too - no doubt! Devoxx, e.g. always had great talks, but there was mostly one or two a day and the rest was mostly boring.

Third and last is the organizational aspect of the conference. It's amazing how Apple manages to keep 5000 developers under control. The food, although not extensive, was very good. Soft drinks all through the day, as well as breakfast and lunch. Another thing that I was blown away is the Wifi. Apple managed to provide a fairly stable internet connection for 5000 developers with probably more than 10000 devices. It didn't always work, as you could see in Steve's keynote, but most of the time it was stable and fast.

Even though I had to travel almost a day, going back and forth to San Francisco and the conference tickets are super expensive, it's definitely worth it. So WWDC11, here I come!

Apple Push Notifications Gotchas

Last year, I worked on a Nine Men's Morris (Mühle) implementation for Android, called Doublemill. Since I'm an iPhone user, I decided to port the game to iPhone/iPod touch and the iPad. There are 3 versions: Doublemill Premium, Doublemill Lite and Doublemill for iPad.

I'm implementing Apple Push Notifications (APN) for Doublemill Premium right now and ran into some gotchas, which I'm pretty sure are implemented somewhere else, but I'm gonna share them here with you. If you are new to APN, checkout Apple's documentation. It's pretty good and will get you quite far.

The first problem I ran into, had to do with my provisioning profile for development. I enabled APN in my Provisioning Portal, installed the certificate and implemented all the delegate methods according to the documentation, but somehow the method

- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error

was called with error code 3000 - "no valid 'aps-environment' entitlement string found for application". I was pretty sure, I setup everything correctly. However, I missed one little thing:

After you have generated your Client SSL certificate, create a new provisioning profile containing the App ID you wish to use for notifications.

That's what the Provisioning Portal tells you to do after you enabled APN. Your existing provisioning profiles are not being hooked up to APN, you really need to create new ones.

Another problem I ran into is a blocked Wifi port. Apple's documentation says:

If a cellular or WiFi connection is not available, neither the application:didRegisterForRemoteNotificationsWithDeviceToken: method or the application:didFailToRegisterForRemoteNotificationsWithError: method is called. For WiFi connections, this sometimes occurs when the device cannot connect with APNs over port 5223.

That also means neither of the methods is called when 5223 is blocked. Fortunately I came across a very helpful post on the Apple Developer Forums (sorry can't link to that here), which pointed me to a mobileconfig, enabling APN logging. If you have your phone connected and can see the log statements, you can find out if your port is blocked or something else is wrong. Don't forget to restart your phone after installing the mobileconfig, in order to enable the logging. For Doublemill the statements look something like this:

Connecting courier stream to sandbox.push.apple.com on port 5223

Connecting courier stream to push.apple.com on port 5223

Connecting to courier 2-courier.sandbox.push.apple.com

Connecting to courier 19-courier.push.apple.com

Connected to courier 2-courier.sandbox.push.apple.com (17.000.34.73)

Sending connect message with token 'xyz'

Connected to courier 19-courier.push.apple.com (17.000.36.88)
Sending connect message with token 'abc'

Recieved connected response OK

Sending filter message for enabled hashes { 34345 = "de.linsin.games.doublemill"; } and ignored hashes {}

...

Recieved connected response OK

These log statements are priceless, when hunting down the reason why you won't receive push notification in your application!

The last gotcha for today is one that I couldn't really find in Apple's documentation or at least I didn't really understand it that way. Anyways, if you distribute your App with an Ad-Hoc provisioning profile, which you would do for beta testing, the destination of your push notifications are not the sandbox, but the production. Come to think of it - it does make sense. However, you do need to create the production certificate and a new provisioning profile for it. Of course, your backend needs to be able to handle both destinations, as well!

Overall, APN is a cool feature and if you are running a server for your App anyways, it actually is for free! If your backend is running on Google App Engine, it's a different story, which I'll talk about in a future blog post.

iPad Apps have priority

Last year, I worked on a Nine Men's Morris (Mühle) implementation for Android, called Doublemill. Since I'm an iPhone user, I decided to port the game to iPhone/iPod touch and the iPad. There are 3 versions: Doublemill Premium, Doublemill Lite and Doublemill for iPad.

I had to wait for a week, after submitting Doublemill Premium for review to the App Store, until Apple decided to have a look at it. Unfortunately, we were rejected - for a good reason! As it turned out, I didn't link my libraries correctly, which turned out to cause a crash every time you wanted to play online, but I digress...

It took me roughly 2-3 hours to find the bug, fix it and resubmit the App. Now I'm waiting for five days again.

Yesterday, I finished polishing Doublemill for iPad, after reworking the UI and implementing a nicer Player vs. Player experience. Since it was a rainy day and there was only Star Trek on TV, I decided to submit it for review, since it would take at least a week until they had a look at it. I want to be ready for the European start of the iPad and if there's anything wrong with Doublemill for iPad, it would take at least 2 weeks to get it into the App Store - that's what I thought!

After the usual email, you get after submitting, I instantly received another, saying my App is in review. Just like that - without waiting for a week. That got me really upset! I invested almost 4 weeks of my spare time, to gett Doublemill Premium ready and polished and I had to wait for a week until it was in review.

To me this is a clear signal, that iPad Apps are more important to Apple than iPhone Apps - at the moment. I hope this will balance again soon. It is understandable, that they want the iPad App market filled as soon as possible, but that's no reason to make the iPhone App developers wait more than a week. That takes us back to where we were a year ago: waiting and waiting and waiting - just to be rejected!