* develop: (150 commits)
Removes changelog file
Fix PR comment
Adds changelog file
Refactors MessageBubbleView
Updating changelog copy
making use of the fake overrides for testing
extracting the personalization complete emitting to a dedicated function
making use of binding api instead of manual findviewbyid
using consistent method naming for setting the capabilities override
taking the personalization feature flag into account when calculating if personalization is supported - also removes a legacy loading workaround for the account creation step, we're navigating to a new screen AccountCreated so we have to stop the loading
adding changelog entry
using correct label for the avatar capability debug override
forwarding to the profile picture flow when display name changing isn't supported but pictures are when personalising the profile
formatting
dynamically switching the onboarding flow based on the capabilities of the homeserver - when avatars can't be changed we complete the personlisation flow
hiding the toolbar back button and handling system back as take the user home if the display name personalisation is not supported
adding test around account creation via dummy
dynamically changing the account created layout based on if the homeserver supports personalisation
adding entry points for injecting and overriding the homeserver capabilities
extracting method for the handling of the profile picture selection
...
I was observing cases where builtEvents[modificationIndex] was not
having the same eventId as the udpatedEntity in.
In particular, I observed both cases that
- there was no item in the list yet with the same eventId as the updated
one
- there was an item with the same eventId already in the list, but at a
different position.
Whenever this happened, the timeline would render missing, duplicated,
or swapped messages in the timeline.
Instead of relying on the modificationIndex to be the same for both the
change set and builtEvents, look up the proper index by eventId.
Change-Id: Ic03bdcc8210ec87b786795848f31e9085096b903
Imagine scenario:
[this] -> [chunkToCheck] -> [lastForwardChunk]
Then, both `isLastForward` checks will not return, and also the `chunkToCheck.doesNextChunksVerifyCondition { it == this }` will return false.
Since both chunks are connected to the last forward chunk, `isMoreRecent()` will still return `true`, which is wrong in this case.
So do not only check if chunkToCheck has this as any of the next chunks, but also the other way round.
Change-Id: I98727d85837e9b38a42297568df82f957b3a2dca
Note: may affect performance a little when loading the timeline, so
better revert when we are confident we have fixed the issue.
Change-Id: Ic4d31e47948984371a02ce51af7a8d56cb120234
