Add sort by size feature

[kilian-hu]

Hi, first time contributor here 👋 Looking forward to get some feedback on this PR.

Summary

This PR adds a feature to sort messages by size and also adds displaying the message sizes in message list view. The size display can be toggled with a new setting.

Closes #5470

Motivation

When an account is running out of space, it can be very useful to see which messages take up most of the space and then delete some of them. This can be done easily when we're able to sort the messages by size.

Open questions / TODOs

• Should the message sizes in the message list be placed somewhere else?
• Should the message size be also shown when a message is opened? If yes, where?
• Should displaying the message size be enabled by default?
• Is the description for the message size display toggle setting alright?
• Should we use 1000 or 1024 as base for the sizes? So KB, MB, GB vs KiB, MiB, GiB?
• Is the schema migration alright?

WIP Demo

[kewisch]

Thank you @kilian-hu for sending a pull request! We have a short week this week so we might not be able to get to it immediately, but at latest next week we'll get back to you with some comments. If you have any ad-hoc questions please feel free to find us in #tb-android-dev:mozilla.org on Matrix.

[rafaeltonholo]

Thanks for introducing this nice feature! I have left a few comments that need to be addressed before merging this. You also need to fix the merge conflict.

[rafaeltonholo]

Answering your questions:

Should the message sizes in the message list be placed somewhere else?

In my opinion, yes, as it reduces the subject line length, especially on small screens. However, I couldn't find a better place for this. Maybe it could be added below the date and above the star, but I'm uncertain about how it would look in the end.
Perhaps @laurelterlesky has more suitable advice.

Should the message size be also shown when a message is opened? If yes, where?

I would really appreciate that and would even suggest it. When you open the message and tap on the header, a bottom sheet should appear with the message details. I would include the information there or/and in the header itself. Since this involves design, I would also like to see if @laurelterlesky has any more suitable suggestions.

Should displaying the message size be enabled by default?

I don't believe we should. While this feature is nice, I haven't seen it often in other email clients, and I'm unsure if all users would want that information displayed without their consent. Moreover, it adds extra information to the message list, which could be distracting for some users. Therefore, I would prefer to keep the default setting as false.

Is the description for the message size display toggle setting alright?

If you add the size information also in the Message Preview, I would change just a bit the end, removing the "list" from "message list". Otherwise, it is a good description!

Should we use 1000 or 1024 as base for the sizes? So KB, MB, GB vs KiB, MiB, GiB?

There is a SizeFormatter class that already handles that. We should use it to keep consistency.

Is the schema migration alright?

Ideally, during the migration process, we should provide the correct size for each message when adding the column. However, I'm not sure how to accomplish that.

What concerns me the most is seeing many instances of "0B" associated with my messages, which suggests that something might be wrong with them.

I would prefer to leave the messages without a calculated size as NULL and hide the size label in these cases. The label should only be displayed once the size has been properly calculated.

Perhaps @wmontwe knows better how to recalculate the current stored messages' size.

[rafaeltonholo]

Also, I would like to shout out the addition of the screen recording as part of the PR. This was very helpful!!

[kewisch]

@kilian-hu hey just checking in, have you had a chance to pick this up again? Would love to help get this merged.

[kilian-hu]

@kewisch I can make the adjustments this weekend :) I think there are some open design questions that @laurelterlesky could answer. But when those are cleared up I can get this in a mergeable state.

[kewisch]

Thank you! I've asked in our design channel if someone could take a look.

[laurelterlesky]

The design team is reviewing this. We'll get back to you in a couple of days.

[solangevalverde]

Hi hi, thank you for taking the initiative and bringing up to light user motivations as well as areas where we can improve! This ticket has helped brought to light bigger issues we have currently in Thunderbird for android.

Following the user’s motivation, at the moment we are able to filter by attachments but not sort the filtered list. The design team is planning to rework filter and sorting as a bigger project where we can create a space where we give users an isolated filter/sort view that solves for their needs without overfilling the message card in the message list (which is an ongoing issue). Because of that I will not be approving the merge, @laurelterlesky feel free to jump in if you got thoughts. When we create tickets for this project we will make sure to use this patch as a reference as it will come in handy once we have a filtered list the user is able to sort.

However I do agree that we should display to the user the size of the attachment size (and/or than the message size). This is something that can be done now :)

We have a solve for showing attachment size pending development! [See attachment 1]

We could also solve showing the size of the message in the in bottom drawer that is shown when the sender information is tapped [See attachment 2]

These 2 design solves are ready to be developed so please feel free to tackle either if you feel inclined to. Once again, thank you for being part of the Thunderbird for android community and helping improve the project!

---

Attachment 1: attachment size solve

Attachment 2: message size solve

[rafaeltonholo]

Hi @kilian-hu,

I apologize for the delay in response. We are currently reworking the message list, and we believe it would be beneficial to introduce this feature once we have completed our work on it.

Could you please hold off on implementing any changes until we finish? Once the new Message List implementation is complete, we will let you know, and we can help you update the implementation accordingly.

We appreciate your efforts in this change, and we would like to incorporate it into the project, but the current state of the Message List makes everything more complicated.

Thank you for your understanding.