I am currently writing a windows store app, where I want to offer the possibility to open a specific file directly, if there is a known app to open it. Otherwise I want to hide this option.
The common way to open a file is using the Launcher.LaunchFileAsync(IStorageFile)-Method. It opens the file directly or offers a list of possible apps to open the file. So it sometimes knows about the apps to open the file and sometimes not. But is there a way to find out whether there is such an app installed or not programmatically, so that i can decide whether to hide the open button?
This isn't supported for Windows Store apps.
The general model is to "keep the user in control" which means if there isn't an app already available for file or URI association, they have the option to find one in the Store to complete the workflow. This is also there, I believe, to encourage acquisition of new apps as well.
Put another way, association launching is demand-driven, wherein the user is invited to find apps exactly at the moment they need them, rather than separately looking for apps that somehow configure the device and then enable functionality in other apps (like enabling certain file types).
In the model you suggest, wherein an app working with files hides unassociated file types, ask yourself this: how would users ever enable a file type? That is, they could see a file on their system using the file explorer (or another apps). But in your app they don't see it listed. This in itself a point of possible confusion--I can see comments in your reviews that would say "How can I get these files to appear?" Your only answer would be "Well, you have to first install some other app that can handle that file type." Customer: "How do I find those apps?" You: "Um..." because the Store app doesn't give you a way to search by association support...maybe you can get lucky with keywords.
Or, let's say the user happens to acquire some other app from the Store, or a desktop app, which means that magically those files start to appear in your app for not clear reason. Customers are bound to ask why this happened.
In short, the model you suggest could potentially create a disconnect between what's on the file system and what shows in your app, which would be hard to reconcile. I imagine that in the course of dealing with that disconnect, you'd eventually be led to create a UI in which you show unassociated file types and then invite the user to go get an app that would support them (if you could even launch the Store with that criteria). I don't know for certain, but I would guess that a number of desktop apps did this very thing, which is why Windows chose, for Store apps, to build the UI directly into the launching API.