iOS8-제약 조건이 모호하게 높이 0을 제안 함

누구든지 이것을 디버그하는 방법을 알고 있습니까?

한 번만 경고 : 제약 조건이 테이블 뷰 셀의 콘텐츠 뷰에 ​​대해 높이 0을 모호하게 제안하는 경우를 감지했습니다. 의도하지 않은 붕괴를 고려하고 대신 표준 높이를 사용합니다.

행의 높이는

- (CGFloat)tableView:(UITableView *)tableView 
           heightForRowAtIndexPath:(NSIndexPath *)indexPath{
   return 34.0;
}

그리고 모두 constraints가 행복한 것 같습니다 ...

반환 높이와 예상 높이를 강요하면 경고가 사라졌습니다.

- (CGFloat)tableView:(UITableView *)tableView 
           estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return 44;
}

- (CGFloat)tableView:(UITableView *)tableView 
           heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return 44;
}

두 개의 재정의가 필요하지 않은 또 다른 솔루션은 단순히 또는 init 메서드 self.tableView.rowHeight = 44;에서 사용 하는 것 loadView입니다.

또한 할 수있는 것은 콘텐츠보기의 상단과 하단에서 수직 제약 조건을 추가하는 것입니다. 이렇게하면 자동 레이아웃이 행복해집니다 (이제 셀의 높이를 직접 계산하는 방법을 알고 있기 때문입니다).

autoLayout 제약 조건과 UITableViewAutomaticDimension을 사용하는 경우이 오류는 코드에서 높이를 재정 의하여 버릴 수있는 잘못된 문제가 아닙니다. 이는 필요한 적절한 수직 제약 조건이 없기 때문에 셀 높이를 자동으로 결정하는 것이 작동하지 않음을 의미합니다.

나와 같고이 오류가 발생하고 오류를 발생시킨 셀을 식별하는 데 도움이 필요한 경우 'heightforRowAtIndexPath'메서드가 반환되기 직전에 다음 줄을 추가 할 수 있습니다.

NSLog(@"Section %ld Row %ld", (long)[indexPath section], (long)[indexPath row]);

이렇게하면 긴 섹션 및 행 목록이 인쇄되지만 오류를 발생시킨 특정 셀 바로 다음에 오류가 나타나며 문제를 일으키는 셀을 신속하게 식별하고 그에 따라 제약 조건을 수정할 수 있습니다. 이것은 특히 정적 셀에 유용합니다. autoLayout 및 자동 셀 높이를 사용하지 않는 경우 수동으로 입력 한 숫자로 높이를 재정의하면 작동하지만 기본적으로 이러한 기능을 비활성화하므로 활용하려는 경우 매우 좋지 않은 솔루션입니다.

이전에 'heightForRowAtIndexPath'메서드를 사용하지 않았지만 UITableViewAutomaticDimension 설정을 실행 취소하지 않고이 오류를 디버그하려면 다음을 코드에 추가하면됩니다.

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    NSLog(@"Section %ld Row %ld", (long)[indexPath section], (long)[indexPath row]);
    return UITableViewAutomaticDimension;
}

자동 레이아웃을 사용하고 각 테이블 뷰 셀의 행 높이 값을 지정하지 않고 대신 "기본값"값을 그대로두면이 문제를 일으키는 XCode 6.1에 버그가있는 것 같습니다. 모든 셀에 대해 행 높이 옆에있는 "사용자 지정"확인란을 선택하기 만하면 경고가 사라집니다.

예, 테이블보기 셀의 항목에 대해 수평 제한 만있는 경우에도 모든 제한이 "행복"합니다. 나는 같은 문제가 있었다. 수직 구속도 추가해야합니다. 그렇게하면 경고가 사라집니다.

제약 조건은 레이아웃 목적으로는 만족할 수 있지만 자동 행 높이 목적으로는 만족스럽지 않습니다. 행복한 레이아웃은 내용이 모호함없이 레이아웃 될 수 있음을 의미합니다. 그것은 Interface Builder의 검사를 만족시킬 것입니다.

자동 행 높이에 대한 행복한 레이아웃은 위와 더불어 셀 하단에도 제약 조건을 포함한다는 것을 의미합니다.

추가 정보 : 제약 조건이 높이 0을 모호하게 제안하는 경우 감지

Table View 크기 검사기에서 Row Height 43 (또는 <> 44)을 사용했는데 오류가 사라졌습니다. 44를 사용하면 오류가 발생합니다. Xcode 버전 6.0.1.

-이 답변은 중재자에 의해 제거되었으므로 문제가 해결됩니다. 이것은 나를 위해 문제를 해결하고 다른 사람들에게도 그렇게 할 수 있습니다. 다시 삭제하지 않으시겠습니까?

경고를 제거 할 수는 없었지만 제약 조건이 작동하도록하기 위해, new를 iOS8, tableview 속성 estimatedRowHeight을 고정 높이로 설정하고 heightForRowAtIndexPath구현을 제거했습니다 .

해당 경고가 표시되는 경우 자동 레이아웃을 사용하고 있고 셀 내부에 제약이 없기 때문일 가능성이 큽니다.

자동 레이아웃 사용을 중지하거나 셀 높이를 명확하게 정의하는 제약 조건을 구현해야합니다.

오른쪽 파일 검사기에서 "자동 레이아웃 사용"옵션을 선택 취소하여 인터페이스 빌더에서 자동 레이아웃을 끌 수 있습니다.

자동 레이아웃 사용을 선택하고 셀 높이가 고정되어 있으면 적절한 제약 조건을 쉽게 구현할 수 있습니다. 단순히 셀 콘텐츠보기의 하위보기에 대한 높이 제한을 추가하고 하위보기 사이, 하위보기와 콘텐츠보기 사이에 수직 공간 제한을 구현합니다. 예를 들어 셀에 레이블이 하나있는 경우 다음과 같이 작동합니다.

수직 제약

1. 콘텐츠보기 상단과 라벨 상단 사이의 수직 공간 제약
2. 라벨의 고정 높이 제약
3. 라벨 하단과 콘텐츠보기 하단 사이의 수직 공간 제약

수평 제약

1. 콘텐츠보기의 앞쪽 가장자리와 레이블의 앞쪽 가장자리 사이의 수평 공간 제약
2. 라벨의 고정 너비 제약
3. 레이블의 후행 가장자리와 콘텐츠보기의 후행 가장자리 사이의 수평 공간 제약

AutoLayout을 사용하여 적합한 높이를 계산할 수 있습니다. 다음은 iOS 8의 Dynamic Cell Height에 대한 멋진 게시물입니다. http://natashatherobot.com/ios-8-self-sizing-table-view-cells-with-dynamic-type/

에서 스위프트가 강제 반환 높이가 내 문제를 해결 :

override func tableView(tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
    if(indexPath.row == 0){
       return CGFloat(131.0)
    }else if(indexPath.row == 8){
       return CGFloat(97.0)
    }else{
       return CGFloat(44.0)
    }
}

늪지 표준 수정의 경우 제약 조건이 없거나 높이를 예측하지 않거나 문제를 과도하게 엔지니어링합니다. 기본 프로젝트를 만들었고 테이블 뷰를 연결 했지만 뷰 컨트롤러에 높이 델리게이트를 넣는 것을 잊었습니다 . 이 경고를 없애려면 이것이 필요합니다.

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
    return 44;
}

테이블의 뷰 컨트롤러에서.

uitableviewcell 내부에서 mapView를 사용했습니다. 지도보기의 높이를 기기 화면 크기의 1/3로 변경했습니다. 같은 오류가 발생했습니다. uitableviewcell의 콘텐츠보기에 누락 된 제약 조건을 추가하여 오류를 수정했습니다.

1) contentView 제약 조건을 지 웁니다.

2) 권장 상수로 재설정을 contentView로 설정하십시오.

3) 누락 된 제약 추가-있는 경우

4) 콘텐츠보기에 필요한 모든 제약이 있는지 확인합니다.

제 경우에는 xib로 셀을 디자인하고 있는데 xib 파일을 대상에 추가하는 것을 잊었 기 때문입니다.

xib 파일을 대상에 추가하면 문제가 사라집니다.

이 페이지의 답변은 heightForRowAtIndexPath에서 44와 같은 rowHeights를 수동으로 반환하거나 높이 제약 조건을 추가하는 것에 대해 설명하지만 경고가 사라지지만 이는 Xcode의 버그가 최소 버전 6.3.2 (6D2105)에서 볼 수 있기 때문에 불필요 합니다.

viewDidLoad에서 중단 점을 설정하면 스토리 보드에서 행 높이를 44로 지정하더라도 self.tableView.rowHeight = -1 (UITableViewAutomaticDimension)이 표시됩니다. 이는 Apple이 기본 설정을 지정할 수있는 플래그를 제공하지 않았기 때문에 행 높이를 44로두면 동적 행 높이를 원한다고 잘못 가정하기 때문입니다.

가능한 해결책과 그 결과는 다음과 같습니다.

• 스토리 보드 (작동)에서 행 높이를 43 또는 45로 설정합니다.

• heightForRowAtIndexPath에서 44의 높이를 수동으로 반환합니다 (작동).

• UITableViewCell의 요소와 contentView (작동) 사이에 높이 제약 조건을 추가합니다.

불행히도 이러한 솔루션을 사용하려면 디자인을 변경하거나 불필요한 제약 조건을 추가하거나 버그를 해결하기 위해 불필요한 코드를 추가해야합니다. 나는 가장 간단한 해결책을 시도했다.

• 스토리 보드에서 각 UITableViewCell의 높이를 44 (사용자 지정)로 설정합니다 (실패).

나는 이것에 대한 순수한 스토리 보드 솔루션을 정말로 원했기 때문에 마침내 시도했습니다.

• 스토리 보드의 UITableView에 사용자 정의 런타임 속성을 추가하고, 향후 개발자가 찾을 수 있도록 rowHeight가 설정되는 방식에 대한 메모와 함께 UITableView의 이름을 지정합니다. (작동) :



이러한 버그는 모두 iOS 개발에서 너무 흔하며 개발자가 솔루션이 장기적으로 유지 관리에 미치는 영향을 평가하는 데 과도한 시간을 소비하게합니다.

유지 관리가 가능하고 난독 화되지 않은 개념적으로 올바른 솔루션을 찾는 것은 매우 어렵고 Apple이 버그를 수정하고 44가 가까운 미래의 기본 행 높이가 될 것이라고 가정하면 제약 조건 또는 사용자 정의 런타임 속성 솔루션은 아마도 가장 유지 관리가 용이합니다.

여기서 일어나는 두 가지 중요한 일이 있다고 생각합니다.

1) ctrl + dragging을 사용하면 제약 조건을 잘못 만드는 것이 매우 쉽습니다. 따라서 올바르게 수행했는지 다시 확인하십시오. 이러한 제약을 그리기 위해 화면 왼쪽의 트레이를 사용하는 것이 가장 좋습니다.

2) ViewDidLoad 또는 다른 곳에서 expectedRowHeight를 지정하는 대신 delegate 메서드를 사용하십시오.

override func tableView(tableView: UITableView, estimatedHeightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {}

이것은 나를 위해 즉시 문제를 해결했습니다.

범용 스토리 보드 또는 xib를 사용할 때도이 오류가 발생했습니다. Any x Any size 클래스에 대한 적절한 제약 조건을 지정하지 않으면이 오류가 나타나는 것을 보았습니다.

Apple은 iOS9에서이 문제를 해결 한 것 같습니다. 오류는 8.4에서만 발생했습니다.

이 오류와 내가 원하는 제약 조건과 충돌하는 제약 조건이 생성되는 또 다른 오류 (어디에서 알 수 없음) 사이에 며칠 동안 빙글 빙글 돌았습니다. 모든 보이는 속성이 다른 속성과 동일한 한 인스턴스에서 작동하도록했습니다. 내가 찾은 유일한 해결책은 원자 단위로 이동하는 것입니다. xib로 완전히 새로운 파일을 만들고 콘센트를 다시 연결하여 이전 코드를 복사하여 붙여 넣습니다. 최선의 해결책이 아닐 수도 있지만 때로는 문제가 보이지 않으면 할 일이 거의 없습니다. 최소한 원자화는 무슨 일이 일어나고 있는지 검토하는 좋은 방법입니다.