Add support for threaded conversations in the iOS app
Part of Threaded Conversations Epic: gitlab-org&360 (closed)
Clarification of the current state of the thread messages in mobile apps
There are two ways how the messages get to your screen:
- initial load or infinite scrolling - these updates are fetching up to 50 messages from the API in a batch. This is using the
chatService.findChatMessagesForTroupe
in the background and will never return a child message - Live updates through our bayeux stream - this stream publishes each message regardless of whether it's child message or not and these will most likely show on the screen
TLDR; thread messages are showing on mobile apps only if they are created when you are looking at the room and after leaving the room and coming back, they won't be visible. This issue is currently working on fixing it
Gitter team doesn't have the capacity to develop new features in native apps (https://gitlab.com/gitlab-org/gitter/webapp/issues/2281) so this issue is about finding a compromise between the amount of work necessary for backporting the "Threaded conversations" feature to native apps and the user experience provided.
These are possible options (we are open to more ideas):
Option A - Threaded messages showing in the main message feed
The thread messages could be showing the same way as normal room messages with some indicator that they belong to a threaded discussion.
Room view implementation
iOS app is showing a webapp/output/ios/www/mobile/embedded-chat.html
file in a WebView. This includes javascript and CSS to fetch and display chat mesasges.
This file is built using build-ios-assets
npm task.
Problems to solve
- Links are taking user out of the app to a mobile browser. Is there a better way to support linking to other messages?
- Filtering out the child messages happens in the
chatService
. How to not filter these out for the mobile experiences? - We wanted each child message to contain a link to the previous (chronologically) message in a thread (so the user can click their way through the whole conversation). This might be difficult because we might have to query DB to get that information (as opposed to linking to the parentId which is present in the child message model)
Option B - Separate route for a thread
For example (community/room/~thread/<parentId>
). This route would show a similar view as the normal room chat with the thread.
Option C - including the Vue Thread message feed on native
Since the room view is a special case of the webapp (with the room page being up front generated), we can adopt the approach from the mobile app https://gitlab.com/gitlab-org/gitter/webapp/merge_requests/1733
I see this to be a better option over option A because it will allow users to follow the threads easily and it won't be taking users out of the mobile app experience when they'll click on the parent permalink.
Problems to solve
- The initialization of the web view is different from the normal app, we are always showing the same page (
webapp/output/ios/www/mobile/embedded-chat.html
) and only changing thetroupeId
in URL query This means that a lot of the Vuex store initialization doesn't happen here - Show users that they can't post messages to threads, because the message is always sent to the MMF
Hacked together version
https://gitlab.com/gitlab-org/gitter/webapp/tree/hacking-on-ios-embed
It sometimes works when I open the embedded-chat.html
directly but it never works in the iOS simulator.