By passing through the callback the message on which the 'loading remote
resources' was requested and notify the item changed once 'loading
remote data' was enabled on the webview.
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
- Move adapter fields to local variables where possible
- Remove redundant "refresh recipeints" logic (this wouldn't work with
conversations as it would always use the first message's recipeint.
Moreover, when keys are refreshed on the VM, a new message is emitted
and the adapter will be refreshed)
- Reformat MessageBodyScaleListener class
- Do not pass MessageInfoView to MessageBodyScaleListener as the
transitionY that was applied to it had no visible effect.
- Rename displayRemoteContentButton for clarity
- Manually fixed rebase conflicts due to changes from 609fdbb596
MAILAND-1770
By pulling the creation of the "attachments adapter" and the displaying
logic into the adapter (so that it gets executed for each item).
Twp pieces of functionality to "set is pgp encrypted" and hide the
"download attachments" spinner were dropped, as migrating them implied a
relevant effort and the existing plan to change attachment presentation
will invalidate such features anyways.
- Manually changed AttachmentsView to MessageDetailsAttachmentView in
layout_message_details_web_view while rebasing over
609fdbb596 changes
MAILAND-1770
Instaead of "injecting" a 'content' string into the adapter once the
message body was ready for rendering, this commit introduces a
`loadMessageBody` method on the VM which takes care of fetching the
messageBody from network when not available, decrypting it and returning
it to the adapter to be displayed into the message's webview.
MAILAND-1770
Since MessageDetailsActivity is not observing the attachments anymore we
can drop the workaround that was storing attachments in a field and
performing some odd checks on it at each method call.
- Extract loadConversationDetails method for clarity
- Rename messageId in MessageDetailsActivity to messageOrConversationId
- Extract lastMessageId method to force the existing logic to work on
the last conversation message (when in conversation mode)
MAILAND-1767
This solves a couple of UI issues:
- Error Toast being shown when opeining a conversation as the first
returned conversation in the flow has no messages
- Pass conversation data to the view when a conversation is loaded
(subject, labels etc)
MAILAND-1767
This issue started happening after 648f4710e56a4797360e1. The bit that
was preventing this was the flag `isDecrypted` which was ensuring the
view was only being called once with a given message.
Mutiple calls to the view cause the issue mentioned above, for which
opening the same message multiple times causes the attachments view to
being shown / hidden randomly.
No issue was found in the attachments data itself (which is always
valid). The assumption is that the issue lies in the adapter's logic
which resets / invalidates the attachments view when showing the
message. This will be tracked in the backlog as tech debt.
- Do not emit the same data twice (distinctUntilChanged)
MAILAND-1767
As otherwise some methods which depends on this (such as loading of
embedded images) might encounter race conditions which would break
their functionality
MAILAND-1767
Depending on whether conversation mode is enabled or not. This is
particularly useful to have access to the model that's currently being
displayed to the user to perform actions.
MAILAND-1767
The messages are wrapped into the `ConversationUiModel` object and they
are always a list (with 1 message when loading a detail in single message mode)
Currently, all the functionalities that are depending on a single
message (eg. decryption, getting attachments, labels etc) **were changed
to act on the last message of the list**
MAILAND-1767
when passing in a conversation ID. This is an intermediate step to get to show
all the messages of a conversation.
- MessageDetailsActivity receives "location" as input param (extra) and
uses it to infer if conversation mode is ON
- loadMessageDetails loads conversation (when ON) and return the last
message within the ConversationUiModel
MAILAND-1767
This is a (manual) partial revert of commit e46d10dbf1061b4c.
Since at now the Detail UI relies on the DB to display updates about
any actions (eg. Add / remove label, star...) we can't stop observing
the message.
MAILAND-1767
- Remove public "message" live data / flow to encapsulate loading logic in the VM
- View now observes only 'decryptedMessageData' to get the detail (source of truth)
- Refactor fetching logic to be synchronous over having a
"MediatorLiveData" which observes multiple properties. Now the message
detail should only be emitted once, when all the needed data was computed.
- Replace "manual" local vs API logic with usage of MessageRepository
- Drop reloading dependencies by user
MAILAND-1767
Such flag was used to differentiate between messages that were coming
from "Search" (being the transient ones) and those that weren't.
This conditional being performed in many places was adding a lot of
noise and not really bringing any value, as the same behaviour can be
achieved by not storing messages from search in the first place.
- Remove unused methods
- Remove prepareMessage method and calls as it is doing nothing
- Track some improvements in the backlog and link back the tasks in the
comments
MAILAND-1767
- Add method in Conversations Repository that will allow us to get the conversation with it's messages from the Remote or Local source.
- Add a way to save the messages into the Message Table
- Add API call to get conversation with it's messages
MAILAND-1766
- Removed messageDraftResult LiveData as not used anymore
- Removed setOfflineDraftSaved as value was set but never read
- Rename findMessageByIdBlocking method to change non-blocking method to
using dispatcher from constructor
* Replaced member injection with constructor injection
* Setup aimed to let Dagger/Hilt generate dependency graph automatically, where possible
Affected: Dagger dependencies
MAILAND-930
#comment If the API returns an error response, don't retry to fetch the message, just show a toast with the error. The retrying of the fetching should happen only when an exception is thrown.
Affected: Trying to open a message
MAILAND-730