This is a suspend function that returns the `RenderedMessage`, instead of `setImagesAndStartProcess`, which is a fire-and-forget, with the result returned on a separate stream.
This will allow us to have more consistency in the class.
MAILAND-2332
Models are needed for the purpose of keeping a track of the message's id and body, removing a dependencies of the class' variable and so preparing it for support multiple messages
MAILAND-2332
The class was exposing fields and Channel's, but this is breaking the principle of Encapsulation. These members are now deprecated, in favour of more standards functions and Flow as result.
The inputs now also require a message's id, in preparation of the support for multiple messages rendering
MAILAND-2332
The class is not designed for render different messages, changing the `messagesBody` is incorrect, as that can happen in any moment, while the process is already started, resulting in many errors, for example displaying twice the same message or being unable to load images.
Usage in conversations must be implemented in a different way
after they were loaded through the "Display embedded images" button for
any message.
There were some issues preventing the functionality from working which
were addressed in this PR:
- The same instance of MessageRenderer was not ready to work with
different messages (messageBody was not changeable and the is a check
that would stop execution when an image was "already rendered" which
didn't take account that different messages can contain the same image)
- When MessageRenderer returns the html, we need to display that
through a new livedata which targets only the message currently opened,
as resetting the whole ConversationUiModel causes UI glitches when the
message is not the last one.
MAILAND-1931
In some cases the message rendering gets triggered again with invalid
(null) values in place of the prevously-valid ones for embedded images
local files. We will skip such invalid values
MAILAND-1770
Since the "file directory" where images are stored is the messageId,
injecting it at class creation is not sufficient anymore with the
addition of conversations (when showing a converation's details
MessageRenderer would be init with conversationId, which is not a valid
image directory and would cause images not to be found).
The directory is now defined using each embedded image `messageId` field
MAILAND-1770
Beforehand, this functionality was working by injecting a string (the
html body with the images) into the adapter which would replace any
content of the webview with the new string. As with conversations we can
have multiple webviews, this didn't work anymore.
The new approach leverages the components currently in place to avoid
touching on a too wide scope: `MessageRenderer` is still in charge of
creating a message body with inline images. Such body is now being
returned with the messageId to which the body refers too. It's observed
in the MessageDetailsViewModel.init method and when fired it "hot swaps"
the `decryptedHtml` on the correct message and emit the
convresationUiModel again for the adapter to refresh the displayed data.
Summary of tech changes:
- Changed MessageRender to return an object containing both the
"rendered message body" and the messageId for which such body was rendered
- Removed `distinctUntilChanged` from _decryptedMessageLiveData as it
prevented embedded images from being emitted (as Message.decryptedHtml
field is not considered for computing equality)
- Rename `embeddedImagesAttachments` field following naming conventions
- `prepareEmbeddedImages` method receives message for which images should be prepared
- Message.decryptedHTML field can be set from outside of the model
- Remove redundant downloadEmbeddedImagesResult live data
MAILAND-1770
Tests were failing because coroutines-test was not used and objects were not properly mocked.
Additionally another test has been added
Affected: MessageRendererTest.kt
* Replaced member injection with constructor injection
* Setup aimed to let Dagger/Hilt generate dependency graph automatically, where possible
Affected: Dagger dependencies
MAILAND-930