-
Notifications
You must be signed in to change notification settings - Fork 780
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
Conversation
i.e. view with `backgroundView` attribute Add also BlurDesignable to table view to blur the background view
Generated by 🚫 Danger |
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
IBAnimatable/BlurDesignable.swift
Outdated
@@ -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) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
newLine missing
There was a problem hiding this comment.
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.
@phimage Thanks for doing this! It's true that a common behavior in iOS development.
Just needed someone to ask for it 😬
Yeah, that's annoying part with the CHANGELOGs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extension UICollectionViewCell: BackgroundDesignable {} | ||
extension UICollectionView: BackgroundDesignable {} | ||
|
||
fileprivate typealias BackgroundImageView = AnimatableImageView |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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?
IBAnimatable/BlurDesignable.swift
Outdated
@@ -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) { |
There was a problem hiding this comment.
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 {} |
There was a problem hiding this comment.
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 👍
@phimage thank you very much for a great PR. @tbaranes has answered your questions. I have 2 cents for them. We do need For the @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 |
@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 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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 well done.
@phimage I merge it now, Travis is failing because of |
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 |
i.e. view with
backgroundView
attributeAdd also
BlurDesignable
to table view to blur thebackgroundView
A lot of time I need to put a background image on this ui components without adding a specific
UIImageView
. With the same principle ofBlurDesignable
a view is added. But this time not in subviews hierarchy, with crapping things like scroll view, etc... but the special attributebackgroundView
to see background of a table, each cell view must be configured with clear color (or some transparency )
UICollectionView
could also conform toBackgroundImageDesignable
but there is noAnimatableCollectionView
yet, any reason?I must edit the change log on my own? could be weird with conflicts when there is multiple PR