Feat/video message

[nicolasbraun]

Implementation notes

• I do not rely on Chewie's player for the bubble because I did not manage to have only the play button and entering fullScreen with chewie's can break device orientation
• I did not allow to go "real fullscreen" (what will make the app eventually go landscape) because it adds a lot of complexity but we could look into it.

Maybe remaining points

• [ ] Caching, not sure how and if we should for videos
• [x] Maybe videoMessage could have a thumbnail but we can do this later
• [x] I'm not sure it works with a local video, especially on web
• [ ] Note the tap overrides the one from ChatMessage (at least on the bubble). But if we want to prevent that the user would have to handle video playback.

https://github.com/user-attachments/assets/668b0764-738f-4a78-85aa-b73966dc721e

[nicolasbraun]

@demchenkoalex Putin this on draft to get your input, as integrating in my app, especially with a thumbnail raised quite a lot of questions I wanna discuss with you.

• Most chat apps videoMessage only display a preview image (maybe coverImage is a good name), and open a extended player when taping the message.
  • That's what i currently do
  • I generate the cover image in the lib (since 67842d5373650ebac17d0ec3f39420bc074db25a, before i was just displaying a static player, see point 2 below)
  • I handle the click to navigate to a full screen player.

1. Should be allow user to pass a the coverImage in high resolution too? something like

                    final fullSizeimageBytes =
                        await VideoThumbnail.thumbnailData(
                          video: videoUrl,
                          imageFormat: ImageFormat.WEBP,
                          quality: 1,
                        );
                    highResCover= base64.encode(fullSizeimageBytes);
// Then pass it to VideoMessage

2. In my commit 67842d5373650ebac17d0ec3f39420bc074db25a I switched tovideo_thumbnail to generate the cover. It's much lighter than instanciating a player just for it but does not work for web.

• Should we revert player but it's quite heavy to instanciate N players
• Should we use player for web only, but i don't really like adding a dependency just or it (useless for mobile only apps). Maybe we can do 2 packages and use switches in the builder.

4. Should we not handle the click in the lib, so user can do whatever he wants in the onMessageTap? and just provide guidance in the docs.

[nicolasbraun]

@demchenkoalex

This PR is ready too. Like i said the tap currently overrides the global onMessageTap but this could be easily changed if you prefer:

• either by just removing the whole full screen player
• or by exposing a showFullScreenPlayerPage method (a bit like the showReactionDialog from #838) to let the player decice, but this would mean the player is part of this package dependencies

[Henry-Hiles]

Is this ready to use? I might just take a couple of your patches onto a fork of mine to use, if that's okay?

[nicolasbraun]

@Henry-Hiles i'm using it without any issue (but my app does not have many users).

Code-wise it's ok, I was mostly discussing the default behavior/interface

[nicolasbraun]

PS: (i may need some adjustement if the main branch moved a lot, did not pull in a while)