Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rely on original delegate for section row, delegate, and footer heights #460

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

maadlog
Copy link

@maadlog maadlog commented Oct 9, 2021

Summary

This PR attempts to provide the functionality required on issue #424 here

The approach was to delegate on the original table view delegate's implementation of the heightForXXX and estimatedHeightForXXX family of methods.
The main issue faced is that given that those methods are optionals on the Objc protocol, then the return types aren't optional.

I was about to return UITableView.automaticDimension, which works similarly, but reading this piece of doc, it states that the value returned by heightForRow takes precedence over the property rowHeight. Following that logic, and to avoid breaking any current implementations, i delegated on the tableView's XXXheight and estimatedXXXHeight and properties, which i'm assuming (and please correct me if i'm wrong) are either properly set by users to the expected height or automaticDimension

Videos

Different-heights-example.mp4
Default-heights-example.mp4

Steps to reproduce

Added on the iOS example:
ViewController > SkeletonTableViewDelegate

    func collectionSkeletonView(_ skeletonView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return 10
    }

    func numSections(in collectionSkeletonView: UITableView) -> Int {
        return 2
    }

    func numberOfSections(in tableView: UITableView) -> Int {
        return 2
    }

And to test the different heights you can use any set of hardcoded values, including automaticDimension

    func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
        if (indexPath.section == 0) {
            return UITableView.automaticDimension
        } else {
            return 250
        }
    }

    func tableView(_ tableView: UITableView, heightForHeaderInSection section: Int) -> CGFloat {
        if (section == 0) {
            return 10
        } else {
            return 50
        }
    }

    func tableView(_ tableView: UITableView, heightForFooterInSection section: Int) -> CGFloat {
        if (section == 0) {
            return 10
        } else {
            return 50
        }
    }

Requirements (place an x in each of the [ ])

@maadlog maadlog force-pushed the issue/424-height-for-section-header branch from 9995c2a to ee434a0 Compare October 11, 2021 12:06
@Juanpe
Copy link
Owner

Juanpe commented Nov 4, 2021

Hi, @maadlog 👋🏼 thanks for this PR!

I've got a doubt about if this code works fine when the library calculates the number of rows. For example, in this line SkeletonCollectionDataSource.swift:42, we calculate the number of rows based on the height. But we are not considering that the sections or the cells could have different heights.

A possible solution could be using only this code when the developer defines the number of rows. WDYT?

@maadlog
Copy link
Author

maadlog commented Nov 24, 2021

Hi @Juanpe !
Sounds good! I'll give it a spin and submit again!

@Juanpe
Copy link
Owner

Juanpe commented Dec 19, 2021

Hi @maadlog! Let me know if you need help to finish this feature :)

@Juanpe
Copy link
Owner

Juanpe commented Jan 11, 2022

@maadlog, Any updates on that? Don't worry if you don't have the bandwidth to do it. Let me know, and I could continue the development 😉

@maadlog
Copy link
Author

maadlog commented Mar 22, 2022

Hi @Juanpe ! Sorry about the late response, i got swamped with the start of the year and didn't get any bandwidth to continue. Feel free to continue the development and thanks for the patience!

@Eke
Copy link

Eke commented Jan 9, 2023

@maadlog Any updates on this? This may be very useful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants