2016-12-08 11 views
10

मुझे लगता है कि मूल कारण है कि estimatedRowHeight अंतर्निहित UIScrollView.contentOffset के बारे में मान्यताओं बनाने के लिए प्रयोग किया जाता है, लेकिन यह हमेशा परिभाषा से गलत होगा, क्योंकि यह एक अनुमान है। सेल सामग्री और डिवाइस अभिविन्यास के आधार पर असली पंक्ति ऊंचाई पूरी तरह अलग होती है।मैं इस तालिका को कैसे ठीक कर सकता हूं या वर्कअराउंड कर सकता हूं टेक्स्ट देखें ऑटोटायआउट गड़बड़?

यहां तक ​​कि अगर मैं estimatedHeightForRowAtIndexPath लागू करीब अनुमान खामियों अभी भी देखते हैं प्रदान करते हैं।

तो आप शीर्ष पर शुरू और नीचे स्क्रॉल सब है अच्छी तरह से क्योंकि tableview वास्तविक सेल ऊंचाइयों सीखता है के रूप में यह सेल पदों के साथ सिंक में contentOffset रखने से चला जाता है जब। लेकिन जैसे ही आप सभी असली सेल ऊंचाई बदलते हैं, तो UITableView अब सिंक से बाहर निकलता है, यह नहीं जानता कि कहां स्क्रॉल करना है।

लेकिन वहाँ भी अजनबी भी हो बातें, कभी कभी UITextField सेल अन्य कक्ष के शीर्ष पर खत्म हो जाएगा रहे हैं, और वहाँ अटक रह ...

वैसे भी मैं यह सब एक सरल उदाहरण के लिए नीचे उबला हुआ है। iPhone के साथ और अगर सिम्युलेटर का उपयोग कर तो सॉफ्टवेयर कुंजीपटल सक्षम

https://github.com/trapper-/autolayout-glitch

  • टेस्ट।
  • आप कई दृश्य खामियों देखेंगे बस के आसपास खेल रहे स्क्रॉल, खेतों का चयन करके और घूर्णन।
  • एक साधारण दोहराने योग्य उदाहरण के लिए।
  • नीचे नीचे स्क्रॉल करें।
  • , UITextField's पिछले कुछ में से एक का चयन करें ताकि UITableView सुनिश्चित करने के लिए क्षेत्र दिखाई जाएगी स्क्रॉल करने के लिए की आवश्यकता होगी।
  • डिवाइस को घुमाएं।
+0

हालांकि आदर्श नहीं है, लेकिन tableView उदाहरण पर एक reloadData कॉल मदद करनी चाहिए। क्या तुमने कोशिश की? –

+0

Autolayout UITableView के साथ अच्छी तरह से काम नहीं करता है। एक संग्रह दृश्य का उपयोग करने पर विचार करें। यह UITableView की सीमाओं के बारे में एक महान पोस्ट है: https://pspdfkit.com/blog/2017/the-case-for-deprecating-uitableview/ –

+0

क्या आप कह रहे हैं कि 'यूआईसीओलेक्शन व्यू' में इन समान प्रकार के ग्लिच नहीं हैं? यदि ऐसा है तो यह एक अच्छा समाधान होगा। – trapper

उत्तर

1

मैंने कुछ मिनट के लिए आपके कोड के साथ खिलवाड़ किया, क्योंकि मैं इसी तरह के मुद्दों से जूझ रहा था। मुझे आशा थी कि मैं मदद कर सकता हूं, लेकिन मुझे इसे पूरी तरह से ठीक नहीं किया गया।

मैं जो पेशकश कर सकता हूं वह यह है कि मैंने कुछ प्रगति की है।

जब डिवाइस घूमता है, तो आप UIViewController तरीकों कि आपको बता यह होगा, और हुआ लागू करना चाहिए। जब ऐसा होगा, दृश्य पंक्तियों को कैश करें। फिर इसके बाद, तालिका को फिर से लोड करें और उन दृश्य पंक्तियों तक स्क्रॉल करें।

यह इस तरह दिखता है:

- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration 
{ 
    // Save the visible row position 
    self.visibleRows = [self.tableView indexPathsForVisibleRows]; 
} 

-(void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation 
{ 
    [self.tableView reloadData]; 
    // Scroll to the saved position prior to screen rotate 
    [self.tableView scrollToRowAtIndexPath:[self.visibleRows objectAtIndex:0] atScrollPosition:UITableViewScrollPositionBottom animated:NO]; 
} 

visibleRows अपने ViewController पर एक सरणी @property है।

यह rightish जगह पर जाना बना (मुझे लगता है कि यदि आप वास्तव में अलग-अलग सेल है कि उपयोगकर्ता से छेड़छाड़ की गई थी बंद संग्रहीत, यह आप 100% सही सेल करने के लिए हर बार मिलेगा।

यह क्या किया ऐसा नहीं है, यह है कि अभी भी कई डिवाइस रोटेशन के साथ गलत तरीके से (अवसर पर) नृत्य किया जा रहा है।

फिर से, समाधान नहीं - लेकिन मैं जो साझा करता हूं उसे साझा करना चाहता था इसलिए उम्मीद है कि यह आपको समाधान ढूंढने में मदद करेगा ।

शुभकामनाएं!

+0

दृश्य पंक्ति ट्रैकिंग के बारे में कोई बुरा विचार नहीं है, लेकिन मुझे scrollToRowAtIndexPath विधि के साथ बहुत सी समस्याएं भी हैं। यह नहीं जानता कि कहां स्क्रॉल करना है। यानि सही सामग्री पर एक अनुक्रमणिका पाथ का सही ढंग से अनुवाद नहीं करता है ऑफसेट। – trapper

+0

हाँ, मुझे संदेह है कि इस तथ्य के साथ ऐसा करना है कि कोशिकाओं को पहले स्थान पर सभी गिलहरी से बाहर रखा जा रहा है। –

0

मैं काफी कुछ आपकी समस्या लाइन के साथ है कर रहा हूँ:

self.tableView.estimatedRowHeight = 44; 

यह tableview इस अनुमान की उंचाई कुछ अनुकूलन कर का परिणाम है। मैं काफी समझ नहीं पाया कि टेक्स्टफील्ड का चयन होने पर यह क्यों टूटता है, लेकिन यही वह है जिसे मैं इसे कम करने में कामयाब रहा। आप वास्तव में स्पष्ट रूप से प्रत्येक पंक्ति के लिए ऊंचाई की गणना करते हैं, तो इस मुद्दे को दूर जाने के लिए लगता है (ध्यान दें कि यह सिर्फ एक मोटा उदाहरण है, और आप वास्तविक क्रियान्वयन में थोड़ा और सोचा डाल करने की आवश्यकता होगी):

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { 

    if (indexPath.row % 2) { 

     return 44.f; 

    } else { 

     NSString *text = @"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."; 

     CGRect frame = [text boundingRectWithSize:CGSizeMake(350.f, CGFLOAT_MAX) 
              options:NSStringDrawingUsesLineFragmentOrigin 
             attributes:@{ NSFontAttributeName:[UIFont systemFontOfSize:14.f] } 
              context:nil]; 

     return frame.size.height; 
    } 
} 
0

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

- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath (NSIndexPath *)indexPath 
{ 
    if (indexPath.row % 2) { 
     return 44.0f; 
    } else { 
     return 175.0f; 
    } 
} 

अब UITextField साथ अजीब जारी करने के लिए के रूप में, मैं तुम्हें विचार करने के लिए है कि इन कोशिकाओं को भी रोटेशन पर पुन: उपयोग किया जा रहा है, इसलिए यदि UITextField अभी भी पहले प्रत्युत्तर भले ही सेल पुन: उपयोग किया गया है आवश्यकता हो सकती है लगता है, तो यह वह जगह है जहां कीबोर्ड को टेक्स्ट फ़ील्ड को ट्रैक करने में समस्या हो रही है।

तुम बस सेल पर एक टैग सेट करके ऐसा परिणाम देख सकते हैं और देखने के कैसे यह बेतरतीब ढंग से तो जैसे रोटेशन पर आदेश में परिवर्तन कर सकते हैं:

NSString* cellID = @"TextFieldCell"; 
TextFieldCell *cell = [tableView dequeueReusableCellWithIdentifier:cellID forIndexPath:indexPath]; 
NSLog(@"cell %@, changing to %@", @(cell.tag), @(indexPath.row)); 
cell.tag = indexPath.row; 
return cell; 

उस के लिए मेरे सुझाव या तो 1) में पाठ फ़ील्ड का उपयोग नहीं करने के लिए है तालिका दृश्य कक्ष, या 2) स्क्रॉलिंग आइटम पर उपयोगकर्ता इनपुट पाठ देने के लिए एक नए तरीके के बारे में सोचें। उदाहरण के लिए, तालिका दृश्य के शीर्ष पर दृश्य में टेक्स्ट फ़ील्ड प्रतिलिपि डालें और पाठ को इनपुट करते समय मैन्युअल रूप से प्रबंधित करें और फिर टेक्स्ट पूर्ण होने पर टेक्स्ट को सेल पर कॉपी करें। 3) विकल्प 3 यह देखने का प्रयास करना है कि कोई कीबोर्ड प्रबंधक लाइब्रेरी सहायता कर सकती है या नहीं। मुझे वास्तव में IQKeyboardManager का उपयोग करना पसंद है। कीबोर्ड प्रबंधन को हल करने के लिए यह वास्तव में आसान है।

संबंधित मुद्दे