Android中提取表单模型

我一直追求从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