When we start a exercise in Apple Watch and open another app, when we put the wrist down the watch will automatically switch to the fitness app.
It has some exceptions, for example, if you open the stopwatch and start a chronograph, when getting the wrist down it will keep the stopwatch in foreground.
But how do I set my app the "importance" to be over fitness (I'm developing a workout chronograph for my own use)?
Everything is already working, just this part that is not.
The app is native for Apple Watch using SwiftUI.
Related
A couple years ago, I had to implement touch features in an application, but my company was still using Scientific Linux 6.4, which did not natively support touch, not to mention multi-touch. Fortunately, I was able to upgrade the kernel to 2.6.32-754, which gave me access to multi-touch events, and while they were not natively handled, I was able to write my own "driver" in the application that would read the /dev/input/event file and use the input_event class in the kernel to capture touch events and translate them to application behavior.
Now, two years later, we're finally moving on to RedHat 8, and obviously there's now native touch support. Pretty much all my code is still required as it's highly specific to this application, and I don't see much point in re-writing anything. However, because touch events are now natively recognized, I'm seeing some issues where touch press events will be registered twice -- once from the OS, and once from my driver. The touch press events from my driver are required because they're being tracked and handled by my driver.
Is there a way I can update my driver to ignore the OS native touch events that are interfering with my driver without affecting my driver's operation? This is especially prevalent with the on-screen keyboard which is causing it to type the same character twice when the button is pressed.
The simple answer to this problem seemed to be to use xinput to disable the touchscreen device input, which gave me the behavior I wanted. The reason I don't want to re-write the code handling it is because it would be a lot of effort and time for no difference in behavior or performance. I can't just use the native touch because the UI doesn't just use single touch actions, it uses custom gestures that are interpreted by my driver.
I developed a command-line program that connects to a BLE device (a motion sensor), subscribes to motion notifications, then prints the coordinates to stdout around 60 times per second. The data is consumed by a legacy Adobe AIR desktop application (which handles running of my "driver" program).
I have used Microsoft's Bluetooth Low Energy code samples as a reference.
I've found the following in one of the code samples:
// BT_Code: BluetoothLEDevice.FromIdAsync must be called from a UI thread because it may prompt for consent.
bluetoothLeDevice = co_await BluetoothLEDevice::FromIdAsync(SampleState::SelectedBleDeviceId);
Those samples are UWP apps, but my program is C++/WinRT console program, and naturally has no UI thread. So I am guessing that in case of consent prompt it will just fail.
I've finished writing the program and it's working, but this comment got me worried about some situation where this consent prompt topic will become an issue. Or perhaps it can work now, and break with some future Windows update if they introduce more widespread consent dialogs.
So far I found that pairing a device requires consent (link). My device doesn't require pairing.
I would like to know if there's a well-defined list of cases when a Bluetooth LE consent prompt might be required?
I have numerous ESP8266 / ESP32 / STM32 IOT devices, running my own firmware. One of the functions is a uPNP/SSDP provider which allows remote control from Amazon Echo devices and/or anything that can "speak" SSDP. I managed to find enough info to get these devices automatically added to the Windows network "Home Automation" view by tweaking the registry:
My next step is to have what I think is a "context menu handler" so I can right-click the relevant device and have on/off/toggle options that then send the relevant SOAP envelop to the device to switch on etc. I'd also like to either change the icon (or add an overlay) in-flight to show the on/off state of the device, but that is icing on the cake.
I am having having serious difficulty finding an example C++ framework I can cut and paste to start me off that is relevant, accurate and modern. Every example I find is either for an explorer file menu, or in C#, or literally decades out of date: no doubt much is similar but it is "hooking" the thing in to the Network Pane of Windows 10 that I simply can't find how to do. Even on the MS developer site the information talks mostly about Vista and even XP(!) and is generally quite incomprehensible. The clearest site I could find (dated 2018) recommended a book on Windows Shell programming that was published in...wait for it...1998!
I know I'm going to have to build a DLL - I'm fine with that, I just need a good "leg-up".
"NetworkExplorerPlugins" brings up precisely 0 hits here.
I have been searching unsuccessfully for weeks - can anybody point me to a recent Windows 10-specific C++ example or tutorial that will get me started?
I have a member of my household who appears to be trying to get in to my PC while I'm asleep. I've decided to write a service which will load at startup, and will use the built-in camera to take a few snapshots of the culprit as soon as the login screen is displayed. Is this possible in Windows 8.1 and VS 2013? I tried using spy++ (with the "Always On Top" option) and then locking my computer to see if I could get more info, but as you'd imagine, the login screen stays top-most. I can't find a whole lot on MSDN about the lock/login-screen, either. Does anybody here have some info I could use?
I have a lengthy number-crunching process which takes advantage of quite abit of OpenGL off-screen rendering. It all works well but when I leave it to work on its own while I go make a sandwich I would usually find that it crashed while I was away.
I was able to determine that the crash occurs very close to the moment The laptop I'm using decides to turn off the screen to conserve energy. The crash itself is well inside the NVIDIA dlls so there is no hope to know what's going on.
The obvious solution is to turn off the power management feature that turns the screen and video card off but I'm looking for something more user friendly.
Is there a way to do this programatically?
I know there's a SETI#home implementation which takes advantage of GPU processing. How does it keep the video card from going to sleep?
I'm not sure what OS you're on, but windows sends a message that it is about to enter a new power state. You can listen for that and then either start processing on the CPU or deny the request to enter a lower-power state.
For the benefit of Linux users encountering a similar issue, I thought I'd add that, you can obtain similar notifications and inhibit power state changes using the DBUS API. An example script in Python, taken from the link, to inhibit power state change:
#!/usr/bin/python
import dbus
import time
bus = dbus.Bus(dbus.Bus.TYPE_SESSION)
devobj = bus.get_object('org.freedesktop.PowerManagement',
'/org/freedesktop/PowerManagement')
dev = dbus.Interface (devobj, "org.freedesktop.PowerManagement.Inhibit")
cookie = dev.Inhibit('Nautilus', 'Copying files from /media/SANVOL')
time.sleep(10)
dev.UnInhibit(cookie)
According to MSDN, there is an API that allows an application to tell Windows that it is still working and that Windows should not go to sleep or turn off the display.
The function is called SetThreadExecutionState (MSDN). It works for me, using the flags ES_SYSTEM_REQUIRED and ES_CONTINUOUS.
Note, however, that using this function does not stop the screen saver from running, which might interfere with your OpenGL app if the screen saver also uses OpenGL (oder Direct3D).