我要评论关于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都难觅的今天，这点性能上的差距几乎可以忽略了。而再之后的设备，不论读取还是解析，只会越来越快。所以性能上的问题完全是没有担心的必要的。
使用storyboard创建导航控制器以及控制器的生命周期
一、基本过程
新建一个项目，系统默认的主控制器继承自uiviewcontroller，把主控制器两个文件删掉。
在storyboard中，默认的控制器是view controller，而我们需要的是导航控制器，那么就把系统的给删掉，拖一个导航控制器进来，导航控制器中默认的第一个子控制器是一个tableview controller，这里不需要，把它删掉，重新拖三个view controller到界面上进行连线，简单的设置就可以了。
按钮连线，按住ctrl，右边界面选择push。
完成基本设置后的界面如下:
经过这么几步简单的设置，就可以实现一个简单的多页面切换。为开发提供了极大的方便，但storyboard也不是万能的，要注意在开发中，如果在最后一个页面添加一个按钮，让它直接跳转到上一个页面会出现问题。
提示：storyboard能做的事情，使用代码都能做，但是代码能够做的事情，storyboard不一定能够做。
通过拖拉控件即可完成简单的界面设置。
下面这样的连线会出现问题：（从后面的控制器跳转到前面，只能通过代码来实现）
产生问题的原因：（当点击返回的时候，不是先把第三个控制器移除栈顶，而是先创建two控制器，此时栈里有四个控制器，栈顶的为two）.
二、控制器的生命周期
代码简单说明：
@interface njoneviewcontroller ()
@property (nonatomic, strong) nsarray *foods;
@end
@implementation njoneviewcontroller
// 当控制器的view加载完毕就调用
- (void)viewdidload
{
[super viewdidload];
nslog(@"1控制器的view加载完毕");
}
// 控制器的view即将显示的时候调用
- (void)viewwillappear:(bool)animated
{
[super viewwillappear:yes];
nslog(@"1控制器的view即将显示");
}
// 控制器的view完全显示的时候调用
- (void)viewdidappear:(bool)animated
{
[super viewdidappear:animated];
nslog(@"1控制器的view完全显示");
}
// 控制器的view即将消失的时候调用
- (void)viewwilldisappear:(bool)animated
{
[super viewwilldisappear:animated];
nslog(@"1控制器的view即将消失");
}
// 控制器的view完全消失的时候调用
- (void)viewdiddisappear:(bool)animated
{
[super viewdiddisappear:animated];
nslog(@"1控制器的view完全消失");
}
// 控制器的view即将销毁的时候调用
- (void)viewwillunload
{
[super viewwillunload];
}
// 控制器的view完全销毁的时候调用
- (void)viewdidunload
{
[super viewdidunload];
// 清空不需要的属性
// [self.foods release];
self.foods = nil;
}
//- (void)setfoods:(nsarray *)foods
//{
// if (_foods != foods) {
// [foods release];
// _foods = [foods retain];
// }
//}
// 接收到内存警告的时候调用
- (void)didreceivememorywarning
{
[super didreceivememorywarning];
}
/**/
@end
打印结果如下
三个重要的方法：
// 控制器的view即将销毁的时候调用
- (void)viewwillunload
{
[super viewwillunload];
}
// 控制器的view完全销毁的时候调用
- (void)viewdidunload
{
[super viewdidunload];
// 清空不需要的属性
// [self.foods release];
self.foods = nil;
}
// 接收到内存警告的时候调用
- (void)didreceivememorywarning
{
[super didreceivememorywarning];
}
补充：
两个内存警告的区别（和代理中得比较）:
代理的内存警告:当application发生一些事情的时候（接收到内存警告的时候），会先通知它的代理，之后代理会通知它的window,window会通知它的根控制器，根控制器会通知它的子控制器。内存警告是由上往下一层一层往下传的（可以通过在两个地方打印输出验证）。
需要了解它的父类是如何处理内存警告的。
模拟内存警告：
内存警告的处理示意图：
控制器的view是否可以销毁？它怎么知道是否可以销毁呢？如何判断？它是判断这个view是否是在windows上面。
当前one控制器在栈顶，one控制器对应的view显示在window上，如果此时发生内存警告，那么one因为在window上面，所以不会被销毁。
若此时再来一个two控制器，它创建对应的twoview显示到window上，one对应的view移开了，此时如果发生内存警告，则此时oneview已经不再在window上显示，所以会被销毁。
特别说明：outlet代表着属性，当控制器创建的时候，属性一般也是有值的，当调用了- (void)viewdidunload方法以后，即控制器的view完全销毁了以后，所有的属性数据会清空。一般在ios5以前，还会在这个方法里面清空里面的所有属性。
提示：所有的控制器的这些方法其实是一个循环。
您可能感兴趣的文章:
如您对本文有疑问或者有任何想说的，请点击进行留言回复，万千网友为您解惑！
网友评论