Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
maadlog wants to merge1 commit intoJuanpe:main
base:main
Choose a base branch
Loading
frommaadlog:issue/424-height-for-section-header

Conversation

@maadlog
Copy link

@maadlogmaadlog commentedOct 9, 2021
edited
Loading

Summary

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

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

I was about to returnUITableView.automaticDimension, which works similarly, but readingthis piece of doc, it states that the value returned byheightForRow takes precedence over the propertyrowHeight. Following that logic, and to avoid breaking any current implementations, i delegated on the tableView'sXXXheight andestimatedXXXHeight and properties, which i'm assuming (and please correct me if i'm wrong) are either properly set by users to the expected height orautomaticDimension

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, includingautomaticDimension

    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 anx in each of the[ ])

Eke and Jarenbeaver reacted with thumbs up emojiJarenbeaver reacted with hooray emoji
@maadlogmaadlogforce-pushed theissue/424-height-for-section-header branch from9995c2a toee434a0CompareOctober 11, 2021 12:06
@Juanpe
Copy link
Owner

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 lineSkeletonCollectionDataSource.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

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

Juanpe reacted with heart emoji

@Juanpe
Copy link
Owner

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

@Juanpe
Copy link
Owner

@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

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 commentedJan 9, 2023

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

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@maadlog@Juanpe@Eke

[8]ページ先頭

©2009-2025 Movatter.jp