Monthly Archives: July 2010

One thing that I’ve wished the iPad had from the beginning was the ability to detect different levels of pressure, similar to a Wacom tablet. That would make it much more useful for things like sketching. I’ve heard from a few people that the hardware supports it, but I’ve been skeptical of those claims. How could a capacitative touch device detect pressure? But a few people I talked to at WWDC insisted it was possible with the hardware.

Turns out they were right. This is really cool. I don’t know anything about the technology – whether they’re really using pressure (I tend to doubt it) or just the relative size of the area being touched, but the results in the video look promising. I also hope the final version can be accomplished with only public APIs somehow.

©2008-2010 Jeff LaMarche.
iphonedevelopment.blogspot.com

So, in my previous post, I told you I was excited about the “synthesize by default” functionality that’s now available in LLVM 1.5. And I am, very much so. But it turns out there’s a caveat that tempers my excitement at the moment.

With synthesized iVars, we’ve had direct access to the underlying synthesized variable for a while now, so if you created a class like this:

#import <UIKit/UIKit.h>

@interface MyViewController : UIViewController {}@property (nonatomic, retain) NSString *foo;@end

You’re able to access the NSString variable foo that backs the property of the same name within the scope of your class. So, in your dealloc method, you can do this, to give one common example:

- (void)dealloc{    [foo release], foo = nil;    [super dealloc];}

However, if you enable the “synthesize by default” feature in LLVM 1.5 and use it, meaning you don’t actually have a @synthesize statement for the foo property, you lose this direct access to the underlying variables, leaving you with a bit of a conundrum – how do you do your memory cleanup without unintentionally triggering unwanted functionality, such as those in a lazy accessor or some more involved mutators.

Earlier today, I tweeted a question asking about the correct way to deal with this situation. After a bit of a Who’s on First-like back and forth with many smart people, it finally came out that this is a bug in LLVM, not an intentional design decision. Hopefully it will be fixed before too long, but in the meantime, the best answer is probably to just keep using @synthesize.

Thanks to a whole bunch of people on Twitter, many of whom I’m sure I missed!

©2008-2010 Jeff LaMarche.
iphonedevelopment.blogspot.com

When working with an NSNotification object, you’ll want to familiarize yourself the userInfo dictionary, which provides access to any additional objects that may be of interest to the receiver. Understanding the object method may also be helpful if you are using the same notification on more than one object.

userInfo Dictionary

Below I add an observer for MPMoviePlayerContentPreloadDidFinishNotification, which will send a message to the method moviePreloadDidFinish: when a MoviePlayerController object has finished playing:

mp =  [[MPMoviePlayerController alloc] initWithContentURL:movieURL];
 
[[NSNotificationCenter defaultCenter] addObserver:self
                     selector:@selector(moviePreloadDidFinish:)
                     name:MPMoviePlayerContentPreloadDidFinishNotification
                     object:mp];
}

Here’s how to access and print the userInfo dictionary from the notification object:

- (void) moviePlayBackDidFinish:(NSNotification*)notification
{
  NSDictionary *userInfo = [notification userInfo];
 
  NSLog(@"MPMoviePlayerPlaybackDidFinishReasonUserInfoKey: %@",
    [userInfo objectForKey:@"MPMoviePlayerPlaybackDidFinishReasonUserInfoKey"]);
 
  ...
}

The value of MoviePlayerPlaybackDidFinishReasonUserInfoKey is an NSNumber object which contains an integer value specifying reason the playback finished. The possible range of return values are defined in MPMovieFinishReason, which is an enum type as shown here:

enum {
   MPMovieFinishReasonPlaybackEnded,
   MPMovieFinishReasonPlaybackError,
   MPMovieFinishReasonUserExited
};
typedef NSInteger MPMovieFinishReason;

Pulling all this together, you could write something similar to the following to check if the user stopped playback of the movie:

if ([[userInfo objectForKey:@"MPMoviePlayerPlaybackDidFinishReasonUserInfoKey"] intValue] == MPMovieFinishReasonUserExited)
    NSLog(@"User stopped playback");

object Method

One more handy method within NSNotification is the method object, which will return the object (as type id) that is associated with the notification. For example, check out the code below that sets up the notification, pay attention to the last parameter mp which is assigned to the object parameter.

mp =  [[MPMoviePlayerController alloc] initWithContentURL:movieURL];
 
[[NSNotificationCenter defaultCenter] addObserver:self
                     selector:@selector(moviePreloadDidFinish:)
                     name:MPMoviePlayerContentPreloadDidFinishNotification
                     object:mp];

Within the method called by the selector, you can now access the object passed in by querying the object method:

- (void) moviePlayBackDidFinish:(NSNotification*)notification
{
  MPMoviePlayerController *mpObject = (MPMoviePlayerController *) [notification object];
...

mpObject will point to the mp object defined in the previous code block – using the object method you can retrieve a pointer to the object that made the original notification request.