xib로 재사용 가능한 UIView 생성 (및 스토리 보드에서로드)


81

좋아, 이것에 대해 StackOverflow에 수십 개의 게시물이 있지만 솔루션에 대해서는 특별히 명확하지 않습니다. UIViewxib 파일과 함께 사용자 지정을 만들고 싶습니다 . 요구 사항은 다음과 같습니다.

  • 별도 없음 UIViewController– 완전히 독립적 인 수업
  • 뷰의 속성을 설정 / 가져올 수 있도록 클래스의 콘센트

이 작업에 대한 현재 접근 방식은 다음과 같습니다.

  1. 우세하다 -(id)initWithFrame:

    -(id)initWithFrame:(CGRect)frame {
        self = [[[NSBundle mainBundle] loadNibNamed:NSStringFromClass([self class])
                                              owner:self
                                            options:nil] objectAtIndex:0];
        self.frame = frame;
        return self;
    }
    
  2. -(id)initWithFrame:내 뷰 컨트롤러에서 프로그래밍 방식으로 인스턴스화

    MyCustomView *myCustomView = [[MyCustomView alloc] initWithFrame:CGRectMake(0, 0, self.view.bounds.size.width, self.view.bounds.size.height)];
    [self.view insertSubview:myCustomView atIndex:0];
    

이것은 잘 작동합니다 (불러 오지 않고 [super init]로드 된 펜촉의 내용을 사용하여 단순히 객체를 설정하는 것은 약간 의심스러워 보입니다. 이 경우 에도 잘 작동 하는 하위 뷰추가 하라는 조언이 여기에 있습니다 ). 그러나 스토리 보드에서도 뷰를 인스턴스화 할 수 있기를 원합니다. 따라서 다음을 수행 할 수 있습니다.

  1. 배치 UIView스토리 보드에서 부모 뷰
  2. 사용자 정의 클래스를 다음으로 설정하십시오. MyCustomView
  3. 재정의 -(id)initWithCoder:– 가장 자주 본 코드는 다음과 같은 패턴에 적합합니다.

    -(id)initWithCoder:(NSCoder *)aDecoder {
        self = [super initWithCoder:aDecoder];
        if (self) {
            [self initializeSubviews];
        }
        return self;
    }
    
    -(id)initWithFrame:(CGRect)frame {
        self = [super initWithFrame:frame];
        if (self) {
            [self initializeSubviews];
        }
        return self;
    }
    
    -(void)initializeSubviews {
        typeof(view) view = [[[NSBundle mainBundle]
                             loadNibNamed:NSStringFromClass([self class])
                                    owner:self
                                  options:nil] objectAtIndex:0];
        [self addSubview:view];
    }
    

물론 위의 접근 방식을 사용하든 프로그래밍 방식으로 인스턴스화하든 파일에서 펜촉을 -(id)initWithCoder:입력 -(void)initializeSubviews하고로드 할 때 모두 재귀 적으로 호출되므로 이것은 작동하지 않습니다 .

여기 , 여기 , 여기여기 와 같은 몇 가지 다른 SO 질문이 이에 대해 다룹니다 . 그러나 주어진 답변 중 어느 것도 문제를 만족스럽게 해결하지 못합니다.

  • 일반적인 제안은 UIViewController에 전체 클래스를 포함하고 거기에서 nib로드를 수행하는 것 같지만 래퍼처럼 다른 파일을 추가해야하므로 나에게 차선책으로 보입니다

누구든지이 문제를 해결하는 방법에 대한 조언을 제공 UIView하고 최소한의 번거 로움 / 얇은 컨트롤러 래퍼없이 사용자 지정 작업 콘센트를 얻을 수 있습니까? 아니면 최소한의 상용구 코드로 작업을 수행하는 대안적이고 깨끗한 방법이 있습니까?


1
이것에 대해 만족스러운 답을 얻었습니까? 나는 현재 이것을 위해 고군분투하고 있습니다. 언급했듯이 다른 모든 답변은 충분하지 않은 것 같습니다. 지난 몇 달 동안 발견 한 내용이 있으면 언제든지 직접 질문에 답할 수 있습니다.
Mike Meyers 2014

13
iOS에서 재사용 가능한 뷰를 만드는 것이 왜 그렇게 어려운가요?
clocksmith


1
실제로 연결하는 답변은 정확히 동일한 접근 방식을 사용합니다 (답에는 rect 함수의 init가 포함되어 있지 않습니다. 즉, 프로그래밍 방식이 아닌 스토리 보드에서만 초기화 할 수 있음을 의미합니다)
Ken Chatfield

1
이 아주 오래된 QA와 관련하여 Apple은 마침내 스토리 보드 참조를 소개했습니다 ... developer.apple.com/library/ios/recipes / ... ...
Fattie

답변:


13

귀하의 문제는 loadNibNamed:(의 자손)에서 전화 하고 initWithCoder:있습니다. loadNibNamed:내부적으로 initWithCoder:. 스토리 보드 코더를 재정의하고 항상 xib 구현을로드하려면 다음 기술을 제안합니다. 뷰 클래스에 속성을 추가하고 xib 파일에서 미리 결정된 값 (사용자 정의 런타임 속성에서)으로 설정합니다. 이제 호출 후 [super initWithCoder:aDecoder];속성 값을 확인하십시오. 미리 결정된 값이면을 호출하지 마십시오 [self initializeSubviews];.

따라서 다음과 같습니다.

-(instancetype)initWithCoder:(NSCoder *)aDecoder {
    self = [super initWithCoder:aDecoder];

    if (self && self._xibProperty != 666)
    {
        //We are in the storyboard code path. Initialize from the xib.
        self = [self initializeSubviews];

        //Here, you can load properties that you wish to expose to the user to set in a storyboard; e.g.:
        //self.backgroundColor = [aDecoder decodeObjectOfClass:[UIColor class] forKey:@"backgroundColor"];
    }

    return self;
}

-(instancetype)initializeSubviews {
    id view =   [[[NSBundle mainBundle] loadNibNamed:NSStringFromClass([self class]) owner:self options:nil] firstObject];

    return view;
}

@LeoNatan 감사합니다! 원래 언급했듯이 문제에 대한 최선의 해결책이기 때문에이 답변을 수락하고 있습니다. 그러나 Swift에서는 더 이상 불가능합니다.이 경우 가능한 해결 방법에 대해 별도의 메모를 추가했습니다.
Ken Chatfield

@KenChatfield 나는 Swift 하위 프로젝트에서 그것을 발견하고 짜증을 냈습니다. 이것이 없으면 Swift에서 Cocoa / Cocoa Touch 내부 구현이 불가능하기 때문에 그들이 무엇을 생각하고 있는지 잘 모르겠습니다. 제 생각에는 실제로 버그보다는 기능에 집중할 시간이있을 때 일부 동적 기능이있을 것입니다. Swift는 전혀 준비되지 않았으며 최악의 공격자는 개발 도구입니다.
Leo Natan 2014

예, 맞습니다, Swift는 현재 많은 거친 모서리를 가지고 있습니다. 즉, self에 직접 할당하는 것은 약간의 해킹 인 것처럼 보이므로 컴파일러가 이제 그런 것에 대해 경고하는 방식으로 기쁩니다 (이 엄격한 유형 검사는 언어). 그러나 xib와 사용자 정의 뷰의 연결을 매우 지저분하고 약간 불만족스럽게 만드는 것이 맞습니다. 그들이 버그 분류를 마치면 이와 같은 것들로 좀 더 도움을 줄 수있는 좀 더 동적 인 기능을 볼 수 있기를 바랍니다!
Ken Chatfield 2014

해킹이 아니라 클래스 클러스터가 작동하는 방식입니다. 그리고 실제로 반환 클래스의 하위 클래스 인 객체의 반환이 대신 반환되도록 허용하는 기술적 인 문제가 없습니다. 현재 Cocoa 및 Cocoa Touch의 초석 중 하나 인 클래스 클러스터는 구현이 불가능합니다. 무서운. Core Data와 같은 일부 프레임 워크는 Swift에서 구현할 수 없기 때문에 대부분의 사용에 쓸모없는 언어입니다.
Leo Natan 2014

1
어떻게 든 나를 위해 작동하지 않았습니다 (iOS8.1 SDK). 작동하는 것보다 런타임 속성 대신 XIB에서 복원 식별자를 설정했습니다. 예를 들어 initWithCoder보다 xib에 "MyViewRestorationID"를 설정했습니다.! [[self recoveryIdentifier] isEqualToString : @ "MyViewRestorationID"]
ingaham

26

이 QA (많은 경우)는 실제로 역사적인 관심사입니다.

요즘 iOS에서 수년 동안 모든 것이 컨테이너보기 일뿐입니다. 여기에 전체 자습서

(실제로 Apple은 얼마 전에 마침내 Storyboard References를 추가 하여 훨씬 쉽게 만들었습니다.)

다음은 모든 곳에 컨테이너 뷰가있는 일반적인 스토리 보드입니다. 모든 것이 컨테이너 뷰입니다. 앱을 만드는 방법입니다.

여기에 이미지 설명 입력

(호기심으로 KenC의 대답은 실제로 "자신에게 할당"할 수 없기 때문에 일종의 래퍼 뷰에 xib를로드하는 데 사용 된 방법을 정확히 보여줍니다.)


이것의 문제는 포함 된 모든 콘텐츠 뷰에 ​​대해 많은 ViewControllers로 끝날 것이라는 것입니다.
Bogdan Onu 2014 년

안녕하세요 @BogdanOnu! 많은, 많은, 많은 뷰 컨트롤러가 있어야합니다. "가장 작은"것은 뷰 컨트롤러가 있어야합니다.
Fattie

2
이것은 매우 유용합니다 – @JoeBlow에게 감사드립니다. 컨테이너 뷰를 사용하는 것은 분명히 대안적인 접근 방식이며 xib를 직접 다루는 모든 복잡성을 피하는 간단한 방법 인 것 같습니다. 그러나 모든 UI 디자인이 스토리 보드에 직접 포함되어야하므로 프로젝트 전반에 걸쳐 배포 / 사용하기 위해 재사용 가능한 구성 요소를 만드는 데 100 % 만족스러운 대안이 아닌 것 같습니다.
Ken Chatfield 2014

3
xib의 경우 사용자 정의 View 클래스에 속하는 프로그램 논리 만 포함하므로이 경우 추가 ViewController를 사용하는 데 문제가 적지 만 스토리 보드와의 긴밀한 결합은 컨테이너 뷰가이 문제를 완전히 해결할 수 있는지 확실하지 않습니다. 아마도 대부분의 실제 상황에서 뷰는 프로젝트별로 다르기 때문에 이것이 가장 '표준적인'최상의 솔루션이지만 스토리 보드 사용을 위해 사용자 정의 뷰를 패키징하는 쉬운 방법이 아직 없다는 것에 놀랐습니다. ) 절연 구성 요소로 분할 및 정복에 내 프로그래머의 충동은 가려움증이다
켄 Chatfield

1
또한, 엑스 코드 (6) 사용자 지정 UIView의 서브 클래스의 라이브 렌더링의 도입으로, 나는이 방법으로 xibs를 사용하여 생성 뷰는 이제 사용되지 않습니다 전제를 구입 여부를 확실하지 않다
켄 Chatfield

24

Swift 출시로 상황을 업데이트하기 위해 이것을 별도의 게시물로 추가하고 있습니다. LeoNatan이 설명하는 접근 방식은 Objective-C에서 완벽하게 작동합니다. 그러나 더 엄격한 컴파일 시간 검사 self는 Swift의 xib 파일에서로드 할 때 할당되는 것을 방지 합니다.

결과적으로 self를 완전히 바꾸지 않고 xib 파일에서로드 된 뷰를 사용자 정의 UIView 하위 클래스의 하위 뷰로 추가하는 것 외에는 옵션이 없습니다. 이것은 원래 질문에 설명 된 두 번째 접근 방식과 유사합니다. 이 접근 방식을 사용하는 Swift 클래스의 대략적인 개요는 다음과 같습니다.

@IBDesignable // <- to optionally enable live rendering in IB
class ExampleView: UIView {

    required init(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
        initializeSubviews()
    }

    override init(frame: CGRect) {
        super.init(frame: frame)
        initializeSubviews()
    }

    func initializeSubviews() {
        // below doesn't work as returned class name is normally in project module scope
        /*let viewName = NSStringFromClass(self.classForCoder)*/
        let viewName = "ExampleView"
        let view: UIView = NSBundle.mainBundle().loadNibNamed(viewName,
                               owner: self, options: nil)[0] as! UIView
        self.addSubview(view)
        view.frame = self.bounds
    }

}

이 접근 방식의 단점은 Objective-C에서 LeoNatan이 설명하는 접근 방식을 사용할 때 존재하지 않는 뷰 계층 구조에 추가 중복 레이어를 도입한다는 것입니다. 그러나 이것은 필요한 악으로 받아 들여질 수 있으며 Xcode에서 사물을 설계하는 근본적인 방식의 산물로 간주 될 수 있습니다 (일관되게 작동하는 방식으로 사용자 정의 UIView 클래스를 UI 레이아웃과 연결하는 것이 너무 어려워서 여전히 미쳐 보입니다. 스토리 보드와 코드 모두에서) – self초기화 기에서 도매를 대체 하는 것은보기에 본질적으로 두 개의보기 클래스를 갖는 것도 그렇게 훌륭해 보이지는 않지만 작업을 수행하는 특별히 해석 가능한 방법처럼 보이지 않았습니다.

그럼에도 불구하고이 접근 방식의 한 가지 행복한 결과는에 할당 할 때 올바른 동작을 보장하기 위해 더 이상 뷰의 사용자 정의 클래스를 인터페이스 빌더의 클래스 파일로 설정할 필요가 없기 self때문에 init(coder aDecoder: NSCoder)발행시 재귀 호출 loadNibNamed()이 중단됩니다 ( xib 파일의 사용자 정의 클래스, init(coder aDecoder: NSCoder)사용자 정의 버전이 아닌 일반 바닐라 UIView가 대신 호출됩니다).

xib에 직접 저장된 뷰에 대한 클래스 사용자 정의를 할 수는 없지만 뷰의 파일 소유자를 사용자 정의 클래스로 설정 한 후에도 콘센트 / 액션 등을 사용하여 뷰를 '부모'UIView 하위 클래스에 연결할 수 있습니다.

사용자 정의보기의 파일 소유자 특성 설정

이러한 접근 방식을 사용하여 이러한 뷰 클래스의 구현을 단계별로 보여주는 비디오 는 다음 비디오에서 찾을 수 있습니다 .


안녕 조 – 귀하의 의견에 감사드립니다. 다른 많은 의견과 마찬가지로 대담한 내용입니다. 귀하의 답변에 대한 답변에서 언급했듯이 대부분의 상황에서 컨테이너보기가 아마도 최선의 접근 방식이라는 데 동의합니다. 뷰가 프로젝트 전반에 걸쳐 사용 (또는 분산)되어야하는 경우, 적어도 나에게는 의미가 있고 다른 사람에게도 대안이있는 것 같습니다. 당신은 개인적으로 그것이 나쁜 스타일이라고 생각할 수 있지만 아마도 이것이 어떻게 참조를 위해 수행 될 수 있는지를 제안하는 다른 많은 게시물을 여기에두고 사람들이 스스로 판단하게 할 수 있습니다. 두 가지 방법 모두 유용한 것 같습니다.
Ken Chatfield

감사합니다. 펜촉의 클래스를 .NET으로 떠나는 것에 대한 조언을 따를 때까지 Swift에서 여러 가지 접근 방식을 시도했지만 성공하지 못했습니다 UIView. 나는 애플이 이것을 결코 쉽게 만들지 않았다는 것이 미쳤다는 데 동의한다. 그리고 지금은 사실상 불가능하다. 컨테이너가 항상 답은 아닙니다.
Echelon

16

1 단계. self스토리 보드에서 바꾸기

메서드 self에서 교체 initWithCoder:하면 다음 오류가 발생하여 실패합니다.

'NSGenericException', reason: 'This coder requires that replaced objects be returned from initWithCoder:'

대신 디코딩 된 객체를 awakeAfterUsingCoder:(아님 awakeFromNib)으로 바꿀 수 있습니다 . 처럼:

@implementation MyCustomView
- (id)awakeAfterUsingCoder:(NSCoder *)aDecoder {
    return [[[NSBundle mainBundle] loadNibNamed:NSStringFromClass([self class])
                                          owner:nil
                                        options:nil] objectAtIndex:0];
}
@end

2 단계. 재귀 호출 방지

물론 재귀 호출 문제도 발생합니다. (스토리 보드 디코딩-> awakeAfterUsingCoder:-> loadNibNamed:-> awakeAfterUsingCoder:-> loadNibNamed:-> ...)
따라서 현재 awakeAfterUsingCoder:는 스토리 보드 디코딩 과정 또는 XIB 디코딩 과정에서 호출되는지 확인해야합니다 . 이를 수행하는 방법에는 여러 가지가 있습니다.

a) @propertyNIB에서만 설정된 private 을 사용하십시오 .

@interface MyCustomView : UIView
@property (assign, nonatomic) BOOL xib
@end

'MyCustomView.xib'에서만 "사용자 정의 런타임 속성"을 설정합니다.

장점 :

  • 없음

단점 :

  • 단순히 작동하지 않음 : 이후에setXib: 호출됩니다. awakeAfterUsingCoder:

b) self하위보기가 있는지 확인

일반적으로 xib에는 하위보기가 있지만 스토리 보드에는 없습니다.

- (id)awakeAfterUsingCoder:(NSCoder *)aDecoder {
    if(self.subviews.count > 0) {
        // loading xib
        return self;
    }
    else {
        // loading storyboard
        return [[[NSBundle mainBundle] loadNibNamed:NSStringFromClass([self class])
                                              owner:nil
                                            options:nil] objectAtIndex:0];
    }
}

장점 :

  • Interface Builder에는 속임수가 없습니다.

단점 :

  • 스토리 보드에는 하위보기가있을 수 없습니다.

c) loadNibNamed:통화 중 정적 플래그 설정

static BOOL _loadingXib = NO;

- (id)awakeAfterUsingCoder:(NSCoder *)aDecoder {
    if(_loadingXib) {
        // xib
        return self;
    }
    else {
        // storyboard
        _loadingXib = YES;
        typeof(self) view = [[[NSBundle mainBundle] loadNibNamed:NSStringFromClass([self class])
                                                           owner:nil
                                                         options:nil] objectAtIndex:0];
        _loadingXib = NO;
        return view;
    }
}

장점 :

  • 단순한
  • Interface Builder에는 속임수가 없습니다.

단점 :

  • 안전하지 않음 : 정적 공유 플래그는 위험합니다.

d) XIB에서 개인 서브 클래스 사용

예를 들어, _NIB_MyCustomView의 하위 클래스로 선언하십시오 MyCustomView. 그리고 XIB _NIB_MyCustomView대신 사용 MyCustomView하십시오.

MyCustomView.h :

@interface MyCustomView : UIView
@end

MyCustomView.m :

#import "MyCustomView.h"

@implementation MyCustomView
- (id)awakeAfterUsingCoder:(NSCoder *)aDecoder {
    // In Storyboard decoding path.
    return [[[NSBundle mainBundle] loadNibNamed:NSStringFromClass([self class])
                                          owner:nil
                                        options:nil] objectAtIndex:0];
}
@end

@interface _NIB_MyCustomView : MyCustomView
@end

@implementation _NIB_MyCustomView
- (id)awakeAfterUsingCoder:(NSCoder *)aDecoder {
    // In XIB decoding path.
    // Block recursive call.
    return self;
}
@end

장점 :

  • 명시 적 if으로하지 않습니다MyCustomView

단점 :

  • _NIB_xib 인터페이스 빌더의 접두사 트릭
  • 상대적으로 더 많은 코드

e) 스토리 보드에서 하위 클래스를 자리 표시 자로 사용

d)XIB의 원래 클래스 인 Storyboard의 하위 클래스와 비슷 하지만 사용합니다.

여기에서 우리 MyCustomViewProtoMyCustomView.

@interface MyCustomViewProto : MyCustomView
@end
@implementation MyCustomViewProto
- (id)awakeAfterUsingCoder:(NSCoder *)aDecoder {
    // In storyboard decoding
    // Returns MyCustomView loaded from NIB.
    return [[[NSBundle mainBundle] loadNibNamed:NSStringFromClass([self superclass])
                                          owner:nil
                                        options:nil] objectAtIndex:0];
}
@end

장점 :

  • 매우 안전함
  • 깨끗한; 에 추가 코드가 없습니다 MyCustomView.
  • 다음 if과 같은 명시 적 검사 없음d)

단점 :

  • 스토리 보드에서 하위 클래스를 사용해야합니다.

e)가장 안전하고 깨끗한 전략 이라고 생각 합니다. 그래서 우리는 그것을 여기서 채택합니다.

STEP3. 속성 복사

이후 loadNibNamed:에 'awakeAfterUsingCoder', 당신은 몇 가지 속성 복사해야 self스토리 보드 f를 인스턴스를 디코딩하는합니다. frame그리고 autolayout / autoresize 속성은 특히 중요합니다.

- (id)awakeAfterUsingCoder:(NSCoder *)aDecoder {
    typeof(self) view = [[[NSBundle mainBundle] loadNibNamed:NSStringFromClass([self class])
                                                       owner:nil
                                                     options:nil] objectAtIndex:0];
    // copy layout properities.
    view.frame = self.frame;
    view.autoresizingMask = self.autoresizingMask;
    view.translatesAutoresizingMaskIntoConstraints = self.translatesAutoresizingMaskIntoConstraints;

    // copy autolayout constraints
    NSMutableArray *constraints = [NSMutableArray array];
    for(NSLayoutConstraint *constraint in self.constraints) {
        id firstItem = constraint.firstItem;
        id secondItem = constraint.secondItem;
        if(firstItem == self) firstItem = view;
        if(secondItem == self) secondItem = view;
        [constraints addObject:[NSLayoutConstraint constraintWithItem:firstItem
                                                            attribute:constraint.firstAttribute
                                                            relatedBy:constraint.relation
                                                               toItem:secondItem
                                                            attribute:constraint.secondAttribute
                                                           multiplier:constraint.multiplier
                                                             constant:constraint.constant]];
    }

    // move subviews
    for(UIView *subview in self.subviews) {
        [view addSubview:subview];
    }
    [view addConstraints:constraints];

    // Copy more properties you like to expose in Storyboard.

    return view;
}

마지막 해결책

보시다시피 이것은 약간의 상용구 코드입니다. 이를 '카테고리'로 구현할 수 있습니다. 여기서는 일반적으로 사용되는 UIView+loadFromNib코드를 확장 합니다.

#import <UIKit/UIKit.h>

@interface UIView (loadFromNib)
@end

@implementation UIView (loadFromNib)

+ (id)loadFromNib {
    return [[[NSBundle mainBundle] loadNibNamed:NSStringFromClass(self)
                                          owner:nil
                                        options:nil] objectAtIndex:0];
}

- (void)copyPropertiesFromPrototype:(UIView *)proto {
    self.frame = proto.frame;
    self.autoresizingMask = proto.autoresizingMask;
    self.translatesAutoresizingMaskIntoConstraints = proto.translatesAutoresizingMaskIntoConstraints;
    NSMutableArray *constraints = [NSMutableArray array];
    for(NSLayoutConstraint *constraint in proto.constraints) {
        id firstItem = constraint.firstItem;
        id secondItem = constraint.secondItem;
        if(firstItem == proto) firstItem = self;
        if(secondItem == proto) secondItem = self;
        [constraints addObject:[NSLayoutConstraint constraintWithItem:firstItem
                                                            attribute:constraint.firstAttribute
                                                            relatedBy:constraint.relation
                                                               toItem:secondItem
                                                            attribute:constraint.secondAttribute
                                                           multiplier:constraint.multiplier
                                                             constant:constraint.constant]];
    }
    for(UIView *subview in proto.subviews) {
        [self addSubview:subview];
    }
    [self addConstraints:constraints];
}

이것을 사용하여 다음 MyCustomViewProto과 같이 선언 할 수 있습니다 .

@interface MyCustomViewProto : MyCustomView
@end

@implementation MyCustomViewProto
- (id)awakeAfterUsingCoder:(NSCoder *)aDecoder {
    MyCustomView *view = [MyCustomView loadFromNib];
    [view copyPropertiesFromPrototype:self];

    // copy additional properties as you like.

    return view;
}
@end

XIB :

XIB 스크린 샷

스토리 보드 :

스토리 보드

결과:

여기에 이미지 설명 입력


3
해결책은 초기 문제보다 더 복잡합니다. 재귀 루프를 중지하려면 콘텐츠보기를 MyCustomView 클래스 유형 유형으로 선언하는 대신 파일의 소유자 개체를 설정하기 만하면됩니다.
Bogdan Onu 2014 년

a) 간단한 초기화 프로세스이지만 복잡한 뷰 계층 구조와 b) 복잡한 초기화 프로세스이지만 단순한 뷰 계층 구조의 절충점 일뿐입니다. n'est-ce pas? ;)
rintaro 2014 년

이 프로젝트에 대한 다운로드 링크가 있습니까?
karthikeyan

13

잊지 마세요

두 가지 중요한 사항 :

  1. .xib의 파일 소유자를 사용자 정의보기의 클래스 이름으로 설정하십시오.
  2. .xib의 루트보기에 대해 IB에서 사용자 정의 클래스 이름을 설정 하지 마십시오 .

재사용 가능한 뷰를 만드는 방법을 배우면서이 Q & A 페이지를 여러 번 방문했습니다. 위의 요점을 잊어 버리면 무한 재귀가 발생하는 원인을 찾는 데 많은 시간을 낭비하게되었습니다. 이 점은 여기와 다른 곳 에서 다른 답변에서 언급 되었지만 여기서 다시 강조하고 싶습니다.

단계에 대한 완전한 Swift 답변은 여기에 있습니다 .


2

위의 솔루션보다 훨씬 더 깨끗한 솔루션이 있습니다 : https://www.youtube.com/watch?v=xP7YvdlnHfA

런타임 속성이없고 재귀 호출 문제가 전혀 없습니다. 나는 그것을 시도하고 IBOutlet 속성 (iOS8.1, XCode6)이있는 스토리 보드 및 XIB에서 사용하는 매력처럼 작동했습니다.

코딩에 행운을 빕니다!


1
감사합니다 @ingaham! 그러나 비디오에 설명 된 접근 방식은 원래 질문에서 제안 된 두 번째 솔루션과 동일합니다 (위의 답변에있는 스위프트 코드). 두 경우 모두와 마찬가지로 래퍼 UIView 하위 클래스에 하위 뷰를 추가하는 것이 포함되며, 이것이 재귀 호출에 문제가없고 런타임 속성이나 다른 복잡한 것에 의존 할 필요가없는 이유입니다. 언급했듯이 단점은 사용자 정의 UIView 클래스에 중복 된 추가 자식 뷰를 추가해야한다는 것입니다. 그러나 논의했듯이 이것은 현재로서는 가장 좋고 가장 간단한 솔루션 일 수 있습니다.
Ken Chatfield 2015 년

예, 당신 말이 맞습니다. 이것들은 동일한 솔루션입니다. 그러나 중복보기가 필요하지만 가장 깨끗하고 유지 관리가 가능한 솔루션입니다. 그래서 저는 이것을 사용하기로 결정했습니다.
ingaham

중복 된 뷰는 완전히 자연스럽고 다른 해결책이있을 수 없다고 생각합니다. 당신이 말하고있는 것을 참고 " '뭔가' '여기'갈 것입니다"를 "여기"자연 기존의 것입니다 .... 거기에는 단순히 "무언가"가 있어야합니다. "당신이 물건을 놓을 장소"가 있어야합니다. "뷰"가 무엇인지에 대한 바로 그 정의입니다. 그리고 기다려! 애플의 "컨테이너 뷰" 는 실제로 당신이 무언가를 추구하는 "프레임", "홀더 뷰"( "컨테이너 뷰")가 있다는 것입니다. 실제로 '중복'보기 솔루션은 정확하게 손으로 만든 컨테이너보기입니다! 애플을 사용하십시오.
Fattie 2015 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.