In many projects I had to implement a login screen, containing two text fields: one for the username, and one for the password. It’s as easy as dropping two textfields on a view, creating the outlets and writing a few lines of code. But when it comes to make your interaction between the form and your user as smooth, efficient and streamlined as possible, you need to write some additional lines of code.

1. Cycle through fields

The user has entered his username, he now needs to edit the password. It’s as easy as tapping the second textfield. But power-users want to go fast, they want to continue tapping without moving too much the fingers on screen. So you decide to set the returnKeyType of your textfields to UIReturnKeyNext. And once both fields are filled (and possibly validation passed), you can launch the authentication process.

Here’s a example for such code:

- (BOOL) textFieldShouldReturn:(UITextField *)textField {

	BOOL loginEntered = !(self.loginField.text == nil || [self.loginField.text isEqualToString:@""]);
	BOOL passwordEntered = !(self.passwordField.text == nil || [self.passwordField.text isEqualToString:@""]);

	if(textField == self.loginField) {
		if(!passwordEntered) {
			[self.loginField resignFirstResponder];
			[self.passwordField becomeFirstResponder];
			return YES;
		}
		else if(!loginEntered) {
			return NO;
		}
	}

	if(textField == self.passwordField) {
		if(!loginEntered) {
			[self.passwordField resignFirstResponder];
			[self.loginField becomeFirstResponder];
			return YES;
		} else if(!passwordEntered) {
			return NO;
		}
	}

    // Start your authentication process
    .....

	return YES;
}

Of cours both text fields have their delegate set to your view controller. You can also auto-enable the return key on fields.
However no matter what the user has entered in the textfields, the keyboard always shows ‘Next’ as the return key.

2. On-the-fly keyboard return key type change

We’d like to have the ‘Go’ return key in the keyboard instead of ‘Next’ when both fields are validated and the user can start the authentication process. But the SDK comes with a limitation: changing the returnKeyType in the textFieldShouldReturn: method does not update the UI. Here’s the trick: use reloadInputViews.

Listen for textfields updates, for instance in your viewDidLoad: method in your controller:

    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(textFieldDidChange:)
												 name:UITextFieldTextDidChangeNotification object:self.loginField];
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(textFieldDidChange:)
												 name:UITextFieldTextDidChangeNotification object:self.passwordField];

Implement the textFieldDidChange: method

- (void) textFieldDidChange:(NSNotification*)notif {
	BOOL loginEntered = !(self.loginField.text == nil || [self.loginField.text isEqualToString:@""]);
	BOOL passwordEntered = !(self.passwordField.text == nil || [self.passwordField.text isEqualToString:@""]);

    UIReturnKeyType keyType = loginEntered && passwordEntered ? UIReturnKeyGo : UIReturnKeyNext;

    BOOL loginReturnTypeChanged = self.loginField.returnKeyType != keyType;
    BOOL passwordReturnTypeChanged = self.passwordField.returnKeyType != keyType;

    self.loginField.returnKeyType = keyType;
    self.passwordField.returnKeyType = keyType;

    if(loginReturnTypeChanged)
        [self.loginField reloadInputViews];

    if(passwordReturnTypeChanged)
        [self.passwordField reloadInputViews];
}

Do not forget to remove your notification observer, in viewDidUnload:

	[[NSNotificationCenter defaultCenter] removeObserver:self];

Et voilà, you now have a login form that do not require the user to tap anywhere outside of the keyboard. If you have other kind of tips, for making forms more efficient, please share!

(You can get a demo project here)

The Apple way

While I’m not interested now in debating which is best, it looks to me there’s a lot of confusion about how to achieve it right and quickly, so I am going to detail the one that Apple present as the official way.
An example is worth a thousand words, this one is taken from the Recipes example in Apple documentation:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    static NSString *IngredientsCellIdentifier = @"IngredientsCell";

    EditingTableViewCell *cell = (EditingTableViewCell *)[tableView dequeueReusableCellWithIdentifier:IngredientsCellIdentifier];
    if (cell == nil) {
		[[NSBundle mainBundle] loadNibNamed:@"EditingTableViewCell" owner:self options:nil];
        cell = editingTableViewCell;
		self.editingTableViewCell = nil;
    }

    ....

}

The three interesting lines are located inside the if block. While they look strange at first, you get all the meaning once you open EditingTableViewCell.xib and see how things got laid down:

The type of the view (the class) is EditingTableViewCell. IBOutlets are mapped to that file. However, the File’s Owner is IngredientDetailViewController, which is the view controller managing the UITableView displaying the EditingTableViewCell.

Right-clicking the File’s Owner shows that EditingTableViewCell is mapped to an IBOutlet called editingTableViewCell in the controller.

Giving a quick look at IngredientDetailViewController.h shows the outlet:

@property (nonatomic, assign) IBOutlet EditingTableViewCell *editingTableViewCell;

That means that when the code calls

[[NSBundle mainBundle] loadNibNamed:@"EditingTableViewCell" owner:self options:nil];

the EditingTableViewCell XIB file is going to be loaded and attached to the self (the owner), in the editingTableViewCell ivar.

cell = editingTableViewCell;

keeps a reference to that loaded XIB, which is a EditingTableViewCell object, and then

self.editingTableViewCell = nil;

resets the outlet, so that it frees up unneeded memory. The cells will be queued and reused in the UITableView, and in case the view controller needs a new reference, it can load it again from the XIB.

Smart. Efficient.

Reusing in other view controllers

The downside is that the EditingTableViewCell XIB is associated to IngredientDetailViewController which is not nice if you want to reuse your XIB for a UITableView in another controller.

Duplicating the file is not a solution. In fact, you can load the XIB from another controller, as long as the outlet is named exactly the same. Even if it’s the original controller which is mentioned as the File’s Owner in the XIB, it works.

Debugging a blank view controller

There’s a common mistake in the class/xib setup that can lead to hours of debugging while all was going smooth a few seconds before. When creating your custom UITableViewCell XIB file, you enter the view controller’s name in the File’s Owner (4th tab in the Inspector).
Then you link the outlet to your view, but you should not link the view controller’s view to your view in that XIB. Instead it must remain blank (it will be mapped by the XIB of the view controller).

Do not link your controller's view outlet in a custom UITableViewCell's XIB file, or you will likely get bugs

Linking the view as well in the cell’s XIB will cause your view controller to appear blank when running the application. This is due to the conflict that the view controller’s view is linked in two different XIBs, and XCode doesn’t show any warning for this. You’re now warned.

Apple’s Core Animation framework is a powerful way for developpers to produce animated content in their graphical interfaces. It is simple enough so that the developer only needs to specify the initial and final states of an object in order to make it animate. Core Animation handles interpolation of intermediate values and executes the animation in different thread than the main run loop, the developper doesn’t need to write specific code for the animations. And CoreAnimations can be automagically accelerated by the GPU.

CoreAnimation can be used in several ways, from the high-level UIView animation syntax down to implicit and explicit CAAnimations.
All animations finally end up being animations of CALayers properties. There are a number of CALayer properties that can be animated, they are called the animatable-properties by Apple (opacity, bounds, content, cornerRadius etc…)

However in some cases, the developper may need to implement its own CALayer subclass. The main purpose of doing such a thing is to let the developer draw custom content in the drawInContext: method (a bit like the drawRect: UIView method).

Let’s say you have a custom CALayer, which basically draws a circle with a given radius. The circle have a border on which you can control the thickness. Let’s name that class CircleLayer.

Basically its interface would look like this:

#import <Foundation/Foundation.h>
#import <QuartzCore/QuartzCore.h>

@interface CircleLayer : CALayer {
	CGFloat		radius;
	CGFloat		strokeWidth;
}

@property (nonatomic, assign) CGFloat	radius;
@property (nonatomic, assign) CGFloat	strokeWidth;

@end

and in CircleLayer.m

- (void)drawInContext:(CGContextRef)ctx {
    NSLog(@"Drawing layer, strokeWidth is %f, radius is %f", self.strokeWidth, self.radius);

    CGPoint centerPoint = CGPointMake(CGRectGetWidth(self.bounds)/2, CGRectGetHeight(self.bounds)/2);

	/* Path the circle */
    CGContextAddArc(ctx, centerPoint.x, centerPoint.y, self.radius, 0.0, 2*M_PI, 0);
    CGContextClosePath(ctx);

    /* And fill it */
    CGContextSetFillColorWithColor(ctx, [UIColor redColor].CGColor);
    CGContextFillPath(ctx);

	/* Path the circle again */
    CGContextAddArc(ctx, centerPoint.x, centerPoint.y, self.radius, 0.0, 2*M_PI, 0);
    CGContextClosePath(ctx);

	/* Stroke the path */
	CGContextSetStrokeColorWithColor(ctx, [UIColor lightGrayColor].CGColor);
	CGContextSetLineWidth(ctx, self.strokeWidth);
	CGContextStrokePath(ctx);
}

If the developper want to make the radius and/or the stroke width of the circle to animate, he would implement a CAAnimation with a fromValue and toValue:

- (void) animateRadius {
	CABasicAnimation *anim = [CABasicAnimation animationWithKeyPath:@"radius"];
	anim.duration = 3.0;
	anim.fromValue = [NSNumber numberWithDouble:50.0];
	anim.toValue = [NSNumber numberWithDouble:150.0];
	anim.timingFunction = [CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionEaseInEaseOut];

	[circleLayer addAnimation:anim forKey:@"animateRadius"];

	circleLayer.radius = 150.0;
}

- (void) animateStrokeWidth {
	CABasicAnimation *anim = [CABasicAnimation animationWithKeyPath:@"strokeWidth"];
	anim.duration = 4.0;
	anim.fromValue = [NSNumber numberWithDouble:25.0];
	anim.toValue = [NSNumber numberWithDouble:1.0];
	anim.timingFunction = [CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionEaseIn];

	[circleLayer addAnimation:anim forKey:@"animateStrokeWidth"];

	circleLayer.strokeWidth = 1.0;
}

However these two methods (which would be placed for instance in the UIView hosting the circleLayer) attempt to animate radius and strokeWidth which are not part of CoreAnimation’s animatable properties. So they wont animate.

But there is a solution, which is not really clear to me in Apple’s documentation. CircleLayer.m needs to implement two other methods:

The first, needsDisplayForKey: tells CoreAnimation which properties of the layer causes the layer to be marked as ‘dirty’ (i.e: needs to be redrawn by drawInContext: method).

+ (BOOL)needsDisplayForKey:(NSString *)key {
	if ([key isEqualToString:@"radius"]
		|| [key isEqualToString:@"strokeWidth"]) {
        return YES;
    }
	else {
        return [super needsDisplayForKey:key];
    }
}

So here we tell that an update on radius or on strokeWidth should cause the layer to be redrawn (other properties cause the redraw too, with the help of [super needsDisplayForKey:key]).

The second, initWithLayer: will ensure that custom properties will be copied for presentation layers. When you animate a CALayer, it creates presentation copies of the layer (using initWithLayer:) for each and every frame of the animation. Each presentation layer contains an intermediate value of the animated properties. The original layer contains the final state of the properties.

- (id) initWithLayer:(id)layer {
	if(self = [super initWithLayer:layer]) {
		if([layer isKindOfClass:[CircleLayer class]]) {
			CircleLayer *other = (CircleLayer*)layer;
			self.radius = other.radius;
			self.strokeWidth = other.strokeWidth;
		}
	}
	return self;
}

Since our custom properties are not copied automatically by CALayer, not implementing initWithLayer: would result in radius and strokeWidth to be zeroed for each intermediate frame, and then finally jumping to their last value when the last frame is displayed.

The radius and border thickness currently being animated

Now you have a simple solution to animate whatever kind of properties on your custom CALayer as long as they represent numbers (which can be interpolated). And yes it works with NSNumbers too.

[UPDATE]: You can find a demo project in this article.

Genèse du projet

Le principe

L’application iPad

La suite

Pour en savoir plus

Apple Push Notifications Service presentation

With the release of the iPhone OS 3.0 in June ’09, Apple introduced their Apple Push Notification Service (APNS), which gives the ability to developpers to push notifications to mobile devices (iPhone / iPod Touch and iPad). The notifications are bound to their respective application and may include badges, sounds or custom text in an alert popup. It works by keeping constantly opened an IP connection between the APNS and the device, allowing third-party application servers to route notifications via the APNS. Their main purpose was to give a workaround for developpers for the lack of multitasking in the OS (there was no multitasking to preserve battery life of the devices).
The push notifications service received a warm welcome, although a part of the tech world was criticizing the solution which seemed to be more like a better-than-nothing solution.

Recently, in June ’10, Apple released iOS4, which brought multitasking to their newest devices. Multitasking is a big word, because Apple is still not offering true multitasking (several apps running concurrently), instead they implemented a solution consisting in suspending/resuming apps and let them perform a limited number of tasks while in the background. This elegant solution solves most of the problems that the lack of multitasking caused: ability to play music in the background, ability to make VoIP calls in the background, ability to complete an upload to a server etc…

However Apple did not update their implementation of the push notifications APIs in the iOS4 (although they introduced local notifications as well).

Before iOS4, an app could be (roughly) in two states: running or stopped.

• If the app was stopped, and the user taps the ‘View’ button in the notification alert, then the app is launched with the

  - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
  

  selector, where the launchOptions contains the notification which caused the app to be launched.

• If the app is running at the time the notification is received, the

  - (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo
  

  selector is fired and no alert is displayed. Their, the developper can chose to act consequently, and even reproduce the alert dialog if he wants to.

But in iOS4.x, an app can (still roughly) be in 3 states: not launched, suspended (in the background), or running (in the foreground). And the APIs for push notification haven’t changed:

• If the app is not launched: it is launched with the application:didFinishLaunchingWithOptions: selector
• If the app is running, its didReceiveRemoteNotification: selector is fired
• If the app was in the background, the notification alert is displayed, and if the user taps ‘View’, the app is brought to the foreground and then didReceiveRemoteNotification: is fired.

So whether the app is running in the foreground or in the background, there is no way to know which state the app was in before receiving the notification.

Suppose you want the following behavior in your app:

• if notification received while app is not running: launch app, and show a specific screen
• if notification received while app is running: only update the badge value for a tab item in your tabbar
• if notification received while app is in background: app returns to foreground and then shows up a specific screen

It’s impossible to implement because there is no way to differentiate the last two scenarios. Some would say it’s easy to make a distinction because the applicationWillEnterForeground: selector is fired prior to the didReceiveRemoteNotification: selector. It is true, we can set a boolean to some value and check the boolean within the didReceiveRemoteNotification: . However in the following scenario: app running -> user hits ‘Home’ button, does some stuff -> app resumed by user -> notification received, the app would behave like if it was brought to the foreground by the notification, while it’s the user who did it.

Apart from trying to compare dates when applicationWillEnterForeground: and didReceiveRemoteNotification: are fired and try to make a guess, there is no real solution to the problem (or if you have one, please drop a comment).

Gowalla receiving a notification while running in the background

Gowalla shows another popup in the app once it's resumed after the user tapped 'View'

So the solution I brought to the problem was to override the default UIWebView. My new NPWebView class inherits UIWebView AND is delegate of the UIWebView. So that it implements the webView:shouldStartLoadWithRequest:navigationType: delegate selector.

First version of the NPWebView class asserted that the passed NSURLRequest was a NSMutableURLRequest and then added a HTTP header to it. And it worked fine!
Until I moved the project to OS4.0, where the trick didn’t work anymore. It seems Apple has modified their implementation of the UIWebview, making any change to the NSURLRequest within the webView:shouldStartLoadWithRequest:navigationType: selector inoperant. So I implemented a new workaround, that works pretty well and should now work for whatever version of the OS exists or will exist in the future.

The new solution is less efficient, I admit it. If you have a better solution, don’t hesitate to drop a comment!
In the webView:shouldStartLoadWithRequest:navigationType: selector, we’re looking in the given request for the HTTP header we want to add, see if it’s there.

• If not, then we copy the request, discard the given one (return NO), add the custom HTTP headers to the copied request and then ask self to load that request.

If present, then we let load the request (return YES).

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)aRequest navigationType:(UIWebViewNavigationType)navigationType {

	NSDictionary *headers = [aRequest allHTTPHeaderFields];
	BOOL hasWhateverAddedHeader = NO;
	for(NSString *key in [headers allKeys]) {
		if([[key lowercaseString] isEqualToString:@"my-added-header"]) {
			hasWhateverAddedHeader = YES;
			break;
		}
	}
	if(!hasWhateverAddedHeader) {
		NSMutableURLRequest *newRequest = [aRequest mutableCopy];
		[newRequest addValue:@"whatever" forHTTPHeaderField:@"My-Added-Header"];
		[self addAppVersionHTTPHeader:newRequest];
		[self loadRequest:newRequest];
		[newRequest release];
		return NO;
	}
	return YES;
}

But one can argue that my NPWebView class is already the delegate of the UIWebView, thus not allowing any other class to be delegate of the original webview. The answer I brought was to reimplement the setDelegate: selector which will retain another delegate while keeping the true delegate as being the NPWebView class.

The NPWebView class I wrote has more features, like the ability to set a NSDictionary for custom headers and solves the delegate issue.

Hit the link to download a sample project with the NPWebView class (work under Apache License version 2.0).

So I decided to create a project from scratch, drop a few buttons on a view, all with different configurations applied to them and see how VoiceOver behaves with them on the iPhone. And then I realised that VoiceOver was saying the name of the picture file that was used in the button. Pretty, elegant solution by Apple for untitled buttons. And then I felt happy because in my work I’ve always been meticulous at naming the images I use in my project. Just so that it’s easy to understand their purpose. But now it has a functional purpose too

Apple has always taken care of disabled people within their operating systems and apps. Of course it doesn’t do miracles in iPhoto for blind people but it helps in many situations, like writing a mail or browsing the web, even on an iPhone.
Their implementation of the VoiceOver technology is great. It’s build right in the system and as long as you use Apple’s standard APIs, your application will be VoiceOver compatible (that means do not put text inside images!). Their technology is much more efficient than other third-party technologies you can find on Windows for instance (thinking of jaws).

The bottom-left 'position' button selected by VoiceOver. It synthesizes "Start tracking, button", probably because the image file is named startTracking.png

While you may think it’s not really important to optimize your code down at the logging level, you should consider that any optimization, as little as it can be, is important. It is important because you know you can do better, but also because at the end, the user will be the one judging your app. By adding little optimizations to little optimizations you finally endup with a code running better, which will somehow be seen or felt by the user at some point.
The good news is that it is not necessary for you to rush on your project right now to remove all your NSLogs because there’s a great feature your compiler come with named the conditional compilation.

With conditional compilation you have a great tool to define which piece of code should appear or not in your target when you compile the code. Conditional compilation is part of the compiler instructions (the ones starting with a #, like #import). In this case we’ll use #ifdef, #ifndef, #endif, along with #define and #undef.

#define DEBUG

#ifdef DEBUG
	NSLog(@"Print a trace");
#endif

This small code says that if the DEBUG variable is defined (which is the case), the precompiler will include the NSLog() instruction in the final code to be compiled by the compiler. Otherwise it won’t.
Here we’re defining the DEBUG variable with the #define instruction. For it to have effect, you have to place it somewhere in your code before the #ifdef is executed. Later on in your code you can undefine the variable with a simple #undef DEBUG. See? It’s easy! You can have your #define instruction placed in a separate constant file and comment/uncomment the instruction at your will.

But it’s not ideal. First you have to wrap every single NSLog() instruction around a #ifdef #endif block and then you have to comment/uncomment your #define instruction depending on which type of build you want to make.

• To solve the first problem, it’s easy, you just have to put your NSLog in a separate method or C function.

  - (void) log:(NSString*)message {
  #ifdef DEBUG
  	NSLog(@"%@", message);
  #endif
  }
  

  Now you just have to call [self log:@"Print a trace"] elsewhere in your class. This is not perfect as your method takes only one argument, a NSString, and is callable only in the class which contains the log: selector. There are solutions to this particular defect, it will be covered in another article.

• For the second optimization, it is possible to define your precompiler variable using the compiler command line (the -Dvariable_name options). And for this XCode comes with configurations in which it’s easy to define these variables. In XCode, you can create different configurations for different release types, and you can create as many configurations as you wish. The menu available on the top left of your main XCode window allows you to specify which configuration you want to use for your build. By default there are the Debug and Release configurations.To edit a configuration, just hit Cmd+I on your project. On the property window, there’s the Configurations tab which allows you to create, delete, duplicate configurations. In the Build tab, you have access to a lot of options in relation to building your project.
  In the Build tab, make sure to select the Debug configuration and not All configurations, then in the search field, enter «Other C Flags». At this point, the field is empty, just add the -DDEBUG value (the field «Other C++ Flags» will be automatically populated). And now you’re done!
  When writing and debugging your project, select your Debug configuration. When preparing an adhoc build or building the binary for submission to the appstore, just select a different configuration and the NSLogs won’t appear in the console, they even won’t be compiled in your code!

Defining variables for conditional compilations, used along with configurations in XCode, is a convenient way for creating slightly different builds of the same code: you can have debug traces and blocks of codes in your debug configuration while having a clean code for your releases, all within the same project. All one-click away!

A l’ouverture de l’application, celle-ci  demande à vous localiser et affiche la carte de France des prix immobiliers en superposant une couche de couleurs sur une vue satellite Google Maps. Une légende est disponible dans la barre d’outils se situant en bas de l’écran, elle permet de connaître la fourchette de prix associée à chacune des couleurs (de vert, le moins cher, à rouge, le plus cher). D’un simple appui sur une zone colorée, l’application affiche une bulle d’information qui indique le prix estimé au m² de la zone en question. Il est possible d’avoir plus de détails sur l’adresse en question (fourchette haute et basse, prix pour un appartement ou une maison, ainsi qu’une photo de la facade de l’immeuble si disponible) et même d’estimer le prix d’un bien à cette adresse, en fonction de paramètres supplémentaires rentrés par l’utilisateur (nombre de pièces, surface, présence d’une cave, d’une terrasse …).
Il est également possible d’effectuer une recherche directement sur une ville ou une adresse grâce à une barre de recherche, ou bien de se  déplacer de département en département avec la fonction dédiée sur la barre d’outil du bas.

Mais le plus fun et impressionnant est sans doute la réalité augmentée (disponible uniquement sur iPhone 3Gs et 4). Celle-ci superpose à la caméra de votre téléphone directement le prix du mètre carré sur l’immeuble que vous aurez pointé. On se prend d’envie à n’importe quel endroit de la capitale de connaître le prix au mètre carré. Evidemment la précision du GPS étant ce qu’elle est, les informations affichées ne se superpose pas forcément exactement à l’immeuble pointé. Mais l’application dispose d’un écran de configuration permettant de régler manuellement sa position sur la carte ainsi que la distance de recherche. Pratique!

L’application MeilleursAgents.com est indéniablement ludique et fun à utiliser. Le service proposé par MeilleursAgents.com permet à un vendeur de réaliser la meilleure vente possible de son bien immobilier et dans les meilleurs délais grâce à leurs agences partenaires. L’application sera d’autant plus utile à tous ceux qui veulent mettre en vente leur bien immobilier.

[EDIT: Cette application est réalisée par Clicmobile]