There a couple Urban Airship cofounders that read HN, myself included - please don't hesitate to ask us any questions. This has been a really, really fun project with some very interesting technology coming out of it.
Couldn't find any Android info on your site. I can think of a ton of questions, here are some off the top of my head.
* Are you just doing polling or did you figure out some TCP keep-alive tricks to keep the connection open?
* If doing keep-alive do you try to adapt your pings to compensate for different timeouts on different carrier networks and deal with half-open connections as Google claims they do with c2dm?
* Have you measured your battery usage? What is it like?
* How many connections can your servers handle?
* What is the Android library like. Is it a separate app that you communicate with via AIDL?
* Does your app handle the notification or does it just broadcast an Intent?
Another Urban Airshipper here. Just wanted to expound upon the TCP keep-alive issue because I was the most vocal proponent of using them vs. reinventing them ourselves.
The main reason using TCP keep-alives were a non-starter was because in our testing, carriers handled them in "special" ways which usually meant they rarely or never actually reach ed the intended endpoint.
Another strike against TCP keep-alives is how the RFC defining them seems pretty ambivalent on their use. Support is optional, delivery is not guaranteed (ACK segments with no data aren't reliably transmitted), and implementations may vary.
At the end of the day they're a fine freebie for protocols like SSH to use (although they're spoofable...), but we wanted finer-grained control in order to optimize resource usage on the device, our servers, and the pipes between.
I'd love to hear about others' experiences with TCP keep-alives though.
The AirMail Control Panel manages a persistent TCP socket connection to our infrastructure using custom keepalives. Our pings aren't adapted to networks yet, as we just don't have good enough data around that - we've got great monitoring set up around this, so I'm not too concerned about that.
We haven't noticed any drop in battery usage during our (very long) testing phase. That was one of our primary concerns :)
Each instance of the layer of our infrastructure that manages the connections can handle several hundred thousand connections.
Our app handles notifications by default, but if you don't want it to handle the alerting and want to do it yourself (this was a requirement by some of our larger customers) you can by specifying only an "extra" value. We'll pass that data along and your app can parse it.
How do you see your business model changing over the next year as Android 2.2 (featuring integrated push notifications, for those who skimmed the article) becomes ubiquitous?
Our core product is a suite of features to make it easier for mobile publishers to add advanced mobile features. If it becomes clear at some point that we need to only use C2DM (Google's version), then we will - it'll still be the same API and the same product from the perspective of our customers.
Right now, it might seem like it's "Oh yay easy push notifications!" but that's not really the main story. The main story is that we're going cross platform with all of our products and we're helping people really take advantage of these great new technologies to help their mobile applications and strategy.
* Are you just doing polling or did you figure out some TCP keep-alive tricks to keep the connection open?
* If doing keep-alive do you try to adapt your pings to compensate for different timeouts on different carrier networks and deal with half-open connections as Google claims they do with c2dm?
* Have you measured your battery usage? What is it like?
* How many connections can your servers handle?
* What is the Android library like. Is it a separate app that you communicate with via AIDL?
* Does your app handle the notification or does it just broadcast an Intent?
* Are the packets encrypted?