項目需求討論-擺脫EditText內容規則的枯燥判斷

作者：青蛙要fly

鏈接：http://www.jianshu.com/p/e4a5fa7edcde

著作權歸作者所有，經作者授權推送。

大家好，又到了新的一期的項目需求討論。我想大家在開發APP，肯定會有很多需要填入EditText內容的界面，比如註冊界面，修改密碼界面。這些界面都會有很多個相應的EditText。同時每個EditText需要填寫的內容不同，所以就造成我們對於每個EditText進行相應的判斷。

比如下面的界面：

可能我們需要輸入「用戶名」、「地址」、「郵箱」、「電話」。然後下面可能就有一個「註冊」的按鈕，當我們按下「註冊」按鈕的時候。我們可能平時都是這麼做的：

1,獲取了四個EditText的對象

2,獲取他們的內容，從上往下，一個個判斷他是不是為空，如果為空，我們就提示用戶漏填了某個內容：

3,當每個都填了內容後，你可能還要相應的不同的EditText還有相應的規則，比如我們上面已經判斷了用戶名不為空了。然後我們的APP有規定，用戶名的長度不能小於5同時不能大於10，然後你又要寫：

4,然後你還要對相應的EditText去一個個判斷郵箱規則，電話規則，如果還要「密碼」的EditText,一般同事還有一個「確認密碼」的EditText，這時候你不僅要第一個EditText符合密碼規則，然後還要判斷二個EditText的內容是不是相等。反正是麻煩至極，而且代碼基本都是很多地方都是重複，讓閱讀也變得很差。

android-saripaar

這裡我們分別對於本文主角的使用功能來進行介紹：

基本使用方法

比如我們上面講到的用戶名不能為空，我們看下用saripaar是怎麼來使用

1,在我們定義的EditText的引用上方，添加相應功能的註解即可

2,創建Validator對象，並且設置EditText中的內容規則判斷後的回調事件：

3,在某種條件下（比如按下註冊按鈕）調用驗證方法：

基本用法就是上面那樣，可能大家會說，老司機你就這樣？？這個功能也太少了吧。別急，容許老司機一步步來介紹相關詳細內容。

基本的註解：

比如有一些：

：非空

: 長度

: 郵箱

:密碼（默認是6位）

:確認密碼

是否被選中

:長度判斷

:ip地址判斷

我就不列舉了，直接看圖吧

@Order:

我們一般來說界面上會有好幾個，比如,,三個輸入框,我們會對三個輸入框都設置相關的規則，這時候每個app中對於這些輸入框的判斷的順序有所要求，比如先是判斷name，然後依次往下判斷，但有些可能先判斷address等。

所以就是用來讓我們驗證好幾個時來進行排序的。

這時候大家可能就會問了。你這裡設置了，那順序體現在哪裡呢？就在我們上面設置過的中：

我們可以看到，這個失敗的方法裡面的參數是

我們可以看下的源碼裡面有這麼幾個方法：

我們一眼就會發現這個方法就是我們所需要的，沒錯，如果我們有好幾個EditText都不符合規則，在List的順序來進行排序。

比如我們想讓EditText不符合規則的時候出現:

我們只需要：

也許有人會說。我希望錯了的時候就提示name，後面的就不管了。報第一個不符合規則的錯誤，然後有人會說獲取,當然這樣是可以的，但是saripaar已經幫我考慮到了：

我們設置了後，同樣的代碼就變成了：

(message = 「」):

有小夥伴會說，你上面提示的內容的都是不符合規則，我們想要不同的不符合規則後提示不同的內容，還記得我們上面ValidationError有個方法,沒錯，我們可以給每個EditText設置不同的,然後在驗證失敗後，顯示相應的message即可：

sequence:

我們有時候對於一個EditText會有多種要求，比如不僅不能為空，而且同時要符合郵箱的標準，這時候我們對於驗證也希望有驗證順序，比如先判斷是否為空，如果為空，直接就提示錯誤了。如果不為空再判斷是不是符合郵箱的規則。

這時候你會發現這個EditText就會按照你所規定的規則順序來判斷。

但這裡注意了，上面提過我們獲取message是用

因為上面我們一個EditText只添加了一個規則判斷，所以無所謂，比如我這裡添加了二個，我們再看的時候會變成怎麼樣？

沒錯，雖然判斷規則的順序的確是按照我們寫的那樣，但是，你發現了，;方法獲取到的message的內容是全部不符合規則的message的集合。但我們想要的是非空的時候先提示不能為空，然後在不為空的條件下，不是郵箱格式，再提示郵箱不符合郵箱格式。

還記不記得我們已經介紹了上面的二個方法，還有一個方法沒介紹過，沒錯，我們可以用這個，從字面意思我們就可以理解，獲取到失敗的規則的集合，而且這個集合的順序就是我們設置的sequence的順序，我們這麼寫：

我們獲取第一個不符合的規則的Message即可。

看效果：

@Optional：

很多時候我們一些信息是非必填的，比如還是email，我們可以為空，但是如果你填了，那麼一定就要符合郵箱的規則，這時候@Optional就起到作用了：

你可以不填，這時候驗證是通過的，但是如果你填了內容，就一定要符合email規則。使用起來什麼方便。

validateTill 和 validateBefore

我們上面在最後起到驗證功能是調用了

同時它還提供了:

從字面意思我們就知道，到某個View為止的規則檢驗，及某個View前的規則檢驗。

validateTill：比如有a,b,c,d四個View，並且order的順序相對應也是1，2，3，4，

比如當前四個View都不符合規則，並且你調用了,那麼我們的中就包含了a,b,c。如果你調用了validateBefore(c),則就包含了a,b,也就是比傳入的View的Order小的會被包含。

同時你在使用的時候會發現他們三個方法都有另外的重載方法，分別是：

當那個值為的時候，就是說我們可以把驗證的過程放在後台的中去執行。

@AssertTrue 和 @AssertFalse

我們有些輸入框可能不是通用的規則，像郵箱啊，電話號碼什麼的，比如某個輸入框的判斷規則是」青蛙要fly好帥」，當的內容是這個的時候才能認為通過。這時候我們就要添加自己的規則。可以使用來判斷是否符合你定義的規則。

Custom Annotation

當然我們還可以自己制定相關的註解，比如我現在自己寫一個,用來判斷EditText是否符合我寫的相關內容：

最後一步：

在Validator.java中添加我們剛聲明好的註解：

然後在我們的代碼中使用：

補充

我們在validator.java中還可以看到其他的申明等：

哈哈，更多的demo大家也可以看：android-saripaar

裡面有相關的testdemo的使用。歡迎大家吐槽。哈哈，還是老話，哪裡錯了，希望大家能指出。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！