> Microsoft's Push Notification Service (WNS) is a HTTP-based, which is awesome. Apple introduce a TCP-based approach to push notifications that basically requires you to write a dedicated sever (again, somehow, Apple didn't specify how to do) to send your push notifications through their APNS. No one rolls their own APNS server because it's too hard and there's Urban Airship.
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.
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").
I'm aware of Apple's sample code, I attended the WWDC talk on integrating Push Notifications. I'm just not aware of many Ruby developers interested in taking Apple's C example and implementing it in Ruby.
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.
Apple has the resources to scale, so "TCP is faster" isn't really an excuse
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.
> For a hobby developer or small business where time is precious, using built-in HTTP libraries is far easier and faster ... 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?
In which case the failure to communicate is mutual; In OP, I said:
... 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.
But what is the actual advantage? Its all very well saying that it's easy to implement Apple's solution, but HTTP is simpler. What makes it worth having to spend a day or two on a custom solution?
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.
Does anyone know about the future of Visual Studio? The current Express editions are pretty crippled and Pro was pretty expensive the last time I looked. Comparing e.g. a Mac Mini and a Win7+VS bundle, entering iOS/Mac development actually came cheaper.
If you join BizSpark [1], you get free MSDN subscription (i.e., Visual Studio and a load of other software). It's a pretty good deal if you're going after the MS stack.
The key takeaway is this: Personally, I'm too entrenched in the Obj-C/iOS ways to develop my own, personal Metro app. But based on what I've seen about Metro, I can see a lot of Enterprise ASP.Net corporate developers going home at night to tinker on their Metro apps, and who can argue against that?
The end of the conclusion really doesn't relate to the article. It starts with "Let's face it: Metro will be a success.", but they he talks about how he has no plans to develop for it.... which is not success in my opinion. Three days of them showing you everything (probably with free food too and access to devs) and it isn't impressive enough for you to make an app what makes you think other devs in mass numbers will develop for it?
Here's the thing: I'm a long-term mac user and a developer for iOS. The training didn't include any XAML training; any interface design was copy-and-paste because writing the XAML wasn't the point of the training. If I was a .Net developer in my day job, I would be writing a Metro app right now.
WPF, (the modern way to create .NET windows client UIs) and Silverlight/Windows Phone 7 development is done using XAML at the minute so those developers would have the best head start. Note, it was probably Visual Studio 2011 you saw, 2010 has been out for a while.
Nice Overview. It seems like Microsoft is actively trying to cope with Apple and I think they are succeeding. A lot of their concepts are well thought. Does anyone have more overviews/guides to the new concepts and technologies introduced in Windows 8?
Developing with HTML, CSS and JS makes it cooler. This way, more people could simply use what they know and start writing applications. This is no different from writing a web page, but has more capabilities too. Unfortunately, there sure are some issues ... :)
Okay he isn't at all fair to XAML. Yes it is XML, but it is also what HTML (which is very, very close to XML, remember?) should have been. A great way to define the user interface and make it easy to dynamically bind to stuff in your source code so that you can easily split code and UI and test all your code.
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.
Synchronous versions of APIs that are now async. Like the HttpRequest object only has async methods instead of both sync and async. Silverlight did this as well.
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").