If all the quests from Apple appear to be from one IP or a series of IPs that are being cached by Google, this could be a good reason.
I too also ended up using Google's new REST API for a custom handler that I used on the server side for other lookups, but you have to be careful that you make only a certain number of requests per day. A single user of your iPhone app could make too many requests in one day to the Google REST API and it could block them. I ended up using Memcached to cache the results since the location I'm checking only changes every other day.
Also see my latest blog post:
Ari Braginsky: The Curious Case of MKReverseGeocoder
Quote:
Originally Posted by edpark
I've been having the same problem-- works in the morning, stops working at night.
Here's my theory. We know that Google throttles reverse-geocoding requests by IP. My suspicion is that this throttling is reset at midnight each night and that MKReverseGeocoder passes its requests through a centralized caching proxy; since that proxy would appear as a single IP to Google, it stops working at a certain point during the day.
In any case, I ripped MKReverseGeocoder out of my app and rolled my own custom class using Google's new REST API ( Geocoding - Google Maps API Services - Google Code) , and the app has been working great.
Hope this helps. The other thing someone could do is to try complaining to Apple and/or Google and get them to fix this, but rolling my own was easy enough and I didn't want to wade through the support bureaucracy. |
