support conversation view in inbox

[tomholub]

The app has two methods to access email provider: Gmail API and IMAP/SMTP.

I'd like to update the app as follows: app stays the same when IMAP is used. When we use Gmail API, I'd like to view a list of conversations instead of list of emails when I open any folder in inbox.

Specifically, with Gmail, at the moment we:

• use messages.list to get a list of messages in inbox: https://developers.google.com/gmail/api/reference/rest/v1/users.messages/list
• user clicks on a message, and we use https://developers.google.com/gmail/api/reference/rest/v1/users.messages/get to download and display it

After update, with Gmail, we will:

• use threads.list https://developers.google.com/gmail/api/reference/rest/v1/users.threads/list to get a list of threads. Choose them using labelIds for a particular folder. Maybe you'll have to threads.get the individual threads to show the details: https://developers.google.com/gmail/api/reference/rest/v1/users.threads/get (like subject etc of each thread in the list)
• also render amount of messages in each thread with a (1) or (3) or similar under the date.
• when user clicks on one of the threads, then on message view we'll use threads.get for this particular selected thread. The threads will be rendered as a list, a bit similar to the inbox list except that we only show the sender and the time, not subject next to each item (since subjects in a thread are all the same).
• to the right side of each thread item (that is, individual email) on the message view, there should be a chevron. Clicking the chevron will expand the message, which will download the actual message from server with messages.get https://developers.google.com/gmail/api/reference/rest/v1/users.messages/get , then decrypt it with parseProcessMsg like we do now
• clicking the chevron again will make that message collapse
• emails on message view should be from oldest in thread on top to newest on bottom
• when I render the message view by transitioning from inbox view, only one message should be expanded - the first unread message from the top.

The technical details above, eg regarding Gmail API usage, may not be 100% precise but it should give you the idea.

The unfortunate part is that somewhere in controller code (both inbox and message view) you'll have to decide if we are using IMAP or Gmail API and branch accordingly. Or do you think it would be better to have completely different controllers, maybe with shared bases? One for IMAP and one for Gmail API?

[Kharchevskyi]

To get amount of messages (3) in a thread we need to call GTLRGmailQuery_UsersThreadsGet for each thread fetched in GTLRGmailQuery_UsersThreadsList.
GTLRGmailQuery_UsersThreadsGet will also fetch all messages in this thread.

I have started draft implementation in #657

The unfortunate part is that somewhere in controller code (both inbox and message view) you'll have to decide if we are using IMAP or Gmail API and branch accordingly.

I do think it's better to inherit from InboxViewController but use a different decorator for it to render number of messages in a thread. This will keep pagination and logic for empty states, refreshing and compose button etc ...

For thread details controller I think it's better to use different controller
Will update with details

[Kharchevskyi]

Should conversation view will also be shown in case of searching? or previous inbox view should be used?

[tomholub]

Yes - also when searching

[tomholub]

I mean, it should do the same thing that Gmail mobile app does. See what it does there. I suspect that it shows threads.

[Kharchevskyi]

Yes, it shows in "thread" view.
Can I fully remove previous implementation for gmail inbox view or it will be still used?

[Kharchevskyi]

[tomholub]

Let's remove it the previous code. Less code to maintain.

[tomholub]

@Kharchevskyi please before self-assigning, see if there is an open issue that is already assigned to you: https://github.com/FlowCrypt/flowcrypt-ios/issues/assigned/Kharchevskyi

Since you already started working on this, ok to finish. But after, please do #287

[tomholub]

Also this issue was in 0.2.3 which is a later milestone than the assigned issue which was in 0.2.1 - please generally prioritize by milestones as well.