TableView inside tableview cell swift 3

2019-08-20 07:13发布

问题:

I'm tring to display tableView inside tableview cell while both parent and child tableview have dynamic cell height.

First problem is not all cells show child tableView. In cells that show childTableView, childTableView height is not right.

 class ViewController: UIViewController {

@IBOutlet weak var tableView: UITableView!
var items = ["Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front !"

    ,"Consider, though, that Swift us a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!"  ,"ccc", "ddd","Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!", "Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!","fff", "Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!","hhhh","Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!","jjj", "Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!", "Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!Consider, though, that Swift uses value types almost exclusively, which is mind-boggling when you consider that the situation in Objective-C is completely the reverse.As a code architect under the new Swift paradigm, you need to doa bit of up-front planning as to how your data will be used. You can solve almost any situation witheither value types or reference types — but using them incorrectly could result in tons of bugs and confusing cde.In all cases, common sense and a willingness to change your architecture when new requirements come up is the best approach.Challenge yourself to follow the Swift model; you just might turn out some nicer code than you originally thought!"]
override func viewDidLoad() {
    super.viewDidLoad()
    setUpTableView();
}

func setUpTableView(){
    tableView.register(UINib(nibName: "MCQCell", bundle: nil), forCellReuseIdentifier: "MCQCell");
    tableView.estimatedRowHeight = 100;
    tableView.rowHeight = UITableViewAutomaticDimension;
}
override func didReceiveMemoryWarning() {
    super.didReceiveMemoryWarning()
    // Dispose of any resources that can be recreated.
 }
}   

  extension ViewController: UITableViewDelegate, UITableViewDataSource{
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    if(tableView == self.tableView){
        let cell = tableView.dequeueReusableCell(withIdentifier: "MCQCell", for:indexPath) as! MCQCell
        let row = indexPath.row
        cell.lblTxt.text = items[row];
        cell.tableView.tag = row;
        cell.tableView.dataSource = self;
        cell.tableView.delegate = self;
        cell.tableView.estimatedRowHeight = 60;
        cell.tableView.rowHeight = UITableViewAutomaticDimension;
        cell.setNeedsLayout()
        return cell;
    }else{
        let cell = tableView.dequeueReusableCell(withIdentifier: "ChoiceCell", for:indexPath) as! ChoiceCell
        let row = indexPath.row
        cell.lblTxt.text = items[row];
        return cell;
    }
}
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    if(tableView == self.tableView){
        return items.count;
    }else{
        return 5;
    }
}


func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
    return UITableViewAutomaticDimension;
}
}

and inside Parent tableview cell I just register childTableView cell and reloading tableview

  override func systemLayoutSizeFitting(_ targetSize: CGSize,
                             withHorizontalFittingPriority horizontalFittingPriority: UILayoutPriority,
                             verticalFittingPriority: UILayoutPriority) -> CGSize{

    tableView.reloadData()
    let size = CGSize(width: targetSize.width,
                      height: tableView.frame.origin.y + tableView.contentSize.height)
    return size

}

what I'm doing wrong?

回答1:

-> Disable childtableview scrolling.        

    func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
                return CGFloat((ChildTableviewCellItem.count) * Height_childtableviewcell+Height_MainTableviewcell)
            }