locked
[UWP]Figuring out what type of Windows 10 device the code is running on RRS feed

  • Question

  • Hi,

    I am developing a Windows Runtime component. I am upgrading an existing Windows 8.1 Universal component. The previous universal component would only be useful for apps developed for Phone or Tablet/Desktop that were developed for the Windows Store.

    Right now, it's not entirely clear to me what the limits or reach of a Windows Runtime component developed for Windows 10. 

    The code I am writing is meant to replace that used in Windows 8.1 Universal apps, but it seems to me that there is nothing preventing people from using it on XBox or some other device.

    I've been looking for information on how this is supposed to work. For example

    https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx#submit_a_universal_windows_app_to_the_store

    But haven't found anything concrete. When developing an app, how does the developer indicate what "platform" the app is for, and is there a way for me to check this, without having to rely on the user explicitly telling me this?

    ****************************

    As for detecting devices, I can do a check like this:

    bool isHardwareButtonsAPIPresent =
            Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.Phone.UI.Input.HardwareButtons");

    I guess I can conclude from this that I am on a phone.

    How can I tell whether I am on a desktop or a tablet or Xbox?

    In short, I want to make sure my code is used only in apps for the Windows store, designed for Phones or Tablets/Desktops. That is, no Xbox, no WPF style desktop apps, etc. How do I go about this?

    I hope my question is understandable, as I find it hard to navigate some of the concepts concisely.

    Thanks,

    Tomas


    Friday, June 19, 2015 12:45 AM

Answers

All replies

  • Welcome to the Developing Universal Windows apps forum! 

    Please read the sticky posts, especially the Guide to posting: subject line tags and Known Issues for Windows 10 SDK and Tools 

    You can limit the devices an app will deploy to in the dev center dashboard. Your app will only be available to users on devices that you've enabled. Take a look at the Build session Store: Deep Dive on Publishing Universal Windows Apps

    Friday, June 19, 2015 1:16 AM
  • Hi Rob,

    Sorry about the missing tag.

    The problem I am having is not how to publish my app. But rather how to ensure my component knows whether or not it's on a Phone. I cannot rely on the developer of the app that is using the component to tell me.

    I hope that clarifies my problem.

    Best Regards,

    Tomas

    Friday, June 19, 2015 6:22 PM
  • Why does this matter?

    If you're just concerned that the code won't be useful I'd leave that up to the developer to decide whether to call it or not.

    If you're concerned about functionality you can check for the features or contracts your code needs.

    Saturday, June 27, 2015 12:57 AM
  • When building a universal Windows app, you basically know the architecture (x86, x64, ARM) and that's all that generally matters. If you are making use of platform extensions, then you need to be concerned with which device the application is running on.

    Can you clarify what it is about the Phone that specifically your component needs to know?

    Monday, June 29, 2015 4:58 PM
  • Not sure about Rob, but I personally need to know whether my code is running on Mobile vs Desktop because the MessageDialog on Mobile doesn't support three commands like Desktop does, and so on Mobile I need to do something different.

    I'm quite sure there's no other way to do this other than using some sort of API to discover whether it's currently Mobile or Desktop...

    So it would help if you answered the question...

    Monday, September 21, 2015 8:38 PM
  • TBH I don't think there is a conclusive mechanism. You could use Phone contracts but who's to say that a tablet won't have a SIM, or a laptop or...etc. Even checking User Interaction Mode also suffers from the same issues, as does size, as does any of these 'guesses'. As already mentioned you have to mitigate problems with the lack of support. In Andrew's example people are programmatically attempting to create the 3rd button and dealing with the failure. It's all a bit hit & miss but it's because we need to consider all devices and permutations of those rather than trying to pigeon hole a few popular ones. I know it's not a specific answer and I know the pain, honestly I know it.

    http://pauliom.wordpress.com

    Monday, September 21, 2015 9:22 PM