I've the following situation using bluetooth:
There several bluetooth devices which we can connect to.
First time we load the fragment in which we control the device connection any attempt of connection is done to the indicated bluetooth device.
But if we navigateup from the fragment with findNaController().navigateUp() then the following error (among others, which I've managed to bypass by several hacks, happen), happens once the fragment is loaded again (despite being in theory completely created as if it were the first time, as in debug mode I've checked that goes through onCreateView method again).
No matter what bluetooth device we order it to connect to, despite having checked that the data that it's told to use to connect to the bluetooth device is the one it should be for that bluetooth device, it always connects to the last bluetooth device which was connected before the up navigation.
What could be causing this faulty behavior?
PD: I've only checked this to happen in device with API 23, not sure about others.
Related
I have to find if the device where my application run, has the Wi-Fi enable or if the device is in hotspot mode, else I want to display an error message.
To detect if I am connected to Wi-Fi, I'm using #react-native-community/netinfo, but I can't find anything about the hotspot for react native.
The only things I want are to know if the hotspot is enabled on my device (and, if possible, if there are devices connected to this hotspot).
Thank you for your help.
I build an iOS Bluetooth Enable app which connects to the external device and after connecting it pairs with the device. Now, I want to check if the user already paired the device so that i will not show the pair alert message next time?
Unfortunately, you can't, there is no means in the Core Bluetooth API to check pairedness. The pairing dialog is shown by iOS when needed.
I am trying to communicate to my embedded(set-top box) device through this(http://numato.com/8-channel-usb-gpio-module) GPIO. Previously, when i attached this device to my set top box, then in dmesg, it is showing only that new usb device has been attached and by some hook/crook method, i manually created a node with major minor number of recently attached usb device and through my cross compiled c program, i tried to send gpio commands, which throws me the errors of invalid commands. After some more research, i get to know that on my set top box kernel, ACM CDC support is disabled. so i compiled the kernel again with CDC ACM support enabled and USB serial convertor support enabled. after flashing the kernel on BOX, now when i attached the device, in dmesg, it is showing that device is attached, New ACM device detected on ttyACM0, but no node is created in /dev, instead i found the device info in /sys/class/tty/ttyACM0. from here, i get the major and minor number of my device and manually created a node. after that i tried to communicate again, but now, instead of saying invalid command, my program is stuck on the first GPIO command and it is not executing any GPIO commands, but giving me the output of all the printf statements at application layer. please help.
Thanks in advance
I'm developing an app which relies on C2DM to be notified of some new data to be fetched from a REST service. I have successfully implemented the C2DM android feature, but the behavior over Wifi is different from the connection over 3G. The messages are received instantly over 3G, but I have to manually turn Wifi off and on to have a "grace period" of ~1 min in which I receive them instantly.
My question is: Is there any way I can programmatically restart the connection, or trigger the notification fetch?
EDIT:
I've implemented an AsyncTask that periodically "reassociates" the connection to the access point (using WifiManager.reassociate()) every minute and a half. Not so sure about the correctness of this solution, though.
I've seen similar issues. It seems that under some circumstances C2DM messages are not delivered over wifi connections, when they are over 3G. On a related note I've also seen Android devices "drop" the push connection, so messages are not delivered (in my case the solution can be to put the device in airplane mode and then turn the network back on).
This reinforces the fact that all applications that use C2DM should be built so that even if push messaging fails, the app still works (even if messages/updates are slower because there's occasional polling to the server)
I wouldn't personally want to mess with the wifi connection as that's something that may cause problems for the user.
I have 2 iOS devices and an application which starts or connects to a NSNetService.
When both devices have have bluetooth turned on the data stream will automatically be done over the bluetooth interface.
I do not want that, i want both devices to communicate over the WiFi. Is there a way to force a NSNetService to communicate over the WiFi?
Thanks
I don't think there is, I haven't looked into the docs, but I know a ton of games recommend disabling Bluetooth and ensuring WiFi is enabled for local multiplayer.