I want to integrate with the Chromecast Developer API so I want my chromecast(being shipped) whitelisted but you are supposed to supply 2 URLs. What exactly are these for? I might just be confused about how it works. Thanks.
EDIT:
I found this source to be a good example to demonstrate how to use it. The HTML in the receiver is what you would have the white listed URL pointing to.
A Receiver is a HTML5 application (HTML/JS/CSS3) that runs on the Chromecast device. Your Sender application must send an APP ID to the device, which then looks up the app in a table and loads your page for you. You then use the App ID in your Receiver (on the Chromecast device) to open a connection to your Sender.
We ask you to provide one or two URL's. We expect that you'll want to have a development URL, and eventually a production one. You only need to provide one.
From the Chromecast Device Whitelist Request Form
Please provide at least one receiver URL, we will provide an
Application ID for each of them, 2 max (typically, you'll list a
production URL and a testing URL)
Related
Is it possible to get the amount of times an URL is received by a device from the proximity beacon API? I want to know what the click through ratio is of the broadcasted URL.
That depends. If you write your own app that scans for Eddystone-URL beacons and triggers some content (e.g., the web page itself) off of that, then naturally you're in full control and can implement this kind of analytics. Though it'll only apply to people which installed the app.
If you rely on Chrome for iOS, or the Physical Web iOS and Android apps to discover the Eddystone-URL beacons, then these apps do not provide any such numbers.
However, both Chrome for iOS and the Physical Web apps do fetch some metadata about the URL they detect, such as the page title and page description, without the user first clicking on the link. So there's a slim possibility that you could filter such requests out (they will be made by the Physical Web Service, or some similar "bot"), separate them from the actual visits, and do analytics based on that. Most likely however, this "bot," or the proxying service (which is there precisely to prevent this kind of tracking, and protect the user's privacy), will also do some caching, so you'll see fewer requests than the actual number of times the URL is received by the device.
And finally, dropping to a lower level, a note: most beacons are uni-directional, i.e., they broadcast information, but don't receive any information back, so beacons themselves usually can't count the number of packets on the receiving end. (I guess you could technically use the Bluetooth "scan response" mechanism to do that, but it would require custom beacon hardware/firmware.)
Unfortunately, no, it will not do this by itself.
Google's Proximity Beacon Api is a server-side system that stores metadata about beacons (location, battery level, etc) It requires you to add special client code integrated with your app to submit detection data.
Similarly, detecting Eddystone-URL beacons generally requires you to add custom code to your app to do the detections and and present the URL to the user. (The only exception to this is for some Chrome for iOS users with the Chrome Today widget enabled, and no public system provides click through rates.)
Since your app must present the URL itself you really have to roll your own solution to this problem.
If I understand right, you should be able to achieve this by Google analytics campaign. Setup a campaign, add campaign url to ibeacon url and you should be able to check the details analytics through Google analytics.
I'm trying to make a Firefox addon with the Firefox Add-on SDK and API, and I have some questions about their possibilities before I start using them.
My college's Wi-Fi authorization expires every 30 minutes only to have fun pissing off their students. There are already some autofill addons available on many browsers but it's still destructing to move the mouse pointer onto the "Login" button and click it when there is one second left to turn in a midterm paper. I've heard my friends complaining like this for months and I myself think the thing is actually annoying sometimes, so I decided to develop a Firefox addon that takes charge of the job so that the authorization process will feel not even existing once the addon is activated. (I just want to impress my friends honestly.)
For ease I would like to develop the addon within the Firefox add-on SDK. I found that my addon would be utilizing the page-mod, password and request APIs; page-mod to detect the Wi-Fi service's auto-redirection into their authorization page, password to fill in the page's form by a student ID and password stored in the individual Firefox browser, request to redirect the "Login Successful!" page into the originally given destination.
So I guess it should be possible to achieve my goal with this SDK and APIs, but there are still some questions that I need to ask before I proceed:
Is it possible to pass a callback function to page-mod::PageMod (not as a String or a URL to another JavaScript file)? If not, can it be done using the lower level API?
Is it possible to actually redirect a page in a tab into another page only using high level APIs?
Is it possible to remember the original destination's location (with the request method and contents) and call it in the process of page-mod::PageMod (in order to re-redirect out of the authorization page)? If not, can it be done using the lower level API?
Is it possible to perform the addon's redirection function on inactive (background) tabs where the opened webpages automatically keep connecting to the Internet and get redirected to the authorization page?
Thank you so much for reading and please spare a little bit of your time for me. Thank you again!
Is it possible to pass a callback function to page-mod::PageMod (not as a String or a URL to another JavaScript file)? If not, can it be done using the lower level API?
No, everything that goes through the port is serialized using JSON serialization (See docs). Instead you would probably emit an event from your content script to execute the callback method with parameters you pass it in the module scope and hardcode parts that need to be done in the content script with port event listeners.
Is it possible to actually redirect a page in a tab into another page only using high level APIs?
Totally, if you're in a content script, you can just set window.location, or in your modules you set the location of a tab, see https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/tabs#url.
Is it possible to remember the original destination's location (with the request method and contents) and call it in the process of page-mod::PageMod (in order to re-redirect out of the authorization page)? If not, can it be done using the lower level API?
Possible? Yes, depends a lot on how the redirection from the W-LAN works. Generally all the SDK offers you is getting load/ready events for tabs and reading a tab's current URL. So if you get a ready event at the point of the redirect you're fine. If your college login remembers the redirect target using a get parameter in the URL you're fine. If your college doesn't adjust the URL, you're fine. If you really need to dig through the request, you'll have to ge a bit deeper than even what the SDK offers you, but it is possible.
Is it possible to perform the addon's redirection function on inactive (background) tabs where the opened webpages automatically keep connecting to the Internet and get redirected to the authorization page?
JS execution for Add-ons is not paused based on a tabs state.
We need to protect our HTML5/JS application from been stolen. (We need to protect JavaScript code mainly.)
Chromecast requires application hosted on HTTPS server. But anyone who puts sniffer on the same network with Chromecast can find what URL it loads and load it directly from any browser.
User agent etc. can be easily mimicked if use it to secure application.
What would be the best mechanism to protect proprietary JavaScript code in published Chromecast JavaScript application from been stolen?
Thanks a lot in advance.
Sasha
One common practice is to minify + obfuscate the JavaScript code.
Can generate some URL with a session id in it, and have the URL become invalid after some time. This way if someone intercept the URL using sniffer it will only work for a short period of time.
One other option is have your HTTP server whitelist the client IP adress or mac adress.
You might want to look at how the Spotify chrome app work.
In my Android Sender Application, I would like to display the status of a newly discovered Chromecast device. For e.g if another app lets say Youtube is currently casting to this device, then I would like to put a status as "casting Youtube" next to the device name in my receiver list.
For this, once I discover a media route, I connect to that device. On getting a ConnectionCallbacks.onConnected() event, I try to retrieve the application metadata using Cast.CastApi.getApplicationMetadata(GoogleApiClient). But I'm getting a null value here. When I run my Sender App, I make sure that I'm casting to the same Chromecast receiver from another app like Youtube. So I expect the application metadata to reflect Youtube app details its like appId, name etc. Is there a different way to achieve this?
YouTube is still using the old preview SDK so that might be a factor in seeing null. Please try an app that is using the new SDK and see if that returns more useful data. I know there was a bug which caused that method to return null all the time but I believe that was fixed with the recent play services update.
From a web browser (Win/Mac) I need to launch a desktop application and pass it a response string (e.g. XML) from the webserver. For Windows, as far as I can tell I have two straightforward options:
Set the application as a default program, and respond in a standard way so the browser associates the response with that extension/Content-type. The browser validates the association, stores the response to a temp file and the app opens it.
Register a protocol, which causes the browser to launch the app, passing the URL to it. In this case apparently the string needs to be something like Base64-encoded (yet shorter than the browser's URL length limit). Otherwise I'd store the file on the webserver and the URL would be given to the app to request itself. This seems to be less than ideal, but iTunes uses it (itms://).
Which is generally easier to register by app installers across platforms? What I don't know at the moment is the particular installer framework being used by this app.
I have NO development experience with this but I think it's all about what you are developing and the business model.
Option 1
Would be useful when you create some sort of custom meta data file which can be viewed nicely in an application.
Company X has their own XML Schema's. Customers can download their data in that format.
Company servers serve these files with their registered/custom content-type. Customer can install an application that handles that content-type. Application development is focused on supporting the XML Schema's and build an interface upon it.
Option 2
Would be useful when you distribute content online.
Apple turned their iTunes business model into a protocol. So every channel (web,browser extensions,mobile apps,desktop,mobile sites,company devices,etc) they want market share can use that protocol. Application development is focused on supporting the protocol (business model) and build an interface upon it most fit for the channel.