Closed Cristiane-Burlamaqui closed 3 years ago
@Cristiane-Burlamaqui Thank you for the issue. It is not exactly flickering - it is additional positioning as due to navigation bar and keyboard frame change not everything can be correctly calculated during the rotation. Also the amount of incorrect offset during rotation depends on the cell content and if you the host application makes updates at the very same moment. Usually that incorrect offset is moderate and does not affect user's impression. You can notice the same behaviour in the iMessage app by apple or in Whtatsapp for example. So this is considered to be an expected behavior. I am welcome contributions in resolving this issue. But it s not considered as a bug.
@Cristiane-Burlamaqui I had another look into an issue you created. Can you provide more details as the jump that you have is too big for the reason I described above. I can not reproduce it. But, you need to keep in mind, that if rotation happens while UICollectionView is updating - there is no way to stop it and calculate the correct offset in principle. So you may see some jumps like in this gif on the second rotation.
But it the real life chat updates happen rarely, and as I said above - same small correction happens even in iMessage
Also have a look at the latest version of the Example app. Some updates have been made since
Hello @ekazaev to reproduce the issue you have to stop load initial messages and comment out the ChatViewController class' line 153 currentInterfaceActions.options.insert(.changingFrameSize)
, because it is only present on the example code and not in the ChatLayout's public API.
After those changes you'll see the gap between last message position and the message composer when you rotate from landscape to portrait mode and the flickering when the correct position is calculated.
@Cristiane-Burlamaqui I see what you are talking about. But this is exactly the resposibility of the host app. ChatLayout knows nothing about elements you have in your app and can not compensate their behaviour. As a layout itself it can not know that keyboar appeared for instance. It should be handled by the host app.
I can reproduce it with the changes you suggested - but there is nothing to fix from the layout point of view.
ChatLayout doesnt know that you have an input view or your view controller can become first responder. Host app deals wit it. and this is exactly why I have those lines that you suggested to comment out.
To see that from the layout point of view it does everything that layout supposed to do comment out this lines as well:
override var inputAccessoryView: UIView? {
return inputBarView
}
override var canBecomeFirstResponder: Bool {
return true
}
And you will see that with suggested changes ChatLayout calculates offsets correctly and it is its only responsibility:
(It is important to say that you may still see little jump but it is related that as its an IPhone 13 - safeArea changes the insets of the collection view but it happens after the rotation started and it is also should be handled and compensated by the host application)
To simplify what is said above: If the host application for whatever reason doesn't calculate the keyboard frame correctly, it has nothing to do with the UICollectionViewLayout
itself (no matter this particular one or any other) - it must be fixed in the host app. No mater what is present or not in the public api. Basically, there is natural separation of concerns and most of them are within the hosting app. Like you dont expect that ChatLayout will do networking calls to load the new messages.
Steps:
Send and receive messages Move the phone to landscape Move it back to portrait
Expected result:
Moving to portrait without flickering
Actual result:
Conversation flickers when moving to portrait
https://user-images.githubusercontent.com/78358306/110513884-a00a2500-80fe-11eb-9158-e7eaacec15a1.MP4