Conversation
Sources/MessageBubble.swift
Outdated
| public let highlightedImage: UIImage | ||
|
|
||
| public func image(highlighted: Bool) -> UIImage { | ||
| return highlighted ? image : highlightedImage |
There was a problem hiding this comment.
This will probably be removed/repurposed considering we most likely won't use images for bubbles. The return values are flipped though 😛
There was a problem hiding this comment.
So why don't we remove this now? I feel like this a key point in this projects development where we have an opportunity to remove any cruft.
Codecov Report
@@ Coverage Diff @@
## master #5 +/- ##
=======================================
Coverage ? 100%
=======================================
Files ? 1
Lines ? 7
Branches ? 0
=======================================
Hits ? 7
Misses ? 0
Partials ? 0Continue to review full report at Codecov.
|
Sources/MessageData.swift
Outdated
|
|
||
| case video(file: NSURL, thumbnail: UIImage) | ||
|
|
||
| case system(String) |
There was a problem hiding this comment.
What is MessageData.system? or rather; what is the difference with .text and .system
There was a problem hiding this comment.
I think a little code comment will be helpful for people to understand.
There was a problem hiding this comment.
I'm actually not sure because this is code leftover from the old repo. The only thing to be concerned about for the moment is MessageData.text. v1 should be basic messages and then expand to Media data types from there.
@towry eventually the code will be fully commented by v1. right now I'm just hacking things together 😅
There was a problem hiding this comment.
IMO I would suggest removing anything that does not make any since. I would rather not have things then to start out with bloat right off the bat. But that might just be me.
|
Some things are shaping up but the code is still very rough. A lot is subject to change. I'm struggling over using a UICollectionViewController opposed to a regular UIViewController. I'd like my collectionView to be typed as Type casting everywhere 😭 |
MacMeDan
left a comment
There was a problem hiding this comment.
Remove anything that is not understood or that is not fully implemented.
Sources/MessageBubble.swift
Outdated
| public let highlightedImage: UIImage | ||
|
|
||
| public func image(highlighted: Bool) -> UIImage { | ||
| return highlighted ? image : highlightedImage |
There was a problem hiding this comment.
So why don't we remove this now? I feel like this a key point in this projects development where we have an opportunity to remove any cruft.
|
|
||
| var sentDate: Date { get } | ||
|
|
||
| var data: MessageData { get } |
There was a problem hiding this comment.
I don't know why we would not have the sentDate as a part of the messageData. Can we think of a reason we would want this?
There was a problem hiding this comment.
I also get confused with naming. Here "MessageData" is the enum of different message category, while the protocol is holding the message content. It's better to name the protocol as "MessageData" and the enum as "MessageType".
There was a problem hiding this comment.
I had similar concerns. I'm considering:
MessageType -> MessageRepresentable
MessageData -> MessageType
|
v0.1.0 Features:
|
|
|
||
| override func apply(_ layoutAttributes: UICollectionViewLayoutAttributes) { | ||
| guard let attributes = layoutAttributes as? MessagesCollectionViewLayoutAttributes else { return } | ||
| print(attributes.avatarSize) |
There was a problem hiding this comment.
For print statements, you should probably forward them to a print statement that only works in DEBUG mode.
There was a problem hiding this comment.
@ArtSabintsev I left those by accident 👍 Thanks. I would never allow them in a release
There was a problem hiding this comment.
I guess the print statements is temporary here, I would add a comment to such thing as to be removed. Even in debug mode, other people may not want to see all kind print messages in the console. But it is good to decorate print statement in a DEBUG util in case the code being merged to master branch or we can use swift lint tool to check that.
There was a problem hiding this comment.
All the code will be cleaned up before any merge to master. Having this PR open is just to show the public that there is work being done.
| return attributes.messageFont == messageFont && attributes.avatarSize == avatarSize && | ||
| attributes.avatarToEdgePadding == avatarToEdgePadding && attributes.avatarBottomPadding == avatarBottomPadding && | ||
| attributes.avatarToContainerPadding == avatarToContainerPadding && attributes.messageLeftRightPadding == messageLeftRightPadding && | ||
| attributes.direction == direction |
There was a problem hiding this comment.
Better formatting.
return attributes.messageFont == messageFont &&
attributes.avatarSize == avatarSize &&
attributes.avatarToEdgePadding == avatarToEdgePadding &&
attributes.avatarBottomPadding == avatarBottomPadding &&
attributes.avatarToContainerPadding == avatarToContainerPadding &&
attributes.messageLeftRightPadding == messageLeftRightPadding &&
attributes.direction == direction
Sources/MessageData.swift
Outdated
|
|
||
| case photo(UIImage) | ||
|
|
||
| case video(file: NSURL, thumbnail: UIImage) |
There was a problem hiding this comment.
Will the video type apply a UIButton to as its internal property? Or is it autoplay when video is sent?
There was a problem hiding this comment.
These aren't commented out yet but v1 will only support basic types like text(String). More details to come when I write up a Vision.md
| let containerX = contentView.frame.width - attributes.messageLeftRightPadding - containerWidth | ||
| let containerY: CGFloat = 0 | ||
| messageContainerView.frame = CGRect(x: containerX, y: containerY, width: containerWidth, height: containerHeight) | ||
| } |
There was a problem hiding this comment.
The logic from the AvatarSizeCalculator is blocking incoming avatar. And there is no difference between incoming and outgoing case. Recommend to add a todo list to remove this constraint.
There was a problem hiding this comment.
It's half implemented, not done yet. This branch is really outdated.
| func setupConstraints() { | ||
|
|
||
| messagesCollectionView.translatesAutoresizingMaskIntoConstraints = false | ||
| view.addConstraint(NSLayoutConstraint(item: messagesCollectionView, attribute: .top, relatedBy: .equal, toItem: topLayoutGuide, attribute: .bottom, multiplier: 1, constant: 0)) |
There was a problem hiding this comment.
Sorry, just here sniffing around.
Why not using anchors? Minimum targets?
There was a problem hiding this comment.
Yes, minimum targets. I struggled with the decision to support iOS 8. I figured why not unless it becomes a hassle.
Sources/AvatarSizeCalculator.swift
Outdated
|
|
||
| class AvatarSizeCalculator { | ||
|
|
||
| func avatarSizeFor(messageType: MessageType, with layout: MessagesCollectionViewFlowLayout) -> CGSize { |
There was a problem hiding this comment.
If I may,
func avatarSize(for messageType: MessageType, with layout: MessagesCollectionViewFlowLayout) would make the calling site read better. :)
|
|
||
| fileprivate extension String { | ||
|
|
||
| func height(considering width: CGFloat, font: UIFont) -> CGFloat { |
There was a problem hiding this comment.
Just another tiny suggestion:
func height(considering width: CGFloat, and font: UIFont)would produce a calling site reading experience a bit smoother.
height(considering: width, and: UIFont.systemFont...)Also, this is nice for views with number of lines = 0. If you want to have a label with max number of lines = 2 for example, this won't do it as it will only consider the text. That way I would prefer the sizeThatFits from the label.
|
Hi @ everyone, first and foremost sorry for the delay! I ran into a nasty bug that ate up most of my time. I'm sure that most of you have gotten bored looking for some way to contribute, but let's not take this PR too seriously. It was primarily to show people this repo is active. It's a WIP so you may see some hacky code or half implemented solutions. It doesn't mean I have the intention of leaving them this way 😅 |
|
|
||
| func avatarForMessage(_ message: MessageType, at indexPath: IndexPath, in collectionView: UICollectionView) -> Avatar { | ||
| let image = isFromCurrentSender(message: message) ? #imageLiteral(resourceName: "Steve-Jobs") : #imageLiteral(resourceName: "Tim-Cook") | ||
| return Avatar(placeholderImage: image) |
There was a problem hiding this comment.
Why not let Sender own the Avatar? To make the API more user friendly. We don't need to map the avatar to message manually.
func avatarForMessage(_ message: MessageType, at indexPath: IndexPath, in collectionView: UICollectionView) -> Avatar {
return message.sender.avatar
}
There was a problem hiding this comment.
Hey @lzyraining thanks for the feedback!
Deciding how to expose an API that allows for easy customization will be a difficult task. I hope to release a really basic v0.1.0 beta in the next few hours and will be looking for feedback/suggestions.
As for your suggestion, I don't think Sender is a good fit for the responsibility of Avatar because some people may not even want Avatars. I'd like to keep this types responsibility minimal. I've even considered making it a protocol.
There was a problem hiding this comment.
@SD10 I agree that it's difficult to build easy customized API. Thanks for the optional type in swift, we can simple handle who don't want Avatars by putting a question mark.
I like the idea using protocol for some models. Swift is basically protocol oriented programming language. It's amazing that protocol allows inheritance and extension to make customize and default values easy. But my concern is that we are build a framework for all potential use. From a user's perspective, I don't want to build all the models which are declared as protocol in the library. I just want to it easy to use.
There was a problem hiding this comment.
@lzyraining Thanks, I had considered making Avatar optional here as well. It will take a bit of time to decide on a nice API. The great thing is we don't have to worry about API stability at this moment 😃
Thanks for raising the concerns of having to build the models required by protocols. I was originally thinking that people would probably already have a User model that they could conform Sender to -- but I see this could also be difficult and intrusive.
Let cell support diary quote message type
No description provided.