Develop Reference

RequestAccessKindAsync from Desktop Bridge

I have Win32 desktop bridge application that uses background task to receive push notifications from WNS. I use UWP background task APIs over C++-WinRT
I'd like to be able to receive push notifications even when OS is in sleep so that it wakes up and the app handles push notification. By default OS does not wake up. It did only after manually changing settings value in System->Battery->See which apps are affecting your battery life->Click my app ->Uncheck Let Windows decide option (by default it is always checked) and check Allow the app to run background taks. Now I'd like to do this is manual work on code for better user experience.
RequestAccessKindAsync API allows to let user to change above setting value by showing popup notification to the user and I could do it without any problem in UWP C# sample app. But same code does not show pop notification from my desktop bridge over C++-WinRT. It simply returns false value for below code
auto result = co_await BackgroundExecutionManager::RequestAccessKindAsync(BackgroundAccessRequestKind::AlwaysAllowed,
L"App needs to use background to catch push notifications while device is in sleep");
Can anyone confirm that RequestAccessKindAsync API works from desktop bridge? If not then how I can make sure OS and the app will always be able to wake up from sleep when it receives push notification?
UPD: Raised request to enable this API from desktop brige here

This is a missing feature. When we designed this API a couple of releases ago we didn't consider desktop bridge apps would be calling it - but clearly there is a use case for supporting this. I have notified the team about this gap, but I'd also encourage you to log a feature request here: https://wpdev.uservoice.com/
Two possible workarounds:
(1) you could add a dummy/empty UWP foreground app to your desktop bridge app. You can then launch this on startup and request the background access from there. This will be a bit ugly, but you could make it look like a splash screen :-)
(2) you can instruct the user to go into the Settings app to set your app to always allowed. You can help them do that with a deep link to the battery save settings, but they will still need to manually flip the switch.

Azure mobile app offline sync causing a MobileServicePushFailedException -> CancelledByAuthenticationError

As part of a UWP app we're developing at work, we have an Azure mobile app (C#, .NET backend) connected to the client which is supposed to sync up with offline SQLite storage and place CRUD operation requests into a queue so they can be processed by a worker role.
Trouble is, for some reason when we attempt to call PushAsync/PullAsync on the sync context and messages table respectively, it throws a MobileServicePushFailedException. When monitoring this in locals, the PushResult status is "CancelledByAuthenticationError" but this happens even after successfully logging in via one of the providers, and we haven't yet set the table to require authentication anyway so this shouldn't be causing any problems.
Interestingly enough, when this was a mobile SERVICE as opposed to a mobile app running in a Windows 8.1 project instead of a UWP, it worked fine, because the MobileServiceClient constructor in that version of the Nuget package takes the application key as one of its arguments. Unfortunately, we're developing a UWP, so it needed to be migrated and thus we can't use the same constructor any more.
Has anyone come across this before, or does anyone have any idea where we might be able to find further information on this? We haven't been able to find any other concrete references online besides another SO post that was asking about a similar but different issue, and a few other posts that either have no answers or are working with different languages/backends.

In-App purchases for Desktop applications

I need to accept in-app purchases from within my desktop application and was wondering if the new Windows 8 API allows thein-app purchasing to be used with Desktop apps aswell as Modern UI apps? (http://msdn.microsoft.com/en-us/library/windows/apps/hh465433.aspx). I have read the docs and it doesn't say that you can't use it in Desktop apps, but there is also no documentation for it for desktop apps and all I have seen online are questions about whether it can be used in desktop apps but no real definitive answers.
This isn't purely a purchasing option. It's more about how I would need to implement this for a Desktop application if it can even be done to begin with.
Aside from that: Are there any in-app purchasing frameworks/SDK's that you could recommend if the one from Microsoft is not an option?

Update:
An article here will outline how you can submit a desktop application to the store. Unfortunately how this works is when the user downloads a Desktop Application from the store, it will load a Metro style portion and then navigate them away from the store to download. The Store will handle said transaction and compensate you accordingly based on the acquisition.
As part of the submission process, you must supply a purchase page URL
for your app. This URL is a link that sends the user directly to the
page where a customer can acquire your app with the fewest clicks
possible. This is a great feature for customers; if you provide them
with a clean and easy way to acquire your app, you’re already making a
great impression by giving them a simple and clear acquisition
experience.
When you submit a desktop app, you must supply a purchase URL for
32-bit and 64-bit systems. This URL can be the same for both.
During the app submission process, we request that you supply a URL
for users who need the x86 version of an app and one for those who
need the x64 version. For Release Preview, both URL fields are
required, and should correspond to the version of Windows that a user
is running. If the acquisition page is the same for both, we recommend
that you use the same URL in both fields. The Windows Store detects
whether a user is running the x86 or x64 version of Windows, and users
can only see apps that correspond to this version.
Essentially Microsoft will only be handling the commerce of your application; all other aspects will be handled outside of the store. The only aspect that Microsoft will directly handle is the initial commerce, with In-App purchases you might be able to have the commerce portion handled, but you'll still need to provide the information to be handled outside of the store.
Also, the current outline for a said feature in desktop applications really hasn't been covered any the documentation, perhaps as 8.1 approaches more details will be announced.

Xamarin Android App update

I've been developing android apps on Xamarin for 3months now, but I am facing a problem to update the application when a new release is available.
The application is not published to any app store(as we use it internally), I know Play store can do automatic updating, but I need to look for an update on our server, I would prefer if all this can be done silently(in the background).
here is my current code, this copy's the app to the device:
intent.SetData(Android.Net.Uri.Parse(#"http://xxxxx/downloads/app.test-signed.apk"));
StartActivity(intent);
this installs the app onto the device:
intent.SetDataAndType(Android.Net.Uri.FromFile(new Java.IO.File(Android.OS.Environment.ExternalStorageDirectory.Path +
"/app.test-signed.apk")), "application/vnd.android.package-archive");
StartActivity(intent);
but this way it asks to install (and I don't think this is the correct way), and doesn't start my app automatically after it was installed. And I am not sure how to wait until the app finished downloading before it tries to install.

I had a similar issue with an app which only gets used internally in my company. I didn't want the app going to the big wide world as the general public wouldn't have any use for it.
So, what we've done is publish the final product as 'Alpha release' in Google Play. You set up a Google Group with a set of e-mail addresses of devices that can access it, and once the app has been downloaded it will update just like any other app from Google Play.
There's an option to 'Promote' it to Beta or Production, but given that it never gets promoted it is never searchable on Google Play.

As Corey Ogburn mentionned, the silent install won't be possible without root.
Altough an answer was already posted to your question on Xamarin's forum.
On another note, following Dave's idea, you could set a Private Channel on Google Play. As you already know, Google Play offers easy automatic update, and with a Private Channel, you will be able to give special authorization on who has access to your app.
Read more on Private Channel here.

Using TAPI speech in a Windows Service

I have purchased a license of AddTapi.NET to simplify my development using TAPI in a product that runs as a Windows service. I was able to use the TAPI in a Windows GUI and console application and ported the code into my Windows service. At that point, I noted that the code which uses the speech API such as TapiCall.Speak or TapiCall.Play (wavefile) was not generating sound on the phone line and was remaining silent.
There are a couple of previous questions that may relate to my issue.
Question: Playing Voice over a modem from a Windows service indicated a problem using speech that was resolved by spawning a GUI thread in the Windows service. I attempted to do this but was unsuccessful in getting the speech to be heard on the phone.
Question: Access violation with Tapi in Windows service seems to indicate an initial problem with TAPI in a service yet was resolved by using the AddTapi product. The ticket does not explicitly mention the use of the speech API though (SAPI)
I am programming in C# using Visual Studio 2010 and .NET 4.0. I am trying to get this to work on Windows 7. I received an e-mail from AddTapi that indicated that Microsoft changed the security to disallow use of the voice subsystem from services in Win 2008 Server, Windows Vista, and Windows 7. The above articles seem to indicate some success with AddTapi although it may not be on Windows 7.
Given that the main system that I am working with is a Windows service (and child processes), what would seem to be the best approach to getting the speech to work. If I put the SAPI code in a console application, I would like this to be managed without requiring a user to be actively logged onto the computer. There is nothing graphical about my TAPI code. Should I take an approach similar to Article: Launching an interactive process and spawn an interactive process? Have there been any success stories using TAPI speech in a Windows service?

We resolved this problem in AddTapi.NET 5.0. Version 5.0 can use Speech API (TapiCall.Speak and TapiCall.Play) in Windows service applications. There is no need to use a separate process and the service can run under default Local Service account.
For everyone who doesn't use AddTapi.NET, the key is to use SAPI5 SpVoice object speaking to a custom stream. You cannot instantiate SpAudio or SpMMAudioOut objects in Windows service, so you will need to implement your own stream class and set SpVoice's output to that stream.

I had the same requirements as your project (TAPI in a Windows Service using AddTapi.NET). I also received the same response. I tried some of the other posts out there recommending that I run the application in a separate thread so I tool my entire solution and converted it to a WPF Application with a simple page that would never appear but had all the AddTapi configuration happening in the constructor.
NO SUCCESS.
The application would run fine when run from the WPF application but when the WPF page was instantiated in the STAThread enabled thread Play and Speak still would not work. I have been looking all over for an answer on this but there isn't anything but others stating that there really is no solution (no real solution).
Running my application through a seperate process simply won't cut it and since running in a seperate thread won't work either I'm going to have to consider running this application as a regular windows app (will require logon).
Wish I had a solution, sorry.