Skip to content
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

Local Development of Receiver Apps #8

Open
chrisjpowers opened this issue Mar 25, 2014 · 1 comment
Open

Local Development of Receiver Apps #8

chrisjpowers opened this issue Mar 25, 2014 · 1 comment

Comments

@chrisjpowers
Copy link
Contributor

So far developing a receiver app has been a pain -- you have to constantly deploy the new receiver code to a server, and then Chromecast seems to aggressively cache, so I had to regularly reboot the Chromecast to get the newest content.

Two possible solutions:

  1. Figure out how to get the Chromecast to see your local server on the network. I tried registering an app using my built-in Mac .local hostname, but it didn't pick it up. Maybe change DNS on the router?
  2. Create a development environment that stubs out Chromecast functionality and fakes it with other code instead. I gave this a quick shot, replacing the Chromecast messaging with Websockets messaging for communication, and having all callbacks succeed by default. This is nice because it means you wouldn't actually need a Chromecast device on the network to do development, but it's more work and could be brittle. The rough code is at https://github.com/chrisjpowers/chromecast-away/tree/websocket

Thoughts?

@tomkersten
Copy link
Collaborator

@chrisjpowers You can register the IP address of your laptop as the URL for your receiver app when setting up/registering your Chromecast. I had it set up to pull from a hosted static HTML page that was running on the python SimpleHTTP server. I used the IP address of my device (laptop) plus the port and it worked fine...

I don't believe the ChromeCast should cache it if the headers don't "promote" it to be...b/c I would think it'd be just like Chrome in that regard (ie: it should respect applicable headers)...I think.

That being said, I have done nothing with the receiver-app side of things. When I was thinking about this a while back, I was always planning on using either SSE's or Websockets for communication (likely SSE's, b/c it's simpler and not 2-way communication).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants