Speaking of the previous post on my iPhone work, the source will of course be available. I'll publish it on Telnic's developer website that should go live in early october. This should allow iPhone developers to quickly get going with .tel without having to figure out how to make low-level DNS calls.
I'd love someone with iPhone and Objective-C experience to look over the source at some point and clean it up for release.
Thursday, August 28, 2008
iPhone app
Okay, continuing to eat our own dog food, I embarked upon the development of my first iPhone app, and also the first iPhone app to use .tel.
Within a couple of days I had an (ugly) app that would look through my address book, find all my friends who had a .tel, look up their .tel for a LOC (location) record, and compare that to my own location via the iPhone GPS service, and finally tell me which of my friends were closest to me.
Now about 2 weeks into it, I have what I think is a nice app (considering my lacking design skills) that does all of the above, shows an actual map with pins, and also looks up all the NAPTR records so I can contact my friends directly.
Looking back, here's the work distribution:
- 5% of the work was to get a DNS library to work on the iPhone. Thanks to the free ldns library, that was just a matter porting the makefiles over to XCode and fixing them up for the iPhone ARM processor.
- a couple of hours only to hook up the LOC records from .tel
- About 5% of the work was to write the query and display structure for the NAPTRs
- 60% of time was spent learning Objective-C (my C skills were almost nonexistent) and the iPhone framework
- 30% of the time was spent banging my head on how to display a map with pins. Unfortunately the nice native Google Maps app on the iPhone does NOT accept KML files as input, which totally sucks. When that's fixed, I'll be able to cut out a good third of the codebase that right now just hacks things to go through a specially set up website that proxies the google maps.
All in all, a very good 2 weeks spent making sure the read apis (i.e. the DNS side of things) are working easily, as expected. The only missing stuff is the private data handling, but the SO Friending system isn't live yet to be able to hook into it.
Within a couple of days I had an (ugly) app that would look through my address book, find all my friends who had a .tel, look up their .tel for a LOC (location) record, and compare that to my own location via the iPhone GPS service, and finally tell me which of my friends were closest to me.
Now about 2 weeks into it, I have what I think is a nice app (considering my lacking design skills) that does all of the above, shows an actual map with pins, and also looks up all the NAPTR records so I can contact my friends directly.
Looking back, here's the work distribution:
- 5% of the work was to get a DNS library to work on the iPhone. Thanks to the free ldns library, that was just a matter porting the makefiles over to XCode and fixing them up for the iPhone ARM processor.
- a couple of hours only to hook up the LOC records from .tel
- About 5% of the work was to write the query and display structure for the NAPTRs
- 60% of time was spent learning Objective-C (my C skills were almost nonexistent) and the iPhone framework
- 30% of the time was spent banging my head on how to display a map with pins. Unfortunately the nice native Google Maps app on the iPhone does NOT accept KML files as input, which totally sucks. When that's fixed, I'll be able to cut out a good third of the codebase that right now just hacks things to go through a specially set up website that proxies the google maps.
All in all, a very good 2 weeks spent making sure the read apis (i.e. the DNS side of things) are working easily, as expected. The only missing stuff is the private data handling, but the SO Friending system isn't live yet to be able to hook into it.
Subscribe to:
Posts (Atom)