Feelin' Fine

One nifty little iPhone feature that left an impression with me is the way that the keyboard in the "Messages" application slides in and out with the keyboard, as if it were attached to it - but it isn't. I needed a similar feature for an app that I'm currently working on for a client, so I decided to investigate how to implement this feature in my own stuff.

Although my first instinct was to simply use an implicit animation using UIView's +beginAnimations:context: method, I decided to quickly search the web for some information on how other developers approached this problem.

The results were a little surprising, possibly because the proper way to do it wasn't as easily available before iPhone OS 3.0 - various people on different message boards and mailing lists suggested a hack that involved looping through all instances of UIWindow to find the one containing an instance of UIKeyboard, a private class that isn't even documented in the iPhone SDK. Those hacks then proceeded to modify the dimensions of the view that contains the keyboard and adding the UIToolbar instance as a subview, so it would animate into the key window right along with the keyboard.

Needless to say, these hacks are not exactly future-proof or what I would consider a proper implementation of this feature. The Core Animation route was the one to go, so I proceeded in that direction.

More about this after the jump. Read More

…and all I got was this lousy lanyard:



Seriously though, I had a great time at the recording of the 11th edition of Apfelshow, Apfeltalk.de's monthly video podcast. I got to talk a bit about Lab Tick and being a Mac and iPhone developer in general.

Watch the full video (German language) after the jump. Read More

A couple of weeks ago, my employer, Enough Software, published a small booklet titled "Mobile Developer's Guide to the Galaxy" in co-operation with Sevenval and WIP. For the second edition, which has just been released, I've been asked to contribute a chapter on iPhone development.

So I did, and it can be found on pages 16 through 20 in the PDF, which you may grab here. Feedback is welcome, a contact email address can be found in the document (p. 52).

Enjoy!

Lately, I have been using a lot of REST APIs for various projects that I have been working on. One development pattern that I have constantly used among all these projects is that of using various NSOperation objects, feed them to an NSOperationQueue and get the results fed back to the caller via delegation.

Why Would You Do This?

Now, why would you go through the trouble of learning all these APIs, creating a delegate protocol and implementing all this stuff if you could use a simple initWithContentsOfURL: (or similar)? The main reason here is asynchronous networking. If you're going to just fetch network data, such as strings, images or whole XML documents from remote servers, you are going to see some latency, especially if you're developing for the iPhone and running on an EDGE or 3G network.

If you were to use synchronous networking from within your main thread, you would be blocking your application's UI until your method stack returns and the system can redraw your views. If you're looking at multiple seconds of latency, which might easily occur if you're fetching dynamically generated data from a server, this practically makes your application unusable. The solution to this problem is to push networking tasks into separate functions and move those to different threads.


Asynchronous networking keeps the main thread available for drawing and other tasks.

Clean Thread Management

Of course, you could just detach new thread selectors all over your controller, but that would be rather ugly, error-prone and a bitch to maintain. Fortunately, Apple introduced NSOperation and NSOperationQueue a while back (in Mac OS X 10.5 Leopard).

For your projects, you will create a subclass of NSOperation and override the -main method to do your bidding. This is where the heavy lifting should take place and all your network latency will not matter anymore. I have written a sample application that uses an NSOperation subclass to fetch an image via HTTP and return it to the controller using a delegate protocol that I have written specifically for this task. My -main method look like this:


- (void)main {
    NSImage *image = nil;
    NSError *error = nil;
    
    NS_DURING
    
    if ([self isCancelled]) {
        NS_VOIDRETURN;
    }
    
    NSData *data = [NSData dataWithContentsOfURL:_url options:NSDataReadingUncached error:&error];
    if (nil != error) {
        [(NSObject *)_delegate performSelectorOnMainThread:@selector(errorOccurred:) withObject:error waitUntilDone:NO];
        NS_VOIDRETURN;
    }

    image = [[NSImage alloc] initWithData:data];
    
    NS_HANDLER
    NS_ENDHANDLER

    sleep(2); // for illustration purposes
    
    [(NSObject *)_delegate performSelectorOnMainThread:@selector(didReceiveImage:) withObject:image waitUntilDone:NO];
}


This method does nothing more than what you would previously have done to retrieve an image given a URL (_url and _delegate are instance variables that were filled during initialization). The delegate implements the selectors defined in my protocol, errorOccurred: and didReceiveImage:.

So much for the heavy lifting. But how do you actually get this method to run in the first place? This is easy, thanks to NSOperationQueue, which provides a method to queue NSOperation subclasses for execution. In my application controller's -awakeFromNib method, I instantiate my NSOperation subclass and add it to the NSOperationQueue like this:


- (void)awakeFromNib {
    [_progressIndicator startAnimation:self];
    NSURL *url = [NSURL URLWithString:@"http://alexrepty.com/other/kiwi.jpg"];
    ImageFetchOperation *operation = [[[ImageFetchOperation alloc] initWithURL:url delegate:self] autorelease];
    [_queue addOperation:operation];
}


Add the implementation of the delegate protocol and you're done! What you end up with is a nice, clean and efficient way of dealing with networking that helps to keep your code readable, error-free and makes for a better user experience by keeping the main thread free of blocking operations.


Delegation makes sure your application controller has immediate access to the image once it has been fetched.

Yes, the cat in the picture is mine. :)

Feel free to download the source code for this example and use it in your own projects. If you have any comments or questions, use the box below or ask me on Twitter.

Update: I've published the source code for this tutorial on Github:
http://github.com/alexrepty/Asynchronous-Image-Fetcher/fast_forward

I have just released Lab Tick 0.9.4 which introduces full 64-bit-support for users running a 64-bit-capable machine and Mac OS X 10.6 Snow Leopard.

Download the new version here or use Lab Tick's built-in updating mechanism.

Last night, I released Lab Tick 0.9.3 which fixes a number of small bugs. The biggest change in this release is support for fast user switching. In previous versions of Lab Tick, you either had to disable or quite Lab Tick before you would switch to a different account on your notebook - otherwise, Lab Tick would continue to run and try to control the illumination. This caused erratic behaviour when another instance of Lab Tick was running under a different account.

Also, since Xcode 3.2 in Snow Leopard comes with a static analyzer built-in, I could find a number of small memory leaks, which should hopefully reduce memory usage by a bit.

However, even though Lab Tick 0.9.3 runs perfectly fine on Snow Leopard, it won't run in 64 bit. That is because some of the APIs I use to control the backlit keyboard are not fully 64-bit-capable and have been deprecated by Apple. I will look into replacing those APIs with modern ones that have 64 bit support. Since spare time is always an issue, I cannot make any promises on a release date.

Until then, I hope the lack of support for 64 bit doesn't bother you too much.

Recently, I've founded a CocoaHeads chapter for the city of Bremen. We've had a lot of initial interest in our meetings and have managed about 15 people coming to each of the meetings. For our second meeting, I organized a small challenge for which I gave away a coupon code to receive the first three NSConference 2009 videos for free (Thanks, Scotty!). This challenge was well received and got me thinking about organizing something bigger and better, much like what Ironcoder used to be, but just for our local CocoaHeads chapter.

I've started asking around on Twitter (I'm @arepty, by the way) for software vendors to donate licenses, and with the Mac developer community being as fantastic as always, I received pledges for software licenses worth over 500 € within a couple of days. To top this off, falkemedia has thrown three one-year subscriptions of their magazine Mac Life into the mix, so the winners of the upcoming competition have quite a lot of stuff to look forward to.

The competition details (theme and API) will be announced at our meeting next Thursday, August 13th 2009. Please note that this being strictly a competition for the Bremen chapter of CocoaHeads, you will only be eligible to enter if you have participated in one of our local meetings in the past or will participate on Thursday. Participants will have about three weeks to build an app (Mac or iPhone) with the theme and API that I will choose for them. After the deadline, I will judge the apps and announce winners at the September meeting of our chapter.

You're probably interested to learn what kind of software was pledged as prizes for the competition, so here's the complete list:

RapidWeaver (5 licenses)

LittleSnapper (5 licenses)

Changes (2 licenses)

Lighthouse Keeper (1 license)

Code Collector Pro (1 license)

Versions (3 licenses)

CoverSutra (3 licenses)

Decloner (5 licenses)

Posterino (5 licenses)

Mental Case (1 license)

TimeBoxed (5 licenses)

Mac Life magazine (3 one-year subscriptions)

In my opinion, that is one fantastic line-up of prizes - especially for developers. They will be distributed as follows among the best-ranking participants:

First prize: RapidWeaver, LittleSnapper, Lighthouse Keeper, Code Collector Pro, Decloner, Posterino, Versions, TimeBoxed, CoverSutra, Changes, Mental Case, Mac Life subscription
Second prize: RapidWeaver, LittleSnapper, Decloner, Posterino, Versions, TimeBoxed, CoverSutra, Changes, Mac Life subscription
Third prize: RapidWeaver, LittleSnapper, Decloner, Posterino, Versions, TimeBoxed, CoverSutra, Mac Life subscription
Fourth and fifth prize: RapidWeaver, LittleSnapper, Decloner, Posterino, TimeBoxed

Including the Mac Life subscriptions, the amount of all the prizes comes to over 1,000 €. I'd like to thank all of the sponsors for their generous offers and hope that all those who attend next week's meeting are going to enjoy the competition. I'm looking forward to seeing what you guys will come up with.

It has this great quote by Matt Legend Gemmell:



By the way, I'm @arepty on Twitter.

Last week, I made a short trip to the UK for the first ever NSConference, organised by Steve "Scotty" Scott and Tim Isted. With a list of speakers including well-known developers such as Matt Legend Gemmell, Marcus Zarra, André Pang, Mike Lee and a bunch more, I was sure that attending would be worth the time, money and effort.

Fortunately, I arrived on Wednesday already, so I could participate in the big get-together at the bar that night. A lot of people who arrived early, too, had a great time getting to know each other, drinking beer and cider and generally talking about Mac development related stuff. Getting to know a bunch of people who I just knew from Twitter made this evening a blast.

Obviously, a night such as that one had its drawbacks - namely, alcohol consumption. Too much of it for a clear head on Thursday morning, anyway. About three cups of coffee, a great breakfast, two paracetamol and a Red Bull later, I was back on my feet and excited about the sessions that the day would offer. And I should not be disappointed. All the speakers knew their stuff really well and presented us with great material and inspiration to start working on something that would utlize our new-found knowledge. Especially Philippe Mougin seemed to have hit a nail with his talk about F-Script, as everyone seemed to be eager to use it right away and find out more about their and Apple's applications.

Thursday night saw the NSConference banquet taking place, which was a great dinner along with the chance to meet even more fellow developers and have some great conversations. Also, even more beer and cider, although I managed to drink in moderation and avoid taking even more medication the next morning.

After four more great sessions and a somewhat decent lunch, we got to be witnesses of the first ever Cocoa Faceoff, which pitted the speakers from America against those from Europe with each team joined by two delegates. Both teams had 30 minutes to design a Cocoa application, along with an iPhone version for conference organisers. By the end of the time, the teams should present their idea to the audience which would judge these applications. Scotty made promises of glory for the winning team and shame for the losers - while seeming completely impartial (*cough*).

Tim and Scotty would grab each speaker out of their group for a few minutes, so that they could provide a quick tip to the remaining delegates. This proved to be a lot of entertainment, although it resulted in Xcode being unusable at some point and almost got the Mac Pro destroyed.

Both teams presented their application ideas to the cheers of the audience, and Europe took the win, with a barely noticeable higher noise level than the American team achieved.

With this, the first ever UK Mac developer conference came to a close, and all of us could go home and look back on a few days full of great talks, informative conversations and a lot of fun. I couldn't find one person who didn't enjoy the conference or didn't think they walked away with some very valuable knowledge.

All that said, I'm looking forward to NSConference 2.0 next year.

I also posted some pictures on Flickr.

In the past few weeks, I have spent quite some time working on an iPhone application for a client. It is a port of a J2ME project, and a rather big one at that. Since I've only been working on some parts of the application, I wasn't really interested in using my time to fix all the compile warnings that I encountered and tried to concentrate only on the features that I had to add.

From time to time the application would crash with error messages such as this one:

2009-01-29 13:32:56.306 Debugging[28349:20b] -[NSCFString doSomething]: unrecognized selector sent to instance 0x3030
2009-01-29 13:32:56.307 Debugging[28349:20b] Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSCFString doSomething]: unrecognized selector sent to instance 0x3030'

It is usually rather difficult to trace the origin of this exception using the debugger. You can of course try to search your code for the name of the selector in question, or you can look through your compiler warnings. In a fairly large project, however, the right spot in your code may not be easy to find. Read More

I have released Lab Tick 0.9.2 today. This minor release includes one serious bug fix and a number of small improvements:

• Fixed a power management issue which caused the backlight to not come back on after being idle.


• Added an option to permanently suppress the donation window for contributors.


• A number of minor bug fixes and improvements.

As always, Lab Tick is provided free of charge, although donations are encouraged. Enjoy the update and let me know if you have any issues.

In the past two years, Lab Tick has matured from a relatively simple slider in a window to a complex application with a bunch of user-configurable preferences and nice features.

The following screen shots will give you an idea of what Lab Tick used to look like in the past. The first image shows version 0.2, one of the very first releases. In version 0.4, I started using a preferences window for some of the very first basic user-configurable behaviour.

Read More