电子商务网站建设 价格,新媒体运营需要具备哪些能力,成都服装网站建设,网站首页风格2019独角兽企业重金招聘Python工程师标准 什么是多状态 Layout 对于大多数 App 而言#xff0c;项目中都有多状态加载 View 这种需求#xff0c;如下图所示。 对应到开发中#xff0c;我们通常会开发一个对应的自定义 layout 用于根据页面不同的状态来显示不同… 2019独角兽企业重金招聘Python工程师标准 什么是多状态 Layout 对于大多数 App 而言项目中都有多状态加载 View 这种需求如下图所示。 对应到开发中我们通常会开发一个对应的自定义 layout 用于根据页面不同的状态来显示不同的提示 view。 在项目中我们大多会在开发初期就把这套 layout 框架写好然后其他人的自己的开发过程中直接使用即可。如下所示 name.gudong.MJMultipleStatusLayoutandroid:layout_widthmatch_parentandroid:layout_heightmatch_parentListViewandroid:idid/lv_activity_centerandroid:layout_widthmatch_parentandroid:layout_heightmatch_parent //name.gudong.MJMultipleStatusLayout这篇文章不讨论如何去实现这样的自定义 loading layoutGithub 上这样的 layout 太多了这里主要思考、总结在实际开发中开发这样的自定义 Layout 时应该注意那些地方。 但是为了说明方便这里还是采用的方案简单叙述一下。 为了后文描述方便这里把这个多状态自定义 Layout 先称为 MultipleStatusLayout。 实现方案 在实现 MultipleStatusLayout 时首先选择继承一个 ViewGroup 作为自己的父类然后默认把内部的第一个子 View 作为 ContentView其它各种情形下对应要显示的 layout view根据不同的加载状态在 MultipleStatusLayout 中通过动态 addView 去控制对应 layout 的加载显示也可以通过 ViewStub 把不同情形的 layout 进行懒加载然后对外提供不同的方法方便外部调用、控制不同状态下的 layout 显示。 嗯简单说来就是这样原理很简单实现起来也没什么技术难度对于一般的开发人员只要一开始明白具体的产品逻辑和实现思路相信花不了多少时间就可以完成这样的 MultipleStatusLayout。具体这种方式的实现可以参看一个开源项目 的实现。 下面着重列举一下开发 MultipleStatusLayout 过程中的注意点或者要点。 Tips 考虑到 MultipleStatusLayout 开发完成后会在项目中的很多页面中应用而且很多时候是作为页面顶级父容器而存在所以开发过程中一定要注意其性能还有稳定性否则一旦出现问题整个项目中应用到该 MultipleStatusLayout 的页面都会随之出现问题。 以下就从性能角度、可维护性、稳定性等方面考虑出发列举一些开发 tip 。 选择最合理的父容器 首先 FrameLayout、RelativeLayout、LinearLayout 都可以作为 MultipleStatusLayout 的父类抛开现在的应用场景不谈都知道 RelativeLayout 在 layout 时需要 measure 两次所以对于一个未来要在很多页面中使用的 Layout 把 RelativeLayout 作为父类这个方案首先 pass 掉。 但是因为 MultipleStatusLayout 中显示的 view 大都需要居中显示所以使用 RelativeLayout 相对比较容易控制居中位置这可能是很多人选择 RelativeLayout 作为父类的初衷。这里自己可以做一下权衡。 关于 LinearLayout 和 FrameLayout如果按照上一节提到的实现方案其实都可以采用不过考虑到该类 Layout 的应用场景建议选择 FrameLayout。 因为MultipleStatusLayout 未来在大多数情况下是作为页面父容器存在的既然是父容器内容可能会有各种变化这时使用 LinearLayout 这种线性布局就会在布局时显得特别局限比如一些页面可能需要在 MultipleStatusLayout 之上显示一个 FloatActionButton 或者其他的 view这时使用 FrameLayout 就会好做很多也会灵活很多。 选择最优的加载 View 方式 如何控制这些多状态对应的 View ? 对于一般的情形至少有两种 View 类型一种是加载中的 loading 样式 view一种是异常状态的 layout view当然还可能有更多具体的情形。 不同的样式对应一个不同的布局为了简便我们可以一次性的把所有状态对应的布局都写在一个 layout 布局里然后可以通过控制隐藏、显示来根据不同的状态来展示不同 view这是最直接的想法。 但是只要多思考一步就会发现这种方式非常不可取。因为很多时候MultipleStatusLayout 作为一个父容器只关心自己的 ContentView异常页面和加载页面甚至可能没有机会出现但是现在这样做就表示这个页面不论有没有异常或者加载逻辑你的布局里都会存在对应的 layout 布局代码。这样在界面绘制时就会白白耗掉多余的时间。 而且这个 Layout 后续会在项目很多页面用到所以这里的布局耗时问题放大后就显得很严重。 鉴于此取而代之的更好的做法应该是动态去 addView只有这个页面第一次调用 loading 或者 showError 这样的方法我才去把对应布局加载进来当然这里使用 ViewStub 也是一样的效果。 这里也就是说只有调用了相应的方法才去加载对应的 layout. 资源命名 其实这个问题是自己开发公用 Api 普遍面临的问题由于开发 MultipleStatusLayout 可能会定义一些颜色资源或者背景资源这里建议所有资源开头使用一个固定的开头这样可以防止跟主版本中的资源重名。进而早成一些奇怪的 UI 问题或者编译问题。比如按钮的背景你可以定义为 msl_btn_normal 而不是 btn_normal文字的颜色你可以定义为 msl_text_white 而不是 text_white。这样就可以有效避免一些资源冲突。 更多关于如何开发一个第三方库可以查看天之界线的开发第三方库最佳实践 提供友好的方法调用方式 既然是提供给大家使用你就应该在方法命名上多花点心思最好见名之意这样大家调用时也会舒服很多。 另外对外提供 Api 时也应该保持克制。不要一下子提供出去太多的方法不论有用没用一下子都对外提供这样会对后续的维护造成隐形的负担因为提供的公用方法越多表示你后续都要对这些方法进行维护。 最好的原则就是用到什么提供什么不要提前设计。 另外随着项目迭代对外提供方法的参数可能会变得多起来比如以前显示错误页面的方法是 void showErrorView(Stirng error) 后来要增加自定义的 icon 或者点击事件响应这时你就需要扩展方法参数往往这种参数可能会变得很多不可收拾这时建议使用 Build 构建模式设计如下示例所示 showErrorView(StatusViewConfig config) 调用时就可以这样调用 showErrorView(new StatusViewConfig.StatusViewBuild(getContext()).icon(icon).message(message).subMessage(subMessage).layoutMode(mLayoutMode).withActionText(actionText, clickListener).build())良好的文档 当你开发完成后最好趁热写一份简单明了的使用文档出来这样大家就可以直接对照文档使用你写的库不用去关心代码实现直接调用 Api 就可以完成自己的业务需求同时也省的自己去面对面跟别人讲怎么使用了。 前段时间在 V 站上看到一个问题说你们公司使用什么样的文档管理工具其中有一个回答言简意赅很有意思四个字 口口相传。 其实对于任何一个项目都是有时间写点文档梳理自己思路的同时方便别人何乐而不为。 其他 这种 Layout 在项目中会随着项目的更新迭代而不断的更新所以一开始你就应该知道后续还要不断迭代更新所以代码设计实现时应该留意扩展性。 另外相关的开源方案有很多建议一开始可以参考一些好的方案然后结合自己项目的实际需求来开发维护属于自己项目的一套框架。因为多状态 loading 加载提示框架大都和产品设计强相关不具备一般的通用性。 下面列举一些自己收集到的多状态加载开源方案方便对比。 开源方案 StatefulLayout progress-activity StateLayout MultipleStatusView 总结 同样功能的 Layout 可能在不同的业务场景下实现方式也会有很大的区别所以不论哪种实现方式无所谓好坏只要适合就好。但是开发此类 Layout 要遵循的基本准则、以及要注意的点应该大都相同希望此文可以给你一些启示帮助。 转载于:https://my.oschina.net/bv10000/blog/891258
