Messagekit: Customize AvatarView position

[SD10]

Customize AvatarView position

It would be nice to be able to move the AvatarView around the cell.
I'm thinking we could allow it to be in 3 positions:

enum AvatarPosition {
    case top
    case messageCenter
    case bottom
}

This could play well with MessageContainerView customizations. Such as allowing the users to set which edge of the MessageContainerView has a tail and adjusting the avatar accordingly.

[fbartho]

Also maybe alwaysLeading / alwaysTrailing?

[SD10]

@fbartho Great idea. This would probably have to be a flag on MessagesCollectionViewFlowLayout.
We could have avatarAlwaysLeft or avatarAlwaysRight.

[fbartho]

Right! Note: the reason I suggested alwaysLeading / alwaysTrailing because I don't know what seems most natural for Right-to-left languages (RTL). -- Does slack or facebook messenger in RTL have the avatars flipped?

[SD10]

As for avatarAlwaysLeft and avatarAlwaysRight these would translate literally to always keep the avatar on the left or right side. If the developer is developing for a RTL then they would just choose avatarAlwaysRight.

I am fine with using leading / trailing though.

I have thought, very briefly, about exposing some sort of API that would flip everything for a RTL language. I'm not sure when but it will likely be supported in some way shape or form.

[fbartho]

@SD10 if you bind to the leading / trailing layoutAnchors, that happens automatically for the right visual elements!

[SD10]

Good to know. We will probably drop iOS 8 support before v1.0 and make the minimum target iOS 9.
I need UIStackView for the MessageInputBar I want to build 😅

[MacMeDan]

I think we may actually want to abstract this. The developer should not be deciding if it is alwayLeft or alwaysRight it should be determined by the language localization. Yes both methods could be implemented but we should but we should probably have a flag for this if it is a LTR language or not. I actually remember working on this for JSQ if fact with localization if we want to get tricky LTR languages will even display their images flipped. Did it here May be something we will want to do in the future.

@SD10 I fully support your thought there for dropping iOS8 but why not push all the way to iOS10 or dare I go as far to say iOS11? If there is not a specific reason I don't see why we would not. We have no current production users no actual reason to support legacy we don't have.

[SD10]

@MacMeDan Good thoughts on the challenges of localization. We'll have to review this issue when we cross that bridge. Using alwaysLeading and alwaysTrailing makes more sense now.

As for iOS version support, it's not about supporting current production users. Only supporting iOS 11 is a huge limitation because applications often need to support targets lower than the latest version of iOS. If we don't support their minimum target -- they can't use our library.

I'm fine with dropping iOS 8 support because with iOS 11 it will be 3 versions behind. I think iOS 9 support is still reasonable.

Take a look at which iOS versions Apple supports for each phone model:
https://www.statista.com/chart/5824/ios-iphone-compatibility/

Anyways, this is taken care of in #70. Minus localization because that is a separate issue.