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.

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

I think I Spider

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.

I'm proud to present, that our first own App has made it to the App Store last week. It's a beautiful mobile interface to the web site http://ithinkispider.com. You can find out more over at the Synyx Mobile Solutions Blog, or just hit the App icon and download it for free from the App Store!

My lovely mister singing club!

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.

Apple Push Notifications on Google Appengine

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've written about the Google Appengine (GAE) a couple of times before and the same goes for Apple Push Notifications (APN). For Doublemill I had to bring those two technologies together and it was a pain and pleasure at the same time.

Let me start with the pain! Apples Push Notifications in a restricted environment like the Google Appengine is no fun to implement! My first approach was to use notnoop's java-apn, which I've used before and works quite well. Unfortunately, there is currently no way of using a client certificate, which you'll need in order to talk to Apple's server on the Google Appengine. There are some javax.security classes missing on GAE.

That's where the pleasure part begins! Thanks to Urban Airship, it's easy to hook up your application running on Google Appengine to Apple's Push Notifications! And the best part - it's free (although not unlimited)! Urban Airshipe provides an easy to use REST interface, which you can call from your Java code on GAE with a good old HttpURLConnection. It uses Basic Auth over Https to ensure that only your application can send Push Notifications to your iPhone App.

I won't provide any code for you here, because it's the basic concept that's the most interesting part when bringing APN to GAE. The first thing you need to do, is store your user's deviceToken. You should do that each time the App launches, to ensure it's the correct token. That token, along with the information you want to present to your user, needs to be passed to Urban Airship's REST interface, everytime you want to send a notification. A Cron Job or Task on Google Appengine could handle that for you.

If your application is designed with notifications in mind, then it's quite easy to bring Apple Push Notifications to the Google Appengine, thanks to Urban Airship!

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.

Lessons learned - iPhone Review

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 submit an App to the Apple App Store it has to go through a "rigorous quality check", conducted by Apple. Although there are plenty of resources out there, here's a short rundown of what we've learned ourselves so far:

• Marketing Apps are not allowed

If the sole purpose of your App is marketing, you'll have a hard time getting your App through. You need to add what Apple calls "user functionality". That could be something simple like a photo gallery or a feature to reserve a room or table.


• You cannot tease your users with features that they have to pay for

If you are offering a lite version of your App, you cannot add disabled functionality, which would be enabled in the paid version. A lite version usually is offered separately from a paid version, which means the user will constantly see disabled menu items or buttons, since the App will never be updated. Instead add a info section about the paid version in your App, which describes what the paid version offers.


• Don't ask your users to upgrade

You cannot add an alert in a free/lite version of your App, which asks users to upgrade or buy the paid version. Instead you should add a "buy me" button or a section in your App further describing what your paid version offers.


• Build a working App

You are definitely rejected if your App is buggy! If the reviewer thinks he found a bug, he'll reject your App. A crash is the worst case scenario, but it happens. However, don't depend on Apple as your QA, because the review times are too long to go back and forth this way.


• Don't infringe Trademarks or Copyrights

Don't mention Apple, Android or any other Trademark therefore - as long as you don't own it. You should also resist to use iPhone like icons or images.

If you respect all of these restrictions and gotchas, you should be save to get your App through the review process. I say "should", because it all appears to depend on the person who reviews your App. Let us know what you experienced, submitting your Apps, I bet there are a lot more of these gotchas.

iPhone App Beta Testing

Last year I was working on a Nine Men's Morris mobile game called Doublemill. My job was to implement a REST-based server back-end on the Google App Engine. You might remember a couple of posts on that. My colleagues were responsible for coding the Android client. Since I'm an iPhone user and I'm not going to switch to Android anytime soon, I decided to port the game to the iPhone/iPod touch platform.

I'm closing in on the first release of the paid version of Doublemill. The only thing missing is a beta test. I'm past the technical problems, which I encountered when I released a beta version of Doublemill Lite a couple of weeks ago. This is more about how to find people, willing to thoroughly and extensively test your App.

Unfortunately, I can't use Amazon's Mechanical Turk - although I'm willing to pay a small amount for people to find bugs in my App. Amazon doesn't let me use it without a US credit card, so I had to look for an alternative. I came accross iBetaTest.com. I used it for Doublemill Lite and I'm also using it for the paid version. Although the site has little flaws (it's still in beta itself), the idea is great and it works pretty well. However, there is still a problem: the people who are using the site and who are supposed to test your App.

After I added the beta for Doublemill, I received a lot of requests, mostly from testers which are not testing any other Apps or look like they have just signed up. I gave a couple of them the benefit of the doubt and let them in, only to experience, that I wasted my valuable device IDs.

At the time this blog was published, I have only received feedback from 2 of my 7 testers. The other just haven't replied. I know, that at least one has downloaded and signed up for the multiplayer feature, but hasn't provided feedback on any aspect of the App. That's just plain disappointing. After Doublemill Lite, this is the second time I wasted device IDs, it won't happen to me anymore.

After all, there's always something to learn from your mistakes: be picky on beta testers and choose people you know they'll give you valuable, honest and thorough feedback! It takes quite some time to setup a beta test and organize all device IDs, so don't neglect Q&A in your project planning.

I'm fortunate enough to have a couple of people around me, which help out with testing and give me exactly the feedback I need - although it's not always what I want to hear.

Being Rejected

Last year I was working on a Nine Men's Morris mobile game called Doublemill. My job was to implement a REST-based server back-end on the Google App Engine. You might remember a couple of posts on that. My colleagues were responsible for coding the Android client. Since I'm an iPhone user and I'm not going to switch to Android anytime soon, I decided to port the game to the iPhone/iPod touch platform.

Tonight I got an email from Apple telling me that they have rejected Doublemill Lite! Although it is kind of annoying, the email was somewhat clear on what I need to to do to fix the problem. It even had a screenshot attached, pointing out what my mistake was - if it really was one.

This is the screenshot apple sent back to me:

What's wrong here, you might think? At least that's what I thought! It turns out that you cannot tease your users with features they can never get with that particular version of your application.

Doublemill Lite features a Player vs. Player and Player vs. iPhone mode. You can challenge your friend by using the same device or play against your iPhone. The upcoming Doublemill Premium version will feature a Player vs. World mode, where you can challenge the world over any kind of internet connection.

My idea was to point out that this is a Lite version by putting the Premium features in the menu. People could immediately see, what's to come or what they are missing out on. However, Apple doesn't think that it's a good idea. And they might even be right. Doublemill Lite is not going to be updated with those features, because we will release a dedicated Premium version soon. People only using the Lite version will always see the disabled menu items and that's kind of messy.

I took the liberty to fix two other things in addition to addressing Apple's issues to remove the two menu items. Now we are back on track and hopefully in the App Store early next week.