I am developing an Universal app capable of running on both Windows Phone and Windows. But initially I want it to be available to phones only because I have not made the Windows part of it. So how can I limit the target devices of this Universal app without creating a new app and without removing the Windows Code from it. I want it to be available to phones only for deployment. Can anybody give a solution?
Windows and Windows Phone apps are submitted separately to the Store. The process for submitting Windows apps is outlined here and for Phone here. So you can simply submit one without the other.
You can also stop building the Windows portion of the app using the Configuration Manager if you want to (to save time or avoid compilation errors you don't want to fix yet).
Related
I'm actually creating an UWP 8.1 app for one of my client.And I've got some little issue with it.At some point of my app I've to get all the names of installed app in the device and view it as a list.When the user will click on any of them, I've to launch that certain app.
I've already tried to add restricted capabilities in the app manifest but it shows a blue line when I add,
Morever I can get access to the AppData/Packages by using folderpicker somehow but don't know what to do.
The app is for WinRT surface 3 and it isn't going to store or anything it has only one user. So if anyone know any sort of solution please let me know.
The PackageManager class has the methods to enumerate all installed apps.
However, in 8.1 the PackageManager can only be used in desktop apps (e.g. WPF, Winforms, Win32). It cannot be used from a Store app on that version of the operating system.
On Windows 10 you can use the class from both Store/UWP apps as well as classic desktop apps.
I have an universal windows app (Windows Store 8.1 & Windows Phone 8.1, NOT UWP!), published it (both Win and WP packages) as hidden (Hide this app in the Store. Customers with a direct link to the app’s listing can still download it, except on Windows 8 and Windows 8.1) but it looks like that people can access app from Windows Phone 8.1, Windows 10, but not from Windows 8.1.
Indeed, on Windows Phone 8.1 (even on simulator) I can debug "real" in-app purchases using CurrentApp instead of CurrentAppSimulator, and even can download app using direct link.
But when I try to use in-app in Windows Store version it doesn't work: Windows.ApplicationModel.Store.CurrentApp.LoadListingInformationAsync() throws Exception HRESULT: 0x801900CC ("no content").
I've read this topic but in my case all the packages are published, so Store knows about my in-app products!
In case with WP8.1 I had to add:
<mp:PhoneIdentity PhoneProductId="my old-style app id" PhonePublisherId="my publisher id" />
into the app manifest.
Maybe there is something similar for Win Store 8.1 apps? Is there a way to test real in-apps on Windows 8.1 before making app available for all?
when I try to use in-app in Windows Store version it doesn't work: Windows.ApplicationModel.Store.CurrentApp.LoadListingInformationAsync() throws Exception HRESULT: 0x801900CC ("no content").
About your first problem, we can see that the Store server is not aware of your app having the In-app purchase that you purchase. As your description, you confirm that your app has been submitted in the store and got it approved, but can you check the In-app-purchases products in your app are approved? you can get these info from the dashboard---Add-ons.
Is there a way to test real in-apps on Windows 8.1 before making app available for all?
According to the Beta testing and targeted distribution, there's no specific option for Windows 8.1 beta testing currently. But you can also download your app on Windows 10 device to test if your IAP product without problem. If it can work well, then you can make it available to all users. This seems to the only work-around.
Please also note that it will take 1-2 days after that for IAP feature from real products to start serving.
I modified my Windows Phone 8.1 application (universal app with just the Windows Phone project live yet) to have a VoiceCommandDefinition (VCD) file in place and this works fine to start my app in foreground mode and handle parameters.
But I want to let my app quickly answer some app specific questions like it is described in this blog for Windows 10. I have tried to apply this blog but the app manifest modification fails. It does not know the:
uap:AppService
When I looked it up, it seems to be available for Windows 10 only. So I searched up the internet mainly MSDN and stack overflow, but I could only find examples that run the app in foreground.
Does anyone know an example how to provide answers to the Cortana content page with a background service?
Only App service can meet your requirements.
But App service is new in Windows 10, so you cannot use uap:appservice in Windows Phone 8.1 application. You can see App to app communication video from 26th minutes which introduce the app service.
So you can use universe windows app to develop. Sample is Cortana voice command sample as you see in that blog.
In one of our projects on Win-RT targeting Windows 8.1 , we had used EasClientDeviceInformation() to get the client device information. But, now we want our app to be working on windows 10. So is there anything else that we could be using?
You need not change your code at all. EasClientDeviceInformation API is available on Windows 10 and you can use it in universal windows app and it would work on both Desktop and Phone. MSDN Page for this API lists the detail.
Quick question ... Microsoft removed support for Process class in Metro Apps. How to get Window title of known Process ID?
I literally Google'd the whole internet for answer without success :/
Microsoft has not supported the Process class in Windows Store apps.
Windows Store Apps are not supposed to have that kind of access, unlike desktop apps. Besides, if you have Windows RT and you're running a Metro App that uses the Process class, you're not going to be able to because Windows RT does not run desktop apps.
Sorry to disappoint you, but if you need to do that, create a desktop app (not able to run on Windows RT).
P.S. They're called Windows Store apps now (not Metro) due to a lawsuit.