Migration Guide: Updating Your Codebase

7min
The external ExoPlayer is now deprecated. We strongly encourage you to switch to our custom player, NwPlayer. Please consult the migration section for detailed instructions on how to migrate from external ExoPlayer to NwPlayer.
We continuously strive to improve the developer experience and ensure our SDK remains flexible, efficient, and easy to integrate. We have updated the mechanism for integrating your custom ExoPlayer instance as part of this effort. Previously, we used a Channel to handle the communication between your application and the SDK. Now, we have transitioned to using CompletableDeferred, which offers a simpler and more robust solution for this use case.
Below, we will explain why this change was made, how it benefits you, and how to migrate your existing implementation.
Why CompletableDeferred is Better Than Channel
When dealing with a single object (like an ExoPlayer instance) that needs to be passed temporarily between your code and the SDK, CompletableDeferred is a more suitable choice than Channel. Here’s why:
Purpose
Channel: Designed to stream multiple values over time.
CompletableDeferred: Designed for a single value that needs to be produced asynchronously.
Complexity
Channel: Requires explicit closing after sending the value (close()).
CompletableDeferred: Automatically resolves after a single value is provided (complete()).
Resource Management
Channel: Needs to be manually closed to avoid resource leaks.
CompletableDeferred: No need for manual cleanup; it’s a lightweight, one-time operation.
Error Handling
Channel: Errors must be handled explicitly (e.g., trySend and checking for failures).
CompletableDeferred: Errors are simpler to handle via the complete function’s return value.
Use Case Fit
Channel: Overkill for single-value communication.
CompletableDeferred: Perfectly suited for single-value, one-time communication.
Benefits of Using CompletableDeferred
Simplicity:
CompletableDeferred is designed for one-time communication, making it easier to use and understand.
No need to manage the lifecycle of a Channel (e.g., opening, closing, or handling backpressure).
Safety:
It ensures that only one value is sent, eliminating the risk of accidentally sending multiple values or forgetting to close the channel.
The complete function provides a clear success/failure indication, making error handling straightforward.
Performance:
CompletableDeferred is lightweight and optimized for single-value communication, reducing unnecessary overhead.
Migration Steps
If you are currently using the Channel-based approach, here is how to migrate to the new CompletableDeferred implementation:
Old Implementation (Using Channel)
Kotlin
expPlayback.expInitializePlayer.collect { responseChannel ->  
    responseChannel.trySend(generateExoplayer())  
    responseChannel.close()  
}
expPlayback.expInitializePlayer.collect { responseChannel ->  
    responseChannel.trySend(generateExoplayer())  
    responseChannel.close()  
}
﻿
New Implementation (Using CompletableDeferred)
Kotlin
expPlayback.expInitializePlayer.collect { deferred ->  
     deferred.complete(generateExoplayer())  
}  
expPlayback.expInitializePlayer.collect { deferred ->  
     deferred.complete(generateExoplayer())  
}  
﻿
Key Changes:
Replace Channel with CompletableDeferred.
Use deferred.complete() instead of responseChannel.trySend().
Remove the need to close the channel manually (responseChannel.close()).
Optionally, add logging to track success or failure.
Why This Change Matters
By migrating to CompletableDeferred, we have streamlined the integration process, making it easier for you to inject your custom ExoPlayer instance into the SDK. This change reduces boilerplate code, minimizes the risk of errors, and ensures a more efficient communication mechanism.
Integrating ExoPlayer
Guides & Tutorials