Validate — είναι η διαδικασία ελέγχου της ορθότητας της εισαγωγής του χρήστη πριν από την αποστολή δεδομένων στον διακομιστή ή την επεξεργασία εντός της εφαρμογής. Στο Android, η επικύρωση πεδίου περιλαμβάνει τον έλεγχο της μορφής email, του αριθμού τηλεφώνου, του κωδικού πρόσβασης, της υποχρεωτικότητας συμπλήρωσης και άλλων επιχειρηματικών κανόνων. Σύμφωνα με τις Material Design Guidelines, 2026, το Validate πρέπει να παρέχει στον χρήστη σαφή ανατροφοδότηση: μήνυμα σφάλματος, αλλαγή χρώματος πεδίου, εικονίδιο κατάστασης. Η σωστή επικύρωση μειώνει τον αριθμό των λανθασμένων υποβολών φορμών κατά 40-60% και βελτιώνει την εμπειρία χρήστη.
Κύρια σημεία
Επικύρωση πεδίου — είναι ο έλεγχος μιας συγκεκριμένης τιμής που εισήγαγε ο χρήστης για συμμόρφωση με καθορισμένους κανόνες. Κάθε πεδίο έχει τον δικό του τύπο δεδομένων: email, αριθμός, τηλέφωνο, κωδικός πρόσβασης, κείμενο. Για κάθε τύπο υπάρχουν δικά του κριτήρια: μορφή, μήκος, εύρος τιμών, υποχρεωτικότητα. Η επικύρωση πεδίου απαντά στην ερώτηση: είναι σωστή η είσοδος σε αυτό το πεδίο;
Η διαφορά μεταξύ επικύρωσης πεδίου και επικύρωσης φόρμας είναι ότι το πεδίο ελέγχεται ανεξάρτητα από άλλα πεδία. Το email ελέγχεται σύμφωνα με το μοτίβο email, το τηλέφωνο — σύμφωνα με το μοτίβο τηλεφώνου. Εάν το πεδίο δεν είναι έγκυρο, ο χρήστης βλέπει το σφάλμα ακριβώς για αυτό το πεδίο. Η φόρμα μπορεί να παραμείνει μη υποβληθείσα ακόμα κι αν ένα πεδίο δεν πέρασε τον έλεγχο. Η επικύρωση πεδίου είναι το δομικό στοιχείο για την πλήρη επικύρωση φόρμας.
Σύμφωνα με έρευνες UX, οι χρήστες αναμένουν να δουν ένα σφάλμα επικύρωσης το αργότερο 1-2 δευτερόλεπτα μετά την ολοκλήρωση της εισαγωγής. Καθυστέρηση άνω των 3 δευτερολέπτων εκλαμβάνεται ως πρόβλημα με την εφαρμογή. Γι' αυτό η επικύρωση σε πραγματικό χρόνο μέσω TextWatcher είναι προτιμότερη από τον έλεγχο μόνο κατά το πάτημα του κουμπιού αποστολής.
Υπάρχουν τρεις κύριες προσεγγίσεις για την επικύρωση πεδίων στο Android. Πρώτη — χειροκίνητος έλεγχος μέσω υπό συνθήκη τελεστών (if, when). Ο προγραμματιστής γράφει μια συνάρτηση που δέχεται μια συμβολοσειρά και επιστρέφει Boolean ή μήνυμα σφάλματος. Αυτή η προσέγγιση παρέχει πλήρη έλεγχο της λογικής, αλλά απαιτεί τη σύνταξη κώδικα για κάθε πεδίο και κάθε συνθήκη.
Δεύτερη προσέγγιση — χρήση ενσωματωμένων κλάσεων Android. Για παράδειγμα, το Patterns.EMAIL_ADDRESS.matcher(email).matches() ελέγχει το email σύμφωνα με το τυπικό μοτίβο. Patterns.PHONE.matcher(phone).matches() — τον αριθμό τηλεφώνου. TextUtils.isEmpty() — ελέγχει το κενό. Αυτές οι μέθοδοι καλύπτουν βασικά σενάρια χωρίς σύνδεση εξωτερικών εξαρτήσεων.
Τρίτη προσέγγιση — βιβλιοθήκες επικύρωσης. Βιβλιοθήκες όπως InputValidator, AndroidValidator ή Commons Validator παρέχουν έτοιμους σχολιασμούς και αλυσίδες ελέγχου. Ο προγραμματιστής περιγράφει τους κανόνες δηλωτικά: @Email, @NotEmpty, @MinLength(6). Η βιβλιοθήκη εκτελεί η ίδια τον έλεγχο και επιστρέφει μια λίστα σφαλμάτων. Αυτό επιταχύνει την ανάπτυξη, αλλά προσθέτει μια εξάρτηση.
| Μέθοδος | Πλεονεκτήματα | Μειονεκτήματα | Πότε να χρησιμοποιείται |
|---|---|---|---|
| Χειροκίνητος έλεγχος | Πλήρης έλεγχος, χωρίς εξαρτήσεις | Πολύς κώδικας, δύσκολη συντήρηση | Απλές φόρμες με 1-3 πεδία |
| Ενσωματωμένες κλάσεις | Γρήγορα, τυπικά μοτίβα | Περιορισμένο σύνολο ελέγχων | Τυπικά πεδία (email, τηλέφωνο) |
| Βιβλιοθήκες | Ελάχιστος κώδικας, δηλωτική προσέγγιση | Εξάρτηση, δύσκολη προσαρμογή | Πολύπλοκες φόρμες με 5+ πεδία |
Για email, ο τυπικός έλεγχος περιλαμβάνει την παρουσία του συμβόλου @, του τομέα και την απουσία κενών και κυριλλικών χαρακτήρων. Το Android παρέχει το Patterns.EMAIL_ADDRESS, το οποίο καλύπτει τις περισσότερες νόμιμες διευθύνσεις email. Ωστόσο, εάν απαιτείται συγκεκριμένος έλεγχος (π.χ. μόνο εταιρικοί τομείς), πρέπει να γραφεί μια προσαρμοσμένη κανονική έκφραση. Το email επικυρώνεται μετά την ολοκλήρωση της εισαγωγής, όχι μετά από κάθε χαρακτήρα.
Αριθμός τηλεφώνου ελέγχεται σύμφωνα με τη μάσκα της χώρας ή της περιοχής. Για διεθνείς αριθμούς χρησιμοποιείται η μορφή E.164: +κωδικός χώρας, κωδικός χειριστή, αριθμός. Η βιβλιοθήκη libphonenumber από την Google είναι το βιομηχανικό πρότυπο για επικύρωση τηλεφώνων. Προσδιορίζει τη χώρα βάσει κωδικού, ελέγχει το μήκος και τη μορφή του αριθμού. Στο Android, μπορείτε να χρησιμοποιήσετε το PhoneNumberUtils.isGlobalPhoneNumber για βασικό έλεγχο.
Κωδικός πρόσβασης έχει πολλά κριτήρια πολυπλοκότητας: ελάχιστο μήκος, παρουσία κεφαλαίων και πεζών γραμμάτων, αριθμών, ειδικών συμβόλων. Στο Android δεν υπάρχει ενσωματωμένη κλάση για έλεγχο κωδικού πρόσβασης — κάθε έργο καθορίζει τις δικές του απαιτήσεις. Συνήθως, ο κωδικός ελέγχεται μέσω κανονικής έκφρασης ή συνόλου συνθηκών. Είναι σημαντικό να μην αποκαλύπτονται οι ακριβείς απαιτήσεις στο μήνυμα σφάλματος: “Ο κωδικός είναι πολύ απλός" είναι καλύτερο από “Απαιτείται κεφαλαίο γράμμα και αριθμός".
data class ValidationResult(
val isValid: Boolean,
val errorMessage: String? = null
)
fun validatePassword(password: String): ValidationResult {
if (password.length < 6)
return ValidationResult(false, "Minimum 6 characters")
if (!password.any { it.isUpperCase() })
return ValidationResult(false, "Uppercase letter required")
return ValidationResult(true)
}
Στο παράδειγμα, η validatePassword επιστρέφει ένα ValidationResult με πεδίο isValid και προαιρετικό μήνυμα σφάλματος. Αυτή η προσέγγιση είναι βολική για σύνθεση: πολλοί έλεγχοι εκτελούνται διαδοχικά και επιστρέφεται το πρώτο σφάλμα που βρέθηκε. Οι επικυρώσεις email και τηλεφώνου χτίζονται με την ίδια αρχή — η καθεμία επιστρέφει ένα αποτέλεσμα με μήνυμα ή επιτυχία.
Η χρονική στιγμή της επικύρωσης επηρεάζει κρίσιμα το UX. Υπάρχουν τρεις στρατηγικές: επικύρωση μετά από κάθε χαρακτήρα (instant), μετά την απώλεια εστίασης (onFocusLost) και κατά την υποβολή της φόρμας (onSubmit). Κάθε στρατηγική είναι κατάλληλη για διαφορετικά σενάρια. Η άμεση επικύρωση είναι καλή για πεδία με αυστηρούς περιορισμούς — αριθμός τηλεφώνου, PIN. OnFocusLost — για email και όνομα. OnSubmit — για υποχρεωτικά πεδία.
Σύμφωνα με τις Material Design Guidelines, συνιστάται ο συνδυασμός στρατηγικών: το πεδίο πρέπει να ελέγχεται κατά την απώλεια εστίασης, καθώς και κατά την υποβολή της φόρμας. Η άμεση επικύρωση είναι κατάλληλη όταν ο περιορισμός είναι προφανής — για παράδειγμα, το μέγιστο μήκος του πεδίου. Εάν εμφανίζεται σφάλμα μετά από κάθε χαρακτήρα για email, ο χρήστης θα δει το μήνυμα πριν ολοκληρώσει την εισαγωγή. Αυτό εκνευρίζει και μειώνει τη μετατροπή.
Ο κανόνας του πρώτου σφάλματος: κατά την υποβολή της φόρμας, εμφανίστε σφάλμα μόνο για το πρώτο μη έγκυρο πεδίο. Μην φορτώνετε τον χρήστη με λίστα 10 σφαλμάτων. Μετά τη διόρθωση του πρώτου σφάλματος, μπορεί να εμφανιστεί το επόμενο. Αυτή η βήμα-προς-βήμα καθοδήγηση μειώνει το γνωστικό φορτίο και βοηθά τον χρήστη να συμπληρώσει τη φόρμα πιο γρήγορα.
Το Android SDK παρέχει βασικά εργαλεία για Validate: Patterns για email και τηλέφωνο, TextUtils για έλεγχο κενού, κανονικές εκφράσεις για αυθαίρετα μοτίβα. Για έργα με 1-3 πεδία, αυτό είναι αρκετό. Ωστόσο, σε φόρμες με 10+ πεδία, η χειροκίνητη επικύρωση γίνεται δύσκολα συντηρήσιμη — κάθε νέο πεδίο απαιτεί ξεχωριστή συνάρτηση και ενημέρωση της λογικής αποστολής.
Δημοφιλείς βιβλιοθήκες επικύρωσης: Android Saripaar (σχολιασμοί @Email, @NotEmpty, @Password), Commons Validator από Apache (έλεγχος email, URL, αριθμού πιστωτικής κάρτας), RxBinding + RxJava για αντιδραστική επικύρωση. Το Saripaar επιτρέπει την τοποθέτηση σχολιασμών απευθείας στα πεδία εισόδου και την κλήση επικύρωσης με μία γραμμή: validator.validate(). Η βιβλιοθήκη εμφανίζει αυτόματα σφάλματα μέσω setError.
Η Google συνιστά τη χρήση Material Design Components με TextInputLayout. Η ενσωματωμένη επικύρωση μέσω setError, setHelperText και setCounterEnabled καλύπτει βασικά σενάρια χωρίς εξωτερικές βιβλιοθήκες. Για πολύπλοκα έργα (fintech, ιατρική), είναι καλύτερο να χρησιμοποιήσετε συνδυασμό: Material Components + προσαρμοσμένη επικύρωση με μοτίβα από το επίπεδο τομέα της Clean Architecture.
Πρώτο σφάλμα — εμφάνιση σφάλματος πριν από την έναρξη εισαγωγής. Εάν το πεδίο είναι υποχρεωτικό αλλά ο χρήστης δεν έχει αρχίσει ακόμα να το συμπληρώνει, μην εμφανίζετε “Το πεδίο είναι υποχρεωτικό". Αυτό δημιουργεί μια ψευδή αίσθηση προβλήματος. Το σφάλμα πρέπει να εμφανίζεται μόνο αφού ο χρήστης αλληλεπίδρασε με το πεδίο: άρχισε να εισάγει, έφυγε από το πεδίο, προσπάθησε να υποβάλει τη φόρμα.
Δεύτερο σφάλμα — ασαφές μήνυμα σφάλματος. Το μήνυμα πρέπει να είναι συγκεκριμένο και να υποδεικνύει πώς να διορθωθεί το πρόβλημα. “Μη έγκυρο email" — κακό. “Το email πρέπει να περιέχει @ και τομέα, π.χ. user@example.com" — καλό. Ο χρήστης πρέπει να καταλάβει τι ακριβώς είναι λάθος και πώς να το διορθώσει χωρίς να ανατρέξει στην τεκμηρίωση.
Τρίτο σφάλμα — αποκλεισμός αποστολής χωρίς εξήγηση. Εάν το κουμπί αποστολής είναι ανενεργό λόγω σφαλμάτων επικύρωσης, ο χρήστης πρέπει να βλέπει ποια πεδία είναι μη έγκυρα. Ένα γκρι κουμπί χωρίς μηνύματα είναι αδιέξοδο για τον χρήστη. Πάντα να επισημαίνετε τα πεδία με σφάλματα και να εμφανίζετε το κείμενο σφάλματος δίπλα σε κάθε μη έγκυρο πεδίο.
| Σφάλμα | Πρόβλημα | Λύση |
|---|---|---|
| Σφάλμα πριν την εισαγωγή | Τρομάζει τον χρήστη | Έλεγχος μόνο μετά από αλληλεπίδραση |
| Ασαφές μήνυμα | Ο χρήστης δεν καταλαβαίνει την αιτία | Συγκεκριμένη περιγραφή + παράδειγμα |
| Γκρι κουμπί | Καμία ανατροφοδότηση | Επισήμανση σφαλμάτων + μήνυμα |
| Υπερβολική επικύρωση | Πολύ αυστηροί κανόνες | Ισορροπία ασφάλειας και UX |
Συχνές Ερωτήσεις
Βέλτιστη στιγμή — κατά την απώλεια εστίασης του πεδίου (onFocusLost) και κατά την υποβολή της φόρμας. Η άμεση επικύρωση μετά από κάθε χαρακτήρα είναι κατάλληλη μόνο για πεδία με αυστηρούς περιορισμούς: μήκος, αριθμοί, ειδικά σύμβολα. Για email και κωδικό πρόσβασης, είναι καλύτερο να περιμένετε να ολοκληρώσει ο χρήστης την εισαγωγή και να ελέγξετε μετά την έξοδο από το πεδίο.
Χρησιμοποιήστε το Patterns.EMAIL_ADDRESS από το Android SDK. Καλέστε το matcher(εισαγόμενοEmail).matches() — η μέθοδος θα επιστρέψει true εάν το email είναι σωστό. Για πρόσθετο έλεγχο (αποκλεισμός προσωρινών τομέων, έλεγχος εγγραφής MX) απαιτείται επικύρωση διακομιστή. Στην πλευρά του πελάτη, αρκεί να ελέγξετε τη μορφή μέσω του ενσωματωμένου μοτίβου.
Χρησιμοποιήστε μια βιβλιοθήκη επικύρωσης όπως το Saripaar με σχολιασμούς στα πεδία. Αυτό θα συντομεύσει τον κώδικα επικύρωσης 3-5 φορές. Εάν το έργο χρησιμοποιεί Clean Architecture, μεταφέρετε τη λογική επικύρωσης στο επίπεδο τομέα και δοκιμάστε την ξεχωριστά από το UI. Για εμφάνιση σφαλμάτων, χρησιμοποιήστε TextInputLayout με setError.
Υποχρεωτικά. Η επικύρωση από την πλευρά του πελάτη είναι για UX, η επικύρωση από τον διακομιστή είναι για ασφάλεια. Ένας εισβολέας μπορεί να στείλει αίτημα απευθείας στο API, παρακάμπτοντας την εφαρμογή. Ο διακομιστής πρέπει να ελέγχει ξανά όλα τα πεδία. Η επικύρωση από την πλευρά του πελάτη δεν αντικαθιστά την επικύρωση από τον διακομιστή, αλλά την συμπληρώνει για την ευκολία του χρήστη.
Χρησιμοποιήστε το TextInputLayout.setError() από τα Material Design Components. Η μέθοδος εμφανίζει ένα κόκκινο μήνυμα κάτω από το πεδίο και αλλάζει το χρώμα του περιγράμματος. Εναλλακτικά: ένα ξεχωριστό TextView για το σφάλμα δίπλα στο πεδίο. Μην χρησιμοποιείτε Toast ή Snackbar για σφάλματα επικύρωσης μεμονωμένων πεδίων — ο χρήστης δεν θα συσχετίσει το μήνυμα με ένα συγκεκριμένο πεδίο.
Σύνοψη
Θα αναπτύξουμε μια εφαρμογή για κινητά έτοιμη για χρήση
Η IT Sectr δημιουργεί εφαρμογές iOS και Android για νεοφυείς επιχειρήσεις και επιχειρήσεις από το 2017. Θα σας συμβουλεύσουμε και θα προτείνουμε την καλύτερη λύση.
Διαβάστε επίσης