iGeoCacher URL Options

iGeocacher web app server URL to dowload cache data uploaded and translated from either LOC or GPX files:

http://www.ayefon.mobi/geo/igeocacher3.cfm?id=your@emailaddress.com

The "id" is the one you got when you registered with me if you are a web app user or the one I sent you when you requested an account to use with iGeocacher (a service included in the purchase.)

Upload your cache file here for parsing/translation.

http://www.ayefon.mobi/geo/upload.cfm

GPX and LOC URL Options

This pretty much depends on where you decide to host your file. I think the easiest approach is to just pick some name like "mycaches.gpx" and stick with it. Then to load different caches just overwrite that same file name with a copy operation. So the GPX url would look like:

http//<your host>/<your folder>/mycaches.gpx

Natureally your actual URL will depend on where you host it and the folder structure in place at that location. Of course the equivalent for the LOC files would be perhaps:

http//<your host>/<your folder>/mycaches.loc

It is worth noting that the file extension is not important. I had one user whose web server would not serve up files with any extention other than .html and he just changed the extension from .GPX to .html and it worked fine. All iGeocacher does is try to read from that URL on port 80 and parse the XML data stream.

Why two URL settings? The format of GPX and LOC files is like night and day different. When you touch the "Add GPX Data" button in downloads, it will read data from the GPX URL and it expects it to be in Groundspeak's GPX format.

he same holds true for the "Add Loc Data" button respectively.

Important Tip for Setup

The iGeocacher information reads the data files over the network in the same way your PC browser would. Therefore you can use your browser as an independent verifcation that you have connectivity and that the data is being served. Simply put the URL you are using for any of the three data types (iGecacher format, GPX, or LOC) into your browser and you should be able to display the data. If not, then most likely your iPhone cant "see" it either and you can use your browser to experiment and test until you have connectivity established. In the first few days of the rollout of this app, just getting the data served was the biggest part of the battle.

Test connectivity with Safari on your iPhone/iPod Touch

Another test you can do is to put the URL into the regular Safari browser on the iPhone. It should connect and display the raw data. If it does then you know that your iPhone isn't being blocked by a firewall or something on the PC. If you can't display it in Safari then iGeocacher won't be able to see the data either. Using Safari on your iPhone/iPod Touch is a good independent connectivity check.

It turns out that the design/development philosopy of the iPhone is very network centric. Storage of files in absolute directory locations on the device is not encouraged as they might change the structure of that at any time. So most data transfer involves URL's. Even iTunes doesn't let you copy over arbitrary files. As much as possible I'm trying to adhere to the guidelines they give us as developers in the SDK and of the options favored there in the documentation and examples, using a URL/network based access clearly seemed best. Besides, this way you don't have to find your cable (grin). As we learn together, other options may become clear but for the 1.0 version leveraging the built in wi-fi Bonjour networking seemed to be the way to go.

I had one user ask me about this as he had "jailbroken" his iPhone and he had full access to the underlying directory structure. He wanted to know if there was a place on the phone he could just "copy" the files. In the current design, I read the network data stream and parse the data "at the door" directly into the database. So your actualy GPX and LOC files never reside in the iPhone (at least not on iGeocacher's account.) Much as I wish we had this available to us as power users, I am obligated to stay within the Apple constraints for access. They do it for your protection as consumers among other reasons. To avail myself of the benefits of the App Store, I have to stay within those bounds as a developer.