I'm trying to voice control my smart TV via Google Nest device. I have made a local fulfillment app and uploaded two bundles both node and web to the action console. When I tried to debug through the chrome://inspect, the web version failed to connect to the TV after a successful discovery. When I tried to run node bundle-node.js in terminal, it threw ReferenceError: smarthome is not defined.
So I am wondering how Google Nest device utilize those two bundles? Which version gets to serve in the Google Nest device? I assume the node version gets to serve, while the web version is for debugging. If my assumption holds, how does the dependency to smarthome get resolved in the node env? thanks for any help.
Check out the test and debug section of the Local Fulfillment Guide as a starting point. A couple highlights based on your question:
You need to upload your bundles to submit for production, but during testing you should self-host your local fulfillment and enter that value in the Enter your testing URL field.
The Local Home SDK is only present on Home/Nest devices, so you cannot currently test or debug on your local machine. You have to load the code onto the device as described in the guide and use chrome://inspect.
Use the web bundle when testing your integration today. This is the version that will be run on Home speakers and Nest displays.
Related
I just released my react app in a production environment in Cloud Foundry, but the only problem is that if I make changes to the app, and reupload the app, my users don't see the changes unless they clear their browser data, what can I do?
Reason for this issue: Browser is using its cache not your build to serve the client
Remedy to outcome: Inform the changes in metadata.json
metadata.json is a file that swings between request and browser checks for any mismatch with it's cache. if no then cache is served to client.
There are more then one way, thus am not telling direct solution, instead gothrough the below link will take to through various steps to follow
flexdinesh blog from dev.to
I am new to Gatsby so please bear with me.
I want to add offline support to my app such that if a user were to try access it while offline (after having visited it online) it would still show up.
Would gatsby-plugin-offline help me achieve this?
If so, how can I try this out? So far I have tried using the plug-in in my app (all default settings), building the app and then serving it locally on my computer at http://localhost:9000/. When I stop the dev server and try access http://localhost:9000/, it does not show up. How can I test to see if this plugin works?
After gatsby build the public folder should include sw.js file.
Otherwise, you can find whether the service worker is registered on not at Chrome Dev Console over Application > Service Workers.
Chrome desktop application for web based product. Is this possible in chrome web apps
Product has following items
Angular JS --- Front-end framework
Rails --- JSon Communication
I have created the chrome desktop apps, which will directly open the site with icon. It's more feel like desktop application. In any OS it will run. The thing is working fine.
Problem:
It will always download the js and css files.
How i want to develop the chrome desktop apps
When launching the chrome desktop app, save all the assets locally.
Whenever chrome desktop app launched, it should refer the locally saved assets (I mean angular js files and css)
Before launching the chrome desktop app, it should request the server whether the assets are changed or not. If changed delete the locally saved files and save the latest one.
If assets are not changed use the old assets files. In this way, we can avoid the initial loading of all the files from the server.
Anybody did it previously or chrome provide any options for this?
Ideas are welcome!
Its totaly possible.
Read these docs: https://developer.chrome.com/apps/offline_apps
By myself i pack the css and javascript into the chrome app so you never have to download them on startup. But in your context its more like a webview app with caching functions.
You can use indexeddb or other local storage APIs to store assets in the client computer.
You can solve this on the web app side by employing ApplicationCache, which specifically fits what you describe.
Using the cache interface gives your application three advantages:
Offline browsing - users can navigate your full site when they're offline
Speed - resources come straight from disk, no trip to the network.
Resilience - if your site goes down for "maintenance" (as in, someone accidentally breaks everything), your users will get the offline experience
The Application Cache (or AppCache) allows a developer to specify which files the browser should cache and make available to offline users. Your app will load and work correctly, even if the user presses the refresh button while they're offline.
While it is primarily an offline-fallback technique, it allows you to cache resources locally just for speedup purposes. Actually having an offline fallback is a bonus in this case.
Actually building a Chrome app for this will probably not help - you cannot update local resources from your web app side, you'll need to update your app through WebStore channels only.
I'm deploying, for the first time, an app on google app engine.
It seems to have succeeded, however when I go to my apps url I'm directed to the traditional "welcome" page from the default installation.
I do not have a "welcome" app. nothing about "welcome" is listed in my routes.py file.
so why am I directed to myURL/welcome/default/index ?
I can't even type in the direct url that I know I want to access without an "invalid request" error.
This also only happens when I upload and run from appspot.com, when I use the local development engine things are fine.
According to the dispatching rules, if you go to a URL without specifying an application, it will default to the init application, and if not found, it will then look for the welcome application. Also, if you used the standard app.example.yaml configuration file when deploying, the welcome application would have been included in your deployment (see the GAE deployment section of the book).
not much of an answer, because I still don't know exactly how the routing occurred, however I had the web2py app in 2 locations. On my local machine and on the web hosting server. I had been uploading the version from the hosting server to GAE. This one was failing. When I uploaded the one from my local machine things started to work.
So I must have had a discrepancy somewhere between the two I just couldn't find.
You must call your application: "init" and deploy it in GAE.
For example, if you have developed yourweb2pyapp, your main page will be yourweb2pyapp/default/index and your main page in GAE would be yourGAEapp.appspot.com/yourweb2pyapp/default/index.
But if you write in your browser yourGAEapp.appspot.com you go to yourGAEapp.appspot.com/welcome/default/index and this is the problem.
The simplest solution is that you call your application "init" instead of yourweb2pyapp when you deploy it in GAE. So you new main, and default page will be yourGAEapp.appspot.com/init/default/index
You can pack yourweb2pyapp and then import it as init.
You have to be careful with the internal links.
I want to test and develop locally, while having the application on the air, and I'd rather not use two separate application id's because this means I have to change the code every time I deploy a new version and then change it back.
I understand that I can change the host file so that localdev.{{my application URL}} would refer to localhost and the URL will be valid, so I won't get the 191 code, but the Google App Engine launcher forces me to use port 8080, and this can't be defined in the host files. If I try to enter localdev.{{my application URL}}:8080 I get the 191 error code again.
Is there any way to use port 80 with the Google App Engine launcher?
Or is there another solution?
UPDATES:
I managed to run locally on port 80 by using the Python file from the Google App Engine directory and not the Google App Engine launcher GUI. However, Facebook doesn't recognize localdev.{{my application URL}} as the URL, and it still gives me the same error code, 191.
Once I changed the host file into {{my application URL}} without the "localdev." it worked, so this must mean the URLs must match exactly, and not just the domain. Is this true? Anyway, it isn't optimal, because it means I have to change the host file all the time, but it's something you can live with...
I have 2 Facebook apps, one with my real URL (for production), and one with http://127.0.0.1/ (for development). Then I have a utility function in my code which checks self.request.host, and selects the appropriate app id and secret.
The reason I use http://127.0.0.1/ and not http://localhost/ or http://localhost:8080/ is that I found only http://127.0.0.1/ would work in Internet Explorer (other browsers seemed fine with those other two URLs, provided they matched the Facebook app).