移动App架构经验总结( 二 ) _App架构

让用户手动再登录一下？这用户体验不太好啊。正确的姿势应该是注冊成功后再自己主动调用一次登录接口，假设由于网络问题第一次登录失败，后面还须要再自己主动调用多一次，假设还是调用失败，才让用户手动登录。
上面的样例中，对參数的有效性检查，注冊成功后的自己主动登录，都属于业务逻辑的处理，也就是说都是业务层的工作。
业务层交付给展示层的数据也是通过接口的方式。只是，和数据层交付给业务层时不同的是：交付给展示层的数据应该是通过异步回调返回的。
由于获取数据是一个比較耗时的任务。通过异步回调才不会堵塞UI主线程。

展示层

展示层作为数据展示者，它仅仅要关心数据怎样展示就能够了。只是。数据怎样展示却不是那么简单。展示层是三层架构中最复杂的一层了。要考虑的东西远远多于其它两层。涉及的东西包含但不限于界面布局、屏幕适配、图片资源、文本资源、颜色资源等等。在开发一段时间后。展示层出现代码混乱是最常见的。
因此。做好展示层。就须要保持高质量的代码。要保持高质量代码。我认为至少应该遵循几条主要的原则：

保持规范性：定义好开发规范，包含书写规范、命名规范、凝视规范等。并依照规范严格运行；
保持单一性：布局就仅仅做布局，内容就仅仅做内容。各自分离好，每一个方法、每一个类，也仅仅做一件事情；
保持简洁性：保持代码和结构的简洁。每一个方法，每一个类，每一个包，每一个文件，都不要塞太多代码或资源，感觉多了就应该拆分。

所谓无规矩不成方圆，展示层的设计。要从开发规范開始。
一份好的开发规范。是保证代码有较高的可读性的基础。
IOS方面，苹果已经有一套Coding Guidelines，主要属于命名方面的规范。
当我们制定自己的开发规范时，首先就要遵守苹果的这份规范。在此基础上再加上自己的规范。
Android方面，我也在我的博客中分享过一套（Android技术积累:开发规范），主要分为书写规范、命名规范、凝视规范三部分。
最重要的不是开发规范的制定。而是开发规范的运行。假设没有依照开发规范去运行，那开发规范就等于形同虚设，那代码混乱的问题依旧得不到解决。
说到单一性。面向对象设计中。有一个基本原则就是单一职责原则。它规定一个类应该仅仅有一个发生变化的原因。保持单一性是减低耦合度的关键标准。其目的就是各方面的解耦。而我这里说的单一性不仅仅是规定类的单一。也包含界面的单一、方法的单一、资源文件的单一等。
界面的单一，首先是界面的布局和界面的数据应该分离。另外。界面数据的获取和展示也应该分离。一句话，保持界面的单一性就是要保持界面上每一个维度都做好分离，从界面的布局。到数据的获取，数据的检查，数据的展示。
方法的单一。则表现为一个方法是对一个行为的封装。行为又能够拆分为多个步骤，每一个步骤事实上也是更细化的行为。因此。方法嵌套方法是一种常态。那么，保持方法的单一性，关键不在于怎么定义这种方法的行为，而在于这个行为要怎么拆分成更细的行为。举个样例。通常在Activity的onCreate方法，做初始化操作。细分出来就分为了：控件的初始化、逻辑变量的初始化、数据的初始化。
数据的初始化又能够再细分：数据的获取、数据的展示。每一个细化的行为都应该封装为一个独立的方法。这样，才真正符合方法的单一性。
资源文件的单一，主要是指Android的各类资源文件，包含存放字符串的strings.xml 。存放字符串数组的arrays.xml 。存放颜色值的colors.xml 。存放尺寸值的dimens.xml，等等。
资源文件的单一，是说全部相关的资源信息要在资源文件中定义并引用到代码或布局文件中。而不是在代码或布局文件中直接定义。这样做。能够非常方便地做各种适配和改动，比方支持国际化，比方不同分辨率的屏幕用不同尺寸值。iOS则没有提供和Android一样的资源文件分离的机制。但能够參考Android的做法自己去实现。

【移动App架构经验总结】