Refactored Message input view into it's own Fragment

[rapterjet2004]

• fixes Refactor MessageInput logic into it's own fragment #3784

Introduction

Shouldn't be merged until after the stable release.

MessageInput is very complex, spanning 1300+ lines of code. It deals with sending, recording, emojis, files, editing, mentioning, etc. It should be placed into it's own fragment, so ChatActivity becomes easier to maintain in the long run. Bit of an investment cost though and not necessarily a priority in case other features require attention. But it's something that should be taken care of before it gets out of control. Chatting is the core functionality of talk-android, and needs to be structured well.

This also gives me an opportunity to clean up the architecture of the view. Separate UI from business logic, and deal with asynchronous work in a less "Spaghetti" manner. Less threads, more coroutines. Less logic in the UI, more logic in the model layer, etc

The plan is the separate the voice recording from the typical messaging. To have two different fragments to handle the behavior. A significant amount of code (admittedly my own 😅 ) is involved in the voice recording logic, which can be pretty complicated. Fragments transaction events will be observed by the ChatViewModel and handled.

As a rule of thumb, I'm going for 25/15/60 (view, view model, model) when implementing logic in MVVM. Not everything is implemented in MVVM, just the functionality that relate to message input (with the exception of typing status).

PR Diagram

Arrows and colors represent the flow and scope of information traveling down from user input.

// TODO normal message input

• sending messages
• sending attachments
• emoji button
• replying
• editing
• mentioning
• typing status?
• recording

// TODO voice message input

• Abstracting over MediaRecorder (Note to self: Make mediarecorder state livedata and immutable, good design)
• Abstract over MediaPlayer
• Abstract over AudioRecord
• MicInputCloud
• previewing // note pause mediaplayer before seeking and resume after
  • Preview SeekBar
  • pause/Play
• sending preview
• deleting preview
• Implement Audio Focus Request (perhaps make this a manager too?)
  • Media Player ( in ChatActivity )
  • Voice Message preview player
  • Media Recorder
  • MicInput

// TODO clean up

• Delete all the old code
• Bugs
  • save messageInputView text and cursor state
  • save position and voicemessage on state change in saved ( this is an issue with the lifecycle being recreated )
  • checkShowMessageInputView
  • checkLobbyState
  • onCreateOptionsMenu (used for context???)
  • handleOnBackPressed
  • Make PreviewSeekbar seekable
  • Fix Voice record bugs
  • use upload file from chatView
  • Micinput restart ui
  • If the preview playback is interrupted, the seekbar will not seek on following recordings, might be related to AudioFocusRequest
  • AudioFocus crash, need to handle receiver illegal arg exception

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not needed
• 🔖 Capability is checked or not needed
• 🔙 Backport requests are created or not needed: /backport to stable-xx.x
• 📅 Milestone is set
• 🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?)

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

[rapterjet2004]

It seems the typing indicator is broken in general, unrelated to this PR, but I'm receiving the same error messages that I encountered on Master, so I'm assuming it should be sending the messages at least.

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

[mahibi]

It seems the typing indicator is broken in general, unrelated to this PR, but I'm receiving the same error messages that I encountered on Master, so I'm assuming it should be sending the messages at least.

As said, typing indicator is broken for now because of nextcloud/spreed#12252
Nothing to fix in your PR...

[mahibi]

see overall comments

[mahibi]

@rapterjet2004 #3792 (comment) is solved right? As the commits are already squashed: can you give a short summary what you changed to solve it?

[rapterjet2004]

At first I hardcoded the leave room logic, but the error persisted. After reverting the git, I think the reason for this, is because the bug was caused by my earlier changes to the PR, where I added an additional GetCapabilitiesUpdateState so that the message state wouldn't get recreated every time capabilities was called.

I forgot that when exiting -> entering an activity, the state will still be GetCapabilitiesUpdateState instead GetCapabilitiesInitialLoadState because it's held in the ChatViewModel. Therefore the room would not be joined, and refreshChatParams wouldn't be called to the start the recursive chain.

is ChatViewModel.GetCapabilitiesUpdateState -> {
                    spreedCapabilities = state.spreedCapabilities
                    chatApiVersion = ApiUtils.getChatApiVersion(spreedCapabilities, intArrayOf(1))
                    participantPermissions = ParticipantPermissions(spreedCapabilities, currentConversation!!)

                    invalidateOptionsMenu()
                    checkShowCallButtons()
                    checkShowMessageInputView()
                    checkLobbyState()

+                   if (!validSessionId()) {
+                       joinRoomWithPassword()
+                       chatViewModel.refreshChatParams(
+                           setupFieldsForPullChatMessages(
+                               false,
+                               0,
+                               false
+                           )
+                       )
+                   } else {
+                       Log.d(TAG, "already inConversation. joinRoomWithPassword is skipped")
+                   }
-
                    updateRoomTimerHandler()
}

[mahibi]

#3792 (comment)

But now the situation that GetCapabilitiesUpdateState remains is still the case right?
Which is confusing because then GetCapabilitiesUpdateState also contains code for initialization (additionally to the code in GetCapabilitiesInitialLoadState)

I think

+                   if (!validSessionId()) {
+                       joinRoomWithPassword()
+                       chatViewModel.refreshChatParams(
+                           setupFieldsForPullChatMessages(
+                               false,
+                               0,
+                               false
+                           )
+                       )
+                   } else {
+                       Log.d(TAG, "already inConversation. joinRoomWithPassword is skipped")
+                   }

should be deleted from
is ChatViewModel.GetCapabilitiesUpdateState
and instead we reset some states in ChatViewModel#leaveRoom? E.g.

        _getCapabilitiesViewState.value = GetCapabilitiesStartState
        _getRoomViewState.value = GetRoomStartState

so the next time the activity is opened the states for initialization are triggered..

PS: it think both solutions should just be a workaround until session is managed in viewModel or wherever. Then a check like
if (!validSessionId()) {
should be done to decide which actions need to be triggered.

[github-actions]

Codacy

Lint

Type	master	PR
Warnings	79	79
Errors	10	124

SpotBugs

Category	Base	New
Bad practice	6	6
Correctness	11	11
Dodgy code	84	84
Internationalization	3	3
Malicious code vulnerability	3	3
Performance	6	6
Security	1	1
Total	114	114

Lint increased!

[github-actions]

APK file: https://www.kaminsky.me/nc-dev/android-artifacts/3792-talk.apk



To test this change/fix you can simply download above APK file and install and test it in parallel to your existing Nextcloud Talk app.