Fortunately enough, Windows::Globalization::DateTimeFormatting includes the DateTimeFormatter class that can be used to get readable date/time display strings from a DateTime structure. Here’s some sample code that shows how you can use this.

auto dateFormatter = DateTimeFormatter::LongDate;
auto timeFormatter = DateTimeFormatter::LongTime;

for(auto item : feed->Items)
{   
  listBox->Items->Append(
    dateFormatter->Format(item->PublishedDate) + " " +
    timeFormatter->Format(item->PublishedDate) + " - " +  
    item->Title->Text);         
}

Obviously, it’d have been heaps better if the compiler gave us easier to use projections, but it’s still not that bad. A common practice is to convert this to standard C++ or ATL/Win32 date structures and formats if you want to do additional date/time processing on the object.

Putting the BindableAttribute on a C++ ref class makes the class available for databinding. Unfortunately, if you add a very simple ref class and then mark it as [Bindable], you’ll get some weird compiler error messages. Example – consider this simple bindable class defined in Restaurant.h.

namespace ViewModels
{
  [Windows::UI::Xaml::Data::Bindable] 
  public ref class Restaurant sealed
  {
  public:
  };
}

Assume there’s a Restaurant.cpp that includes this file. You’ll get these compiler errors (or something close to it).

Error 1 error C3083: 'ViewModels': the symbol to the left 
    of a '::' must be a type ...\xamltypeinfo.g.cpp 
Error 2 error C2039: 'Restaurant' : is not a member 
    of 'ViewModels' ...\xamltypeinfo.g.cpp 
Error 3 error C2061: syntax error : identifier 
    'Restaurant' ...\xamltypeinfo.g.cpp

The not so obvious fix for these errors is to include Restaurant.h in any of your xxx.xaml.h files (right after the include to the xxx.g.h file would be a good place). This seems to be due to how the XAML compiler ties into the whole build process. Not a major hassle, but more something to be aware of.

• Alternatives to Windows APIs in Metro style apps

Be aware that you will most likely not get a one-to-one mapping for various API functions and structures. So you should fully expect to re-design and workaround that and use alternate approaches to achieving the same functionality/usability.

void Show(int&&)
{
	cout << "int&& called" << endl;
}

void Show(int&)
{
	cout << "int& called" << endl;
}

template<typename T> void Foo(T&& x)
{
	cout << "straight: ";
	Show(x);

	cout << "move: ";
	Show(move(x));
	
	cout << "forward: ";
	Show(forward<T>(x));
	
	cout << endl;
}

int _tmain(void)
{
	Foo(10);

	int x=10;
	Foo(x);
	return 0;
}

The output of the above code is:

straight: int& called
move: int&& called
forward: int&& called

straight: int& called
move: int&& called
forward: int& called

When Foo is called with an rvalue, T&& is deduced as int&&. But the variable itself is an lvalue within that function. So the straight call calls the Show(int&) overload – no surprises there. Both the move-call and the forward-call calls Show(int&&) as expected. In the 2nd case, Foo is called with an lvalue, and again the straight call will go to Show(int&) while the move-call will go to Show(int&&). Now here’s where forward comes in handy, it will go to Show(int&) because that’s what T has been deduced to in this instance of the function call (perfect forwarding). If you are wondering why, the collapsing rule for T&& collapses it to T& during template argument type deduction.

With desktop apps, the metro app cannot take for granted that it’s running or available, and thus it makes sense to not allow that. But you may be wondering why IPC is blocked between two metro apps. Well, metro apps can be in a suspended state at any given time, and there’s no sure way to predict its state. So even if there are two apps running at the same time, neither app can be sure if the other app’s ready to accept data or a command. This is quite likely why they decided to design it so that metro apps cannot talk to each other.

So, what’s the workaround? Again, the only reliable way an app can talk to another app on the same machine is to use a a 3rd service that’s running on the network, or to use a cliched phrase, use the cloud.

Note: you can connect to localhost for debugging, but your app will not be approved for publishing to the store.

class Native { };

public ref class MyRef sealed
{
private:
        voidFoo1(Native n) { } // <--This is fine

public:
        voidFoo2(Native n) { } // <--This won't compile
};

You’ll get a compiler error there:

error C3986: 'Foo2': signature of member contains native type 'Native'

Note that this is by design. (If you think about it, it’s perfectly logical, since WinRT components can be consumed by any WinRT caller including non-C++ ones)

• The big thing with WRL is that you can use ISO C++. You don’t have to learn a new syntactic extension that you cannot use outside the Microsoft-world. Most C++ devs would feel comfortable using WRL, specially if they’ve used ATL before. That said portability is a myth, since WRL code is as tied into Windows as would be C++/CX code.
• Do you want to totally avoid exceptions (perhaps to remain in sync with existing code that doesn’t use exceptions)? If so, you have to use WRL since C++/CX uses exceptions.
• Performance wise, will you see any difference? As stated above, C++/CX uses exceptions while WRL uses HRESULTs. So the performance implications of using exceptions will obviously come into play. There is also the non-trivial conversion between HRESULTs and RT exceptions. Outide of that, I don’t think there’s going to be any noticable difference in performance
• Not sure to what extent you can do this, but since WRL exposes the underlying COM architecture, you can fine-tune your code to some degree (since WinRT is built on top of COM). I haven’t read or heard about any scenarios where this has actually made a difference.
• The psycological aspect. While this is the least technical of the reasons, it might be the biggest factor here. Many C++ devs would simply hate anything that they see as foreign syntax. And C++/CX is certainly not ISO C++. Its close similarity with C++/CLI (which many C++ devs found disgusting) doesn’t help either. If your C++ dev team comprises mainly of a bunch of these guys, I reckon it’d be wise to just use WRL.

And personally speaking, I’d probably recommend that you learn to use both C++/CX and WRL. That way you can use what’s best for your specific scenario. And finally, you can mix WRL and C++/CX in the same project.