J'ajoute une vue en bas d'un UITableView (ou UICollextionView ) mais pas en tant que cellule ou pied de page, mais je l'ajoute simplement à la vue de tableau elle-même (donc , au UIScrollView ) puis en jouant avec le contentInset du scroll. Le but est de conserver la vue en bas du contenu du tableau, au lieu de la fin du contenu. De cette façon, si le contenu est plus court que les limites du tableau, la vue est visible (image de gauche), mais si le contenu est plus grand, la vue apparaît à la fin du contenu (image de droite).
Voici un extrait du code:
a> let yCoord = collectionView.contentSize.height >= view.frame.height - viewHeight
? collectionView.contentSize.height
: view.frame.height - viewHeight
let bottomView = UIView(frame: CGRect(x: 0, y: yCoord, width: collectionView.contentSize.width, height: viewHeight))
collectionView.contentInset = UIEdgeInsets(top: 0, left: 0, bottom: viewHeight, right: 0)
collectionView.addSubview(bottomView)
Je me demande si ce type d'approche pourrait être considéré comme nuisible de quelque manière que ce soit, par exemple , problèmes avec AL, rotations, rechargement de la table ... Je n'en identifie aucun, en effet c'est une approche très similaire à la fonction pull-to-refresh avant iOS 6, mais j'en suis plutôt sûr avant de le pousser en production.
Si cela peut être considéré comme un problème, quelle solution proposez-vous en plus d'ajouter une nouvelle cellule?
3 Réponses :
Si vous voulez la fonctionnalité ci-dessus, vous devez prendre tableView et vue de dessous dans scrollView et donner une hauteur dynamique à tableView en fonction du contenu à l'aide de l'observateur de contenu et garder la vue du bas en bas de la vue de défilement et donner tableView en vue de haut en bas et donner une valeur supérieure ou égale à celle attribuée.
J'espère que cela fonctionnera.
Essayez ce code ci-dessous. Faites en sorte que la couleur de votre vue de pied de page soit claire et placez une autre vue dans votre vue de pied de page avec une contrainte inférieure, gauche, droite et de hauteur
@IBOutlet weak var footerView: UIView!
//MARK:- View Controller life cycle method
override func viewDidLoad() {
super.viewDidLoad()
yourTableView.addObserver(self, forKeyPath: "contentSize", options: .new, context: nil)
}
override func viewWillDisappear(_ animated: Bool) {
super.viewWillDisappear(animated)
yourTableView.removeObserver(self, forKeyPath: "contentSize")
}
override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?) {
if(keyPath == "contentSize"){
let contentHeight: CGFloat = yourTableView.contentSize.height
let tableHeight = yourTableView.frame.size.height
if contentHeight < tableHeight {
footerView.frame = CGRect(x: footerView.frame.origin.x, y: footerView.frame.origin.y, width: footerView.frame.size.width, height: CGFloat(tableHeight - contentHeight + 44.0))
// 44.0 is your initial footer height which you put in xib
} else {
footerView.frame = CGRect(x: footerView.frame.origin.x, y: footerView.frame.origin.y, width: footerView.frame.size.width, height: 44.0)
// 44.0 is your initial footer height which you put in xib
}
}
}
Je préférerais créer une sous-classe UIView qui encapsule la vue de table et la vue de pied de page flottante. J'évite de modifier la hiérarchie des vues des classes entièrement gérées par le framework et en utilisant une sous-classe il serait facile d'utiliser cette disposition ailleurs. En utilisant l'événement délégué de vue de défilement scrollViewDidScroll , il mettrait à jour le cadre de vue de pied de page chaque fois que l'utilisateur fait défiler. Au fait, j'utiliserais certainement des contraintes pour placer ma vue de pied de page plutôt que de jouer avec des cadres susceptibles de changer.
Y a-t-il quelque chose de dangereux dans votre mise en œuvre?
Vous n'avez pas mentionné où vous avez ajouté votre code. S'il s'agit de viewDidLoad, vous aurez des problèmes si vous utilisez la disposition automatique et que le cadre de la vue change en raison d'une rotation ou d'un changement de collection de traits. De plus, si votre contenu n'est pas statique, l'appel des données de rechargement invalidera la taille du contenu de la vue de table, ce qui créera également une vue de pied de page mal placée.
Où devrions-nous mettre ces lignes de code?
Doit-on KVO observer le cadre de la vue tableau et son contenu pour mettre à jour le cadre de la vue pied de page à chaque fois qu'ils changent?
Bien sûr que non! Apple a déjà fourni tous les événements dont nous avons besoin. Au moins, mettez ces lignes dans viewDidLayoutLayouts et assurez-vous de ne pas ajouter votre vue de pied de page plusieurs fois. viewDidLayoutLayouts est appelé à chaque fois que la vue du contrôleur est présentée.
Je l'ajoute lors de l'affichage de la dernière cellule. J'ai mis à jour la question.
Comment calculez-vous le yCoord? Pourquoi ne pas utiliser ces calculs pour décider si la vue doit être ajoutée au-dessus de notre vue de table ou en tant que tableViewFooterView? Ici, même si le contenu est plus court que la limite de la table, l'utilisateur peut faire défiler un peu la vue de la table (attendez-vous si vous définissez alwaysBounceVertical sur false, mais ce n'est pas un comportement natif)
Salut à tous. Je viens de publier un extrait de mon code mais ça marche. Je ne demande pas une solution de travail mais une meilleure. Je veux dire, je pense que vérifier la coordonnée du décalage de contenu et ainsi de suite est plus compliqué que de le faire comme ça, à mon humble avis. Quoi qu'il en soit, j'ai ajouté le code complet.