rebase and land

Refactor code to make more readable check for ability to request notifications permission

More robust check as to whether issue notifications permission request.

1. Replace method overloading with different names.
2. Simplify check for Android OS version.
3. Add comment to explain hardcoded request code for notifications permission.

Add intent-filter for MainActivity to be started from SplashActivity in debug build

I don't have experience in writing tests in jest but looks reasonable

Makes sense! Thanks for clarifying and answering the questions!

Add a comment explaining why we don't check subthread_permissions here and also ORDER BY m.pin_time DESC to fetch pinned messages from newest to oldest

address review

Discussed the revision mainly offline with @ashoat, so I'll copy the changes we discussed from our chat here, as well as outline any additional changes.

Address review

In D6924#212627, @ashoat wrote:

The current fetchPinnedMessageInfos query doesn't have the ability to paginate, but it can always be added in later. We could initially fetch all of the pinned messages at once from the server, but have a task to paginate the fetching.

Yeah agreed, I've made a task to track: https://linear.app/comm/issue/ENG-3397/add-pagination-to-fetching-message-pins-for-a-thread

Separately, I'm a bit confused about how the client will determine eg. how many messages are pinned for a given chat. Is this info going to be fetched on-demand when the user opens the chat? (In which case it would appear "dynamically" after being fetched.) Or are we looking to "cache" this information for each thread, so that we correctly display it when opened?

I think it would be good to avoid having to fetch anything "dynamically" when a chat is opened. Depending on what information we show by default (I don't recall the designs exactly but it might just be a number of pinned messages), we might want to consider modifying ThreadInfo to store this information.

That's a good point, it probably would be good to store the number in ThreadInfo. I've similarly made a follow-up task: https://linear.app/comm/issue/ENG-3396/store-the-number-of-pinned-messages-in-threadinfo

Rename file, move processMessagesForSearch to postMessageSend

Rebase

Rebase

Address comments

Change type to inexact

Address review comments

Address comments

In D6965#212104, @ashoat wrote:

We can consider preventing users from sending empty edit messages.

We should do this. We don't allow empty messages for messageTypes.TEXT. Can you create a follow-up Linear task for this before landing?

In D7067#212617, @ashoat wrote:

One last thing that would be great if you could test: what happens if you upload a single very "thin" photo? I want to make sure it doesn't expand to take the whole width and then becomes super tall. (Or at least, that there's no regression in this.)

Sorry for all the specific test plan requests, I just remember there being a lot of edge cases with this code from back when I was working on it.

That makes sense RE older clients. Thinking about it more, I'm not actually sure why we ever thought it made sense to "hide" the avatar field from older clients... they're going to eventually need the field, and if we hide it from them initially then they will need to rely on the state check mechanism to fix things after they upgrade codeVersions.

The current fetchPinnedMessageInfos query doesn't have the ability to paginate, but it can always be added in later. We could initially fetch all of the pinned messages at once from the server, but have a task to paginate the fetching.

Yeah we can probably get rid of them, feel free to put up a diff

One last thing that would be great if you could test: what happens if you upload a single very "thin" photo? I want to make sure it doesn't expand to take the whole width and then becomes super tall. (Or at least, that there's no regression in this.)

Back to your queue for nits and fetchDerivedMessages

Adding @kuba here – he is looking at fetchDerivedMessages right now in D7141

Can you please amend the Test Plan to include: