Feelin' Fine - Tutorials

Paging-enabled UIScrollView With Previews

alexander.repty@mac.com (Alexander Repty) — Fri, 12 Feb 2010 17:14:00 +0100

App Store

In some of the applications that come with the iPhone, such as the App Store and Mobile Safari, Apple uses a technique for paging-enabled UIScrollViews that show a little bit of the neighbouring pieces of content instead of displaying a single view controller over the whole width of the screen. I think those previews are a really great UI element, since they're much easier to spot than the UIPageControl which usually sits right below the UIScrollView. It shows the user that there is more (or no more) content right next to what they are currently seeing.

Mobile Safari

If you've ever used UIScrollView's pagingEnabled property, you probably know that this is not easily doable. The UIScrollView will stop only at multiples of its frame's width and cannot be configured to stop at shorter intervals. I recently needed to implement a paging-enabled UIScrollView and was trying to replicate this behaviour and found a way to implement these previews.

Read on for the full tutorial.

Continue reading "Paging-enabled UIScrollView With Previews"

Attaching a UIToolbar to the iPhone's Keyboard

alexander.repty@mac.com (Alexander Repty) — Tue, 06 Oct 2009 20:30:54 +0200

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.

Viewing messages, keyboard not shown.

Keyboard displayed. The toolbar moves up, attached to the keyboard.

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.
Continue reading "Attaching a UIToolbar to the iPhone's Keyboard"

Asynchronous Networking Using NSOperation And Delegates

alexander.repty@mac.com (Alexander Repty) — Mon, 28 Sep 2009 23:41:48 +0200

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