I am attempting to write a small helper app for macOS that captures the input of a Nimbus Steel Series game controller and converts it to keyboard and mouse events for another application (a game that does not support controllers).
In my first attempt I used GCController but as soon as the app becomes inactive no more events are received from the controller. There seems to be no way to change this.
In my second attempt I used CBCentralManager to discover the controller, hoping I could work with it using standard Bluetooth services. But the controller does not even show up in a scan, either with the controller being connected or disconnected. I find devices around the house (iPads, iPhones, smart tv's, computers), but no peripheral that identifies itself as Nimbus. However, there are a couple nil peripherals which I suppose are auxiliary peripherals from Apple devices such as the Magic Mouse or the Wireless Keyboard.
In my third attempt I tried to make the main window an NSPanel in HUD style. The panel stays afloat but it still becomes inactive when I click elsewhere. No controller events received. I thought maybe I could show the panel above the fullscreen game in a corner somehow. But it still needs to be active to get GCController events, then the game would not get events.
Are there any other options to receive game controller inputs which the app is inactive?
Would it work via IOKit? I have been hesitant to use IOKit so far because I was hoping to resolve this issue without it, being a very lowlevel API.
I solved this problem using the IOHIDManager functions. The callbacks receive events even if the app is not active.
Related
Since the latest update (I think some time in December 2022), the built-in camera app on my Samsung Galaxy S21 asks for "Nearby devices" permission, and refuses to run if I don't grant it. By "Nearby devices" it means "Bluetooth". I don't know why it calls the permission
"Nearby devices": all other references to Bluetooth call it "Bluetooth",
and you can also access a nearby device using Wi-Fi or even NFC if the device
is close enough.
It doesn't actually need Bluetooth to take photographs, or even to record movies,
but you might have a Bluetooth microphone (I don't) and you might want to use
it to get better sound quality when recording a movie.
Of course the Android best practice advice at
https://developer.android.com/guide/topics/permissions/overview
is not to ask for runtime permissions unless and until you need them,
but Samsung aren't doing that.
I don't want the camera app to announce my presence by probing the Bluetooth headset of
anyone who happens to be near me, and they might regard such an action as intrusive.
So I don't want to give the camera app its nearby devices permission, but it won't
run at all without it.
So how do I get the camera app to run without accessing Bluetooth?
I found some workarounds for this. If your device supports it, you can download Expert Raw from the Galaxy Store. This will take still photos without requiring "Nearby devices" permission. However it doesn't seem to be able to do selfies because there seems to be no way to switch cameras, and it can't do movies or many of the extra tricks that the full camera app can do.
Another option is to run the camera app with Bluetooth disabled. Then it can have its "Nearby devices" permission, but it can't use it. The problem with this is that if you use Bluetooth at other times you have to remember to disable it and enable it.
So I wrote a tiny app which disables Bluetooth, runs the camera app, and restores the previous enabled or disabled state of Bluetooth when the camera app exits. I put this on my home screen instead of the camera app: it has the same icon. You have to remember to exit properly from the camera app using the Back button: the Home or Recents buttons leave my app and the camera app sitting on the task's back stack, so my app doesn't get to run and restore the Bluetooth state.
The app is available on github here in case anyone else wants to use this solution.
I have an app that streams live audio and it will connect and play through the chromecast with no errors (play and connect). So now I am trying to figure out how to play through the chromecast if the user connects first before playing the audio. Per the UI guidelines you have to display a cast button on all activities. So my app has a main activity with 2 play buttons for different stations and also the cast button and then has another activity for when the station is playing after you select which station you want to play (ie the ip address gets selected depending on which button you choose). In this activity's onRouteSelected() I am then switching to the chromecast and stopping local playback on the device.
My questions is how do I call the onRouteSelected() to get the chromecast going if the chromecast has already been connected in the previous activity?? I have looked at the sample apps and cannot figure out how to do this.
Take a look at the CastVideos-android sample project that uses the CastCompanionLibrary to maintain state and manage most of the cast related job. You can either use the library or see how things are done there if you want to do it yourself.
If you are already connected to a chromecast device, you are not going to get a new call to onRouteSelected() so you need to maintain the state of connectivity across your activities (say, in a singleton or in your Application), that is what CastCompanionLibrary does.
I'm working on a Control Extension for Sony SmartWatch 2 that needs to update a TextView every second on the SW2 Display.
It happens that if I've my Smartphone connected via USB or when USB disconnected if I've my Smartphone screen active, the Control Extension works as expected on SmartWatch 2.
But soon my SmartPhone screen idles, the control extension stops the regular TextView updates. First starts breaking and eventually get stuck. The Extension is not closed by the Host Application and the SW2 continues well paired with the Smartphone. In fact if I touch the display, the Extension appears to recover state for some moments with a few TextView updates, but rapidly breaks and get stuck again.
Meanwhile, if I turn ON my Smartphone screen, the control extension recovers the state and resume the normal TextView updates.
It seems that when the smartphone idles it stops to send the regular bluetooth messages to the SW2. I've tried many solutions to avoid this behaviour, even set the keepRunningWhenConnected to true. But the behaviour is allways the same.
Is anyone also having this problem or have a clue for the solution?
Thanks :)
What model of phone are you using?
If it is indeed that the bluetooth connection is not persisting then you could try the following possible solutions:
Is there a setting on the phone to keep bluetooth on even when going into idle?
You could set the phone to not go into idle while your app is running, of course this is not ideal as it will cause battery drain.
Ok. After testing and testing several solutions (AlarmManager, BluetoothAdapter, etc...) I came to following conclusion:
Its not the Bluetooth connection that is lost, otherwise the SmartWatch 2 would lost connection with the Smartphone, and that never happens. In fact is the Phone CPU that is lost by the ControlExtension, because when the Smartphone idles the CPU also idles. By loosing the Phone CPU the ControlExtension cannot process the "sendText(...)" call and this means that the corresponding upper call "sendHostApp(...)" that uses the Bluetooth messages its also never called, that's why the TextView is not updated on the SmartWatch 2.
Also I think that when I touch the SmartWatch 2 screen, this triggers an hardware interruption that wake up the Phone CPU for short seconds to answer to the SmartWatch 2 Touch Event and thats why when I touch the SW2 screen the TextView is updated a few times before get stuck again.
This works fine for static Control Extension applications that only display static content and/or replies to the user (touch, swipe, etc...) events. But its a complete disaster for Control Extensions applications that need to be doing some processing regardless the user direct interaction.
I never though in this terms because I though that it was the job of the SmartConnect Host Application to guarantee Phone CPU to the Control Extensions.
So the solution for some apps could be using an AlartManager in order to schedule wake up calls to do some processing. For other apps the solution could be the PowerManger and use a wakelock.aquire()/wakelock.release().
I am trying to find a clever way to keep a BLE app active in the background on iOS 6, without breaking any of Apple's rules. I plan to use the phone as a peripheral device and another BLE circuit as the central. My app will automatically be opened when a user arrives to a building using geofencing. After that the iPhone will connect to the first BLE central device it sees (the device will be in its white list). The user will then be able to move throughout the building switching to different BLE "nodes".
My question is: What do I need to do in the background when a user is stationary at their desk so that the app does not get suspended due to memory resources?
My idea is based on this solution for a separate problem: There could potentially (not regularly) be 10-50 users in an area with only a few BLE "nodes" and I read at bluetooth.org that I could setup a dynamic connection system, basically rotating connections through all the users.
My idea is to setup a similar dynamic system where the central device (not the iPhone) disconnects the device on regular intervals (30-40 minutes) and then the iPhone will reconnect.
Is this something that some feasible? Is this against the iOS development guidelines? I was unable to find anything explicit about this. I have also asked on the iOS developer forum, but unfortunately it is not as popular as this site.
Thanks in advance!
Xcode -> Project target -> Capabilities -> Enable background mode
Check Uses Bluetooth LE Accessories
Capabilities
Also enable the following key in .plist file
Required background modes
App communicates using CoreBluetooth
Plist
I want to be able to pair Microsoft PixelSense hardware with multiple mobile devices via bluetooth and I want PixelSense to know which device is which. So if I place two phones on a table, PixelSense should be able to label them by device name. My initial thought was to have the phone display an Identity Tag that has encoded its Bluetooth MAC address so that it could associate them but PixelSense sees in infrared and can't read the phone screen so that idea is out. Can anyone think of another way to do this?
Microsoft has demonstrated a way to do this in their Mobile Connect sample application. They've ingeniously used the fact that almost all phones have a camera that faces down when the phone is placed on a flat surface. So they created an app that will read incoming color data from Surface while the phone is sitting on it.
So it goes like this:
The Surface app starts and makes the Surface computer itself visible on bluetooth (although you may have to do this manually in admin mode, can't remember)
you run the mobile app on your phone, click connect, and place it on the Surface at a designated spot
the Surface flashes a serious of colors into the phone's camera
the phone decodes those colors into a pin and scans through all the open bluetooth devices it can see until it finds one that is a desktop running the appropriate service and accepts the decoded pin.
Now the two are connected with no need for manual input and the Surface knows which physical device it's talking to because it knows which pin it displayed to each device.
*Note - They don't actually allow multiple simultaneous connections in this sample app, but I see no reason why it wouldn't work.
One issue with this approach (other than being pretty complicated to code), is the need for the app on the phone. One way to make it easier for people to get the app is to display a Microsoft Tag or qrcode on the Surface for people to scan (they're much more likely to have a scanning app already). I don't think there's any getting around the need to have something installed on the phone if you're using bluetooth anyway.