Some of you read that title and thought: “Of course it crashes on desktop! You can’t send text messages on desktop!”. However, as you’ll notice here, the Windows.ApplicationModel.Chat.ChatMessageManager is a universal API. That means a universal app can use this API without having to add any mobile specific extensions. This is great, because it allows you to build a single app that can light up text message features on Windows 10 versions where sending text messages is supported while still making all the other features available elsewhere.
Problem is, as @yortw pointed out in this tweet:
— yortw (@yortw) July 23, 2015
the ChatMessageManager.ShowComposeSmsMessageAsync API crashes the app on desktop. Even worse, it isn’t the kind of crash that can be handled by an app. Anyway, having to swallow an exception in order to find out whether sending texts is available would be a pretty crappy way to handle this. What if I don’t want to draw the Send Text Message button unless text messaging is available. Well, worry not, for ChatMessageManager.GetTransportsAsync is riding to the rescue!
The GetTransportsAsync API simply returns a list of chat messaging transports available on a device. What this means that at the moment this API will return an empty set on desktop and a set of 1 or more transports on mobile. So, it should be straightforward to write code to check if a transport is available before calling ShowComposeSmsMessageAsync (or drawing the button). That’s exactly what the sample at https://github.com/arunjeetsingh/SampleCode/tree/master/ComposeTestMessage does. Note that your app will have to have the “chat” capability to use the ChatMessageManager.GetTransportsAsync API. The sample app does this by declaring the capability in it’s package.appxmanifest. Thanks to Maurizio Manca for pointing that out in the comments.
As always, feel free to reuse the code in there in your app and send in a pull request if you find a bug.