通过这个看似简单的例子,使用BUI快速开发出来的应用是可以上得了台面的.在没有设计稿的情况下,我们可以仿照任何一款APP开发,并且按照APP的相同比例完美还原.另外一个是在各种复杂的手势操作交互里面,BUI游刃有余.
请使用手机扫码操作看看.
建议扫码在手机预览,PC预览不支持手势操作.
如果你也跟我一样在寻找一款快速开发的Webapp框架,相信我,你来对地方了.欢迎加入BUI移动开发交流群:691560280满BUI移动开发交流群2:4170980新
我自己从2011年开始接触移动混合app开发至今,开发的应用也有几十个了,这些经验可能对别人也会有所帮助.于是我把它整理出来,围绕着快速开发,BUI做了很多事情,看完你就会明白,BUI的快是有意义的.
我找过很多框架,对框架有一些要求:
...
这样的要求不过分吧但发现每个UI框架都有自己的定位,跟我要的还不太一样,于是我们只能自己造轮子.既然自己造轮子,那就要先做最适合自己的,然后才是适合别人.这里有必要交待一下背景.
早在2011年,品高公司就开始接触移动互联网,并有了第一个基于Cordova的混合app开发框架及打包平台--Bingotouch(那个时候除了Appcan,没有像Dcloud,APICloud等比较成熟的平台),为了配合Bingotouch开发框架,我们需要有一个UI,于是我们有了一个简单的UI,那时只有一些简单的基础控件,简单的适配(可以在打包自适应,但无法在浏览器预览),页面切换传参使用原生的切换,其它复杂点的就用第三方的插件,下拉刷新就用iscroll,投入到项目开发中就没去管UI了,一晃就4年过去了,简直就是奇迹.
但随着混合应用的技术推广及系统的升级,手机屏幕越来越大,我们的UI存在的一些不足,我们意识到,我们的UI必须升级了.经过4年的移动开发项目经验沉淀,于是2015年底我们就开始着手UI的改造.
这里顺便交待一下我们的旧UI存在的问题吧.
旧UI采用viewport固定宽度的方式适应,把设计稿更改成320大小,然后我们按这个大小量取间隙,还原设计稿,这样会导致在浏览器整个页面变大,之前不考虑浏览器,所以问题还不大,但随着viewport在不同手机设备的表现,这种方式瓶颈越来越大,ifelse越来越多.
早期的时候,基于zepto的控件还要适应移动端,是少之又少,所以我们经常需要上网找或者自己写控件,这样就造成每个控件的使用方式不一,兼容不一,较难上手.
正是因为有了这些问题,才让我们的新BUI适应性越来越强.
场景1:客户指定要使用第三方平台打包;
我们的Bingotouch就派不上用场,即使我们很优秀,但是客户不放心,用第三方平台后面可以不依赖于某一家公司,可以很容易找到其他开发者,客户的担心也不无道理.
第三方平台的出现方便了开发者,但也带来了新的难题,一个第三方平台,会有自己的开发生态,工具,API,UI,开发者要学习的东西太多.
这样,客户不管指定哪个平台,都可以使用我们的UI来做开发交互,开发人员都不用再学习新的UI,能减少一点是一点啊.
围绕这个想法去设计,再分析了互联网上的一些UI的特点,我们的框架应该是这样子的:介于webapp跟混合app开发之间,大部分应用有80%以上的功能都是由UI实现的,这样通过学习一次BUI,你就可以游刃于不同平台之间.
在软件公司里面,开发者占多数以及人员的流动等因素,如果开发者愿意去学习使用,可以解决招不到合适的前端问题.所以学习要快,简单.
我们在技术上没有依赖于vue,react等先进理念,我们就是要简单,Dom是最基础也是最容易理解的,所以我们基于zepto或者jquery.
开发者习惯用什么工具,就用什么工具.习惯用什么webpack,gulp,sass,less完全由自己做主.但是如果使用我们推荐的sublimetext工具,我们有针对这个工具的一个插件,可以快速书写,事半功倍.
如图,其它UI的适配的高度是固定的,随着屏幕增高,底部的空白会越来越多,而BUI是整体等比缩放,像一张大图缩放到合适的屏幕一样.真正是一次开发,多平台适配.
前面我们也说过,旧UI我们需要经常找插件,找来的插件也不一定能用,调用系统原生的交互,在安卓跟ios会有不同的表现,为了避免这种情况,我们把互联网上常见的插件都统一开发出来,一致的交互,一致的使用方式,一致的API.
bui.slide是一个焦点图组件,它除了自身支持,横向,纵向,全屏,自动播放等功能以外,我们稍微改变了参数,它就变成了tab组件.
**(这里不能直接上传gif交互图,我把重要的交互展示一下,想看更多交互请直接点击预览交互效果)**
js:varuiSlide=bui.slide({id:"#uiSlide",height:200})html: