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

Allow to set a background image to table view and cells views #416

Merged
merged 2 commits into from
Apr 2, 2017

Conversation

phimage
Copy link
Member

@phimage phimage commented Mar 25, 2017

i.e. view with backgroundView attribute
Add also BlurDesignable to table view to blur the backgroundView

  • A lot of time I need to put a background image on this ui components without adding a specific UIImageView. With the same principle of BlurDesignable a view is added. But this time not in subviews hierarchy, with crapping things like scroll view, etc... but the special attribute backgroundView

  • to see background of a table, each cell view must be configured with clear color (or some transparency )

  • UICollectionView could also conform to BackgroundImageDesignable but there is no AnimatableCollectionView yet, any reason?

  • I must edit the change log on my own? could be weird with conflicts when there is multiple PR

i.e. view with `backgroundView` attribute
Add also BlurDesignable to table view to blur the background view
@IBAnimatableBot
Copy link

IBAnimatableBot commented Mar 25, 2017

1 Error
🚫 Any changes to library code need a summary in the Changelog.
1 Warning
⚠️ Consider adding supporting documentation to this change. Documentation can be found in the docs directory.

Generated by 🚫 Danger

Copy link
Member

@tbaranes tbaranes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made a first quick review of this, just a few small comments, if you can take a look, I will make a second review after that.

There's also the CHANGELOG and documentation entry missing.

public extension BackgroundImageDesignable where Self: BackgroundDesignable {
public func configureBackgroundImage() {
if let image = backgroundImage {
if let imageView = self.backgroundView as? AnimatableImageView {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That self. isn't mandatory, is it? As the others below

Copy link
Member Author

@phimage phimage Mar 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

self is not mandatory I think (there is no closure)
I put self when possible to avoid some issue when renaming stuff and local variable become class variable etc...
But there is poor or con, and swift lint do not have this rule yet
realm/SwiftLint#321

Like I do in previous PR I will remove it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@phimage It is a controversial topic for keeping self or not. We try to omit self if possible for our repo, can you also follow that?

extension UICollectionViewCell: BackgroundDesignable {}
extension UICollectionView: BackgroundDesignable {}

fileprivate typealias BackgroundImageView = AnimatableImageView
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about that typealias, I feel that bring more confusion than using directly AnimatableImageView.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am thinking about doing something like

class PrivateImageView: AnimatableImageView {}

so making typealias allow to change quickly

but I can remote it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see advantages to not use AnimatableImageView directly here, is there a reason?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree with @tbaranes for using AnimatableImageView instead of typealias BackgroundImageView.

On the other hand for the private subclass. I think creating a private subclass is good for some case I can think of. For example, we can check like backgroundView as? PrivateImageView then we know backgroundView must be set within extension BackgroundImageDesignable. Another someone may use AnimatableImageView for backgroundView outside of IBAnimatable framework. And we should not reset backgroundView = nil if backgroundView is not original set by extension BackgroundImageDesignable.

Is it the case you are thinking of, @phimage ? I leave it to you to make a decision to use private class PrivateAnimatableImageView: AnimatableImageView or not.

@@ -28,11 +28,14 @@ public extension BlurDesignable where Self: UIView {
configureBlurEffectStyle method, should be called in layoutSubviews() method
*/
public func configureBlurEffectStyle() {
configureBlurEffectStyle(self)
}
public func configureBlurEffectStyle(_ blurableView: UIView) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

newLine missing

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shall we use public func configureBlurEffectStyle(for blurableView: UIView)? using for instead of _ there.

@tbaranes
Copy link
Member

@phimage Thanks for doing this! It's true that a common behavior in iOS development.

UICollectionView could also conform to BackgroundImageDesignable but there is no AnimatableCollectionView yet, any reason?

Just needed someone to ask for it 😬
There's no reason to not have it, just no one take the time to do it or need it until now.

I must edit the change log on my own? could be weird with conflicts when there is multiple PR>

Yeah, that's annoying part with the CHANGELOGs

Copy link
Member

@JakeLin JakeLin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@phimage well done on this PR, can you please address the comment from @tbaranes , and we should be ready to go after that.

extension UICollectionViewCell: BackgroundDesignable {}
extension UICollectionView: BackgroundDesignable {}

fileprivate typealias BackgroundImageView = AnimatableImageView
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree with @tbaranes for using AnimatableImageView instead of typealias BackgroundImageView.

On the other hand for the private subclass. I think creating a private subclass is good for some case I can think of. For example, we can check like backgroundView as? PrivateImageView then we know backgroundView must be set within extension BackgroundImageDesignable. Another someone may use AnimatableImageView for backgroundView outside of IBAnimatable framework. And we should not reset backgroundView = nil if backgroundView is not original set by extension BackgroundImageDesignable.

Is it the case you are thinking of, @phimage ? I leave it to you to make a decision to use private class PrivateAnimatableImageView: AnimatableImageView or not.

public extension BackgroundImageDesignable where Self: BackgroundDesignable {
public func configureBackgroundImage() {
if let image = backgroundImage {
if let imageView = self.backgroundView as? AnimatableImageView {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@phimage It is a controversial topic for keeping self or not. We try to omit self if possible for our repo, can you also follow that?

@@ -28,11 +28,14 @@ public extension BlurDesignable where Self: UIView {
configureBlurEffectStyle method, should be called in layoutSubviews() method
*/
public func configureBlurEffectStyle() {
configureBlurEffectStyle(self)
}
public func configureBlurEffectStyle(_ blurableView: UIView) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shall we use public func configureBlurEffectStyle(for blurableView: UIView)? using for instead of _ there.

extension UITableViewHeaderFooterView: BackgroundDesignable {}
extension UITableView: BackgroundDesignable {}
extension UICollectionViewCell: BackgroundDesignable {}
extension UICollectionView: BackgroundDesignable {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It took me a while to understand this, I found out is a great idea for having a protocol BackgroundDesignable Because we can't use protocol extension for conforming different classes like public extension BackgroundImageDesignable where Self: UITableViewCell or UITableViewHeaderFooterView or UITableView or UICollectionViewCell or UICollectionView. To have BackgroundDesignable and make the code looks better. Well done 👍

@JakeLin
Copy link
Member

JakeLin commented Mar 27, 2017

@phimage thank you very much for a great PR. @tbaranes has answered your questions. I have 2 cents for them.

We do need AnimatableCollectionView and AnimatableCollectionViewCell, we can see there is a card/issue for that #53. But as @tbaranes said, we didn't do it because no one asked for. It will be great if you can offer some hand on it. BackgroundImageDesignable is great for AnimatableCollectionView and AnimatableCollectionViewCell as well.

For the CHANGELOG.md, it is annoying, we have to rebase every time before we merge into master. But good for the user to check all changes. Please modify it when you submit a PR.

@phimage please let me know if you would like to offer some small helps on this project and join IBAnimatable GitHub organisation as an internal contributor. We have a Slack channel for all internal contributors as well. Thanks again for all you contributions, you make IBAnimatable better 💪

@JakeLin JakeLin added this to the 4.0 milestone Mar 28, 2017
@phimage
Copy link
Member Author

phimage commented Mar 28, 2017

I will make the change after finishing with #418

@JakeLin ok for organisation and Slack
I have some other topics that I want to add to IBAnimatable, and some like buttons touch animation must be discussed

@JakeLin
Copy link
Member

JakeLin commented Mar 28, 2017

@phimage welcome onboard. I have sent you an invite to be an internal contributor of the IBAnimatable organisation. Our rule is simple: There is no pressure to work on the project. Everyone has the same access to the repo. We use feature branch like feature/animatable-collection-view or bugfix/fix-corner-radius and PR to master. We are open to any opinions. Once we have one or two 👍 , we can merge the PRs. Please shout out if you have any question.

Can you also please send me your Slack account (email)? You can find my email on my GitHub profile page. Thanks

…mage

# Conflicts:
#	IBAnimatable.xcodeproj/project.pbxproj
#	IBAnimatable/AnimatableCollectionViewCell.swift
#	IBAnimatable/AnimatableTableViewCell.swift
Copy link
Member

@JakeLin JakeLin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 well done.

@JakeLin JakeLin merged commit e7cf528 into IBAnimatable:master Apr 2, 2017
@JakeLin
Copy link
Member

JakeLin commented Apr 2, 2017

@phimage I merge it now, Travis is failing because of bundle exec danger. But I can see the app has been built successfully. Thanks for your PR, well done 👍

@tbaranes
Copy link
Member

tbaranes commented Apr 2, 2017

There's a documentation and example app update missing, should we add an issue? Pretty sure we will forget about this otherwise 😬

I added an entry in #238 for the example app

@lastMove lastMove mentioned this pull request Apr 2, 2017
11 tasks
@tbaranes tbaranes modified the milestones: 4.x, 4.0 Apr 20, 2017
@phimage phimage deleted the feature-backgroundimage branch April 22, 2018 10:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants