1.1，重新规划Android项目结构
- Activity：存放与业务无关的Activity基类
- BaseActivity封装的是业务无关的公用逻辑
- AppBaseActivity封装的是业余相关的公用逻辑
- net：存放的网络底层封装
- cache：存放的是缓存数据和图片的相关处理
- ui：存放的是自定义控件
- utils：存放的是何种与业务无法的公用方法
- activity：我们按照模块继续拆分，将不同模块的activity划分到不同的包下。
- adapter：所有适配器都放到一起
- entity：将所有的实体都放在一起
- db：SQLLite相关逻辑封装
- engine：将业务相关的类都放在一起
- ui：将自定义控件都放在这个包中
- utils：将所有公共方法都放在这里
- interfaces：真正意义上的接口，命名以 I 作为开头
- listener：基于Listener的接口，命名以On作为开头。
1.2，为Activity定义新的生命周期
同时这三个子方法,要声明为 abstract 的,从而要求所有子类必须实现这三个方法：
- initVariables：初始化变量，包括Intent带的数据和Activ-ity内的变量。
- initViews：加载layout布局文件，初始化控件，为控件挂上事件方法。
- loadData：调用MobileAPI获取数据。
1.3 统一事件编程模型
第一种用法：（不推荐）
使用switch…case…语句来对R.id.btnNext中的值进行判断，我不希望R这个在程序中反复出现，这会扰乱面向对象编程的风格，按照我的设想，我们在initViews方法中一次性把所有的控件都初始化了，今后就再也不会使用R.id了。
第二种用法：（推荐）
Button btnLogin=(Button)findViewById(R.id.sign_in_button);
btnLogin.setOnClickListener(
new View.OnClickListener() {
@Override
public void onClick(View v) {
gotoLoginActivity();
}
})；
这是我比较推崇的方式，有以下两个优点：
- 直接在btnLogin这个按钮对象上增加点击事件，是面向对象的写法。
- 将onClick方面的实现，封装成一个gotoLoginActivity方法，如下所示：
private void gotoLoginActivity() {
Intent intent = new Intent(LoginNewActivity.this,
startActivity(intent);
}
这样onClick事件方法就不那么臃肿了。设想当我们在initViews方法中声明了10个按钮对象，并都给它们挂上不同的点击方法，那么initViews方法该有多少行代码呢？我写过上千行的，直接感受就是initViews方法很难维护。但是我们把这些点击方法都分别封装到私有方法中，代码就清晰多了。但是，只要在一个团队内部达成了协议，决定使用某种事件编程方式，所有开发人员就要按照同样的方式编写代码。我认为这是没错的。只要不是各有各的编码风格就好。
1.4 JSON解析
1. 推荐使用FastJson进行实体化编程：
JSON.parseObject(content, T.class);
这里说一件非常狗血的事情，就是在我们使用fastJSON后，App四处起火，主要表现为：
- 加了符号Annotation的实体属性，一使用就崩溃。
- 当有泛型属性时，一使用就崩溃。
在调试的时候没事，可是每次打签名混淆包，就会出现上述问题。我们几个开发人员曾经查到晚上十点半，最后才发现是混淆文件缺了以下两行代码导致的：
-keepattributes Signature // 避免混淆泛型
-keepattributes *Annotation* // 不混淆注解
2， 在页面跳转中使用实体
- intent传递，序列化传递对象（推荐）
- 全局变量（不推荐，容易存在被系统杀死的情况）
1.5 Adapter模板
public class CinemaAdapter extends BaseAdapter {
private final ArrayList<CinemaBean> cinemaList;
private final AppBaseActivity context;
public CinemaAdapter(ArrayList<CinemaBean> cinemaList,
AppBaseActivity context) {
this.cinemaList = cinemaList;
this.context = context;
}
public int getCount() {
return cinemaList.size();
}
public CinemaBean getItem(final int position) {
return cinemaList.get(position);
}
public long getItemId(final int position) {
return position;
}
}
对于每个自定义的Adapter，都要实现以下4个方法：
- getCount()
- getItem()
- getItemId()
- getView()
此外，还要内置一个Holder嵌套类，用于存放ListView中每一行中的控件。ViewHolder的存在，可以避免频繁创建同一个列表项，从而极大地节省内存，如下所示：
class Holder {
TextView tvCinemaName;
TextView tvCinemaId;
}
1.6 类型安全转换函数
public final static int convertToInt(Object value, int defaultValue) {
if (value == null || "".equals(value.toString().trim())) {
return defaultValue;
} try {
return Integer.valueOf(value.toString());
} catch (Exception e) {
try {
return Double.valueOf(value.toString()).intValue();
} catch (Exception e1) {
return defaultValue;
}
}
}
我们将这个方法放到Utils类下面，每当要把一个Object对象转换成整型时，都使用该方法，就不会崩溃了：
int result = Utils.convertToInt(obj, 0);
本章小结
- 本章介绍的内容都是为后面的章节打基础。有了AndroidLib这个业务无关的类库，我们将在接下来的章节中封装更多的公用逻辑，比如第2章介绍的网络底层封装，以及第9章介绍的模块化拆分和插件化编程。实体化编程将极大提升代码可读性，从而进一步提高开发效率。而实体生成器的出现，将是解决重复劳动的一大利器。为Activity定义新的生命周期，把onCreate方法中的几百行代码拆分为3个具有不同功用的子方法，也是提升代码可读性的一个手段。
- 相比后面的章节，本章更多内容是写代码的方法，如果整本书都是这个内容，那就没意思了。接下来的各章，我将详细介绍移动App开发领域的常见问题以及解决问题的思路或方法。
