关于代码手写UI,xib和StoryBoard
代码手写UI
这种方法经常被学院派的极客或者依赖多人合作的大型项目大规模使用。Geek们喜欢用代码构建UI,是因为代码是键盘敲出来的,这样可以做到不开IB,手不离开键盘就完成工作,可以专注于编码环境,看起来很cool很高效,而且不到运行时大家都不知道会是什么样子,也显出了程序员这一职业的高大上及神秘气息(这个真的不是在黑..想想大家一起在设计师背后指点江山的场景吧)。大型多人合作项目使用代码构建UI,主要是看中纯代码在版本管理时的优势,检查追踪改动以及进行代码合并相对容易一些。
另外,代码UI可以说具有最好的代码重用性。如果你的目的是写一些可以高度重用的控件提供给其他开发者使用,那毫无疑问最好的选择应该是使用代码来完成UIView的子类。这样进一步的修改和其他开发者在使用时,都会方便不少。使用代码也是最为强大的,会有xib或者StoryBoard做不了的事情,但是使用代码最终一定能够完成所要的需求。
但是代码手写UI的劣势同时也是最明显的,主要就是一个字:慢。首先相比可视化的IB来说,完成一个并不太复杂的界面,你可能需要写上数百行的UI代码。不论是初始化一个Label,还是设定一个frame或者添加一个target-action,都需要写代码,这不仅在前期极为浪费时间,在之后维护时代码定位和寻找也会很痛苦。其次,因为你无法直观地看到你能得到的结果,所以你很可能需要不断地Cmd+R
/Cmd+.
来修改各个视图的位置大小。即使你用上了Reveal或者RestartLessOften之类的工具,也还是无法特别方便地完成需要的布局。另外加上如果需要利用AutoLayout来进行尺寸适配的话,使用代码进行约束就更加头疼了。很多时候一个无法满足的约束的问题就够来回运行修改调试很长时间了。
Xibs
相对于代码,使用IB和xib文件来组织UI,可以省下大量代码和时间,从而得到更快的开发速度。如果你曾经受到过微软家Visual Basic或者其他Visual系的可视化界面的荼毒与残害,因此怀疑Interface Builder的纯正血统和工作能力,建议可以看看这些资料以纠正三观:Jean-Marie Hullot的Interface Builder神话以及西装革履的青涩乔帮主在NeXT时亲手用IB构建应用(需要翻墙)。另外,不妨打开你的Mac上的Application文件夹中或者iPhone上Apple家的各种应用。你会惊奇地发现,IB远比你看到的要强大:小至计算器取色器这类小工具,大至iWork三件套,Aperture或Final Cut这样的专业级应用,无一不是使用IB来完成UI制作的。
其实IB和xib是从iOS SDK初次面世开始就是捆绑在开发者工具套装内的内容了,而到了Xcode 4之后更被直接集成到了Xcode中成为了IDE的一部分。xib设计的一大目的其实是为了良好的MVC:一般来说,单个的xib文件对应一个ViewController,而对于一些自定义的view,往往也会使用单个xib并从main bundle进行加载的方式来载入。IB帮助完成view的创建,布局和与file owner的关系映射等一些列工作。对于初学者来说,牢记xib的文件都是view的内容,有助于建立起较好的MVC的概念,从而在开发中避免或少走弯路。
xib文件之前一大被诟病的问题是文件内容过于复杂,可读性很差,即使只是简单打开没有编辑也有可能造成变化而导致合并和提交的苦难。在Xcode 5中Apple大幅简化了xib文件的格式,使其变得易读易维护。可以说现在对于xib文件在版本管理上其实和纯代码已经没有太大差异,只要仔细看过一遍xib的文件内容,自然能理解绝大部分,并很好地追踪并查找过往的修改记录了。
当然xib也不是完美的。最大的问题在于xib中的设置往往并非最终设置,在代码中你将有机会覆盖你在xib文件中进行的UI设计。在不同的地方对同一个属性进行设置,这在之后的维护中将会是噩梦般的存在。因为其实IB还是有所局限的,它没有逻辑判断,也很难在运行时进行配置,而反之使用代码确是无所不能的。在使用xib时,辅以部分代码来补充和完成功能几乎是不可避免的。关于这点在开发时应该予以高度重视,如果选择xib,那么要尽量将xib的工作和代码的工作隔离开来:能够使用xib完成的内容就统一使用xib来做,而不要说三个Label其中两个在xib设置了字体而另一个却在代码中完成。尽量仅保持必要的、较少的IBOutlet和IBAction会是一个好方法。
StoryBoard
iOS5之后Apple提供了一种全新的方式来制作UI,那就是StoryBoard。简单理解来说,可以把StoryBoard看做是一组viewController对应的xib,以及它们之间的转换方式的集合。在StoryBoard中不仅可以看到每个ViewController的布局样式,也可以明确地知道各个ViewController之间的转换关系。相对于单个的xib,其代码需求更少,也由于集合了各个xib,使得对于界面的理解和修改的速度也得到了更大提升。减少代码量就是减少bug量,这也是程序开发中的真理之一。
在Xcode5之后,StoryBoard已经成为新建项目的默认配置,这也代表了Apple对开发者的建议和未来的方向。WWDC2013的各个Sample Code中也基本都使用了StoryBoard来进行演示。可以预见到,之后Apple必定会在这方面进行继续强化,而反之纯代码或者单个xib的方式很可能不会再得到增强。
如果不考虑iOS版本的支持(其实说实话现在已经很少还见到要从iOS4开始支持的app了吧),现在StoryBoard面临的最大问题就是多人协作。因为所有的UI都定义在一个文件中,因此很多开发者个人或企业的技术负责人认为StoryBoard是无法进行协作开发的,其实这更多的是一种对StoryBoard的陌生所造成的误解。虽然Apple并没有在WWDC明确提及,但是没有人规定整个项目只能有一个StoryBoard文件。一种可行的做法是将项目的不同部分分解成若干个StoryBoard,并安排开发人员对自己的部分进行负责。简单举例比如一个有4个tab功能相互独立的基于UITabBarViewController的应用,完全可以使用4个StoryBoard来分别代表4个tab,并在相互无干扰的情况下完成开发。这样一来就不会存在所谓的冲突问题了。StoryBoard的API是如此简单,现在的SDK中一共方法数量一只手就能数过来,所以具体方法在这里就不再罗嗦了。
StoryBoard的另外的挑战来源于ViewController的重用和自定义的view的处理。对于前者,在正确封装接口以及良好设计的基础上,其实StoryBoard的VC重用与代码的VC重用是没有本质区别的,在StoryBoard中添加封装良好需要重用的Scene即可解决。而对于后者,因为StoryBoard中已经不允许有单个view的存在,因此很多时候我们还是需要借助于单个的xib来自定义UI。这一点可以说是由于StoryBoard的设计思路所造成的,StoryBoard更强调的是一种层次结构,是在全局的视角上来组织UI设计和迁移。而对于单个的view,更多的会注重于重用和定制,而与整个项目的流程没有太大关系。相信抓住这一要点,就能很好地了解什么时候使用xib,什么时候使用StoryBoard。
关于StoryBoard最后要说的是,现在会有一些对于StoryBoard性能上的担忧。因为相对于单个xib来说,StoryBoard文件往往更大,加载速度也相应变慢。但是其实随着现在设备的更新换代,在iPhone4都难觅的今天,这点性能上的差距几乎可以忽略了。而再之后的设备,不论读取还是解析,只会越来越快。所以性能上的问题完全是没有担心的必要的。
我的观点和选择
我入门的时候是使用xib的,因为那时候还没有StoryBoard,而我也不是喜欢代码的学院派Geek。到现在,三种方式我都有尝试过,并分别得到了一些可能还并不是特别深刻体会。对于现在的我来说,xib是我的奶酪,也是我在自己的一些项目里一直使用的方式,我可以在极短短时间内用xib架起一套包括自定义要素和良好部件重用性复杂UI。但是在我尝试了几次使用StoryBoard制作demo之后,我已经决定在之后的项目转向使用StoryBoard。一方面因为确实是未来方向(每次新工程删StoryBoard很讨厌..),现在的StoryBoard专有的preview功能,以及之后AutoLayout的进一步改进等都很值得期待;另一方面也觉得奶酪放一个地方太久了会不好,趁着iOS7的大变革,也更新一下自己的观念和方式,把奶酪换个地方摆摆,也许会对以后大有裨益。
对于初心者来说,我并不建议上手就直接使用代码来进行UI制作和布局,因为冗长的UI代码确实非常乏味无趣。尽快看到成品,至少尽快看到原型,是保持兴趣,继续深入和从事职业的有效动力。所以如果有可能有条件,在老鸟的指导下选择StoryBoard来进行快速构建(或者如果是单个人开发的话,可以不用考虑多个StoryBoard协作,就更容易),会是入门的好选择。而最新的教程和文档已经开始逐渐偏向StoryBoard,关于StoryBoard的问题在SO上关注度也会更高,这样在入门时会有更多的资料可以进行参考。
这并不是说不需要关心代码UI或者xib,因为使用StoryBoard的时候在只能使用代码以及自定义单个view时,还是不可避免地需要接触它们的。这里想给的一点建议就是,虽然你不依赖代码来进行UI制作,但是了解并掌握如何使用纯代码来从头构建UI还是非常必要的:包括从新建Window开始,到初始化ViewController,添加必要的view,设定它们的property,以及添加和处理它们的各种响应及responser链等内容。现在iOS开发入门非常容易,Xcode和xib/StoryBoard帮助开发者隐藏了太多的细节,但是很多时候如果你不明白underhood到底是些什么,为什么这些xib/StoryBoard会这样运作的话,经常会出现卡在一些很可笑的和初级的bug上找不着北,这其实会是对时间的巨大浪费,很不值得。
一些IB小技巧
最后分享一些IB使用上的小技巧作为结束吧。其中很多方法也可以用在StoryBoard上,所以在向我自己之前xib使用者生涯致敬的同时,也算是一点小的备忘总结吧。
同时添加多个outlet
在IB中,选中一个view并右键点击,将会出现灰色的HUD,可以在其上方便地拖拉或设定事件和outlet。你可以同时打开多个这样的面板来一次性添加所有outlet。右键点击面板,随便拖动一下面板,然后再打开另一个。你会发现前一个面板也留下来了,这样你就可以方便地进行拖拽设定了。
当然,对于成组和行为类似的IBOutlet,应该直接使用IBOutletCollection来进行处理会更方便。
可视化坐标距离
IB最烦人的问题就是对其。用代码的时候我们可以明确地指定x,y坐标,但是换到IB的时候我们更多的时候是靠拖拽UIView来布局。比如需要三个间隔相同的label,除了用强大的肉眼来估测距离是否相等以外,难道只能乖乖分别选中三个label,记下它们的坐标然后打开计算器来做加减法么?
显然不要那么笨,试试看选中一个label,然后按住option键并将鼠标移动到其他label上试试?你可以发现view之间的距离都以很容易理解的方式显示出来了。不仅是同层次的view,被选中view与其他层次的view之间的距离关系也可以同样显示。
在一组view层次中进行选择
对于一些复杂的view层级关系,我们往往直接在IB中选择会比较困难。比如view相互覆盖时,我们很难甚至不能在编辑视图中选中底层的view。这时候一般的做法是打开左侧的view层级面板,一层层展开然后选择自己需要的view。其实我们也有更简单的方法:按住Cmd
和Shift
,然后在需要选择的view上方按右键,就可以列出在点击位置上所有的view的列表。藉此就可以方便快速地选中想要的view了。
添加辅助线
这么高大上的技巧必须放在最后啊...在左边的层级列表中双击某个view,然后Cmd+_
或者Cmd+|
即可在选中的view上添加一条水平或者垂直中心的辅助线。当然这个辅助线是可以随意移动的。如果干过设计的同学肯定明白这个的意义了,在之后的对其和设计变更的时候都有重要的参考价值。
关于代码手写UI,xib和StoryBoard的更多相关文章
- 【Xamarin挖墙脚系列:代码手写UI,xib和StoryBoard间的博弈,以及Interface Builder的一些小技巧(转)】
正愁如何选择构建项目中的视图呢,现在官方推荐画板 Storybord...但是好像 xib貌似更胜一筹.以前的老棒子总喜欢装吊,用代码写....用代码堆一个HTML页面不知道你们尝试过没有.等页面做出 ...
- 代码手写UI,xib和StoryBoard间的博弈,以及Interface Builder的一些小技巧
近期接触了几个刚入门的iOS学习者,他们之中存在一个普遍和困惑和疑问.就是应该怎样制作UI界面.iOS应用是非常重视用户体验的,能够说绝大多数的应用成功与否与交互设计以及UI是否美丽易用有着非常大的关 ...
- 几道JS代码手写面试题
几道JS代码手写面试题 (1) 高阶段函数实现AOP(面向切面编程) Function.prototype.before = function (beforefn) { let ...
- JAVA集合类(代码手写实现,全面梳理)
参考网址:https://blog.csdn.net/weixin_41231928/article/details/103413167 目录 一.集合类关系图 二.Iterator 三.ListIt ...
- 小游戏:200行python代码手写2048
#-*- coding: utf-8 -*- import curses from random import randrange, choice from collections import de ...
- 如果选择构建ui界面方式,手写代码,xib和StoryBoard间的博弈
代码手写UI这种方法经常被学院派的极客或者依赖多人合作的大型项目大规模使用. 大型多人合作项目使用代码构建UI,主要是看中纯代码在版本管理时的优势,检查追踪改动以及进行代码合并相对容易一些. 另外,代 ...
- 手写代码UI,xib和StoryBoard间的的优劣比较
在UI制作方面,逐渐分化三种主要流派:使用代码手写UI:使用单个xib文件组织viewController或者view:使用StoryBoard来通过单个或很少的几个文件构建UI.三种方式各有优劣,也 ...
- UI到底应该用xib/storyboard完成,还是用手写代码来完成?
UI到底应该用xib/storyboard完成,还是用手写代码来完成? 文章来源:http://blog.csdn.net/libaineu2004/article/details/45488665 ...
- IOS开发中UI编写方式——code vs. xib vs.StoryBoard
最近接触了几个刚入门的iOS学习者,他们之中存在一个普遍和困惑和疑问,就是应该如何制作UI界面.iOS应用是非常重视用户体验的,可以说绝大多数的应用成功与否与交互设计以及UI是否漂亮易用有着非常大的关 ...
随机推荐
- MySQL_DML操作
DML(Data Manipulation Laguage)指对数据库数据的增(Create)删(Delete)改(Update)操作 1.增加操作 (1)先创建一个表,如图所示: 语法:Insert ...
- [BZOJ5463][APIO2018]铁人两项:Tarjan+圆方树
分析 根据题目中的要求,从\(s\)出发前往\(f\)一定可以,并且只可能经过这两个结点所在的点双连通分量和它们之间的点双连通分量,因此切换点\(c\)只能从这些点中选取. 建出圆方树后,因为圆方树上 ...
- eclipse设置酷炫的代码颜色风格
eclipse安装默认的代码颜色风格是“白色背景”,颜色有些刺眼,于是想到手动去改eclipse的代码颜色,但改来改去还是很难达到我们的要求,甚至有时候将背景和某些代码的颜色改成相同,导致代码看不见. ...
- 修改docker下mysql配置
1.在/home/smile/docker/mysql/config/目录下增加一个文件 my.cnf # Copyright (c) , Oracle and/or its affiliates. ...
- python之random随机函数
random.random()用于生成 用于生成一个指定范围内的随机符点数,两个参数其中一个是上限,一个是下限.如果a > b,则生成随机数 1 n: a <= n <= b.如果 ...
- easyhook源码分析一
easyhook简要说明: easyhook是一个开源的hook库(http://easyhook.github.io/),其支持托管代码(.NET)和非托管代码(C/C++)hook,这里只分析了其 ...
- leetcode 441.排列硬币(python)
1.题目描述 你总共有 n 枚硬币,你需要将它们摆成一个阶梯形状,第 k 行就必须正好有 k 枚硬币. 给定一个数字 n,找出可形成完整阶梯行的总行数. n 是一个非负整数,并且在32位有符号整型的范 ...
- 阶段3 1.Mybatis_03.自定义Mybatis框架_4.自定义mybatis的编码-解析XML的工具类介绍
导入xml操作的类和用到的相关包 创建util包,然后把提供好的XMLConfigBuilder.java文件复制3过来 复制过来,里面用到了很多dom4j的东西 打开pom.xml 输入depend ...
- 【漏洞复现】局域网 ARP 中间人攻击 获取他人账号密码
日期:2019-07-18 14:24:42 更新: 作者:Bay0net 介绍:如何在局域网内,窃取其他用户的账号密码? 0x01. 漏洞环境 攻击工具 arpspoof 基本用法: arpspoo ...
- 思维导图之kubernetes
k8s docker