La biblioteca ahora admite anotaciones, puede validar sus campos con solo agregarlos. Aquí hay un fragmento de código de ejemplo.
@NotEmpty
@Order(1)
private EditText fieldEditText;
@Checked(message = "You must agree to the terms.")
@Order(2)
private CheckBox iAgreeCheckBox;
@Length(min = 3, message = "Enter atleast 3 characters.")
@Pattern(regex = "[A-Za-z]+", message = "Should contain only alphabets")
@Order(3)
private TextView regexTextView;
@Password
@Order(4)
private EditText passwordEditText;
@ConfirmPassword
@Order(5)
private EditText confirmPasswordEditText;
La anotación de la orden es opcional y especifica el orden en que se deben validar los campos. Esto SOLO es necesario si desea conservar el orden de los campos durante la validación. También hay otras anotaciones como @Email
, @IpAddress
, @Isbn
, etc.,
Android estudio/Gradle
compile 'com.mobsandgeeks:android-saripaar:2.0.2'
para descargar la última versión disponible.
Eclipse
Usted puede descargar el tarro de here y añadirlo a su directorio Android libs
.
respuesta Viejo (Saripaar v1)
he escrito una biblioteca para su validación. Aquí está el associated blog y el project. Lo utilicé con éxito en aplicaciones de producción y actualmente satisface la mayoría de los escenarios comunes que enfrentamos en formularios de validación para Android. Hay reglas que vienen de la caja y si necesita escribir la suya, puede hacerlo escribiendo su propia Regla.
Aquí hay un fragmento que ilustra el uso de la biblioteca.
validator.put(nameEditText, Rules.required("Name is required."));
validator.put(nameEditText, Rules.minLength("Name is too short.", 3));
validator.put(emailEditText, Rules.regex("Email id is invalid.", Rules.REGEX_EMAIL, trim));
validator.put(confirmPwdEditText, Rules.eq("Passwords don\'t match.", pwdEditText);
También hay or
y and
reglas que permiten llevar a cabo &&
y ||
operaciones en varias normas. También existe una regla compositeOr
y compositeAnd
que le permite realizar validaciones entre varias Vistas.
Si alguno de ellos parece ser insuficiente, siempre puede escribir su propia regla ampliando la clase Rule.
+1 Gracias por la información. ¿Hay ValidatorListeners disponibles que, p. resaltar los cuadros de entrada de error, etc.? –
Recibirá failView y failedRule en la devolución de llamada onFailure. Si desea resaltar los campos EditText, siempre puede llamar a los métodos setError() o requestFocus(). La regla fallida tendrá un mensaje de error cuando pueda obtener llamando a failedRule.getFailureMessage(). –
¿Está planeando alguna extensión declarativa para eso? (Eso solo se puede aplicar y no necesita codificarlo todas las veces). –