I am currently looking for the best way to test my receiver app code. I would like to know if there is a way to have a non-production version of the receiver app code running, which is not visible to my users, so that I can test new functionalities without possibly breaking others that are currently live and in production. So far I have been doing trial and error with small snippets, but this is far from optimal.
My final goal is to be able to create different GIT branches of my code, which I can test on my Chromecast that is not visible to the public.
Thanks
One approach is to create another app id to be used for testing/development; as long as you do not publish that app id, no other device but your registered devices can see that app.
Related
In Google's latest docs, they say to test Go 1.12+ apps locally, one should just go build.
However, this doesn't take into account all the routing etc that would happen in the app engine utilizing the app.yaml config file.
I see that the dev_appserver.py is still included in the sdk. But it doesn't seem to work in Windows 10.
How does one test their Go App Engine App locally with the app.yaml. ie: as an actual emulated app engine app.
Thank you!
On one hand, if your application consists of just the default service I would recommend to follow #cerise-limón comment suggestion. In general, it is recommended for the routing logic of the application to be handled within the code. Although I'm not a Go programmer, for single service applications that use static_files and static_dir there shouldn't be any problems when testing the application locally. You might also deploy the new version without promoting traffic to it in order to test it as explained here.
On the other hand, if your application is distributed across multiple services and the routing is managed through the dispatch.yaml configuration file you might follow two approaches:
Test each service locally one by one. This could be the way to go if each service has a single responsibility/functionality that could be tested in isolation from the other services. In fact, with this kind of architecture the testing procedure would be more or less the same as for single service applications.
Run all services locally at once and build your own routing layer. This option would allow to test applications where services needs to reach one another in order to fulfill the requests made to them.
Another approach that is widely used is to have a separate project for development purposes where you could just deploy the application and observe it's behavior in the App Engine environment. As for applications with highly coupled services it would be the easiest option. But it largely depends on your budget.
google play developer console has a near channel called "internal test". it is the last one in the list and i took a image of it below. how does it compare with alpha channel ? im not understanding its usecase ? seems your allowed 100 users.
I tried looking for documentation but i only see that it makes the app available faster. is that the prime benefit ?
That is correct, the Internal test track primary advantage is that APKs published to this track are available to testers within seconds, instead of up to several hours for Alpha or Beta.
Also, Internal testers can access app versions that are not otherwise available to other tracks users due to various restrictions such as device exclusions.
Finally, Internal testers do not have to pay to acquire the test version of the app, if the app is paid.
The internal test track is designed for internal testing use cases.
I'm trying to prevent spam and I want to know:
how can I detect if the request to the API is coming from a mobile device?
Thank you
The only way to check if the request is coming from a mobile device is by checking the user agent sent with each request. The user agent can be found in HttpContext.Request.Headers['User-Agent'].
Then compare the user agent value with a list of mobile browsers found at e.g.: https://deviceatlas.com/blog/mobile-browser-user-agent-strings
One option is to write your own user agent parser that figures out if it's a mobile browser or not. That is a HUGE job and one you will have to continually keep expanding as new devices are released. It has all its own problems like you said in the other comment - how do you get a list of the new user agents to include...
Another option is to find some free library written in ASP which will do this work for you. I can't see libraries written in asp.net Core API. If you use one, be making sure that it's regularly updated by the developers and that you keep updating your copy of the library too.
Last option would be to use a user agent parsing API. A good one will give you detailed information about the browser, software and the hardware/software types.
I did a comparison of these for my job a few months ago - https://developers.whatismybrowser.com/api/ looked the best to me - it's platform independent (doesn't matter what language you're writing your system in ASP/C#/Ruby), and is freemium and has an active dev team working on it. also because it's an API, you never have to update your code libraries, it always works on the latest detection of what they have written. We still use it today.
I am trying to use the sample code provided for Amazon Alexa API, and trying to run hello world / history buff examples through the computer. How do I test from my local machine, about the request and response formats. In the README file it is given to visit this website : http://echo.amazon.com/#skills, but I could see nothing there as it mentions more about connecting to the device. I dont have the device, but I would like to test things locally through my laptop.
We have a tool that we built specifically for this purpose:
https://bespoken.tools/blog/2016/08/24/introducing-bst-proxy-for-alexa-skill-development
Requests and responses from Alexa will be sent directly to your development laptop, so that you can quickly code and debug without having to do any deployments. We have found this to be very useful for our own development.
Our Github project is here:
https://github.com/bespoken/bst
We are also adding other useful commands for Alexa development.
Yes, the Test tab in the Alexa Developer Console allows you to interact completely with your skill during development.
You will type in your utterances instead of speaking them, but from a program logic perspective, there is no difference.
The Test page also provides a place to type in your skill's reponses, to see what they'll actually sound like. I recommend that you do so if you don't have an actual device. Sometimes adding or removing a comment can help make the responses easier to understand, or sound more natural.
Use http://ngrok.com
See my video for a tutorial:
https://youtu.be/eC2zi4WIFX0?t=108
I'm guessing the key point in OP's question is "dont have the device".
There is a web simulator at https://echosim.io
It behaves just like any other Alexa 'device'. Login with your Amazon account and it picks up all your selected skills, etc. Shows up as just another device in the Alexa app.
Only downsides: You have to click to talk, and it's pretty slow, presumably because it has to receive, buffer, convert and re-ship the audio.
Also, I'm not sure how you register/connect to the Alexa service in the first place without an Echo/Dot device, but I assume there is a way.
UPDATE:
More recently, there are a number of free 3rd-party apps on Android and iOS devices to also simulate an Alexa/Echo device. It can be less klunky than the web site. Search for 'Alexa' in your App/Play store and try a few of them out. "Reverb" is one: https://itunes.apple.com/us/app/reverb-for-amazon-alexa/id1144695621
Good luck.
I dont have the device, but I would like to test things locally
through my laptop.
If you are developing the skill using an AWS Lambda function in Python, have a look at: https://pypi.python.org/pypi/FirstAlexaSkills/0.1.2
It can generate custom Alexa events based on your parameters (utterances, slot variables) and allows you to create test cases against your local code, as well as against AWS Lambda itself.
You can also test your skill locally by following this tutorial:
How to test your Alexa skill locally
I have basically two URL's http://xyzwebsite.com (for Development Testing) and http://abcwebsite.com (For Production). I have a simple Login mechanism where a user can click on Google Plus icon to log in rather than using their Username and Password. I created one Project for Development with obviously different Client ID and different for Production with a separate client ID.
But I tested both the URL's above with the client ID of Development project and it worked fine. I am wondering why there is a need ot having multiple projects in Google API console?
There is no particular need. A single project can have several URLs and client IDs for use.
Some reasons you might use multiple projects include:
Changing project settings in dev without worrying about breaking production
If you have a development script that gets into an endless loop or something it might use up all of the quota and the production app might start throwing errors
You might want clear branding on the dev app that explicitly identifies as not production.
Some unknown reason I can't think of.