ipadmobile通用webapp框架前哨战

响应式设计的意义

随着移动设备的发展，移动设备以迅猛的势头分刮着PC的占有率，ipad或者android pad的市场占有率稳步提升，所以我们的程序需要在ipad上很好的运行，对于公司来说有以下负担：设备系统上来说主要分为android ios；尺寸上看又以手机与pad为一个分界线，如果再加一个H5站点，其开发所投入资源不可谓不小！

Hybrid的出现，解决了大部分问题，针对尺寸上的问题有一种东西叫做响应式设计，这个响应式设计似乎可以解决我们的问题，所以今天我就来告诉大家什么是响应式设计，或者说我这种外行以为的响应式设计。

响应式Web设计(Responsive Web design)的理念是：集中创建页面的图片排版大小，可以智能地根据用户行为以及使用的设备环境（系统平台、屏幕尺寸、屏幕定向等）进行相对应的布局。

以我粗浅的理解，响应式的提出，其实就是单纯的根据不同的尺寸，以最优的展示方式呈现罢了，仅仅而已，不能再多了，如果真要更多点，便是根据不同的尺寸对静态资源加载上有所控制，节约流量，换句话说，响应式设计不涉及业务逻辑，jser神马都不需要做，css同事便可完全解决，但事实上最近碰到的需求完全不是这么回事嘛。

以最简单图片轮播来说，手机上是这个样子的：

而在ipad横屏上，却变成了这个样子了：

我当时就醉了，iPad竖着保持手机样式，横着iPad样式，什么CSS有这么伟大，可以完成这个功能，而真实的场景是这个样子的：

手机端：首页搜索页->list页面->详情页->预定页

但是到了ipad横屏上：首页左屏是搜索页，右边是日期选择/城市选择/......，然后到了list页面，左边是list，右边是详情页，单击左边的list左边详情直接变化！

其实单独页面做的话，好像没有什么问题，但是手机业务早已铺开了，老板的意思是，代码要重用，还是全局改改CSS实现就好啦，我当时真为我们的UED捏了一把汗。到了具体业务实现的同事那里情况又变了，UED只是给出了两个设计好了的静态html+css，要怎么玩还得那个业务同事自己搞。

那天我去支援时，看到了其牛逼的实现，不由的菊花一紧，里面媒体查询都没有用，直接display: none 搞定一切问题了，这个对手机程序带来了很大的负担：原来一个view就是用于手机，现在无端的在里面加入了大量的pad端程序，直接造成了两个结果：

① 业务逻辑变得复杂，容易出BUG

② js尺寸变大，对手机端来说，流量很宝贵

虽然知道他那种做法不可取，当时忙于其它事情，并且天意难违，天意难测也只有听之任之，但是这里要说一点，响应式布局不太适合业务复杂的webapp，各位要慎重！

ipad版本应该怎么做？

虽然如此，问题还是需要解决，并且需要在框架层做出解决，这类需求本不应强加与CSS，好在曾经我们业务层的View设计基本是满足条件的，现在只需要扩展即可，仍然以blade框架为例：

每个页面片完成的工作仅仅依赖了一个View类，既然View是类，那么继承mobile的View，实现ipad的View，似乎是可能的，这一切的基石便是继承

继承的意义

我们这里的View Controller index.js开始是不完全满足我们的需求的，我们做一些调整，这里是调整前的代码：

调整前的代码

对应HTML模板

调整后的代码如下：

View Code

PS：上面的代码是我几个月前写的，今天一看又觉得可以优化，当真优化无极限啊！！！

变化的关键点是每次我点击的事件全部放到了Index这个类的prototype上：

1 searchItemAction: function (e) {

2 var gindex = $(e.currentTarget).attr('data-group');

3 var index = $(e.currentTarget).attr('data-index');

4 this.forward(this.uidata[gindex].data[index].uiname);

5 },

7 closeSearchAction: function () {

8 this.closeSearch();

9 },

11 demoItemAction: function (item, groupIndex, index, e) {

12 scope.demoItemAction(item, groupIndex, index, e);

13 },

这里粒度到哪个程度与具体业务相关，我这里不做论述，于是我这里继承至index产生一个新的index类：index.ipad.js，这个是其基本实现：

1 define([getViewClass('index'), getViewTemplatePath('index'), 'UIGroupList'], function (View, viewhtml, UIGroupList) {

2 return _.inherit(View, {

4 onCreate: function ($super) {

5 $super();

6 },

8 onPreShow: function ($super) {

9 $super();

10 this.turning();

11 },

13 onShow: function ($super) {

14 $super();

15 this.initGoupList();

16 },

18 onHide: function ($super) {

19 $super();

20 },

22 events: {

24 },

26 searchItemAction: function (e) {

27 var gindex = $(e.currentTarget).attr('data-group');

28 var index = $(e.currentTarget).attr('data-index');

29 this.forward(this.uidata[gindex].data[index].uiname);

30 },

32 demoItemAction: function (item, groupIndex, index, e) {

33 scope.forward(item.uiname);

34 }

36 });

37 });

这个时候直接运行blade/ipad/debug.html#index.ipad的话，页面与原来index保持一致：

第二步便是重写其事件的关键位置了，比如要跳出的两个事件点：

1 searchItemAction: function (e) {

2 var gindex = $(e.currentTarget).attr('data-group');

3 var index = $(e.currentTarget).attr('data-index');

4 this.forward(this.uidata[gindex].data[index].uiname);

5 },

7 demoItemAction: function (item, groupIndex, index, e) {

8 scope.forward(item.uiname);

9 }

11 //简单改变

13 searchItemAction: function (e) {

14 var gindex = $(e.currentTarget).attr('data-group');

15 var index = $(e.currentTarget).attr('data-index');

16 alert(this.uidata[gindex].data[index].uiname);

17 },

19 demoItemAction: function (item, groupIndex, index, e) {

20 alert(item.uiname);

21 }

这个时候原版本的跳转，变成了alert：

这个时候便需要进一步重写了，比如这里：我点击alert，事实上是想在右边加载那个子view，所以框架全局控制器APP需要新增loadSubView的接口了：

新增接口

loadSubView要实现实例化某一View非常简单，但是该接口的工作并不轻松，换句话说会非常复杂，因为：

History与路由归一化是mobile与pad版本整合的难点

mobile的view与ipadview是公用的，所以本身不存在主次关系，是业务给予了其主次，这里需要一个管理关系

子View的实例化会涉及到复杂的History与路由管理，我们这里先绕过去，下个阶段再处理，因为完成pad版本，框架的MVC核心要经过一次重构

1 //这里暂时不处理History逻辑，也不管子View的管理，先单纯实现功能

2 //这样会导致back的错乱，View重复实例化，这里先不予关注

3 loadSubView: function (viewId, wrapper, callback) {

5 //子View要在哪里显示需要处理

6 if (!wrapper[0]) return;

8 this.loadView(viewId, function (View) {

10 var curView = new View(this, viewId, wrapper);

12 //这个是唯一需要改变的

13 curView.turning = $.proxy(function () {

14 curView.show();

15 curView.$el.show();

16 }, this);

17 curView.onPreShow();

18 callback && callback(curView);

20 });

22 },

在样式上再做一点调整就变成这个样子了：

这里History管理还是乱的，但是整个这个方案是可行的，所以我们前哨战是成功的，方案可行的话便需要详细的设计了

结语

今天，我们对ipad与mobile统一使用一套view代码做了研究，有以下收获与问题：

① 继承可实现ipad与mobile代码复用，并且不会彼此污染，至少不会污染mobile程序

② pad版本中History与路由管理需要重构

③ MVC需要重构，特别是View一块，甚至需要完全重新写

④ 样式方面还需要处理优化

总而言之，今天的收获还是有的，剩下的问题，需要在核心框架上动大动作了，最后的目标是能够出一套同用于ipad与mobile的框架。

源码：

https://github.com/yexiaochai/blade

demo在此：

http://yexiaochai.github.io/blade/ipad/debug.html#index.ipad

本文转自叶小钗博客园博客，原文链接：http://www.cnblogs.com/yexiaochai/p/4148235.html，如需转载请自行联系原作者

ipadmobile通用webapp框架前哨战相关推荐

2018开发最快的Webapp框架--BUI交互框架
原文地址: https://segmentfault.com/a/1190000012994082 一.案例代表这是你看下去的动力, 我用BUI仿照QQ的手机截图做出来的一个demo, 包含QQ的常 ...
2018开发最快的Webapp框架--BUI交互框架 1
一.案例代表这是你看下去的动力, 我用BUI仿照QQ的手机截图做出来的一个demo, 包含QQ的常见交互, 侧滑边栏,TAB切换,侧滑列表,下拉刷新,下拉菜单,弹窗搜索等交互操作, 这几种操作很多U ...
python 解决IndentationError: unexpected unindent的报错！和通用代码框架，import requests def getHTMLText(url)...的解释
python报错IndentationError: expected an indented block. 解决办法很简单,是脚本缩进的问题,检查脚本缩进是否有空格和tab混用的情况或者是缩进明显不对 ...
15类Android通用流行框架
15类Android通用流行框架 Android流行框架缓存 DiskLruCache Java实现基于LRU的磁盘缓存图片加载 Android Universal Image Loader 一个 ...
gRPC：Google开源的基于HTTP/2和ProtoBuf的通用RPC框架
gRPC:Google开源的基于HTTP/2和ProtoBuf的通用RPC框架 gRPC:Google开源的基于HTTP/2和ProtoBuf的通用RPC框架 Google Guava官方教程(中文版 ...
基于ASP.Net Core开发的一套通用后台框架
基于ASP.Net Core开发一套通用后台框架写在前面这是本人在学习的过程中搭建学习的框架,如果对你有所帮助那再好不过.如果您有发现错误,请告知我,我会第一时间修改. 知其然,知其所以然,并非重 ...
【开源推荐】AllJoyn：打造全球物联网的通用开源框架
摘要:随着智能设备的发展,物联网逐渐进入了人们的生活.据预测,未来几乎一切东西(超过500亿台设备)都可以互联.高通公司发布了开源项目AllJoyn,这是一个能够使连接设备间进行互操作的通用软件框架和 ...
C语言日志级别和作用,自己写的C语言通用日志框架，可以控制日志输出等级
/************************************c语言通用日志框架************************************ * * @author 南栀(ke ...
tcp/ip 协议栈Linux内核源码分析十邻居子系统分析一概述通用邻居框架
内核版本:3.4.39 为什么需要邻居子系统呢?因为在网络上发送报文的时候除了需要知道目的IP地址还需要知道邻居的L2 mac地址,为什么是邻居的L2地址而不是目的地的L2地址呢,这是因为目的地网络可 ...

ipadmobile通用webapp框架前哨战

ipadmobile通用webapp框架前哨战相关推荐

最新文章

热门文章