NSLayoutConstraint "UIView-Encapsulated-Layout-Height" क्या है और मुझे इसे साफ-सुथरे तरीके से फिर से तैयार करने के लिए कैसे जाना चाहिए?

Question

मेरे पास UITableViewiOS 8 के तहत एक रनिंग है और मैं स्टोरीबोर्ड में बाधाओं से स्वचालित सेल हाइट्स का उपयोग कर रहा हूं।

मेरी एक कोशिका में एक एकल होता है UITextViewऔर मुझे उपयोगकर्ता इनपुट के आधार पर अनुबंध करने और विस्तार करने की आवश्यकता होती है - पाठ को सिकोड़ने / विस्तारित करने के लिए टैप करें।

मैं टेक्स्ट व्यू में रनटाइम बाधा को जोड़कर ऐसा कर रहा हूं और उपयोगकर्ता घटनाओं के जवाब में बाधा पर निरंतर परिवर्तन कर रहा हूं:

-(void)collapse:(BOOL)collapse; {

    _collapsed = collapse;

    if(collapse)
        [_collapsedtextHeightConstraint setConstant: kCollapsedHeight]; // 70.0
    else
        [_collapsedtextHeightConstraint setConstant: [self idealCellHeightToShowFullText]];

    [self setNeedsUpdateConstraints];

}

जब भी मैं ऐसा करता हूं, मैं इसे tableViewअपडेट और कॉल में लपेटता हूं [tableView setNeedsUpdateConstraints]:

[tableView beginUpdates];

[_briefCell collapse:!_showFullBriefText];

[tableView setNeedsUpdateConstraints];
// I have also tried 
// [self.tableView reloadRowsAtIndexPaths:@[indexPath] withRowAnimation:UITableViewRowAnimationTop];
// with exactly the same results.

[tableView endUpdates];

जब मैं ऐसा करता हूं, तो मेरी कोशिका का विस्तार होता है (और इसे करते हुए एनिमेट करता है) लेकिन मुझे एक चेतावनी मिलती है:

2014-07-31 13:29:51.792 OneFlatEarth[5505:730175] Unable to simultaneously satisfy constraints.

Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) 

(

    "<NSLayoutConstraint:0x7f94dced2b60 V:[UITextView:0x7f94d9b2b200'Brief text: Lorem Ipsum i...'(388)]>",

    "<NSLayoutConstraint:0x7f94dced2260 V:[UITextView:0x7f94d9b2b200'Brief text: Lorem Ipsum i...']-(15)-|   (Names: '|':UITableViewCellContentView:0x7f94de5773a0 )>",

    "<NSLayoutConstraint:0x7f94dced2350 V:|-(6)-[UITextView:0x7f94d9b2b200'Brief text: Lorem Ipsum i...']   (Names: '|':UITableViewCellContentView:0x7f94de5773a0 )>",

    "<NSLayoutConstraint:0x7f94dced6480 'UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentView:0x7f94de5773a0(91)]>"
 )

Will attempt to recover by breaking constraint 

<NSLayoutConstraint:0x7f94dced2b60 V:[UITextView:0x7f94d9b2b200'Brief text: Lorem Ipsum i...'(388)]>

388 मेरी गणना की गई ऊंचाई है, अन्य बाधाओं पर UITextViewएक्सकोड / आईबी से मेरा है।

अंतिम एक मुझे परेशान कर रहा है - मैं अनुमान लगा रहा हूं कि UIView-Encapsulated-Layout-Heightयह पहली बार पेश किए जाने पर सेल की गणना की गई ऊंचाई है - (मैंने अपनी UITextViewऊंचाई निर्धारित करने के लिए> = = 70.0) हालांकि यह सही नहीं लगता है कि यह व्युत्पन्न बाधा तब खत्म हो जाती है अद्यतन उपयोगकर्ता cnstraint।

इससे भी बदतर, हालांकि लेआउट कोड कहता है कि यह मेरी ऊंचाई की बाधा को तोड़ने की कोशिश कर रहा है, लेकिन ऐसा नहीं है - यह सेल की ऊँचाई को पुन: गणना करने के लिए जाता है और जैसा मैं चाहता हूं सब कुछ ड्रॉ होता है।

तो, क्या है NSLayoutConstraint UIView-Encapsulated-Layout-Height(मैं अनुमान लगा रहा हूं कि यह स्वत: सेल आकार देने के लिए गणना की गई ऊंचाई है) और मुझे इसे साफ सफाई के लिए मजबूर करने के बारे में कैसे जाना चाहिए?

Comments

क्रॉस को Apple देव मंचों पर पोस्ट किया गया: devforums.apple.com/thread/238803

— Rog

मैंने निम्नलिखित तरीके से एक समान मुद्दे को हल किया और यह iOS 7/8 पर काम करता है। 1) बाधा प्राथमिकताओं में से एक को 750 तक कम करें। मैं पहली या दूसरी 2 की कोशिश करूँगा) awakeFromNib सेट में सेल उपवर्ग में self.contentView.autoresizingMask = UIViewAutoresizingFlexibleHeight;। मुझे लगता है कि शुरू में ऑटोरेस्ज़ मास्क को सेट करने से अंतिम बाधा को जोड़ा जाता है। मुझे यह समाधान यहां मिला: github.com/wordpress-mobile/WordPress-iOS/commit/…

— Jesse

@RogerNolan, कोई खबर? इंटरफ़ेस बिल्डर में ऑटो-लेआउट के साथ खेलते समय मुझे एक ही मुद्दा मिला। कुछ कोशिकाएँ इस समस्या का कारण बनती हैं, कुछ नहीं।

— orkenstein

मुझे नहीं लगता है कि ऑटोराइज़िंग मार्क जोड़ना एक अच्छा उपाय है।

— रोज

@RogerNolan क्या आप इन लेआउट परिवर्तनों को करने से पहले IB में इस सेल का निर्माण कर रहे हैं? मैं एक ही समस्या पर डिबगिंग कर रहा हूं लेकिन मैं कोई अतिरिक्त बाधा नहीं जोड़ रहा था। मैं स्क्रैच से अपने दृष्टिकोण को फिर से बनाने के द्वारा चेतावनी को दबाने में कामयाब रहा, और जब मैंने 2 स्टोरीबोर्ड फ़ाइलों को अलग किया तो फर्क सिर्फ इतना था कि चेतावनियों वाला संस्करण <rect key="frame" x="0.0" y="0.0" width="600" height="110"/>अपनी परिभाषा में रेखा को याद कर रहा था , जिससे मुझे विश्वास हुआ कि यह एक आईबी बग है । कम से कम मेरा तो वैसे भी था।

— एल नील नील

Answer 1

_collapsedtextHeightConstraint999 की प्राथमिकता को कम करने की कोशिश करें । इस तरह से आपूर्ति UIView-Encapsulated-Layout-Heightकी गई बाधा हमेशा पूर्वता लेती है।

यह इस पर आधारित है कि आप किस चीज में लौटते हैं -tableView:heightForRowAtIndexPath:। सही मूल्य और अपने स्वयं के बाधा को वापस करना सुनिश्चित करें और उत्पन्न एक ही होना चाहिए। अपने स्वयं के बाधा के लिए कम प्राथमिकता केवल अस्थायी रूप से संघर्ष को रोकने के लिए आवश्यक है जबकि पतन / विस्तार एनिमेशन उड़ान में हैं।

Comments

जो मैं चाहता हूं उसके ठीक विपरीत होगा। UIView-Encapsulated-Layout-Height गलत है - यह पिछले लेआउट से संबंधित है।

— Rog

UIView-Encapsulated-Layout-Heightबाधा UITableView से जोड़ा एक बार ऊंचाइयों निर्धारित कर रहे हैं है। मैं systemLayoutSizeFittingSizecontentView के आधार पर ऊंचाई की गणना करता हूं। यहाँ, UIView-Encapsulated-Layout-Heightकोई फर्क नहीं पड़ता। उसके बाद, TableView द्वारा लौटाए गए मान के लिए सामग्री को स्पष्ट रूप से सेट करता है heightForRowAtIndexPath:। इस मामले में यह हमारे कस्टम बाधाओं की प्राथमिकता को कम करने के लिए सही है क्योंकि rowHeights की गणना के बाद tableView बाधा को पूर्ववर्ती होना चाहिए।

— ऑर्टविन गेंट्ज़

@OrtwinGentz: फिर भी बात समझ में नहीं आता यह हमारे कस्टम की कमी 'प्राथमिकता कम करने के लिए सही है, क्योंकि tableView बाधा पूर्वता लेना चाहिए के बाद rowHeights गणना कर रहे हैं । बात यह है कि UIView-Encapsulated-Layout-Heightअगर मैं प्राथमिकता कम नहीं करता हूं तो यह गलत है ...

— परीक्षण

मुझे लगता है कि संघर्ष को वास्तविक समस्या को ठीक नहीं करने से बचा रहा है - हालांकि यह अभी भी एक Apple बग जैसा लगता है, मुझे लगता है कि यह शायद सही बात है। विशेष रूप से इस तथ्य के प्रकाश में कि Apple इस बाधा को पुनर्गणना करता है और त्रुटि प्रिंट के बाद सब कुछ सही ढंग से बाहर निकलता है।

— रोज

-1 इस उत्तर के लिए क्योंकि यह माना जाता है कि बाधा जोड़ी जा रही है, सही है। UIView-Encapsulated-Layout-Widthमेरे मामले में जोड़ा गया सिर्फ गलत है, लेकिन यह रनटाइम के दौरान मेरी स्पष्ट बाधाओं पर पसंद किया जाता है।

— किरण

Answer 2

मेरे पास एक समान परिदृश्य है: एक पंक्ति सेल के साथ एक टेबल व्यू, जिसमें यूआईबेल ऑब्जेक्ट्स की कुछ लाइनें हैं। मैं iOS 8 और ऑटोलेयूट का उपयोग कर रहा हूं।

जब मैंने घुमाया तो मुझे गलत सिस्टम की गणना की गई पंक्ति की ऊंचाई (43.5 वास्तविक ऊंचाई से बहुत कम है) मिली। ऐसा लग रहा है:

"<NSLayoutConstraint:0x7bc2b2c0 'UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentView:0x7bc37f30(43.5)]>"

यह सिर्फ एक चेतावनी नहीं है। मेरी टेबल व्यू सेल का लेआउट बहुत ही भयानक है - सभी टेक्स्ट एक टेक्स्ट लाइन पर ओवरलैप किए गए हैं।

यह मुझे आश्चर्यचकित करता है कि निम्न पंक्ति मेरी समस्या को जादुई रूप से "ठीक करती है" (ऑटोलैयट कुछ भी नहीं शिकायत करता है और मुझे स्क्रीन पर जो उम्मीद है वह मुझे मिलता है:)

myTableView.estimatedRowHeight = 2.0; // any number but 2.0 is the smallest one that works

इस पंक्ति के साथ या उसके बिना:

myTableView.rowHeight = UITableViewAutomaticDimension; // by itself this line only doesn't help fix my specific problem

Comments

आखिरकार! यह एक सही उत्तर है। WWDC के सत्र में, यह उल्लेख किया गया था, यदि आप स्वचालित पंक्ति ऊंचाई साइज़िंग का उपयोग करने वाले हैं, तो आप एक अनुमान लगाते हैं कि होइट या खराब चीजें होती हैं। (हाँ, Apple वास्तव में बहुत बुरा हुआ)

— अब्दुलरहमान शतो

एफडब्ल्यूआईडब्ल्यू, अनुमान को जोड़ने से मेरे लिए बिल्कुल भी कोई फर्क नहीं पड़ा है।

— बेंजोना

हे। मैं फिर से उसी जवाब पर वापस आ गया हूं, और इसे खुशी और आशा के साथ लागू करने के लिए चला गया। एक बार फिर, यह मेरे लिए कोई फर्क नहीं पड़ता :-)

— बेंजो जूल 20'15

तालिका दृश्य द्वारा लौटाए गए अनुमान: अनुमानितहाइटोरोरोएटइंडेक्सपैथ: सेल के रूप में कम से कम बड़े होना चाहिए । अन्यथा, तालिका की गणना की गई ऊंचाई वास्तविक ऊंचाई से कम होगी, और तालिका स्क्रॉल कर सकती है (उदाहरण के लिए मेज पर अलग-अलग रिटर्न के बाद)। UITableViewAutomaticDimension का उपयोग नहीं किया जाना चाहिए।

— मैट

ध्यान दें कि कम को estimatedRowHeightअधिक बार cellForRowAtIndexPathशुरू में कहा जाएगा। टेबलव्यू ऊँचाई अनुमानित राओहाइट समय से विभाजित, सटीक होने के लिए। 12 इंच के आईपैड प्रो पर, यह संभावित रूप से हजारों में एक संख्या हो सकती है और डेटासोर्स को हथौड़ा कर सकती है और इसके परिणामस्वरूप एक महत्वपूर्ण विलंब हो सकता है।

— मोजजो 66

Answer 3

मैं चेतावनी के संदेशों में से एक मूल्यों पर प्राथमिकता को निर्दिष्ट करके दूर जाने की चेतावनी प्राप्त करने में सक्षम था , चेतावनी संदेश कहता है कि इसे (नीचे "Will attempt to recover by breaking constraint") तोड़ना था । ऐसा प्रतीत होता है कि जब तक मैंने प्राथमिकता को किसी चीज़ से अधिक निर्धारित किया 49, तब तक चेतावनी चली जाती है।

मेरे लिए इसका मतलब यह था कि मेरे अवरोध को बदलते हुए चेतावनी ने इसे तोड़ने का प्रयास किया:

@"V:|[contentLabel]-[quoteeLabel]|"

सेवा:

@"V:|-0@500-[contentLabel]-[quoteeLabel]|"

वास्तव में, मैं उस बाधा के किसी भी तत्व को प्राथमिकता जोड़ सकता हूं और यह काम करेगा। यह जो एक बात करने के लिए प्रतीत नहीं होता है। मेरी कोशिकाएँ उचित ऊँचाई को समाप्त करती हैं और चेतावनी प्रदर्शित नहीं होती है। रोजर, आपके उदाहरण के लिए, ऊंचाई मान बाधा (जैसे ) के @500बाद सही जोड़ने का प्रयास करें ।388388@500

मुझे पूरी तरह से यकीन नहीं है कि यह क्यों काम करता है लेकिन मैंने थोड़ी जांच की है। में NSLayoutPriority enum , ऐसा लगता है कि NSLayoutPriorityFittingSizeCompressionप्राथमिकता के स्तर है 50। उस प्राथमिकता स्तर के लिए दस्तावेज़ कहते हैं:

जब आप किसी दृश्य को एक फिटिंग संदेश भेजते हैं, तो सबसे छोटा आकार जो दृश्य की सामग्री के लिए काफी बड़ा होता है, गणना की जाती है। यह प्राथमिकता स्तर है जिसके साथ उस गणना में दृश्य जितना संभव हो उतना छोटा होना चाहता है। यह काफी कम है। आम तौर पर इस प्राथमिकता पर एक बाधा बनाना उचित नहीं है। आप उच्च या निम्न होना चाहते हैं।

प्रलेखन संदर्भित के लिए fittingSizeसंदेश में लिखा है:

दृश्य का न्यूनतम आकार जो इसे धारण करने वाली बाधाओं को संतुष्ट करता है। (सिफ़ पढ़िये)

AppKit इस संपत्ति को दृश्य के लिए उपलब्ध सर्वोत्तम आकार के लिए सेट करता है, सभी बाधाओं को देखते हुए और इसके साक्षात्कार आयोजित करते हैं और दृश्य को यथासंभव छोटा बनाने के लिए प्राथमिकता को संतुष्ट करते हैं। इस गुण में आकार मान कभी नकारात्मक नहीं होते हैं।

मैं उससे आगे नहीं डूबा हूं, लेकिन यह समझ में आता है कि जहां समस्या है, उसके साथ कुछ करना है।

Comments

जेक्स ने कहा। अभी भी मुझे एक बग की तरह लगता है। Apple ने हालांकि rdar को जिम्मेदारी नहीं दी है :-(

— Rog

Answer 4

99.9% समय, कस्टम कोशिकाओं या हेडर का उपयोग करते समय, सभी संघर्ष UITableViewsतब होते हैं जब पहली बार तालिका लोड होती है। एक बार लोड होने के बाद आप आमतौर पर फिर से संघर्ष नहीं देखेंगे।

ऐसा इसलिए होता है क्योंकि अधिकांश डेवलपर्स आमतौर पर सेल / हेडर में एक तत्व को लेआउट करने के लिए किसी प्रकार की निश्चित ऊंचाई या एंकर बाधा का उपयोग करते हैं। संघर्ष तब होता है क्योंकि जब UITableViewपहले लोड किया जाता है / बाहर रखा जाता है, तो यह इसकी कोशिकाओं की ऊंचाई को 0. पर सेट करता है। यह स्पष्ट रूप से आपके स्वयं के बाधाओं के साथ संघर्ष करता है। इसे हल करने के लिए, बस किसी भी निर्धारित ऊंचाई की बाधाओं को कम प्राथमिकता ( .defaultHigh) में सेट करें। कंसोल संदेश को ध्यान से पढ़ें और देखें कि लेआउट सिस्टम ने किस बाधा को तोड़ने का फैसला किया है। आमतौर पर यह वही है जिसे अपनी प्राथमिकता बदलने की आवश्यकता है। आप इस तरह प्राथमिकता बदल सकते हैं:

let companyNameTopConstraint = companyNameLabel.topAnchor.constraint(equalTo: companyImageView.bottomAnchor, constant: 15)
    companyNameTopConstraint.priority = .defaultHigh

NSLayoutConstraint.activate([
            companyNameTopConstraint,
           the rest of your constraints here
            ])

Comments

सुंदर व्याख्या।

— ग्लेन

Answer 5

मैं एक नकली हटाने के द्वारा इस त्रुटि को हल करने में सक्षम था cell.layoutIfNeeded()कि मैं अपने में था tableViewकी cellForRowAtविधि।

Comments

हां, इससे मेरे लिए भी समस्या हल हो गई। मैं कोड लेआउट विरोधाभास कर रहा था इसलिए मैंने शुरू में सोचा था कि मैं कुछ याद कर सकता हूं। धन्यवाद

— जॉन

वही चीज़! धन्यवाद!

— एंड्री चेर्नुखा

Answer 6

अपने अवरोधों को अद्यतन करने के लिए तालिका दृश्य को सूचित करने के बजाय, सेल पुनः लोड करने का प्रयास करें:

[tableView beginUpdates];

[_briefCell collapse:!_showFullBriefText];

[tableView reloadRowsAtIndexPaths:@[[tableView indexPathForCell:_briefCell]] withRowAnimation:UITableViewRowAnimationNone];

[tableView endUpdates];

UIView-Encapsulated-Layout-Height संभवतया उस समय सेल की बाधाओं के आधार पर प्रारंभिक भार के दौरान सेल के लिए गणना की गई तालिका की ऊंचाई है।

Comments

मुझे अपने प्रश्न में कहा जाना चाहिए था, मैंने यह कोशिश की है और यह काम नहीं करता है। मैं UIView-Encapsulated-Layout-Height

— Rog

कम से कम एक जवाब प्रस्तुत करने के लिए वैसे भी इनाम है। एसओ की तरह लगता है कि यह अन्यथा वाष्पित हो जाएगा।

— रोज

Answer 7

एक अन्य संभावना:

यदि आप सेल की ऊँचाई की गणना करने के लिए ऑटो लेआउट का उपयोग कर रहे हैं (contentView की ऊँचाई, नीचे का अधिकांश समय), और यदि आपके पास uitableview विभाजक है, तो आपको सेल ऊँचाई पर लौटने के लिए विभाजक ऊँचाई जोड़ने की आवश्यकता है। एक बार जब आप सही ऊँचाई प्राप्त कर लेते हैं, तो आपके पास उस ऑटोलैयट चेतावनी नहीं होगी।

- (CGFloat)calculateHeightForConfiguredSizingCell:(UITableViewCell *)sizingCell {
   [sizingCell setNeedsLayout];
   [sizingCell layoutIfNeeded];
   CGSize size = [sizingCell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
   return size.height; // should + 1 here if my uitableviewseparatorstyle is not none

}

Comments

इससे मुझे एक ऐसे मामले में मदद मिली जहां मुझे कुछ जटिल सिमुलेटरों (iPad 6 प्लस) में एक बहुत ही जटिल सेल लेआउट में लेआउट ऊंचाई अस्पष्टता मिली। यह मुझे प्रतीत होता है कि कुछ आंतरिक गोलाई की त्रुटियों के कारण सामग्री थोड़ा निचोड़ा हुआ है और अगर बाधाओं को मेरे द्वारा अस्पष्टता से निचोड़ने के लिए तैयार नहीं किया गया है। तो लौटने के बजाय UITableViewAutomaticDimensionमें heightForRowAtIndexPathमैं लौट [sizingCell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize] + 0.1

— सिंह

मैं निश्चित रूप से मतलब है[sizingCell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize].height + 0.1

— लियो

लड़खड़ाते हुए; विभाजक को हटाने से मेरी तालिका को व्यवहार मिल गया, इसलिए धन्यवाद।

— शाहीमूर्ति

Answer 8

जेसी द्वारा प्रश्न की टिप्पणी में उल्लेख किया गया है , यह मेरे लिए काम करता है:

self.contentView.autoresizingMask = UIViewAutoresizingFlexibleHeight;

FYI करें, यह समस्या iOS 10 में नहीं होती है।

Comments

स्विफ्ट 4.2 में: self.contentView.autoresizingMask = [.flexibleHeight]

— airowe

Answer 9

UITableViewAutomaticDimension का उपयोग करते समय और सेल के अंदर एक दृश्य पर एक ऊंचाई की बाधा को बदलते समय मुझे यह त्रुटि हुई थी।

मुझे अंत में पता चला कि यह बाधा निरंतर मूल्य निकटतम पूर्णांक तक गोल नहीं होने के कारण था।

let neededHeight = width / ratio // This is a CGFloat like 133.2353
constraintPictureHeight.constant = neededHeight // Causes constraint error
constraintPictureHeight.constant = ceil(neededHeight) // All good!

Comments

यह वह टिप्पणी थी जिसने मुझे अपने मुद्दे में बांध दिया। मेरे पास एक छवि सेल है जो गतिशील रूप से (बढ़ता है और सिकुड़ता है) और अनुमानितRowHight = 50 और rowHeight = UITableViewAutomaticDimension के साथ एक टेबलव्यू। मैं अभी भी बाधाओं पर टूट रहा था, भले ही टेबलव्यू सही ऊंचाई थी। बाहर विभाजक 0.3333 ऊंचाई पर थे और यही वह था जो सेल में मेरी छवि के आकार की बाधा को तोड़ रहा था। विभाजकों को बंद करने के बाद सब ठीक हो गया। मुझे क्या देखने के लिए देने के लिए धन्यवाद चे।

— migs647

इस मामले में, एक अतिरिक्त बाधा बनाएँ, उदाहरण के लिए, नीचे की ओर> = view.bottomMargin+1@900। AutoLayout अतिरिक्त 1 बिंदु को समायोजित करने की कोशिश करता है, सेल का आकार बदलता है, विभाजक की ऊंचाई के कारण भ्रमित हो जाता है, कुछ बाधाओं को तोड़ने / आराम करने की कोशिश करता है, एक @ 900 पाता है, और यह खुलासा करता है। आपको बिना किसी चेतावनी के इच्छित लेआउट मिलता है।

— एंटोन

मेरा दिन बचाओ। वैसे भी कुछ घंटे

— एंटोन ट्रोपास्को

Answer 10

अपनी सामग्री को फिट करने के लिए पाठ दृश्य को आकार देना, और परिणामी ऊंचाई के लिए ऊंचाई की बाधा को अद्यतन UIView-Encapsulated-Layout-Heightकरना, मेरे लिए बाधा संघर्ष तय किया , उदाहरण के लिए:

[self.textView sizeToFit];
self.textViewHeightConstraint.constant = self.textView.frame.size.height;

Comments

आपने यह कहां किया? लेआउट में साक्षात्कार?

— stuckj

Answer 11

इस बग के साथ अपना सिर खुजाने के कुछ घंटे बिताने के बाद आखिरकार मुझे एक उपाय मिला जो मेरे लिए काम कर गया। मेरी मुख्य समस्या यह थी कि मेरे पास विभिन्न सेल प्रकारों के लिए कई nibs पंजीकृत थे, लेकिन एक सेल प्रकार को विशेष रूप से अलग-अलग आकार के लिए अनुमति दी गई थी (उस सेल के सभी उदाहरण एक ही आकार के नहीं होंगे)। जब टेबलव्यू उस प्रकार के एक सेल को समाप्त करने की कोशिश कर रहा था, तो यह मुद्दा पैदा हुआ और यह एक अलग ऊंचाई है। मैंने सेटिंग करके इसे हल किया

self.contentView.autoresizingMask = UIViewAutoresizingFlexibleHeight; self.frame = CGRectMake(0, 0, self.frame.size.width, {correct height});

जब भी सेल के पास इसके आकार की गणना करने के लिए इसका डेटा था। मुझे लगता है कि यह हो सकता है

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

कुछ इस तरह

cell.contentView.autoresizingMask = UIViewAutoresizingFlexibleHeight; cell.frame = CGRectMake(0, 0, self.frame.size.width, {correct height});

उम्मीद है की यह मदद करेगा!

Answer 12

IndexView से प्रतिनिधि के लिए TableView को सेल के लिए ऊंचाई मिलती है। तब से सेल प्राप्त करें cellForRowAtIndexPath:

top (10@1000)
    cell
bottom (0@1000)

if cell.contentView.height: 0 // <-> (UIView-Encapsulated-Layout-Height: 0 @ 1000) टॉप (10 @ 1000) के साथ परस्पर विरोधी (UIView- एन्कैप्सुलेटेड-लेआउट-ऊंचाई: 0 @ 1000),

क्योंकि वे प्राथमिकताएँ 1000 के बराबर हैं। हमें प्राथमिकता के तहत सर्वोच्च प्राथमिकता निर्धारित करने की आवश्यकता UIView-Encapsulated-Layout-Heightहै।

Answer 13

मुझे इस तरह एक संदेश मिल रहा था:

एक साथ बाधाओं को संतुष्ट करने में असमर्थ ...
...
...
...
NSLayoutConstraint: 0x7fe74bdf7e50 'UIView-Encapsulated-Layout-Height' V: [UITableViewCellCententView: 0x7fe75330c5c0 (21.5)]
... पुनर्प्राप्त करने का प्रयास करेंगे
...
ब्रेकिंग कॉन्स्टेंट NSLayoutConstraint: 0x7fe0f9b200c0 UITableViewCellContentView: 0x7fe0f9b1e090.bottomMargin = UILabel: 0x7fe0f9b1e970.bottom

मैं एक कस्टम उपयोग कर रहा हूँ UITableViewCellके साथ UITableViewAutomaticDimensionऊंचाई के लिए। और मैंने estimatedHeightForRowAtIndex:विधि भी लागू की है।

जो अड़चनें मुझे परेशानियाँ दे रही थीं, वह कुछ इस तरह दिख रही थीं

[NSLayoutConstraint constraintsWithVisualFormat:@"V:|-[title]-|" options:0 metrics:nil views:views];

इसके लिए बाधा को बदलना समस्या को ठीक करेगा, लेकिन एक अन्य उत्तर की तरह मुझे लगा कि यह सही नहीं था, क्योंकि यह एक बाधा की प्राथमिकता को कम करता है जिसे मैं चाहता हूं:

[NSLayoutConstraint constraintsWithVisualFormat:@"V:|-6@999-[title]-6@999-|" options:0 metrics:nil views:views];

हालाँकि, मैंने जो देखा वह यह है कि अगर मैं वास्तव में प्राथमिकता को हटा देता हूं, तो यह भी काम करता है और मुझे ब्रेकिंग की बाधाएं नहीं मिलती हैं:

[NSLayoutConstraint constraintsWithVisualFormat:@"V:|-6-[title]-6-|" options:0 metrics:nil views:views];

यह एक रहस्य है कि क्या अंतर है |-6-[title]-6-|और क्या है |-[title-|। लेकिन आकार निर्दिष्ट करना मेरे लिए कोई समस्या नहीं है और यह लॉग से छुटकारा दिलाता है, और मुझे अपनी आवश्यक बाधाओं की प्राथमिकता को कम करने की आवश्यकता नहीं है।

Answer 14

यह सेट करें view.translatesAutoresizingMaskIntoConstraints = NO;इस समस्या को हल करना चाहिए।

Comments

यह मेरे लिए पूरी तरह से काम करता है, भले ही यह सही समाधान नहीं था।

— एनका

Answer 15

मुझे संग्रह व्यू सेल के साथ भी ऐसी ही समस्या थी।

मैंने इसे अंतिम बाधा की प्राथमिकता को कम करके हल किया था जो सेल के नीचे से जुड़ा था (श्रृंखला में पिछले एक को ऊपर से नीचे तक देखने के लिए - यह अंततः वही है जो इसकी ऊंचाई निर्धारित करता है) 999 तक।

सेल की ऊंचाई सही थी, और चेतावनी चली गई।