[quote=“jules”]I think that WinRT actually looks like a pretty good API, but the thought of supporting yet another completely new platform… Aghh…!!
[/quote]
I just took about 20 minutes to describe in details how horrid and disgusting the Metro API actually is, and it must have been so bad my browser crashed and when I restored it it was all gone.
Long story short - Metro is a good API in the way that it works well and is complete. However, working with Metro, the “amazing new paradigms” it enforces, the extra “language extensions” - new keywords and operators, intended to make your code non-portable - it really makes me want to puke. I spent about an our watching a presentation on Metro style app development with C++, about half way through I simply couldn’t get any more and vowed to never ever touch the Metro API even with a stick.
Don’t get me wrong, I like the visual aspects of Metro, the minimalism, the USER experience it provides. But the DEVELOPER experience is a completely different picture. The new keywords, the new operations, the new partial classes - who would want his classes spread across a dozen of different source files, to spend more time tracking what is where than actually developing? And Metro’s operations - don’t even get me started. The concept is that for every operation, before you can execute it, you have to tell it what happens next. So in a regular C++ API you’d do something like:
File file = FileOpenDialog();
if (file) someObject->name= file.getName;
And that’s it!!!
With Metro it is a little more “elegant”
FileOpenPicker openPicker = ref new FileOpenPicker();
auto pickOperation = openPicker->PickSingleFileAsync();
pickerOperaiton->Competed = ref new AsyncOperationCompletedHandler<StorageFIle^>(
[someObject](IAsyncOperation<StorageFIle^)^ operation)
{
StorageFile^ file = operation->GetResult();
if (file) someObject->name = file->FileName;
}
)
This horror done in the name of Asynchronicity, even thou there are much less painful ways to keep an app from blocking the UI thread, like… umm… simply having a dedicated UI thread… But it gets even better, if you have a number of operations in a row it gets really nice, you cannot start operation1 before you define its Completed handler, so if the Completed handler is operation2, you cannot start operation2 and subsequently operation1 before you define the Completed handler for operation2. And it gets EVEN BETTER, you have to start operation2 inside the handler of operation1, so you must nest the handler for operation2 inside the handler of operation1. And if you have 10 operations in a row, you pretty much end up with a wall of code that goes back in time before the age of procedural programming in some odd, backwards cascading fashion. Or alternatively, you can use regular functions in the place of the lambdas, but that only makes the code less readable, and you still have to nest the handler function pointer within a handler function, according to the order of the operations.
Oh, and last but not least, I think I should mention the InsanelyLongOperationStatusHandlerNames that can put to shame even the most old-school hardcore C API in existence.
I honestly cannot imagine anyone willingly putting himself through this hell, it either has to be demanded by an employer or you have to be a blind fanatical MS fanboy devotee to do that to yourself.
As for me, a few dozen lines of code and the “Metro” style can perfectly be implemented in a good, cross platform framework like JUCE or Qt that will still offer the nice USER experience, with the added benefit of being portable, while saving me the horrible DEVELOPER experience that the Metro API is designed to conform to (no, it is not optional, MS knows if it is optional on one will use it). And if that closes the doors to the MS app store for my app, well that is going to be an obstacle only for people with less than 2 working brain cells.
