

A Comprehensive Overview of Windows 8 Metro App Development - AshFurrow
http://ashfurrow.com/2011/12/overview-of-metro-apps/

======
nupark2
> _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.

Apple even provides sample code:
[http://developer.apple.com/library/mac/#documentation/Networ...](http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingWIthAPS/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW1)

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").

~~~
AshFurrow
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.

~~~
Rusky
_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.

~~~
AshFurrow
For a hobby developer or small business where time is precious, using built-in
HTTP libraries is far easier and faster than implementing this:
[http://developer.apple.com/library/mac/documentation/Network...](http://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Art/aps_provider_binary.jpg)

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.

~~~
nupark2
> _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?

~~~
AshFurrow
Sorry, you may have just not heard me before:

> 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.

~~~
nupark2
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.

------
tomjen3
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.

~~~
AshFurrow
> 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.

~~~
tomjen3
The trouble is that when you have no experience with it, it tends to be
dismissed because it is something you are not familiar with.

------
mhd
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.

~~~
nhebb
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.

[1] <http://www.microsoft.com/bizspark/>

------
AshFurrow
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?

~~~
icefox
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?

~~~
AshFurrow
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.

~~~
MatthewPhillips
The C#/Xaml stuff is for WPF and Silverlight developers. HTML5/JS is the
obvious choice for everyone else.

------
nchuhoai
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?

~~~
AshFurrow
This one is linked to by a commenter at the end of my article:
[http://blog.nparashuram.com/2011/10/developing-apps-for-
wind...](http://blog.nparashuram.com/2011/10/developing-apps-for-
windows-8-my.html)

~~~
axemclion
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 ... :)

\- Parashuram

------
Hominem
Drops APIs from .Net ? What is dropped?

~~~
justncase80
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.

