| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat: on the fly thumbnail generation (#3523) ## 🎯 Goal This PR adds native video thumbnail generation for local assets and wires it into the attachment flows. The rationale' behind the PR is the fact that starting RN 0.84 and onwards, `ImageBackground` can no longer reliably render `ph:///` video assets on iOS (and probably other edge cases too). Thumbnails are now generated natively on iOS and Android for local video assets coming from the attachment picker / image picker / camera flows, cached in the app cache directory, and reused if they were already generated before. The native API is batched, so we can generate multiple thumbnails in one go instead of doing them one by one. The module only handles local assets. If thumbnail generation fails for a single video, we soft fail that item only and fall back to the existing placeholder / no thumbnail UI instead of failing the whole batch. So in other words: - added native video thumbnail generation on iOS and Android under shared-native - exposed it through a new TurboModule `StreamVideoThumbnail` API - batched thumbnail generation for `getPhotos`, `pickImage`, and `takePhoto` - added deterministic cache reuse for generated thumbnails - limited concurrent native generation to avoid decode storms - made thumbnail generation best-effort per item: - native returns `{ uri, error }` per requested asset - failed items no longer fail the whole batch - restricted `thumbnail` generation for local assets only - Android: raw path, `file://`, `content://` - iOS: raw path, `file://`, `ph://` - switched attachment picker items and image upload previews away from ImageBackground to plain Image Notes - this is new architecture only - thumbnails are written to the app cache dir, so they can survive relaunches but are still disposable cache - existing cached thumbnails from the old cache folder name will not be reused ## 🛠 Implementation details <!-- Provide a description of the implementation --> ## 🎨 UI Changes <!-- Add relevant screenshots --> <details> <summary>iOS</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> <details> <summary>Android</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> ## 🧪 Testing <!-- Explain how this change can be tested (or why it can't be tested) --> ## ☑️ Checklist - [ ] I have signed the [Stream CLA](https://docs.google.com/forms/d/e/1FAIpQLScFKsKkAJI7mhCr7K9rEIOpqIDThrWxuvxnwUq2XkHyG154vQ/viewform) (required) - [ ] PR targets the `develop` branch - [ ] Documentation is updated - [ ] New code is tested in main example apps, including all possible scenarios - [ ] SampleApp iOS and Android - [ ] Expo iOS and Android | 5 个月前 | |
feat: native shimmer and image loading redesign (#3467) ## 🎯 Goal In this PR, we redesign the implementation of `ImageLoadingIndicator` to present as a gradient shimmer with an activity indicator. Since we tried a couple of approaches (one with `LinearGradient` from `RNSVG`), at the end we settled for a purely native implementation for performance reasons. Having that many animated views be potentially active on the screen tanks scrolling performance of the `MessageList` (i.e a lot of images loading, perhaps with poor network conditions if they aren't cached). The shimmer is Fabric only, lives in shared native sources, and is exposed through the native handler registration flow for consistent integration across the current SDK setup. Visuals and behaviour are aligned between Android and iOS, keeping a single moving shimmer gradient, and tuning width/shape/alpha for a smoother effect closer to the previous output. For packaging and local development flow, native source sync is now driven from `shared-native` as the source of truth so local dev and release packaging stay aligned, with build/script flow updated so copies refresh automatically when running the sample app. I'm not yet sure this is the correct approach, but since this is relatively new as we didn't have that many native implementations in the SDK in the past it'll have to do for now and we'll of course refine it as we go on. Just for reference, the native shimmer implementation improves: - Scrolling on Android by about 30-40 FPS (yes, really) - Scrolling on iOS by about 10 FPS (it was fine-ish before as well) compared to a `LinearGradient` and `Animated.View` approach for rendering a shimmer. TODO: - [x] Write docs for the native side - [x] Some additional cleanup - [x] Maybe tweak/polish the shimmer/gradient a little bit more - [x] Consolidate where we copy resources from (probably one folder for the shared stuff, and we always copy from there) so that future native implementations are trivial to add and all of the tooling works - [x] Have another run at the `build.gradle` copying edge cases, I think this can be done simpler ## 🛠 Implementation details <!-- Provide a description of the implementation --> ## 🎨 UI Changes <!-- Add relevant screenshots --> <details> <summary>iOS</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> <details> <summary>Android</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> ## 🧪 Testing <!-- Explain how this change can be tested (or why it can't be tested) --> ## ☑️ Checklist - [ ] I have signed the [Stream CLA](https://docs.google.com/forms/d/e/1FAIpQLScFKsKkAJI7mhCr7K9rEIOpqIDThrWxuvxnwUq2XkHyG154vQ/viewform) (required) - [ ] PR targets the `develop` branch - [ ] Documentation is updated - [ ] New code is tested in main example apps, including all possible scenarios - [ ] SampleApp iOS and Android - [ ] Expo iOS and Android --------- Co-authored-by: Khushal Agarwal <khushal.agarwal987@gmail.com> | 5 个月前 | |
feat: native shimmer and image loading redesign (#3467) ## 🎯 Goal In this PR, we redesign the implementation of `ImageLoadingIndicator` to present as a gradient shimmer with an activity indicator. Since we tried a couple of approaches (one with `LinearGradient` from `RNSVG`), at the end we settled for a purely native implementation for performance reasons. Having that many animated views be potentially active on the screen tanks scrolling performance of the `MessageList` (i.e a lot of images loading, perhaps with poor network conditions if they aren't cached). The shimmer is Fabric only, lives in shared native sources, and is exposed through the native handler registration flow for consistent integration across the current SDK setup. Visuals and behaviour are aligned between Android and iOS, keeping a single moving shimmer gradient, and tuning width/shape/alpha for a smoother effect closer to the previous output. For packaging and local development flow, native source sync is now driven from `shared-native` as the source of truth so local dev and release packaging stay aligned, with build/script flow updated so copies refresh automatically when running the sample app. I'm not yet sure this is the correct approach, but since this is relatively new as we didn't have that many native implementations in the SDK in the past it'll have to do for now and we'll of course refine it as we go on. Just for reference, the native shimmer implementation improves: - Scrolling on Android by about 30-40 FPS (yes, really) - Scrolling on iOS by about 10 FPS (it was fine-ish before as well) compared to a `LinearGradient` and `Animated.View` approach for rendering a shimmer. TODO: - [x] Write docs for the native side - [x] Some additional cleanup - [x] Maybe tweak/polish the shimmer/gradient a little bit more - [x] Consolidate where we copy resources from (probably one folder for the shared stuff, and we always copy from there) so that future native implementations are trivial to add and all of the tooling works - [x] Have another run at the `build.gradle` copying edge cases, I think this can be done simpler ## 🛠 Implementation details <!-- Provide a description of the implementation --> ## 🎨 UI Changes <!-- Add relevant screenshots --> <details> <summary>iOS</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> <details> <summary>Android</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> ## 🧪 Testing <!-- Explain how this change can be tested (or why it can't be tested) --> ## ☑️ Checklist - [ ] I have signed the [Stream CLA](https://docs.google.com/forms/d/e/1FAIpQLScFKsKkAJI7mhCr7K9rEIOpqIDThrWxuvxnwUq2XkHyG154vQ/viewform) (required) - [ ] PR targets the `develop` branch - [ ] Documentation is updated - [ ] New code is tested in main example apps, including all possible scenarios - [ ] SampleApp iOS and Android - [ ] Expo iOS and Android --------- Co-authored-by: Khushal Agarwal <khushal.agarwal987@gmail.com> | 5 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 5 个月前 | ||
| 5 个月前 | ||
| 5 个月前 |