[AND-318] Fix fading issue in media attachment content items

[andremion]

🎯 Goal

Address #5582

🛠 Implementation details

• Introduce ShimmerProgressIndicator component, which can be used to indicate loading states. It uses a default StreamShimmerTheme provided as a local composition component through the ChatTheme.
• Replace StreamImage with StreamAsyncImage in MediaAttachmentContent and handles content for the each async image state using the foundation Crossfade animation component.
• Replace StreamImage with StreamAsyncImage in MediaGalleryPreviewActivity and GiphyAttachmentContent so that we can remove the dependency of placeholder.shimmer.ShimmerPlugin from Compose SDK.

🎨 UI Changes

MediaAttachmentContent

Before	After
media.issue.webm	media.fix.webm

GiphyAttachmentContent

Before	After
giphy.before.webm	giphy.media.after.webm

🎉 GIF

[github-actions]

SDK Size Comparison 📏

SDK	Before	After	Difference	Status
stream-chat-android-client	3.17 MB	3.17 MB	0.00 MB	🟢
stream-chat-android-offline	3.38 MB	3.38 MB	0.00 MB	🟢
stream-chat-android-ui-components	7.87 MB	7.87 MB	0.00 MB	🟢
stream-chat-android-compose	8.75 MB	8.75 MB	0.01 MB	🟢

[skydoves]

Overall, it looks good to me! Out of curiosity, are there any critical issues with the previous StreamImage, or specific benefits to migrating to StreamAsyncImage? Since I've been maintaining Landscapist myself, I'd be happy to address any issues or improvements if needed.

[andremion]

Overall, it looks good to me! Out of curiosity, are there any critical issues with the previous StreamImage, or specific benefits to migrating to StreamAsyncImage? Since I've been maintaining Landscapist myself, I'd be happy to address any issues or improvements if needed.

Thanks for reviewing it, @skydoves

We have seen issues like that, which also happens with the avatars because they use the CrossfadePlugin.

The idea with moving out from StreamImage was to make it simpler to maintain and give more flexibility to build content based on the image loading states.

[skydoves]

To be honest, I don’t see the advantages you mentioned—"simpler to maintain and provides more flexibility for building content based on image loading states"—since Landscapist already offers richer APIs that support these functionalities.

Such as,

• Build Your Own Composable
• Image States
• Preview on Android Studio

[andremion]

To be honest, I don’t see the advantages you mentioned—"simpler to maintain and provides more flexibility for building content based on image loading states"—since Landscapist already offers richer APIs that support these functionalities.

Such as,

• Build Your Own Composable
• Image States
• Preview on Android Studio

The Landscapist is a great library, indeed. It has innumerable possibilities for customization.
However, IMO, when it comes to a chat library, a couple of helper-composable functions and Coil dependency should be enough to support their features, with no need for any other external dependency.

[skydoves]

I understand your concerns, and that’s a great point. The reason I introduced Landscapist was for its greater flexibility in state customization and additional features like crossfade, shimmering effects, placeholders, and seamless previews, which offload responsibilities to the library. However, as you mentioned, implementing all the things ourselves also has its advantages, such as reducing dependency on third-party libraries, and we can customize them under our control.

Since we've already started the migration, we can consider removing all landscapist dependencies across the project to maintain consistency, not at once but gradually. What do you think?

[sonarqubecloud]

Quality Gate failed

Failed conditions
2.3% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud