A Comprehensive Overview of Windows 8 Metro App Development
ashfurrow.com
ashfurrow.com
This is ostensibly a professional engineer, and this position drives me bonkers ("not HTTP, too hard")!
Apple provided protocol documentation and a very, very simple TCP+SSL protocol. Rolling your own client should be a matter of a day or two of work, at the absolute maximum.
Apple even provides sample code: http://developer.apple.com/library/mac/#documentation/Networ...
The fact that people are frightened of TCP and a simple binary protocol is a mind-boggling indictment of the ineptitude and inexperience of the engineers that have been placed in a position of responsibility.
I dealt with a server team recently that refused to consider a push-based feature because it would "cost too much to send that many pushes through Urban Airship". Implementing their own local client for the protocol never occurred to them, and our doing so for them dismissed out of hand ("too complicated").
Efficient high throughput performance. That's why Apple went with the protocol they did in the first place.
> What makes it worth having to spend a day or two on a custom solution?
It's not "custom", it's just a TCP connection.
I quoted a day or two as a maximum estimate, assuming someone totally unfamiliar with the space, and possible integration issues with their existing infrastructure. I'd be surprised if Urban Airship was fully integrated any faster, since most of the heavy lifting will be in managing state and creating an internal push API, not in speaking TCP+SSL to Apple.
[edit] Here's an implementation in about 20 lines of Python: http://blog.nuclearbunny.org/2009/05/11/connecting-to-apple-...
HTTP POST is simpler for the developer. TCP is better for Apple. Apple has the resources to scale, so "TCP is faster" isn't really an excuse, in my ostensibly professional opinion.
Really? HTTP is just sending lines of text over TCP- what's so hard about a binary format instead? In many ways it's easier. You shouldn't need an excuse to remove unnecessary layers of translation.
Sorry, but you're not going to convince me that rolling your own implementation of Apple's APNS is better than an HTTP-based APNS would have been.
Something is rotten in the state of Denmark; if this can be done in 20 lines of Python (see comment above), then why do so many ostensibly capable engineers find it so difficult?
> I'm just not aware of many Ruby developers interested in taking Apple's C example and implementing it in Ruby.
I don't find it difficult; I find it more difficult than a simple POST.
... this position drives me bonkers ("not HTTP, too hard")!
As professional engineers, it's my hope that opening up a persistent TCP socket and sending a small, stateless binary message should be easier, faster to implement, and better performing than marshaling everything into HTTP (for no other reason than HTTP is more familiar to you!).
If that's not the case, then I would strongly recommend that any engineers that are uncomfortable with this simple task should review UNIX Network Programming Vol 1, and Network Security with OpenSSL, rather than complain that an HTTP interface isn't available.
At the very least, such a study would provide a necessary understanding of what HTTP is doing. With that in place, opening up a connection to APNS should be a walk in the park.
If you work on server-side stuff on the back-end of some web app, you do not really need (for some definition of 'need'h to know either.
Also the idea was to have something your designer can make beautiful without having to trouble the programmers every time they want to make a simple change. That is why you define animations in XAML and not C#.
Don't let your hate for MS lead you to disregard this framework. It really is genuently great.
I think I was pretty fair in my treatment of XAML as something I didn't care for but admittedly had no experience in.
Driver development is moving into Visual Studio. I guess that's pretty big.
- Parashuram