-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] The example code for setting up the player is complicated and docs are insufficient - can you take the example setup code and productize it? #2344
Comments
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
I believe this issue remains open. If someone could explain what is required here wrt properly initializating rntp, I'm more than happy to write some doc. |
hard to say what happens with your setup code without some serious attention. but the general workflow (android) is:
because of this it is advised to call TP.setupPlayer ASAP so any other TP calls can actually work. I've never seen these errors and retries are there because android is notorious for changing requirements over versions (in a way, becoming more secure as well). This lib dates from 2018. Although I can tell you the particular error you mention, |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
This issue was closed because it has been stalled for 7 days with no activity. |
Context
These thoughts were triggered by my receiving an error in the field that is
On Android the app must be in the foreground when setting up the player.
and my realizing the code I have in index.js isn't sufficient (or perhaps incorrect) for robust rntp initialization.I offer it below as an example with my app's other index.js goo left in (sorry).
What is the need and use case of this feature?
The code in the example app here for setting up the player is complicated and the requirements are not really explained in the documentation (e.g., handling of initialization failures and retries). The published docs on how to set things up should be sufficient to cover what to do for your app to be robust in production, but they aren't.
Describe the ideal solution
I would suggest re-working the initialization APIs and/or creating a higher level, simple API call or perhaps two. (This is par for the course for almost every other library.) One could define an object that takes in the information you need for initialization and then abstract away the complexity in the example as much as possible.
The code here is what I'm talking about. At one end of the spectrum, you could just move the example code into the library itself or some version of it that is slightly more general purpose.
Relatedly, with today's APIs, it's not clear the requirements are for ordering and timing of registering the playback service and setupPlayer. Which one needs to happen when? Updating the docs for that would be a helpful step.
Sample insufficient initialization code of mine
The text was updated successfully, but these errors were encountered: