我一直追求從Android活動中分離代碼。在最近的一個項目中，我成功的實現了傳統的”Form Model”模式，想在此分享我的感想。

“Form Model”的基本思想是，把處理UI交互以及數據綁定和狀態保持的代碼提取到單獨的類中。這種分離非常自然，并且讓我們的Activity變得簡單。

我認為在Android中這個領域不太被關注——在大多數的開發文檔中數據錄入和表單不是重點。在很多流行的社交應用程序中，大多數的畫面只是顯示信息；可能也有幾個畫面用于發微博或者消息，但不是應用的痛點。

對我來說，上兩個Android應用有特別多的數據錄入工作。部分原因是因為所處的領域（醫療、金融）和客戶（更貼近于企業應用而不是創業）。但我 們經常把“表單輸入”界面搞得一片混亂——特別是當開始添加東西的時候，比如編輯現有的條目，提示丟棄未保存的更改，以及處理旋轉而不會清除所有字段值。

使用這種表單模型方案會減少bug，讓代碼更容易理解，開發者也會變得更快樂。

搜索表單示例

我們有一個銀行應用程序，希望有一個畫面來搜索交易數據。有多個過濾條件：開始是一個金額下拉列表，一個關鍵字字段和一個金額范圍。（希望你可以想象在未來將會增加更多的這類過濾器，復雜性會激增）。

我們沒有把所有的視圖、單擊處理程序，驗證邏輯和數據綁定的代碼堆到一個Activity中，而是要創建一個 SearchForm類來處理這一切。

public class SearchForm extends LinearLayout { 
  
  @InjectView(R.id.account) 
  private Spinner mAccountSpinner; 
  private AccountAdapter mAccountAdapter; 
  
  @InjectView(R.id.keyword) 
  private EditText mKeywordField; 
  
  @InjectView(R.id.min_amount) 
  private CurrencyEditText mMinAmountField; 
  
  @InjectView(R.id.max_amount) 
  private CurrencyEditText mMaxAmountField; 
  
  public SearchFormModel(Context context, AttributeSet attrs) { 
    super(context, attrs); 
    setup(context); 
  } 
  
  private void setup(Context context) { 
    LayoutInflater.from(context).inflate(R.layout.search_form, this, true); 
  
    ButterKnife.inject(this); // <3 @JakeWharton 
  
    mAccountAdapter = new AccountAdapter(context); 
    mAccountSpinner.setAdapter(mAccountAdapter); 
  } 
  
  public initialize(List<Account> accounts) { 
    mAccountAdapter.setItems(accounts); 
  } 
  
  public String getKeywords() { 
    return mKeywordField.getText().toString(); 
  } 
  
  public void setKeywords(String keywords) { 
    mKeywordField.setText(keywords); 
  } 
  
  public MoneyAmount getMinimumAmount() { 
    return mMinAmountField.getAmount(); 
  } 
  
  public void setMinimumAmount(double amount) { 
    mMinmountField.setAmountFromDouble(amount); 
  } 
  
  public MoneyAmount getMaximumAmount() { 
    return mMaxAmountField.getAmount(); 
  } 
  
  public void setMaximumAmount(double amount) { 
    mMaxAmountField.setAmountFromDouble(amount); 
  } 
  
  public Account getSelectedAccount() { 
    return mAccountSpinner.getSelectedItem(); 
  }  
  
  public boolean validate() { 
    clearErrors(); 
    boolean isValid = true; 
  
    if (!isValidAmountRange()) { 
      isValid = false; 
      mMinAmountField.setError("Invalid range"); 
      mMaxAmountField.setError("Invalid range"); 
    } 
  
    return isValid; 
  } 
  
  private boolean isValidAmountRange() { 
    return getMinimumAmount() <= getMaximumAmount(); 
  } 
  
  private void clearErrors() { 
    mMinAmountField.setError(null); 
    mMaxAmountField.setError(null); 
  } 
  
  public SearchParameters buildParameters() { 
    return new SearchParameters(getSelectedAccount(), 
                                getKeywords(), 
                                getMinimumAmount(), 
                                getMaximumAmount()); 
  } 
  
  public void persist(Bundle outState) { 
    outState.putInt("SELECTED_ACCT_INDEX", mAccountSpinner.getSelectedItemPosition()); 
  } 
  
  public void restore(Bundle bundle) { 
    int accountPosition = bundle.getInt("SELECTED_ACCT_INDEX"); 
    mAccountSpinner.setSelection(accountPosition, false); 
  } 
} 

 #p#

我們創建了一個類，繼承自LinearLayout（或者FrameLayout，由你的喜好決定）。它允許把相關的控件組織到一個布局中，我們將填充布局，設置列表視圖并為金額列表創建一個適配器。

我們把Android控件封裝到getter和setter方法中​——這可能會有些爭議，但我認為它使SearchForm擁有更好的公共API。我們有一個方法來驗證用戶的輸入，并根據需要提供錯誤信息。 buildParameters()方法做了一些數據綁定工作并返回業務對象。結尾的兩個方法使用了Android onSaveInstanceState中的Bundle，以處理自定義配置的更改（注意，大多數的原始UI控件會自行處理持久化）。

這是個一百行左右的代碼，大部分還不錯。這個類中所有內容似乎都屬于“搜索表單”對象，對未來的特性有良好的功能擴展點（日期范圍過濾器、支出與存款過濾器、只用支票等）。我們有意避免處理如何獲取數據，把它留給了其他更適合的地方處理這些邏輯代碼。

活動中的代碼是什么樣的呢？

public class TransactionSearchActivity extends BaseActivity { 
  
  @InjectView(R.id.search_form) 
  private SearchForm mForm; 
  
  @Override 
  public void onCreate(Bundle savedInstanceState) { 
    super.onCreate(savedInstanceState); 
  
    setContentView(R.layout.transaction_search); 
    setTitle("Search Your Transactions"); 
  
    mForm.initialize(mAccounts); // fetch accounts via API/DB/etc 
  
    if (savedInstanceState != null) { 
      mForm.restore(savedInstanceState); 
    } 
  } 
  
  @Override 
  public boolean onOptionsItemSelected(MenuItem menu) { 
    switch (menu.getItemId()) { 
      case R.id.action_submit_search: 
        onSubmitSearch(); 
        return true; 
    } 
  
    return super.onOptionsItemSelected(menu) 
  } 
  
  private void onSubmitSearch() { 
    if (mForm.validate()) { 
      // Do your magic, post to an API/DB/etc 
      // You have access to the domain object with mForm.buildParameters() 
    } 
  } 
  
  @Override 
  public boolean onCreateOptionsMenu(Menu menu) { 
    getMenuInflater().inflate(R.menu.search_menu, menu); 
    return super.onCreateOptionsMenu(menu); 
  } 
  
  @Override 
  protected void onSaveInstanceState(Bundle outState) { 
    super.onSaveInstanceState(outState); 
  
    mForm.persist(outState); 
  } 
} 

我們的Activity在XML布局文件中包含了一個 **標簽，并且只處理高層面的用戶交互（點擊動作欄中的提交按鈕），并協調獲取和存儲數據。繁重的UI控制和表單邏輯都委托給了 **SearchForm。

Activity的代碼在50行左右——其中大部分是處理框架中生命周期和菜單創建的樣板代碼。

總體印象

一旦涉及到API或數據庫，事情總是會變得更復雜。但總體來講，通過把表單特定的邏輯和視圖相關內容移出活動，代碼變得更容易理解。

我可以為 SearchForm編寫大量的Robolectric測試代碼而且不會帶來與活動生命周期有關的問題。我可以為表單的交互、動作欄、后端編寫測試代碼而不用考慮邊界。當為表單添加新過濾條件時，可以避免對活動做任何的更改（類似于設計模式中的開/閉原則）。

對比其他框架（從其他開發人員的角度來說），Android中數據綁定功能很弱。這種設計似乎還差點什么，因為和Android的類耦合的過于緊 密，依賴于方法的調用順序（initialize()方法應在validate()方法之前調用）——盡管如此，但我認為對于“所有內容混在一起的 Activity”來說是一種改進。

隨著表單模型越來越復雜，你可能要考慮把驗證邏輯提取到一個單獨的對象中，并且把自定義視圖功能移動到自己的控件中（就像我們例子中的 CurrencyEditText）。此外，為了更好的為用戶服務，也可以考慮把復雜的表單拆分成為多步驟向導。

我們發現這種模式可以成功的清理亂糟糟的表單代碼，建議嘗試一下。我把代碼模式稍微規范了一下，并創建了一個小的基類，以減少樣板代碼，可以隨意的使用。

譯文鏈接：http://blog.jobbole.com/73195/

原文鏈接：mdswanson

本文鏈接：http://blog.jobbole.com/73195/

翻譯： 伯樂在線 - lum