I am facing a strange problem concerning Google Maps' geocoding/reverse geocoding service.
My iPhone app uses Google Maps services in order to geocode addresses or reverse geocode points of a map view. The URLs I am using are:
#define WS_GEOCODE #"http://maps.google.com/maps/api/geocode /json?address=%#&sensor=true&l anguage=%#"
#define WS_REV_GEOCODE #"http://maps.google.com/maps/api/geocode/json?latlng=%#,%#&sensor=true&language=%#"
The problem is that when I use Wifi everything works well, but when I access internet through the carrier's network I always get googlemaps status OVER_QUERY_LIMIT.
Any ideas?
Google maps has very strict limits for personal use. I guess that the IP it detects has been using their service too much and has been blocked. Next step is the professional paying service which costs $10K .... a year ....
May I suggest (as I just did the switch myself yesterday) to use Bing's geocoding service. It works nearly as good and the limits for free use are A LOT higher than google's. Google kicks you out after 2500 requests per day. a Bing "developer" app allows 250.000 calls a year or something like that.
Imagine the topology of your connection in the case of mobile carrier: your phone connects to the carrier server through an APN, the carrier server forwards the requests on your behalf. The external IP that Google Maps API sees is always that of your carrier.
The Google Maps API terms of use say something about usage limit; so I'm thinking there's a possibility that a lot of devices connected to the same server generate quite an amount of requests and reach that limit cumulatively.
there is a tricky for this...
with php you can use sleep function to delay another request php sleep
Related
I am trying to integrate smart home devices with Google home and Alexa but I am facing following issue.
Communication between Google Home/Alexa and our device cloud server is HTTP.
Communication between smart home device and our device cloud server is MQTT.
How do I keep track of synchronous request-response? Is there a better way to implement this system?
Perfectly possibly to do with HTTP to MQTT and back again.
I've done it for both Alexa & Google Home for my Node-RED nodes.
You just need to keep track of on going requests and include a unique id in the request/response MQTT messages while also running a timer to handle no response from the device.
The project gBridge (https://github.com/kservices/gBridge; https://about.gbridge.io) basically implements plain Google Assistant/ Alexa to MQTT bridging.
Regarding your questions, there are two points that help to implement these solutions:
Think in terms of devices or endpoints, rather than requests. When you just want to "translate" HTTP to MQTT, you are inducing a lot of issues like you've figured out. You probably want to implement a logic that allows MQTT topics to control/ query your actual deviecs - not ones that respond to HTTP requests. This makes thing a whole lot simpler.
Caching is essential. Allow your bridge to have a local copy of your device's states. When having the properly implemented cache, you won't need for any response. Just use the cached data.
We are using the Twilio Programmable Voice Service globaly. In the US and EU the performance is acceptable. In Australia there is a long delay after the user answers the phone and before the user hears anything. I attempted to set the region using the C# SDK using the regions specified here. That essentially sets the root API url to https://api.au1.twilio.com which does not exists/respond (502 error). Has anyone had any success specifying the region for REST API calls using Twilio?
** I have tried using us1 and ie1 with the same results.
I received this from Twilio Support. It looks like server side API calls are US only.
Thanks for writing and sorry for the trouble. I think where we're
getting stuck is the difference between the server-side helper library
concept of the HTTP client for making and responding to REST API
requests, and the voice over IP product Client and its associated
SDKs.
The region can absolutely be set on the VoIP Client applications, and
we have this in place specifically to address the types of audio
latency you're describing below; the important distinction being that
the region designation happens at the local application, not in the
serve-side code. You can see how to set the region in the JavaScript
library, the Android SDK, and the iOS SDK.
The reason this works for VoIP Client calls is that we have media
endpoint in those regions; however, we do not have regionalized API
endpoints--api.twilio.com is only located in the US, so trying to
create a TwilioRestClient for HTTP requests will not work.
Hope that helps. Please let me know if you have any questions
I recently have been very interested in developing iOS apps (for iPhone specifically) that can "communicate" with nearby (geographically) apps.
My networking skills/resources are limited, so I was really hoping to make it a peer to peer app, avoiding the need to host my own server.
It seems like I have a few options, including the newish Multi-peer Connectivity framework, and Location services.
I was hoping someone who has experience writing peer to peer apps could direct me to what they think the most logical approach would be.
Additonal info:
*I am only looking to send text/small pictures (speed is not a priority)
*Detecting nearby (within a mile or so) geographically is the main goal
*Possibly communicate with Android devices (I know multi-peer connectivity lacks this)
Peer-to-peer communication is limited to a range of about 50 meters. To extend the range you can create a mesh using intermediate peers to relay messages. That is how the Firechat app works.
If you want to communicate over greater distances without a mesh I believe you will need to go via the cloud
In terms of communicating with Android, the people who made FireChat are coming out with their SDK. Not sure how/what pricing will be but I assume they will offer this cross platform function. There are of course other ways but I am not that advanced in app development to know them yet.
For a simple chat app there are many free online tutorials that help you create iphone to iphone chat app that can also send images. Range will be limited however to whatever is max for WiFi. Like Keith said, mesh is another option but I believe everyone in the network has to have the app for the data to bounce.
Apologies in advance for the general-ness of the question.
I'm writing a multiple client iOS app for viewing the video feed from a single camera. Can the QX10 api support two (or 3) iPad's discovering/viewing the same QX10 at the same time?
I've been looking QX10 sample code, the camera api docs, StackOverflow, and of course the dev website and haven't seen an answer. I'd just buy the bloody thing to test with, but there are none nearby and I was hoping to avoid having to mail order/return it if it didn't work.
....And we're not locked into HW. If there's a better option, I'm open....
I don't believe it does. For ios, the camera creates a network that the ios connects to. (In ios settings/wireless) Any further attempts to connect to the camera from another device fail. Since the API only works after a network connection is established, I don't see how the API could possibly allow 2 devices could connect at once.
(No extraneous words in this post b/c that will get edited which auto down votes the question.....ahhh internet)
I did not try it, but you could use a computer with nat. For example an openrwt router to open up multiple wifi interfaces, one to connect to the camera, using the 10.0.0.0 network the camera uses and then an other network to connect your clients with NAT.
The question would be when the API would start to get confused.
So depending on what you want, maybe some mapper on that helper-computer could
do some proxying of information.
So in theory with an external box, maybe, but as Oldmicah said, it seems that only
one device can connect at the time (at least my QX100 also behaves like that). :(
I use the static map google webService in my iOS app.
And when i read the google document of the static map, i found this Note:
https://developers.google.com/maps/documentation/staticmaps/?hl=fr#Limits
The Google Static Maps API has the following usage limits:
25 000 free static map requests per application per 24 hour period.
Additional image requests can be purchased on a per application basis at the rate currently listed in the FAQ. Additional quota is purchased through the API Console and requires the use of an API key.
If a user exceeds these limits, the server will return an HTTP 403 status.
Then i created an app that sent more then 25 000 request to the WebService,
but my application from the other devices and the iOS still working without any problem.
Please someone can explain to me, what the static map WebService work, because i reached the number max of the request/application and my ios App still work on the other devices ?
From an ip or from a device number of free request that can be made from google is 25000 request only per day after this you have to pay to google for it. So answer to your question is request from a particular ip is considered for calulating total requests.