Click on the above
The blue words
Focus on
Code an egg

In the spirit of code laziness, the hero enters

The author blog

http://www.jianshu.com/u/5aad180d1ea8

The article directories

  • Basic usage

  • Basic notes

    • @Order:

    • (message = “”):

    • sequence:

    • @ Optional:

    • ValidateTill and validateBefore

    • @ AssertTrue and @ AssertFalse

    • Custom Annotation

  • supplement

Hello everyone, it’s time for another session of project requirements discussion. I think when you’re developing your APP, you’re going to have a lot of EditText interfaces that you’re going to need to fill in, you know, register, you know, change your password. Each of these interfaces will have a number of editTexts. At the same time, each EditText needs to fill in different content, so we make the corresponding judgment for each EditText.

For example, the following interface:

We may need to enter “username”, “address”, “email”, “phone”. And then there might be a “register” button underneath, when we press the “register” button. This is what we probably do on a regular basis:

  • Gets four EditText objects

  • Get their content, from top to bottom, and determine if it’s empty. If it’s empty, we’ll prompt the user to miss something:

  • Once each one is filled in, you may need to have different EditTexts and rules for each one, such as the one above that determines that the user name is not empty. And then our APP says, well, the username can’t be less than 5 and it can’t be more than 10, and then you say,

  • And then you have to go through the email rule, the phone rule, and if you have a “password” EditText, you also have a “confirm password” EditText, so not only do you want the first EditText to comply with the password rule, Then you need to determine whether the contents of the two EditTexts are equal. It’s a hell of a lot of trouble anyway, and the code is basically repetitive in a lot of places, which makes reading very bad.

So programmers follow the principle of being lazy about this code. I went looking for a good tool, and here comes the main character of this article:

* * * * android – saripaar (https://github.com/ragunathjawahar/android-saripaar)

Here we respectively introduce the usage functions of the main characters in this paper:

0

Basic usage:

For example, the user name mentioned above cannot be empty. Let’s see how to use saripaar

  • Above the reference to the EditText we defined, add an annotation for the corresponding function

  • Create the Validator object and set the callback event in the EditText after the content rule is judged:

  • Invoking validation methods under certain conditions (such as pressing the register button) :

Basic usage is above that, may everybody will say, old driver you so?? That’s too few features. Don’t worry, allow the old driver step by step to introduce the relevant details.

1

Basic notes:

For example, there are some:

@notempty: non-empty @length: Length @email: Email @password: Password (6 digits by default) @confirmpassword: ConfirmPassword @checked :CheckBox is selected @length: Length check IpAddress: IP address check

Wait, I’m going to skip the list and just look at the picture

  • @Order:

Generally speaking, there will be several editTexts on the interface, such as name,email and Address input boxes. We will set relevant rules for the three input boxes. At this time, each app has requirements on the judgment order of these input boxes. But some may judge address and so on first. So at sign Order is just going to allow us to sort when we validate several EditTexts.

That’s when you might ask. So you have at sign Order here, so where does the Order go? In the Listener we set up above:

List

Errors = List

Errors = List

Errors


If we have multiple editTexts that don’t match the rule, we’ll sort them in the Order we wrote @Order in List

.

For example, we want EditText to appear when it doesn’t conform to the rule:

We just need to:

Some might say. I want to say “name” if it’s wrong and forget about the rest. Errors.get (0).getView(). Of course this is ok, but Saripaar has already taken it into account for me:


  • (message = “”):

We want different editTexts that don’t conform to the rules to display different editTexts. Remember we had a method called getCollatedErrorMessage(Context) for ValidationError. Yeah, We can set a different message for each EditText and display the corresponding message if validation fails:

  • sequence:

An EditText must not be empty, but it must conform to the mailbox standard. In this case, we also want an validation order, such as whether it is empty or not. If it is empty, an error message will be sent. If it is not empty, then determine whether it conforms to the mailbox rule.

At this point, you’ll notice that the EditText will judge in the order of the rules you specify. But notice here, we said that we get message using

Because above we only added one rule judgment to one EditText, so it doesn’t matter, let’s say I added two here, what happens when we look at it again?

Yes, although the order of the judgment rules is according to our writing, but, you see, the error. The getCollatedErrorMessage (context); The contents of the message retrieved by the method are a collection of all non-conforming messages. But what we want is for non-empty to say that it can’t be empty, and then if it’s not empty, it’s not a mailbox format, and then it says that the mailbox doesn’t fit the mailbox format.

Remember that we’ve covered two methods of ValidationError above, and getFailedRules(). Yes, we can use this, literally, to get a set of failed rules, And the order of the set is the order of the sequence we set. Let’s write it like this:

We just get the Message for the first nonconforming rule. See the effect:


  • @ Optional:

Sometimes we have some information that is Optional, such as an email, so we can leave it blank, but if you fill it in, you have to comply with the email rules, and @optional will do the job:

You don’t have to fill it out, it’s validated, but if you do fill it in, you have to follow the email rules. What is convenient to use? ,

  • ValidateTill and validateBefore

We have called the validation function at the end

It also provides:

Rule checking up to a View and rule checking up to a View.

ValidateTill: For example, there are four views a,b,c and d, and the corresponding order is 1,2,3,4. For example, the current four views do not conform to the rules. And if you call validateTill(c), then our List

errors contains a,b, and c. If you call validateBefore(c), then List

errors contains a and B, i.e., those smaller than the Order of the View passed in are included.

And you’ll notice that all three methods have additional overloaded methods:

When the Boolean value is true, it means that the validation process can be performed in a background AsyncTask.

  • @ AssertTrue and @ AssertFalse

Some of our input fields may not be generic, like email, phone number, etc., for example, an input field that says “the frog must fly” is considered approved if the EditText says this. This is where we add our own rules. You can use @assertTrue to determine if the rules you define are true.

  • Custom Annotation

We can also make our own annotations. For example, I’m writing a @coolboy to see if EditText matches what I wrote:

CoolBoy.java

CoolBoyRule.java

Final step: Add the annotations we just declared in validator.java:

Then use it in our code:


2

supplement

We can also see other declarations in validator.java:

Ha ha, more demo you can also see: * * android – saripaar (https://github.com/ragunathjawahar/android-saripaar), there is a relevant testdemo * *.

Messages have benefits, please see the specific rules

“Help you develop good habits”