I was reading Paul’s post on iPhone SDK bug reporting and sort of pondering that list.
I’m not sure I care specifically about a bug for being able to run a background application so much as I want to be able to get application events when my application isn’t active. At least for my needs – I could come up with some specific reasons for wanting a background app on the iPhone, but moving that processing/event waiting stuff off the Phone seems like a pretty reasonable way to go to me. More expensive surely – you’ve got to have something running somewhere – it’s easy to put that on an iPhone (at least technically), but you’re using potentially using power and dealing with memory pressure when you don’t need to on the device.
But it was the bug entitled “Allow iPhone applications to access the host computer when docking” that really caught my eye (Bug ID #5788803). The iPhone and iPod touch has bonjour, and straight ole TCP/IP network access available to it. I thought back to various conversations about hybrid applications, and then I recalled that Gus even stuffed a whole web server into VoodooPad Pro. I don’t know if he just linked in something like lighttpd or if he wrote his own http request handling classes (I’d easily believe either – I know he’s basically done both in the past for different projects). Take that concept a little further, and I could see how you might have a paired application that enabled you to sync data down to the Mac over Bonjour and maybe http. Okay – that’s a hell of a workaround because Apple isn’t enabling a path through Sync Services, which would make a lot more sense (and be a lot less coding) – but the idea is intriguing. Since VoodooPad Pro has bonjour enabled already, it wouldn’t surprise me if Gus fiddled together a “read only” VoodooPad client. That is a little weird since you can already just point Safari at VoodooPad Pro, so maybe that’s a dumb idea after all.
I can imagine a whole class of what Apple’s iPhone HIG is labeling “utility applications” that would take advantage of periodic data updates from syncing with a desktop client. Data you couldn’t or didn’t want to share across the web that you wanted to have in a quick read-only format.
I’ve even been debating that process myself – I have some relatively static data that I’m planning on using for a little application. For my first iteration, it won’t need to change and re-releasing the application with updated data looks to be the easiest path when I need to do that. On the other hand, to make it more generic (assuming I follow through with a “more generic” path), I think it would be really handy to be able to pull an update, or allow a user to provide custom data. It’s that custom data from the user track that would really benefit from a Sync Services link of some form.
Holy cow – I just noticed that Jon Wight of ToxicSoftware has included TouchHTTPD, which looks to be right along these lines of something to be used to help transfer data into and out of the iPhone.
3 thoughts on “Syncing data from your iPhone app to a desktop… and other “iPhone SDK bugs””
Hey… have you been watching me code? How did you get in my house?! (I wrote my own http server by the way)
Jon Wight of http://toxicsoftware.com/ has also been updating his webserver to do some crazy objc stuff as well.
We *talked* about this one night over beers after an XCoder meeting. I didn’t break into your house… If I had, you wouldn’t have any leftover pizza.
Neat – hadn’t known Jon’s did the same stuff. Guess its not as crazy as I thought. I still entered a “pile on” bug (Bug # 5796356 to Paul’s original though. The more I thought about it, the more it was clear that it was a crappy user experience to have to load up multiple programs to sync with your iPhone or iPod Touch.
My ears were burning!
The code gus might have been referring to is getting a little long in the tooth. So I took the time the other day to rewrite it completely using all new APIs. Didn’t quite get a chance to finish it before I got whisked away to the west coast. But I will be working on it some more and blogging.
The new code is on the new TouchCode google code site: http://code.google.com/p/touchcode/
Comments are closed.