5 approach to load UIView from Xib
After the past few years I found that the only manageable way for creating/maintaining view (or any UI element in more general) is to instantiate the UIView from Xib file. Creating/designing is far more intuitive in Interface Builder than write layout code, defining layout constants (dimensions, colors), or even worse introduce magic numbers to nudge the elements all around.
I’m planning to introduce 5 methods below, I’ve been used each of them in different circumstances over the times.
1. The plain way (the poor man’s method to load UIView from XIB)
This approach works only in really the case when you don’t need anything else just a view assembled in Interface Builder without any communication bindings. It has actually no any particular advantages unless it’s relatively easily understanding in the beginning of the Cocoa learning process.
It uses [NSBundle loadNibNamed:owner:options] method with no respect only to the first parameter. Just include the lines below anywhere in you controller’s implementation.
1
2
3
4
5
6
7
8
9
10
11
12
|
// Instantiate the nib content without any reference to it.
NSArray *nibContents = [[NSBundle mainBundle] loadNibNamed:@"EPPZPlainView" owner:nil options:nil];
// Find the view among nib contents (not too hard assuming there is only one view in it).
UIView *plainView = [nibContents lastObject];
// Some hardcoded layout.
CGSize padding = (CGSize){ 22.0, 22.0 };
plainView.frame = (CGRect){padding.width, padding.height, plainView.frame.size};
// Add to the view hierarchy (thus retain).
[self.view addSubview:plainView];
|
In interface builder you don’t have to setup anything special other than a single (!) customized view that you want to instantiate in you controller. No bindings, even there is no need to specify File’s owner class. You have to write you own hardcoded layout code in return (as you may noticed above).
In interface builder you don’t have to setup anything other than a single (!) view with your static customized content.
the plain way, 第二种方法:
You need to load it using the -loadNibNamed
method. -initWithNibName
is only for UIViewControllers.
Add the following code to your MyCustomView init method:
NSArray *subviewArray = [[NSBundle mainBundle] loadNibNamed:@"MyCustomView" owner:self options:nil];
UIView *mainView = [subviewArray objectAtIndex:0];
[self addSubview:mainView];
Remember, if you are initializing an object from a nib, it calls - (id)initWithCoder:(NSCoder *)aDecoder
to initialize, so you'll have to override that if you are creating the MyCustomView object within the nib. If you're just doing it with initWithFrame:
, then just override that and add the code above. Also, in your nib, make sure you have one top-level UIView, and place all other elements within that (that makes sure that your subviewArray only has one entry).
This will load the views from the nib and add them to the object, and should do the trick.
2. The referenced way (a bit more explicit)
This method is a next step compared to the plain way, since it defines an explicit reference to the view we need. A bit cumbersome that you have to define an outlet property in your controller class to hook up the view with. This point makes this method too specific, or can say unportable.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
@interface EPPZViewController ()
// Define an outlet for the custom view.
@property (nonatomic, weak) IBOutlet UIView *referencedView;
// An action that triggers showing the view.
-(IBAction)showReferencedView;
@end
@implementation EPPZViewController
-(IBAction)showReferencedView
{
// Instantiate a referenced view (assuming outlet has hooked up in XIB).
[[NSBundle mainBundle] loadNibNamed:@"EPPZReferencedView" owner:self options:nil];
// Controller's outlet has been bound during nib loading, so we can access view trough the outlet.
[self.view addSubview:self.referencedView];
}
@end
|
The shiny part here is that you can define a context view (actually a wrapper) in Interface Builder. That can be really useful to define the contextual layout information for the view in the XIB file (much more convenient than coded layout). But in the same time you have to be aware of the Interface Builder setup. File’s Owner must be set to the instantiating controller’s class and the referencedView outlet must be bound to the actual view you need.
You can see that File’s Owner class is set to the instantiating controller’s class (EPPZViewController) and the referencedView outlet is to be bound to the actual view you want to have a reference to.
Be warned not to hook up the controller’s view outlet to the wrapper view (nor if it feels instinctually right), since that would reassign the controller’s view at instantiation with this empty one.
This approach is also known as a UITableViewCell instantiating method (without the wrapper view), by adding a UITableViewCell to the XIB file, though, it is not the scope of the present article.
3. Connected actions (some addition for the above actually)
Having a setup like above, you can easily hook up actions to the client controller sent by objects in the custom view. This could be useful, although, it still forces the view to cooperate with a given type of controller. So just define an IBAction in the main controller like below.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
@interface EPPZViewController ()
@property (nonatomic, weak) IBOutlet UIView *referencedView;
-(IBAction)showConnectedActionsView;
-(IBAction)connectedActionsViewTouchedUp:(UIButton*) button;
@end
@implementation EPPZViewController
-(IBAction)showConnectedActionsView
{
// Instantiate a referenced view (assuming outlet has hooked up in XIB).
[[NSBundle mainBundle] loadNibNamed:@"EPPZConnectedActionsView" owner:self options:nil];
// Controller's outlet has been bound during nib loading, so we can access view trough the outlet.
[self.view addSubview:self.referencedView];
}
-(IBAction)connectedActionsViewTouchedUp:(UIButton*) button
{
// Any interaction (I simply remove the custom view here).
[button.superview removeFromSuperview];
}
@end
|
Then simply hook up a button event to the action you’ve just defined before.
4. Encapsulated instantiation (a step toward enlighting controller code)
Controller codes tend to be complicated. Period.
As you incorporate new features, your controller code immediately starts to grow, which you obviously strive to avoid. A step toward keep client code clean is to create a subclass for the custom view, and start to factor the instantiating features down.
The first trick here is to remove that File’s Owner dependency, introducing a tiny little class EPPZSubclassedViewOwner with the sole purpose of referencing the right view among XIB content. It nor even need a separate file as it is specific for this type of custom view. It lifts up the owning role from the controller’s shoulder.
1
2
3
4
5
6
7
8
9
|
@class EPPZSubclassedView;
@interface EPPZSubclassedViewOwner : NSObject
@property (nonatomic, weak) IBOutlet EPPZSubclassedView *subclassedView;
@end
@interface EPPZSubclassedView : UIView
+(void)presentInViewController:(UIViewController*) viewController;
-(IBAction)dismiss;
@end
|
So as a benefit, we can introduce a class method that instantiates the given view presentInViewController:, then adds it to the view hierarchy. If you need different XIBs, like separate interfaces for iPhone and iPad, you can include it here as well, instead of littering the controller’s code around.
In addition, the dismissal for the view dismiss can also moved down here, as it has nothing to do with the controller itself. In the implementation we can tackle the whole instantiating in place, you can see the owner object in action below.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
@implementation EPPZSubclassedViewOwner
@end
@implementation EPPZSubclassedView
+(void)presentInViewController:(UIViewController*) viewController
{
// Instantiating encapsulated here.
EPPZSubclassedViewOwner *owner = [EPPZSubclassedViewOwner new];
[[NSBundle mainBundle] loadNibNamed:NSStringFromClass(self) owner:owner options:nil];
// Add to the view hierarchy (thus retain).
[viewController.view addSubview:owner.subclassedView];
}
-(IBAction)dismiss
{ [self removeFromSuperview]; }
@end
|
In the XIB file you’ll need to assign the appropriate classes, like mark File’s Owner as an EPPZSubclassedViewOwner instance, and EPPZSubclassedView for the view.
Connect the view to it’s reference.
As well as the button event to the action. Since the IBAction is defined in our custom view, you should hook up the action there.
As a result, you can watch the client code cleaning. Much better, with ain’t no custom view related properties in the controller.
1
2
3
4
5
6
7
8
9
10
11
12
13
|
@interface EPPZViewController
-(IBAction)showSubclassedView;
@end
@implementation EPPZViewController
-(IBAction)showSubclassedView
{
// A tiny one-liner that has anything to do with the custom view.
[EPPZSubclassedView presentInViewController:self];
}
@end
|
It started to look like a reusable code, but we might still need some communication from the view towards the controller.
5. Encapsulate everything (a really flexible, reusable way to load your custom UIView from XIB)
As we successfully separated the view from the controller above, we follow this approach regarding actions as well. To achieve this we introduce a thin protocol declaration <EPPZDecoupledViewDelegate> that introduces the features to the controller, and assure the view that controller will respond to it’s messages, just as every protocol does. It contains two calls decoupledViewTouchedUp: and decoupledViewDidDismiss: at this particular case.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
@class EPPZDecoupledView;
@interface EPPZDecoupledViewOwner : NSObject
@property (nonatomic, weak) IBOutlet EPPZDecoupledView *decoupledView;
@end
@protocol EPPZDecoupledViewDelegate
-(void)decoupledViewTouchedUp:(EPPZDecoupledView*) decoupledView;
-(void)decoupledViewDidDismiss:(EPPZDecoupledView*) decoupledView;
@end
@interface EPPZDecoupledView : UIView
// Indicate that this view should be presented only controllers those implements the delegate methods.
+(void)presentInViewController:(UIViewController<EPPZDecoupledViewDelegate>*) viewController;
-(IBAction)viewTouchedUp;
-(IBAction)dismiss;
@end
|
The impelmentation now should keep a reference delegateViewController for the controller, so it can forward the actions. You need to indicate that the controller has to implement delegate methods, so you’ll declare the type as UIViewController <EPPZDecoupledViewDelegate>. The rest is the same as before.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
@implementation EPPZDecoupledViewOwner
@end
@interface EPPZDecoupledView ()
@property (nonatomic, weak) UIViewController <EPPZDecoupledViewDelegate> *delegateViewController;
@end
@implementation EPPZDecoupledView
+(void)presentInViewController:(UIViewController<EPPZDecoupledViewDelegate>*) viewController
{
// Instantiating encapsulated here.
EPPZDecoupledViewOwner *owner = [EPPZDecoupledViewOwner new];
[[NSBundle mainBundle] loadNibNamed:NSStringFromClass(self) owner:owner options:nil];
// Pass in a reference of the viewController.
owner.decoupledView.delegateViewController = viewController;
// Add (thus retain).
[viewController.view addSubview:owner.decoupledView];
}
-(IBAction)viewTouchedUp
{
// Forward to delegate.
[self.delegateViewController decoupledViewTouchedUp:self];
}
-(IBAction)dismiss
{
[self removeFromSuperview];
// Forward to delegate.
[self.delegateViewController decoupledViewDidDismiss:self];
}
@end
|
So having this, you can setup a completely independent XIB file that knows nothing (!) about it’s context. It instantiates itself, hooks up their actions on it’s own. It is reusable, can be instantiated from any kind of UIViewController that implements its protocol, which is stated clearly in the header.
The actions themselves doing not too much here, other that they invoke the implemented delegate methods in the controller, so it can customize its own features within, a pretty straight / strict / formal delegate pattern.
To make it more readable and explicit, we can move some declarations down to the .m file, so the header for our shiny custom view is just embodies only the client needs to know about it.
1
2
3
4
5
6
7
8
9
|
@class EPPZDecoupledView;
@protocol EPPZDecoupledViewDelegate
-(void)decoupledViewTouchedUp:(EPPZDecoupledView*) decoupledView;
-(void)decoupledViewDidDismiss:(EPPZDecoupledView*) decoupledView;
@end
@interface EPPZDecoupledView : UIView
+(void)presentInViewController:(UIViewController<EPPZDecoupledViewDelegate>*) viewController;
@end
|
So usage in the client controller just reflects these pretty neat declarations. You have to indicate that the controller gonna implement the view’s delegate features, so you include <EPPZDecoupledViewDelegate> to the interface.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
@interface EPPZViewController () <EPPZDecoupledViewDelegate>
-(IBAction)showDecoupledView;
@end
@implementation EPPZViewController
-(IBAction)showDecoupledView
{ [EPPZDecoupledView presentInViewController:self]; }
-(void)decoupledViewTouchedUp:(EPPZDecoupledView*) decoupledView
{ /* Whatever feature. */ }
-(void)decoupledViewDidDismiss:(EPPZDecoupledView*) decoupledView
{ /* Acknowledge sadly. */ }
@end
|
Tada! A beautiful UI module for your project that you can customize independently leaving the controller’s code alone. Having this clients of this class never have to know anything about the XIB content, nor hook up anything within.
Interface Builder setup is nearly the same as you may figured out, but as an overview, you can find the whole project with all the five methods at GitHub.
As it is common with flexible code, it needs a bit more code under the hood, but anyway sooner or later these code lines will land in a collection of reusable classes of one’s own everyday framework.
This is a rough skeleton for the method, in production these classes are likely to implement presenting/dismissal animation, a model object to configure with, sometimes some UI logic shaping a more sophisticated experience, or weak delegate messaging without explicit protocol, but this is yet another story.
5 approach to load UIView from Xib的更多相关文章
- Xcode5 创建模板和UIView 关联XIB
转自:http://www.cnblogs.com/china-ldw/p/3533896.html 在做ios应用开发的过程,难免遇到要创建 子view 和 自定义view的时候,归根到底,我们需要 ...
- iOS 给UIView添加xib
2017-08-25编辑:这文章有点过时了 推荐新的文章:http://www.cnblogs.com/hero11223/p/6881848.html 一段时间没敲代码,以前一些简单的都不会做了,翻 ...
- uiview关联xib
1,在需要实例的地方 //加载一个uiview的作法 [LotteryInvestigationView *lotteryInvestigationView=[[[NSBundle mainBundl ...
- UIView创建xib
这里有两种类都可以实现,但是推荐用Empty类来创建 (Empty): 参考链接:https://blog.csdn.net/wtdask/article/details/76439295 https ...
- 从Xib文件加载UIView的5种方式
在不同的Xib文件中最容易维护的是定义的视图,因此对于从Xib文件中加载UIView来说一个方便的流程是非常重要. 在过去的几年里我发现唯一易于管理创建和维护视图(或者任何界面元素,通常会更多)方式就 ...
- 加载 xib 文件 UIView
记在 UIView 的 xib 文件方式有一下几种: 一 .直接加载 xib 文件, 没有.h.m 文件 1. NSBundle 方式 NSArray *objs = [[NSBundle mainB ...
- Xib设计UITableViewCell然后动态加载
转自: http://www.2cto.com/kf/201202/120764.html (注:环境Mac OS X Lion 10.7.3 + Xcode 4.2.1 + iOS SDK 5.0. ...
- iOS开发UI篇—xib的简单使用
iOS开发UI篇—xib的简单使用 一.简单介绍 xib和storyboard的比较,一个轻量级一个重量级. 共同点: 都用来描述软件界面 都用Interface Builder工具来编辑 不同点: ...
- **IOS:xib文件解析(xib和storyboard的比较,一个轻量级一个重量级)
使用Xcode做iOS项目,经常会和Xib文件打交道,因为Xib文件直观的展现出运行时视图的外观,所以上手非常容易,使用也很方便,但对于从未用纯代码写过视图的童鞋,多数对Xib的理解有些片面. Xib ...
随机推荐
- Linux Shell脚本之自动修改IP
作为一名Linux SA,日常运维中很多地方都会用到脚本,而服务器的ip一般采用静态ip或者MAC绑定,当然后者比较操作起来相对繁琐,而前者我们可以设置主机名.ip信息.网关等配置.修改成特定的主机名 ...
- js微博发布框
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/ ...
- 使用sui实现的选择控件【性别、日期、省市级联】
使用sui mobile做的选择控件,其中sm.js有修改,增加自定义api,详情请看index.html的注释,不多说了,上代码 <!DOCTYPE html> <html> ...
- init.d文件夹
/etc/init.d 是 /etc/rc.d/init.d 的软链接(soft link). [root@asus ~]# ll /etc/init.d lrwxrwxrwx. 1 root roo ...
- php 接口 implements 使用
主要对类名,类所拥有的方法,以及所传参数起约束和规范做用,感觉跟php abstract 抽象类又有点像. 一,接口的定义和调用 <?php interface face1 { const pa ...
- mysql开启日志记录慢查询
1.查看mysql配置 2.利用set (variables)命令设置变量 set global log_slow_queries = ON;/*(必须带上global)*/ set global s ...
- 【python】aassert 断言
语法 : assert 3>4 结果Traceback (most recent call last): File "<pyshell#0>", line 1, ...
- Mongoengine 使用笔记
1.直接将某个document对象导出对应的json数据. #models class Feed(Document): """ @summary: 所有订阅内容 &quo ...
- Python3实现连接SQLite数据库的方法
本文实例讲述了Python3实现连接SQLite数据库的方法,对于Python的学习有不错的参考借鉴价值.分享给大家供大家参考之用.具体方法如下: 实例代码如下: ? 1 2 3 4 5 6 7 8 ...
- u-boot Makefile整体解析
一.概述 1.理解u-boot的makefile需要的准备 linux常用命令.shell脚本基础知识.makefile脚本基础知识 2.Makefile的元素 万变不离其宗,无论工程多么复杂,文 ...