Розробка екрану реєстрації користувача мобільного приложення
Екран реєстрації — точка входу користувача в продукт. Конверсія з "відкрив приложення" в "зареєструвався" на 80% визначається якістю UX форми та технічними деталями: швидкістю валідації, поведінкою клавіатури, обробкою помилок сервера.
Клавіатура та фокус: дрібниці, що бють по конверсії
На iOS UITextField/SwiftUI TextField з неправильним keyboardType та textContentType — перша проблема. Поле email без textContentType = .emailAddress не отримає автозаповнення з Keychain. Поле пароля без textContentType = .newPassword не вивикає системне пропозицію сгенерувати надійний пароль.
Послідовність фокуса — returnKeyType кожного поля повинен вести до наступного або відправляти форму:
TextField("Email", text: $email)
.keyboardType(.emailAddress)
.textContentType(.emailAddress)
.submitLabel(.next)
.onSubmit { focusedField = .password }
SecureField("Пароль", text: $password)
.textContentType(.newPassword)
.submitLabel(.join)
.onSubmit { submitRegistration() }
На Android — imeOptions + nextFocusDown у XML, або ImeAction.Next/ImeAction.Done у Jetpack Compose з явною передачею фокуса через FocusRequester.
Валідація: на клієнті та на сервері
Inline-валідація зменшує число помилок при відправці форми. Перевіряємо email regex-ом, але не надто строгим — [^@]+@[^@]+\.[^@]+ покриває 99% реальних адрес без ложних спрацьовань. Пароль — мінімальна довжина та наявність символів різних типів через CharacterSet.
Валідуємо поле після втрати фокуса (onBlur), не при кожному натисненні клавіші — нема сенсу показувати помилку, поки користувач не закінчив ввід.
Помилки сервера (409 Conflict — email вже занят, 422 — невалідні дані) — відображаємо під конкретним полем, не в загальному toast. "Цей email вже зареєстрований" + посилання "Увійти" — прямо рядом з полем email.
Терміни
Екран реєстрації з inline-валідацією, коректною поведінкою клавіатури, обробкою помилок сервера та покриттям UI-тестами — 3–5 робочих днів на одну платформу.