I have been using Windows APIs for NFC communication. I am successful in getting and sending NFC messages from Windows PC, using a local console app. However, I want the communication to be done using a Windows service. Here is what I have:
A C# plugin (DLL), which makes the API calls.
C++/CLI Wrapper that allows unmanaged C++ code, to use the above plugin.
A C++ plugin, that the service will load (this is a requirement, it has to be a plugin)
If I load the C++ plugin into a local console app, and run, it can catch all NFC events (NFC device arrives in proximity, departs from proximity, can read and write to it). But, when I use the same plugin with a service, it is not able to catch those events. I can clearly hear the ping sound that comes when an NFC device comes close to Windows PC, however, none of the event handlers are called (For device arrival, device departure, read or write).
I also tried impersonation thinking that perhaps the context of who calls the method might result in blocking of the events. I could impersonate local user on the service, but the results were the same, no events could be identified.
Is there a reason why I cannot see any NFC events from a service, where as a local console app can get all of them? Again, I am able to hear the ping sound signifying that NFC device is close to Windows PC, but there is no handler getting called for it, suggesting there is blockage of something. Any ideas of what is going on?
Appreciate your time guys!
Related
My team has been struggling with a pretty strange issue while using the WinRT/C++ APIs for Windows to connect to both a MIDI port and receive BLE notifications through a proprietary service on the same device.
The WinRT/C++ library itself is really nice and provides easy and modern C++ interfaces to access the managed Windows runtime classes.
I've pushed a sample repo to Github where we've replicated the issue with a minimal example.
The repo's readme goes over the problem in detail, but I'll post the relevant bits here for completeness.
The sample program is performing roughly these steps:
Check for available MIDI devices using a DeviceWatcher.
Check for available Bluetooth LE devices using another instance of a DeviceWatcher.
Match discovered MIDI and BluetoothLE devices on their ContainerId property (see DeviceInfo for details). This is the method JUCE employs in the native WinRT code for their library, and works as expected.
Open the MIDI port and attach a handler to the MessageReceived event (see the code).
This causes the system to create a connection to the Bluetooth LE device. The program detects this state change, creates a BluetoothLEDevice, we perform GATT service discovery and attach a handler to the ValueChanged event for the characteristic we're interested in notifications from (see the code).
The program then counts how many MIDI messages are received on each port and how many BLE notifications are received from the corresponding device.
The behaviour we notice is that data from the most recently connected device streams just fine, while the throughput for the others is severly limited. We are at quite a standstill regarding this issue, and are not sure where the problem may lie.
We are at quite a standstill here. I'd be more willing to accept it if all the devices would exhibit this behaviour, but that's not the case. Is there any reason that creating both a MidiInPort and an BluetoothLEDevice from the same peripheral should cause this issue?
A BLE radio can only receive or send at any given time. And therefore only communicate with one device at any given time. It uses a scheduler to allocate radio time for every device when you have many devices. That way a second connection can "interrupt" a connection event from another device, decreasing the throughput for that device. See https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/multilink_scheduling/central_connection_timing.html
I am building an Android App to control power outlets with a smartphone. The app features an Android Wear app so people can control their lights right from their wrist.
When the user wants to control a light I send a String action via the MessageApi from the smartwatch to the smartphone, which receives this action in a WearableListenerService and sends the appropriate network signal to the power outlet/gateway in an AsyncTask.
This works fine as long as the phone has not been in idle for too long. However if the phone is still on the table for too long and doze kicks in Wear actions do execute very slow or sometimes not at all. I guess this is in part intended behavior however it is not practical in my case as the user cant wait that long for his lights to turn on if he wants to enter a dark room.
I am aware that doze completely cuts the networking for everything except FCM/GCM if you are not on the doze whitelist. But even when my app is on this whitelist and the networking part works actions can take a long time to execute on the phone.
So my specific question is:
Whats the recommended way to handle this scenario, where an action from a wearable device needs to be done via network on the connected smartphone which is in doze mode?
Is there a way to exit doze for a quick amount of time to execute calculations triggered by the wearable companion app faster?
I know the AlarmManager has a new method that works even in doze mode, but will this fix the processing delay too? Firing an alarm after receiving a MessageEvent from MessagApi seems like a workaround to me.
Or maybe is an AsyncTask just the wrong way to handle background networking and thats where the delay comes from?
Actually, there are a few options that you can do to handle Doze's effects as given in Adapting your app to Doze. You may want to consider the following options:
If your app requires a persistent connection to the network to receive messages, you should use Google Cloud Messaging (GCM) if possible.
GCM is optimized to work with Doze and App Standby idle modes by means of high-priority GCM messages. GCM high-priority messages let you reliably wake your app to access the network, even if the user’s device is in Doze or the app is in App Standby mode.
To help with scheduling alarms, Android 6.0 (API level 23) introduces two new AlarmManager methods: setAndAllowWhileIdle() and setExactAndAllowWhileIdle(). With these methods, you can set alarms that will fire even if the device is in Doze.
However, please note that with these methods, neither setAndAllowWhileIdle() nor setExactAndAllowWhileIdle() can fire alarms more than once per 9 minutes, per app.
Please try going through Optimizing for Doze and App Standby for a more detailed information or discussion.
In addition to these given documentations, the same options in handling Doze were also given and discussed in Diving into Doze Mode for Developers which might also help.
The company I work for is considering to build an application for Windows Phone. Well, actually we plan to build an universal app ( for phone, tablet and PC ).
There are some requirements ( especially for Phone version ), so I would like to clarify few things before allocating resources & hiring people.
I would be very grateful, if some Windows expert goes through these requirements and confirm that this is possible.
So:
1) We need to launch a call within the application.
I've found this solution:
Make a phone call in Windows Phone 8.1
The question: is it possible to launch a call without a prompt? As far as I understand this solution prompts a question to user, if he wants to call or not. Our flow and design is made in a way, that this prompt will be redundant ( of course, we launch a call on user's behalf ).
2) We need to maintain internet persistent connection and be able to react if some message comes using this persistent connection. I've checked PubNub and it seems that everything is OK and PubNub provides SDK for Windows Phone.
Important: this is not VoIP application, so it might get complicated if Microsoft has some policies that persistent connection might be used only by VoIP application ( Apple has these policies ).
Important thing: Persistent connection should stay connected, if application goes background, so there should be no "cut off".
3) We should be able to present some notification ( with sound alarm ) to user and launch the app if he "accepts" the notification. Basically, we should be able to send some message to the device using PubNub or even Microsoft WNS service for pushes and present the notification on the device. Like "Local Notification" in iOS.
Any help would be highly appreciated.
Thank you in advance.
Best Regards,
Maksim
1)Unfortunately on Windows Phone you can't start a call without the system prompt.. It's for security..
2)I can't help you here..
3)Of course you can send notification to a device. This notifications are called toast notification.
A notification's custom sound can't be setted within the app, you have to load the sound on a server or let the user decide (he can change the sound in the system settings). If you don't need a custom sound.. no problem, it'll be used the default ones and you don't have to worry about anything.
I use Parse.com to send push notifications or you can even run a sheduled task every 30 mins on the user's phone(maybe is not appropriate for your application).
In the notification you can also set the property navigationUri to open the app on a defined page.
Unfortunately you can't still customize the notification aspect(you'll be able to do it in Windows 10) and you can see the default aspect here: http://www.codeproject.com/KB/windows-phone-7/ToastNotification/PushNotification.png
I am trying to collect GPS location every 5 seconds from a smart phone by using socket.io.
I notice that when users pick up a phone call, socket.io will stop emitting messages. When users switching tabs in the browser, socket.io will stop emitting messages too.
Does anyone know how to solve this problem?
Thanks very much!
Your best bet would be to package the website in a native app. Use a service such as http://build.phonegap.com or Intel XDK. There are configuration options to keep your app alive in the background. As for it disconnecting during phone calls, this is a carrier limitation. If the user was connected to WIFI, most phones will that for data while simultaneously on a call.
Some networks (such as Verizon) do not have the capability to do voice and data at the same time. Thus, when a call is made, data is suspended until the call is finished. AT&T does not have this limitation.
The operation of background tabs will vary by mobile browser and is likely done for battery conservation reasons. It is unlikely there is a work-around to keep the background tab running (because that would defeat the whole battery management purpose).
I'm writing an application for Windows Mobile 7 which required information about "When a voice call was placed" and "when a voice call was hanged up or disconnected". Are there any API's or events/triggers that can give me this information.
The current SDK doesn't offer this capability - generally, you cannot keep track of user activity (like calls) outside the application due to a sandboxed environment that by default doesn't offer any system process hooks.
While you can't get any information about a specific phone call, if your application is running you can be informed when a call is received (and ended) by using the Obscured and Unobsured events on the page.
Please note that this will be triggered when ANY piece of UI chrome covers the page. In addition to incoming call notifications, this will also include incoming SMS notifications, alarms, etc.
These event are an important part of the application lifecycle for some types of apps (typically games) but are often overlooked.