Posts Tagged ‘drawing’

Close this Number Keypad I shall not see!

  • Did you ever use an iPhone app with a Number Keypad to edit numbers only fields?
  • Did you ever wonder how you could close the keypad, just like you would do with the standard keyboard and its ‘Done’ button?
  • Are you sure you want to know the answer…?

YOU CAN’T! (at least if the application just used the standard Number Keypad provided within iOS SDK)

So, what choice do you have?

  • Generally, the keypad closure is not really necessary, since the edited field is in its own screen, you just let the user go back (generally through the navigation bar) and the keypad is closed automatically.
  • You may imagine other solutions, too…
  • But the one I’ll give you here offers the following result:
Simulateur iPhone
Uploaded with plasq‘s Skitch!

Now that you’ve seen this, you wan’t to know how to do it, don’t you? So here’s the howto! It’s not my own creation, I followed their tutorial and used the graphic files provided, so you can do so! I just poured a little bit of idea I found on another blog to make it a little more better (to me at least).

So this idea is just to use the powerfulness of Cocoa’s categories (extending classes without subclassing), to add a method to the UIView class enabling me to find the firstResponder from a view and resign it. Calling this method on the app’s main window when I want to close the keypad, it will seek and find the firstResponder, resign it, and thus close the keypad! Easier, isn’t it? And the corresponding is below…


@interface UIView ( RoCHExtensions )
- (UIView *)findAndResignFirstResponder;

@implementation UIView (RoCHExtensions)
- (UIView *)findAndResignFirstResponder {
    if (self.isFirstResponder) {
        [self resignFirstResponder];
		return self;

    for (UIView *subView in self.subviews) {
        UIView *firstResponder = [subView findAndResignFirstResponder];

        if (firstResponder != nil) {
			[firstResponder resignFirstResponder];
			return firstResponder;

    return nil;

UIView may be worth it! …better than CALayer? this may be no surprise…

Just a short post… Since I’m getting on another project (a shorter one, in order to have something done for once), and that project requires to manipulates UIView‘s subclasses, I may think again next time I go on my previous project (the one I was doing when I talked you of CALayer – see previous post Drawing with layers on the iPhone).

Trying to animate my views a little bit, I uncovered one thing that was provided by UIView and that I could not get with CALayer: the ability to delay an animation (which is done by UIView‘s class method setAnimationDelay:).

This is it. I only found this, but I know suspect that I would find more if looking further… So CALayer may seem nice (drawing oriented class, more simple object…), but you may think again before deciding what should be drawn through layers, and what through views.

Drawing with layers on the iPhone

I’m currently giving myself some time to discover the iPhone’s SDK. Wanting to have some fun with it, I’m playing with the graphical Cocoa engine, Quartz.

Liking the layer concept each time I see it (in particular in picture edition software), I dive into the CALayer class description and associated concept. For my newbie’s eyes, using layers may just be the same as using views. However, I have found somewhere on the net it may be faster (in performance terms) to use layers than views. So I give them a try!

Seeming quite simple in theory, I have had a very hard time to get my layers displayed. I will not come back on the whole theory here (you can find it just like I did in the Apple’s documentation), however, you may soon face the same solid wall as me. It kept me several hours, but since I got over it, I’ll give you my advice on this…

My goal was quite simple:

  1. adding a layer to the UIView’s default layer,
  2. trying to draw a picture in this layer (in fact, drawing anything would have been alright…).

Adding a sublayer was no problem, defining the methods to draw inside neither (well documented in Apple’s documentation). However, I could not have it drawn. And I hardly found code helping me on this: Apple’s one seems to be more on Mac’s Cocoa than on iPhone’s at the moment, and not much help was found on the net. I finally found an question/answer that almost matched my case, and I found the answer:

When you want to display your sublayer, don’t ask the view owning the main layer to redraw (with setNeedsDisplay), ask the main layer!

@interface MyView : UIView {}

@implementation MyView
- (void)setupLayers {
CALayer *mySublayer = [CALayer layer];
mySublayer.delegate = aDelegate;
[self.layer addSublayer:mySublayer];
[self.layer setNeedsDisplay];

This is just a simple tip, but I hope it may save some problems to some of you. If you see an error or want to comment, do not hesitate!

[EDIT] Hey, you know what? Finally that may not have been the problem (neither the solution) at all! In fact this post is now too old, I am not going to give another try, but in my recent developing, I think I faced the same problem. So I looked here, hoping I had already wroten on the solution (long time ago, not so good memory…). In fact I had, but my own solution didn’t work that time šŸ˜¦ Finally, the whole problem may just have been the layer’s size! Check it before looking further: it may well be 0x0… in which case there is no surprise it won’t display anything!

%d bloggers like this: