1.0.0 Refactor (Issue #36) #54
Conversation
…raries. Fixes issue#26 jellyfin-archive#26
…raries. Fixes issue#26 jellyfin-archive#26
…tyle) (Will satisfy the eslint test in another commit.)
# Conflicts: # tests/tests.js # www/chrome.cast.js
…ork version. (Most tests fail. Will try to fix in another commit.) # Conflicts: # README.md # tests/tests.js
…cess. (Chromecast.java) We shouldn't prevent requestSession from going through if there is no receiver. It handles this fine. It just shows that it is searching for a chromecast. This follows the behavior of chrome browser cast SDK. (chrome.cast.js) Remove unused imports. (Chromecast.java) Try to be a bit more safe with the threads. (Chromecast.java) Just pass the Chromecast instance to the callback on initialization. (Chromecast.java and ChromecastMediaRouterCallback.java)
…f power and annoying. Use the cordova log utility instead.
…n though. Updated the README.md with instructions on how to run these tests. We shouldn't load the tests.js file when the user is using the plugin for production use. We shouldn't include the test framework as a dependency. (Even a dependency of the test plugin.) Added a pull_request_template.md
Managed to match the desktop chrome SDK behavior regarding receiver updates on start up. Added some additional tests to cover more of the basic situations with receiver updates. Simplified all the get route stuff (will fix it up properly later)
capture routeUnselected reason
stop spamming emaiAllRoutes
…lute the top level of www
…good stack trace. So remove them and check error as soon as possible to the criminal code.
…chrome desktop chromecast behavior. We are supposed to receive a callback to the error handler. Not have it silenced. This is important if you have started connection animations. If you never receive a callback you don't know when to stop the animations, and whether to transition back to the unconnected state or to a connected stated. If you wish to ignore the cancel error, just filter it out in your error callback. eg. if (err.code === 'cancel') { //ignore }
…pendencies is not great. Though, we are on our way to a monolith test this way. :/ Pick our poison I guess.
Session is automatically "rejoined" when the webview goes to a new page and calls initialize (this follows chromecast desktop sdk) Do not call sessionListener on requestSession success (this does not follow chromecast sdk desktop behavior)
(So I changed all the tabs to spaces in the java files. Sorry commit history. o.o) It was a lot of work, so I disable a couple of the java checkstyle rules. They are listed in the first comment in check_style.xml. Issue jellyfin-archive#36 progress
…ent item index is i, you load items [i-1, i, i+1] *exclude i-1 if it is < 0, and exclude i+1 if it is >= queue.length. (aka. don't wrap the items.) This is to match chrome desktop behavior. Fixes a bug where larger queues (maybe 20+) result in a loop and queueLoad never returns. This is also safer because it should not result in a crash due to eating all the memory for extremely large queues.
…alse for successfull preChecks (chrome.cast.js)
…vered this case was effectively skipped. So the test now works properly and you can control the media after an app restart.
…t before the client has received the session. (Can happen on occaision when resuming a session on page reload or app restart).
Lindsay-Needs-Sleep
force-pushed
the
master
branch
from
71a556c
to
d7371ff
Compare
|
@dkanada Sure. I mean, I won't be able to dedicate much more time to this project (but I think it is working pretty good now). I don't mind if we "officially" transfer it. I should be able to answer questions/reviewing PR's. I'm not sure what else ownership entails? |
|
Figure this out because right now when one searches for "cordova chromecast plugin" it's not easy to get to Lindsay's plugin and it should. |
Lindsay-Needs-Sleep
force-pushed
the
master
branch
from
4d4c671
to
35cd482
Compare
…array whenever media doesn't exist (instead of setting mediaSessionId to 'invalidated').
|
Hmmm since your fork is hard to find it might be easier to just handle the issue here. If you consider your work almost finished we could make sure the existing master is tagged with a release, then pull in your changes. If you plan on making more changes in the future we could also give you write access to this repository so you can push to master. |
|
Haha, yep. I thought it was finished basically every commit since I submitted the pull request, but a couple of users kept finding bugs. Thankfully, the last one was closed yesterday, and no new ones have been reported, so I really, really, think it is done now. (fingers crossed >.<) Yep, that sounds like a fine plan! I don't have any plans for the immediate future.
|
|
@Lindsay-Needs-Sleep fyi: I've tested your latest master and the crash on iOS (#53) is still happening edit: I've now created a new issue in your fork with some more information, I hope this helps a bit |
|
@Lindsay-Needs-Sleep @dkanada Since the current master that we're using is already tagged as a release, I'm willing to:
Let me know what you think. |
|
Yep, I am fine with that. We can wait for that, or increment the version (1.0.1), or whatever the preferred method is. :) |
|
@anthonylavado Thanks for the merge and invitation! :D I was wondering if it would be possible to un-squash the commits in the merge? I was quite meticulous with writing detailed commit messages so that git blame would be useful in determining exactly why and what importance each piece of code does/holds. I would really hate to lose all of that! (I find it super useful!) |
|
@Lindsay-Needs-Sleep Sorry for the delay - I'm not very good at Git, and I forgot about my GitHub default for squash. @dkanada Here's a reminder 💯 |
|
@Lindsay-Needs-Sleep I reset our master branch to just before your pull request was merged. If you open a new PR with the same changes we can merge it again. |
I am excited to present to you the 1.0.0 re-write of the plugin! The plugin now follows the chrome.cast api much more closely! And (as far as I am aware) works without issue!
I say re-write because I estimated that ~80% of Android was changed. And iOS was moved to objc to fit the cordova plugin standard (so a ~100% rewrite).
There should be very few changes required to migrate from 0.x to 1.0.0. Mostly if you depended on
getRouteListElementyou will have to switch toscanForRoutes/stopScan, or if you depended on behavior not found on chrome desktop's api implementation.These changes have been tested on:
The largest changes of this refactor are:
iOS, Android, and Chrome Desktop all work the same now! (With a few caveats.)
All 3 will pass the same set of tests included in the plugin.
iOS and Android have
scanForRoutes,stopScan, andselectRouteto replacegetRouteListElementiOS and Android still do not implement the full chromecast API, but a few more have been added, and existing ones have been made to match chrome desktop behavior.
Bug Fixes:
sendJavascriptusageImprovements:
Auto-tests:
Manual Tests:
In addition to all the issues listed above, this probably fixes these as well: