Your mobile device has encountered an unexpected error (0xE800003A) Dealing With An Hyperactive Keyboard
May 02

One of the more tedious things in iPhone development is to create functional data entry screens. The challenge is to fit the necessary text fields on the screen and deal with the keyboard that pops up and covers roughly half the screen. There is surprisingly little support for this in the SDK.

Data entry is also one of the more tedious activities for users of your iPhone app, so you should think long and hard about ways to eliminate data entry and make the UI for what you can’t eliminate as user friendly as possible.

This blog post may not offer UI nirvana, but it has some techniques that I’ve found useful on screens with multiple UITextField and UITextView controls. The methods described here are generic enough that they should fit most such screens.

The first step is to create your screen in Interface Builder (or in code if you prefer). The first UI element you need to add is a UIScrollView. It should cover the entire view and be configured to scroll vertically.

Then you place your UITextFields and UITextViews on the UIScrollView. Each data entry control needs to have its delegate set to the view controller so that the controller can act upon events from the controls. In Interface Builder you also configure captitalization, correction, keyboard type, etc for each field. With the exception of the scroll view, this is probably what most of your screens already look like.

Next we’re going to use the versatile “tag” attribute of UIView. The value is tag will be used similar to how tab order is used in other UI technologies. So set the tag to 1 for the data entry field at the top of your screen, 2 for the second, etc.

Now let’s dive into some code. Your controller needs to implement the protocols UITextFieldDelegate and UITextViewDelegate (assuming that you have both types of UI controls in your screen).

@interface MyViewController : UIViewController <UITextFieldDelegate, UITextViewDelegate>

Implement the following methods which are called when a text field or text view becomes the first responder, either by the user tapping inside the field or by your code explicitly requesting it to become the first responder.

#pragma mark UITextFieldDelegate

- (void)textFieldDidBeginEditing:(UITextField *)textField {
	[self scrollViewToCenterOfScreen:textField];
}

#pragma mark UITextViewDelegate

- (void)textViewDidBeginEditing:(UITextView *)textView {
	[self scrollViewToCenterOfScreen:textView];
}

The scrollViewToCenterOfScreen simply takes the frame of the view and positions the scroll view so that the view is in the center of the visible area. The visible area may be significantly reduced by the space taken up by the keyboard. More on that later.

- (void)scrollViewToCenterOfScreen:(UIView *)theView {
	CGFloat viewCenterY = theView.center.y;
	CGRect applicationFrame = [[UIScreen mainScreen] applicationFrame];

	CGFloat availableHeight = applicationFrame.size.height - keyboardBounds.size.height;	// Remove area covered by keyboard

	CGFloat y = viewCenterY - availableHeight / 2.0;
	if (y < 0) {
		y = 0;
	}
	scrollView.contentSize = CGSizeMake(applicationFrame.size.width, applicationFrame.size.height + keyboardBounds.size.height);
	[scrollView setContentOffset:CGPointMake(0, y) animated:YES];
}

Notice that the calculations above used a variable, keyboardBounds.size.height, for the height of the keyboard. The lazy approach would be to just use a constant with the value 216. That would work fine in portrait mode with the current keyboards available in the current iPhone OS. But listen to Apple's warnings: Do not hardcode values like this in your code. Your app will break in the future.

One way to get the accurate size of the keyboard is to observe keyboard notifications.

	[[NSNotificationCenter defaultCenter] addObserver:self
											 selector:@selector(keyboardNotification:)
												 name:UIKeyboardWillShowNotification
											   object:nil];

If your screen allows the keyboard to disappear, then you should also observe the UIKeyboardWillHideNotification.

The keyboardNotification method looks like this:

- (void)keyboardNotification:(NSNotification*)notification {
	NSDictionary *userInfo = [notification userInfo];
	NSValue *keyboardBoundsValue = [userInfo objectForKey:UIKeyboardBoundsUserInfoKey];
	[keyboardBoundsValue getValue:&keyboardBounds];
}

And the declaration of  keyboardBounds:

CGRect keyboardBounds;

The above steps ensure that the current field where the user is entering data is made visible. Now for some extra credit let's use the return key on the keyboard to move from one field to the next. This is where the "tag" attribute will be used.

For UITextFields you can implement textFieldShouldReturn like this:

- (BOOL)textFieldShouldReturn:(UITextField *)textField {
	// Find the next entry field
	for (UIView *view in [self entryFields]) {
		if (view.tag == (textField.tag + 1)) {
			[view becomeFirstResponder];
			break;
		}
	}

	return NO;
}

What this method does is to look through an array of entry fields to find the one with the next higher tag value. The entryFields method looks like this:

/*
 Returns an array of all data entry fields in the view.
 Fields are ordered by tag, and only fields with tag > 0 are included.
 Returned fields are guaranteed to be a subclass of UIResponder.
 */
- (NSArray *)entryFields {
	if (!entryFields) {
		self.entryFields = [[NSMutableArray alloc] init];
		NSInteger tag = 1;
		UIView *aView;
		while (aView = [self.view viewWithTag:tag]) {
			if (aView && [[aView class] isSubclassOfClass:[UIResponder class]]) {
				[entryFields addObject:aView];
			}
			tag++;
		}
	}
	return entryFields;
}

Taken together you now have a pretty good framework for creating usable data entry screens. Please let me know in the comments any improvements you make or any alternative techniques you've used.

written by Nick \\ tags: , , ,

36 Responses to “How To Create A Data Entry Screen”

  1. Rob Says:

    minor suggestion; I’d return [entryFields autorelease] from
    - (NSArray *)entryFields
    or rename it to createEntryFields…

  2. Derek Neighbors Says:

    Good tips and agree that it is surprising how lacking the SDK is in this area.

  3. Trevor Says:

    Typo: “needs to have it’s delegate” –> “needs to have its delegate”

  4. Trevor Says:

    Typo: “the heigh of the keyboard” –> “the height of the keyboard”

  5. Trevor Says:

    The point about hard-coding a value for the keyboard height is interesting because Apple’s own code samples do exactly that. See, for example, the kOFFSET_FOR_KEYBOARD constant in their UICatalog sample. They clearly do not practice what they preach.

  6. Create Says:

    Great tutorial, I have always wondered about the problems the keyboard could create by popping up in your face.

  7. Frank Says:

    Very nice. However, there’s a potential infinite loop in – (NSArray *)entryFields. If a view is found that does not satisfy the innermost ‘if’ statement, the code will loop forever.

  8. Nick Says:

    @Frank: Good catch. Thanks!

  9. Nick Says:

    @Rob: I neglected to show in the code snippets that entryFields is declared as a property.

    @property (nonatomic, retain) NSArray *entryFields;

    Since this method is called multiple times while the user is interacting with the screen, I want to allocate memory for the array once and keep it around. This might be a slight misuse of @property since no code outside of this class will ever access entryFields. But it cuts down on the amount of code I have to write for memory management. ;-)

  10. John Says:

    I have a re-usable class that allows you to define a form in a table. This supports editing existing data or creating new data. Even though it’s canned, it is fairly customizable. Please read about it here: http://osmorphis.blogspot.com/2009/04/tableformeditor-v14-text-field-settings.html

  11. Clawoo Says:

    Thanks, this is an interesting and very usable approach.

    I’m having a hell of a time adapting this to a grouped UITableView with controls inside the cells, the behavior is rather erratic: when an UITextField which is below the keyboard grabs the focus the table scrolls to an arbitrary position. In my case with 5 fields + section titles it jumps to precisely 98.0 points.

    For the cells I’m using CellTextFields instances from the UICatalog samples.

    Do you have any success using this technique with UITableViews?

  12. Nick Says:

    @Clawoo: Check out John’s TableFormEditor class. URL in his comment above.

  13. iphone architect Says:

    very good article, thanks

  14. Roland Says:

    I’m having trouble getting this code working in my app. There are no build errors but no matter what I do textFieldDidBeginEditing and scrollViewToCenterOfScreen won’t fire.

    Any chance of posting a working sample for download so I compare it with mine?

    Cheers

  15. Chad Says:

    Roland, this is a month later, but…
    you may have to
    [myTextField setDelegate:self];

  16. Karl Says:

    Hey there,
    This worked almost perfect for me except for one thing. If the scrollview is at the top (i.e. on first load) then the scroll view snaps back to the top after it scrolls to the textfield. If you immediately touch the textfield again or scroll a bit down first then it works ok.
    Any ideas why this would happen, its driving me nuts!

  17. Jason Says:

    Karl, any luck?

    I’m having the same thing happen only slightly weirder. I have two text fields, the top one works perfectly but the bottom one (immediately below the top one) behaves just as you explain, “snaps back” after it starts scrolling the desired direction.

    If you found any fix, please post!

  18. Sean Says:

    I’ve inserted the code into my app for the NSArray but I get “error: ‘entryFields’ undeclared (first use in this function)” right after “if (!entryFields) { . I then also get an error of “warning: control reaches end of non-void function” after “return entryFields; } . What am I missing?

  19. Josh Says:

    Great article. This helped a bunch!

  20. Mark ON Says:

    Trying to get this logic to work! I am assuming that most of the above code should be implemented in the .m file of the controller file that is being created.

    Everything compiles but when I try to enter a textField field I get this:
    2009-11-16 20:23:09.504 TestMe[1287:20b] *** -[CreateNewTestViewController keyboardNotification]: unrecognized selector sent to instance 0×3f30bb0
    2009-11-16 20:23:09.506 TestMe[1287:20b] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘*** -[CreateNewTestViewController keyboardNotification]: unrecognized selector sent to instance 0×3f30bb0′

    Any suggestions?

    Thanks

  21. Cameron Says:

    @Karl and @Jason,

    I *might* have figured out the jump problem. had the exact same issue in an app I’m working on right now. Coincidentally, it’s my first iPhone app, so my understanding and explanation might be a bit limited.

    Here’s the solution that works for me. I assume it should work for you guys, too. scroll up and look at line 11 of the scrollViewToCenterOfScreen: method. Instead of adding the keyboard height, it works perfectly well when I *subtract* the keyboard height:
    scrollView.contentSize = CGSizeMake(applicationFrame.size.width, applicationFrame.size.height – keyboardBounds.size.height);

    That’s the same as saying:
    scrollView.contentSize = CGSizeMake(applicationFrame.size.width, availableHeight);

    OR you could delete that line altogether and have the same result.

    It makes sense to me because you’re supposed to be making that scrollView smaller, not adding to make it larger (the height PLUS the height of the KB). Because you can delete the line and still have the same results, it tells me that the size of the scrollView is unimportant, but you do have to know the point where they offset is located. The only side effect I see is that the scrollView doesn’t scroll when the keyboard is activated. Personally I like it that way, as it keeps focus on where the user is typing.

    This method hasn’t been checked with textViews – only textFields. YMMV

  22. Cameron Says:

    And now looking back at my reasoning – after my comment – I see what’s going on. The size of the content inside, not the size of the scrollView, is getting resized. So I understand how that should work, but now I’m back to square one in understanding why it doesn’t work as intended.

    Any ideas, Nick?

  23. Hardik Says:

    Sir,This is good example
    but can u give me document with explanation of each and every ling broadly to understand ur concept

    2>Is ur code is working on Portrait,Landscape,Portrait to Landscape and Landscape to portrait mode

  24. Nick Says:

    @Hardik: The code above is not dependent on portrait or landscape mode. If your screen layout works in both orientations, then this code should work too.

  25. Sam Says:

    Thanks for the example you don’t even know how many books and the SDK itself I browsed to even get a little of the knowledge you just dropped. I clipped this into evernote just in case I can’t access your site in the future. Thanks, again, and know that I’m using it.

  26. Alexander Mardari Says:

    Here is the solution to the snap problem and the code to scroll view down after editing:

    //We register for keyboard notifications in View init:
    [self registerForKeyboardNotifications];

    //Add this func to you View .m
    - (void)registerForKeyboardNotifications{
    [[NSNotificationCenter defaultCenter] addObserver:self
    selector:@selector(keyboardWasShown:)
    name:UIKeyboardDidShowNotification object:nil];

    [[NSNotificationCenter defaultCenter] addObserver:self
    selector:@selector(keyboardWasHidden:)
    name:UIKeyboardDidHideNotification object:nil];
    }

    //We add a implementation for the return key
    - (BOOL)textFieldShouldReturn:(UITextField *)aTextField {
    [myScrollView setContentOffset:CGPointMake(0, 0) animated:YES];
    return YES;
    }

    //We move the View resize funcs out of textFieldDidBeginEditing
    //The bKeyboardWasShown is for smooth scrolling when the keyboard is already on screen
    - (void)keyboardWasShown:(NSNotification*)aNotification{
    if(!bKeyboardWasShown){
    bKeyboardWasShown=YES;
    CGRect applicationFrame = [[UIScreen mainScreen] applicationFrame];
    myScrollView.contentSize = CGSizeMake(applicationFrame.size.width, applicationFrame.size.height + 216);
    }
    }

    // Called when the UIKeyboardDidHideNotification is sent
    - (void)keyboardWasHidden:(NSNotification*)aNotification{
    bKeyboardWasShown=NO;
    CGRect applicationFrame = [[UIScreen mainScreen] applicationFrame];
    myScrollView.contentSize = CGSizeMake(applicationFrame.size.width, applicationFrame.size.height);
    }

    //And finally, add this to scrollViewToCenterOfScreen to check that the view won’t scroll too much down
    if (y > 216) {
    y = 216;
    }

  27. Alexander Mardari Says:

    EDIT: Add the necessary funcs and variables to your View .h

  28. Jonathan Sterling Says:

    Stop. Please never make a data entry screen out of fields in a scrollview. Always use a UITableView; also, scrolling is done automatically for you when you do it the way I suggest.

  29. Nick Says:

    @Jonathan: In some cases a table view makes more sense, i.e. when all data entry fields are uniform in size and type, in other cases I think using a scroll view as described above is a good solution. Would you like to expand on your reasons for “never” making a data entry screen using a scroll view?

  30. Jonathan Sterling Says:

    @Nick: It’s not standard UI, and it’s just plain ugly.

  31. Joe Data Says:

    Thanks for this post. Would be great to see it updated showing entryFields added as a property and synthesized. But once I figured that out it worked like a charm in my code. Greatly improved my data entry screen and I learned a think or two!

  32. bob Says:

    [[aView class] isSubclassOfClass:[UIResponder class]]
    should be written as
    [aView isKindOfClass:[UIResponder class]]

  33. Larry Says:

    Thanks for the post. What do you think about splitting data entry tasks into successive views (with next/ back and progress feedback) so the user doesn’t have to scroll and worry about the keyboard covering up the more info. More development work for sure, but perhaps better for high-frequency data entry. I am trying to figure out a data entry design and am torn about the approach. Thanks!

  34. Ivan Says:

    I have tried this code, and I cannot get the values from the textfields.

    I am fairly certain I set the outlets correctly in IB. The scrolling, the textFieldShouldReturn to the next field, the textfield centering, … all that works but when I try this:

    NSString *strCal = txtfieldCal.text;

    NSLog(@”cal entered: %a”, strCal);

    I get:

    calories Entered: -0×1.fdbe804e6f74p+0

    Any ideas?

  35. Ivan Says:

    please disregard that last question. I realized it should have been %@ not %a. Can’t believe I missed that. Hopefully someone will learn from my idiocy.

  36. joe Says:

    UIView is a subclass of UIResponder. So [[aView class] isSubclassOfClass:[UIResponder class]] will always be true.

Leave a Reply