Forms, Keyboard Handling and Input Validation

A signup form that works perfectly in the simulator can be genuinely unusable on a real device the moment the keyboard appears: the keyboard covers the exact field the user is typing into, the submit button slides out of reach, or the screen's content jumps unpredictably as focus moves between fields. Unlike a web form, there is no browser reflowing the page around a fixed on-screen keyboard for free — React Native has to be told explicitly how the layout should respond when the keyboard shows, and getting that wrong is one of the fastest ways to make an otherwise solid app feel broken to a real user typing on a real phone.

This lesson is an exercise: you will build a two-field login form — email and password — that stays usable with the keyboard open, validates input without punishing the user for still being mid-keystroke, and gives clear, timely feedback when something is wrong. The concepts feeding into it — controlled inputs, `KeyboardAvoidingView`, debounced validation, and accessible error messaging — are exactly the concepts a production auth screen, checkout form, or profile-edit screen all depend on.

Analogy🏏Cricket

🏏 Think of it like cricket: A team's team-sheet submission process ahead of a match has a hard deadline and a specific, structured format — playing XI, batting order, designated wicketkeeper — and the process is built to catch a genuine problem (a name spelled wrong, a duplicate entry, a squad member who is not actually eligible) before the sheet is submitted to match officials, not after, when a correction becomes a much bigger administrative problem. But the process does not flag every field as an error the instant the team manager starts filling it in — a batting-order field left blank while the manager is still deciding is expected mid-process, not treated the same as a submitted sheet with a genuine gap in it. Just as the team-sheet process validates for real problems at the right moment — as fields are completed and finally at submission — rather than treating an in-progress form as already broken, a well-built input form validates as the user progresses and finally on submit, not on every keystroke of a field they have not finished typing. The insight is that good validation respects where the user actually is in the process — mid-entry, not yet done — rather than applying submission-time rules to a form that is still being filled out.

Problem Statement and Requirements

What You'll Build

A login form with an email field and a password field, a submit button, and inline validation feedback. The form must remain fully usable when the keyboard is open on both iOS and Android — no field should be hidden behind the keyboard, and the submit button should remain reachable. Email format is validated, but only after the user has finished typing (on blur, or after a short pause), never on every keystroke while they are still mid-entry. The password field masks its value by default with a visibility toggle, and the submit action is disabled while either field is invalid or empty, with a clear reason shown for why.

The specific requirements: (1) both inputs are controlled components with their state colocated in the form, not lifted unnecessarily; (2) the screen wraps its content in `KeyboardAvoidingView` with platform-appropriate behavior, since iOS and Android need different `behavior` values to get correct results; (3) email validation runs debounced, not synchronously on every keystroke, so a user typing `name@` does not see an error flash before they have had a chance to finish; (4) validation errors are exposed with `accessibilityLiveRegion` so a screen reader announces them without the user needing to manually navigate to find out what went wrong.

Analogy🏏Cricket

🏏 Think of it like cricket: A ground's electronic scoreboard does not flash 'ILLEGAL DELIVERY' on the screen the instant a bowler starts their run-up, before the ball has even been bowled — that would be nonsensical, since there is nothing yet to judge. It waits until the delivery is actually complete and the umpire has made a call, then displays the result clearly and immediately, not several overs later when the moment has already passed. The scoreboard's timing is deliberate: judge only when there is something real to judge, and communicate the result the instant it is actually known, not before and not with unnecessary delay. Just as the scoreboard withholds judgment until the delivery is genuinely complete, a form's validation should withhold an error message until the user has genuinely finished entering that field, not react to every partial keystroke as if it were a final answer. Just as the scoreboard communicates a real result immediately and clearly once it exists, a form should surface a real validation error immediately and clearly once the user has actually finished the input in question, not buried in a generic banner disconnected from the specific field it concerns. The insight is that good feedback is timed to match reality — neither premature, before there is anything real to react to, nor delayed once there genuinely is.