2

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?

Christoph Meißner
  • 1,511
  • 2
  • 21
  • 40

2 Answers2

1

I don't know about native RT methods to get such a data, but windows-runtime is nonetheless still Windows. So you can access the registry. And all the needed information to determine whether the file type has the associated application is contained inside the registry.

Taking into account those two considerations you can try to use this SO thread as the basis for your enabling code.

P.S.: Native RT methods would have been much better solution but, sadly, I have very fleeting experience with Win-RT. May be someone more knowledgeable can propose better native solution.

Community
  • 1
  • 1
Eugene Podskal
  • 10,270
  • 5
  • 31
  • 53
  • 1
    The problem with accessing the registry would be, that my app wont pass the store certification process as you can read [here](http://stackoverflow.com/questions/17050394/read-the-registry-using-win-8-app). And additionally there is also the requirement that it runs on ARM. In these terms it is no solution for me. But thank you for this idea. – Christoph Meißner Jul 02 '14 at 08:56
  • Oh, yes. Sorry, I just have looked through the win-store tag. – Eugene Podskal Jul 02 '14 at 08:59
1

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.

Kraig Brockschmidt - MSFT
  • 7,004
  • 1
  • 20
  • 23
  • I understand what you want to tell me, and I already know about this model. *In general terms of usage you are right with what you are saying.* But since my app is a LOB app, it should be only sold and deployed using the windows store, and while usage it has no access to the internet. So the user will not be able to get a new app. Additionally if the user connects the device to the internet it would be illegal in terms of the company policies. Furthermore there would be security issues, when the user opens a file he shouldn't open. In these terms of usage such a feature would be really useful. – Christoph Meißner Jul 10 '14 at 06:42
  • Could you clarify the LOB nature for me? You're saying that it would be sold and deployed via the Store and not side-loaded? Because if you side-loaded, then you could use a brokered WinRT component to get to registry APIs for this purpose. – Kraig Brockschmidt - MSFT Jul 11 '14 at 00:23
  • Since the app should be deployed to the store AND via sideloading to customers devices, and we don't want to maintain different versions of it, we have decided to go the regular way to "keep the user in control". So you are right! Thanks. – Christoph Meißner Oct 10 '14 at 12:44